Introducing Agile Into the Workforce with a few simple steps.

Problem

"I have introduced Agile, and more specifically Scrum, to several different organizations. The first challenge that I face with this transition is identifying where Agile will have an impact. In most cases, the teams I've joined in the past have had very lax approaches to development. They see what they can check off an ever growing, unprioritized list of projects. This is what is also known as 'throwing spaghetti against the wall to see what sticks'. This approach is problematic for a few reasons. One, it is not great for morale. The teams do not feel like they're making progress against their overall goals. It also lacks direction, developers will gravitate towards what they know, not what is the highest priority. Finally, there is no way to predict a time frame for what can be accomplished in the future. Knowing the impact Agile can have to address all of these issues, I have developed a modest method for effectively introducing the framework into the workforce. Once you show the immediate impact you can more fully train the team on additional aspects of Agile/Scrum, but this will get your foot in the door."

Actions taken

"What I have done in each case is set measurable and achievable goals early on. Don't go for the moon shot! I set one objective for the first quarter: to get an understanding for how much work the team can get done. To understand team capacity we need to have a way of measuring the actual work. We do this with Story Points. Story points reflect effort that is not linked to time. I explain that measurements will not be based on individual capacity but based on overall effort. Plenty of tutorials exist online to help with the pointint process. One tried and true method is to pick a baseline story, something that every person can agree on, something simple, and set that up as a 3 point story. Story points are a modified Fibonacci sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, etc. Apply story points to new stories relative to that baseline story. Is this story twice as much effort? It's an 8. Is it half? It's either a 2 or a 1. The estimations don't have to be perfect, just close. I warn the team that the first couple of sprints would be a leap of faith but from then on good things would happen, we'd begin to stabilize our estimations and arrive at an overall on a team velocity, the sum of all points we complete during a sprint.

Now that you have an overall understanding of the work that happens over the course of each Sprint, the team's capacity, estimate the work for subsequent sprints and try to keep within the team's historical velocity for the amount of future work you allocated. In the following quarter, we prioritize the work that needs to get done. Not everything is 'hair on fire P0'! The team should work closely with their product manager to prioritize the backlog of work based on the team's velocity. You'll be surprised that some priorities may change based on how big the work is estimated to be for some projects. Would you rather spend all of the team's time on one P0 project or get 5 P1s done?"

Lessons learned

• "Knowing a team's historical velocity for a sprint will help you prioritize what fits into the next sprint. Don't take in more than what the team can get done!"
• "Focus on what teams can accomplish in a quarter's time frame and evaluate from there the cut line for subsequent quarters. For example, if a team can realistically get done 400 points of work during the quarter, when they have estimated beyond that limit for the next quarter's work, stop there. Focus on those work items and do them well."
• "After a couple of quarters of this process the team begins to trust their own estimations. They develop into teams that consistently deliver what they sign up to do. Leadership can count on them to successfully execute against the plan."
• "Bottoms up estimation empowers teams, improves the quality of the work, boosts morale and builds trust within the organization."
• "When you have solid results executing on a few tenants of the Agile framework, teams are more receptive to adopting the framework more completely."