Agile is a great way of building software, but it can take some getting used to. You may be wanting to dip your toes in to see what it’s like, but not want to change your process all at once. Unfortunately, it can be difficult to know what to try first. Not just that, if your customer hasn’t tried Agile before, then they may not understand why it’s worth it.
In this post you’ll get a outline of some first steps you can take, and what to expect when you try them out. I’ve tried to pick steps to try as a team which don’t require huge buy-in from the client. You can start by trying a single one, but you will certainly benefit from combining a few together. If the client can see how effective your team becomes by working in a more Agile way, it will be much easier to convince them to fully commit to Agile delivery. This is in no way a complete resource, but I’m hoping it will give you a bit of an idea on the techniques you want to try as a starting point. The advice I’m providing is coming from a service company perspective, but I’m hoping this post will be of use for anyone wanting to upgrade their teams delivery model.
A visual board is where you track what state the work is in. It helps the team focus on getting work finished, and minimizes the amount of work in progress. A basic visual board has 3 columns, “to do”, “doing”, and “done”, but can be extended with more detailed columns if you find the basic format lacking. With a visual board, the work becomes less about the individuals, “what I have to do to finish this task”, and more about the team, “what can the team do to get this work finished”. If you aren’t sure how to start your board, try and get the help of a scrum master, or check out this useful guide for getting started. I’d recommend starting with a physical board, because it’s easier for the team to use during their stand ups, and is easier to change as you work out what columns work best for the team.
Daily stand ups are short meetings where team members come together to share what they worked on yesterday, and what they will be working on today. The main benefit of the stand up is that you keep the team in sync without relying on email. It also provides a time for team members to talk about issues blocking their progress. Stand ups don’t require the stakeholders, but having them there will save you from a lot of email communication.
Focusing on the MVP is a perfect way to avoid waste. If you are unfamiliar with the concept of the Minimum Valuable Product, I’ve found a great Quora discussion which explains it. A rough idea is that the team builds the basic version of the all the key features, before starting to build any “nice to haves”. Think of it being a bit like the “free” tier version of the final product, good enough to get by, but with a few rough edges. It can be tricky to work out what these key features are, but if the team has a chance to build like this, then the project will be in a much better place if you ever find that you are running out of budget.
Sitting together will make the team feel much more cohesive. When there is a bug, the tester doesn’t have to walk across the room or send an email, they just tap the developer on the shoulder and let them know. This is one of the easier changes you can make, because it just requires that the team be willing to try it. Personally I’ve found I work a lot more successfully when I’m sitting near my team mates, you will also find that some good Agile practices, such as peer programming, will start happening naturally.
Retrospectives are a meeting where the team has a chance to reflect on what went well, what they struggled with, and decide on actions to fix issues the team are facing. No team is ever going to be perfect, but you can use the retrospective to make sure you are always improving. Retrospectives are most effective when the team feels comfortable that they can give their feedback without backlash, so all participants in the meeting need to have an open mind. Following through on retrospectives can also be difficult, each action should have a team member who will fulfill it before the next retrospective. I would recommend having someone experienced run your first retrospective, but if you don’t have someone who can help, then have the team read through some “first retro” resources so that you are all on the same page.
Reviews are well worth it if you can convince the stakeholders to attend. Every few weeks, a member of the team shows the functionality they have completed since the last review. This is a chance for the stakeholder to see what the team has been doing, and give feedback on any adjustments they would like to have made. Reviews help the team know that they are building the right thing, as the client has had multiple chances to review the functionality as it has been built. If the team feels comfortable, the review is a chance for the stakeholders to try the functionality out themselves.
Giving the stakeholders a chance to try the functionality does not have to be limited to the review, but it’s a good opportunity to get them used to the concept of trying out the functionality early. If you find they are enjoying the reviews, you can take it a step further and get stakeholders trying out features as the team completes them. I’ve found the best time to push for this is when a project is nearing a release, because this is when the cost of getting something wrong is most clear.
What’s next?
If you’ve found some success in these techniques, now may be the time to start looking into fully committing to a battle tested Agile framework such as Scrum or Kanban. There is a multitude of material online for each of these frameworks, and I’d recommend getting an experienced Agile coach to help your team get started.
For those of you with an interest in learning more about Agile in a casual way, check out the podcast, “This Agile Life”. They have some great episodes around topics like the current state of Agile, and being thankful for Agile.
I hope this post has been useful to you! Feel free to leave a comment if you need clarification on anything, or to suggest any techniques you have found helpful.