This is a long one, so stick with me . . .
Here is a quick, step-by-step guide of how to start implementing Agile.
Step 1 – Choose a Product Owner
The product owner is the one with the vision of what we’re going to do, make, or accomplish. They take into account the risks, rewards, what is possible, what can be done, and what they are passionate about. They are the experts in the field and know the most about what the best version of the product can look like.
Step 2 – Choose a Team
The team is composed of the people who will actually be doing the work. This team needs to have all the skills needed to take the product owners vision and make it a reality. The team should be small. 3-8 people is plenty. More than 8 and your communication channels get a little crazy.
Step 3 – Choose a Scrum Master
This is the person who will coach the rest of the team through the Scrum framework, and help the team eliminate anything that’s slowing them down. This is the bulldog who blocks and tackles, blasts through roadblocks, and whose main focus is what the team is focusing on.
Step 4 – Create and Prioritize a Product Backlog
This is a list, at a high level, of everything that needs to be done to make that vision a reality. This backlog exists and evolves over the lifetime of the product. It is the product roadmap. At any moment in time, this is the single, definitive view of everything that can be done by the team, ever. It’s in order of priority. Only 1 exists. This means the product owner is required to make prioritization decisions across the entire project spectrum. The product owner should consult with all stakeholders and the team, to make sure they’re representing both 1) what people want and 2) what can be built. When you’re just starting out, I recommend doing this at the 30,000 ft level. Getting too specific will create more work later on if you’re going for speed.
Step 5 – Refine and Estimate the Product Backlog
It’s crucial that the people who are actually going to complete the items in the product backlog estimate how long they will take. The team should look at each Backlog item and see if it is actually do-able. Is there enough information to complete the item? Is it small enough to estimate? Is there a definition of “done?” (Done = Everyone agrees on what standards must be met to call something “done.”) Does it create visible value? Each item should be shown, demonstrated and will be potentially shippable. Do not estimate in hours or any unit of time. People are terrible at this. Estimate by relative “size” instead. I usually use T-Shirt sizes to start (Sm., Med., Lg.). Later you might use something more quantitative, like the Fibonacci sequence.
Step 6 – Sprint Planning
First, meet between the Team, Scrum Master, and the Product Owner to plan the Sprint. (Sprints = fixed length of time that is less than a month.) If you’re just starting out, you may want to consider having a sprint = 1 week. This will help you get iterating through the process faster. You can always change your sprint length and normalize your output data later. During Sprint Planning, the Team looks at the top of the Backlog and forecasts how much of it they can complete in this sprint. If the team has been going for a few Sprints, they should take into account the number of points they did in the last Sprint (the team’s Velocity). The Scrum Master and the Team should be trying to increase that number every Sprint. This is another chance for the Team and the Product Owner to make sure everyone understands how these items are going to fulfill the vision. Also during this meeting, everyone should agree on a Sprint Goal. (Sprint Goal = What everyone wants to accomplish with this Sprint). One of the pillars of Scrum is that once the team has committed to what they think they can finish in one Sprint, that’s it. It cannot be changed, it cannot be added to. The team must be able to work autonomously throughout the Sprint to complete what they forecasted they could.
Step 7 – Make work visible
The most common way to do this is to create a Scrum Board with three columns. To-Do, Doing, Completed.
Create a Burndown Chart. Every day, the Scrum Master tallies up the number of points completed and graphs them on the Burndown Chart. Ideally, there will be a steep, downward slope, leading to zero points left on the last day of the Sprint.
Step 8 – Daily Standup
This is the heartbeat of Scrum. Each day, for no more than 15 minutes, the team and the Scrum Master meet and answer 3 questions: 1) What did I do yesterday to help the Team finish the Sprint? 2) What will I do today to help the Team finish the Sprint? And 3) Is there anything impeding you from helping the Team finish the Sprint? If this takes more than 15 minutes, you’re doing it wrong.
What this does is help the whole team know where everything is in the Sprint. Are all the tasks going to be completed on time? Are there opportunities to help other team members overcome obstacles? There’s no assigning of tasks from above. The team is autonomous, they do that. There’s no detailed reporting to management. The Scrum Master is responsible for making the obstacles to the team’s progress go away.
Step 9 – Sprint Demo
This is the meeting where the Team shows what they’ve accomplished during the Sprint. Anyone can come; not only the Product Owner, the Scrum Master and the Team, but also stakeholders, management, and customers. This is an open meeting what they were able to move to “done” during the Sprint. The Team should only demo what meets the definition of done (what is completely finished and can be delivered without any more work). It may not be a completed product, but it should be a completed feature or two.
Step 10 – Sprint Retrospective
After the Team has shown what they’ve accomplished during the last Sprint, that thing that is “done,” and can be potentially shipped to customers for feedback, they sit down and think about what went wrong, what went right, and what could be made better in the next Sprint. What is the improvement that they, as a team, can implement right away? To be effective, this meeting requires a certain amount of emotional maturity and an atmosphere of trust. The key thing to remember is that you’re not seeking someone to blame, you’re looking at the process. Why did that happen that way? Why did we miss that? What could make us faster? It is crucial that people, as a team, take responsibility for the process and outcomes, and seek solutions. At the same time, people have to have the fortitude to bring up the issues that are really bothering them in a way that is solution oriented rather than accusatory. The rest of the team has to have the maturity to hear the feedback, take it in, and look for a solution–rather than getting defensive.
By the end of the meeting, the Team and the Scrum Master should agree on one process improvement that they will implement in the next Sprint. That process improvement (the principle of Kaizen) should be put into the next Sprint’s Backlog with acceptance tests. That way, the team can easily see if they actually implemented the improvement and what effect it had on velocity.
Step 11 – Rinse and Repeat
Immediately start the next Sprint Cycle, while taking the team’s experience with Sprints and product improvements into account.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Those are your 11 steps to start your project on the right path with Agile. Hope this was useful.
2 Minute Action:
How can you get started right now?
I bet you can do step 1 in under 2 minutes.
Pull the trigger by reaching out to this person and letting them know the role you’ll need them to play in your project.