Elevate Spring Summit has been announced (Thu, Mar 11th)

🔥


Don't have an account? 

Introducing Agile Into the Workforce with a few simple steps.

Productivity
Agile / Scrum

17 April, 2019

Kathryn Koehler shares her simple yet effective approach for introducing the Agile development framework into several different organizations.

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.

Related stories

Are We Solving the “Right Problems”?
13 November

Michael Vanhoutte, Chief Architect at Aprimo, discusses why it is important to establish that a problem you are trying to solve is the right one and how the engineering obsession with ‘fixing the problems’ can lead us astray.

Impact
Productivity
Prioritization
Michael Vanhoutte

Michael Vanhoutte

SVP Engineering at Ontoforce

From a Dysfunctional Group to a High Performing Team
28 October

Narbeh Mirzaei, Associate Director of Engineering at HelloFresh, recalls how he transformed a dysfunctional group of siloed individuals into a high performing team.

High Performers
Productivity
Team processes
Narbeh Mirzaei

Narbeh Mirzaei

Director of Engineering at HelloFresh

Why AB Testing Is Good for Your Company Culture
28 October

Graham McNicoll, CEO of Growth Book and former VP of Product and Engineering at Education.com, recalls how he introduced data-driven decision-making and AB testing to drive growth, and the unexpected effects it had on development speed, team alignment, intellectual humility, and collaboration.

Managing Expectations
Collaboration
Team processes
Agile / Scrum
Graham McNicoll

Graham McNicoll

VP Product and Engineering at Education.com

Introducing Processes for Continuous Improvement
30 September

Peter Berg, Founder and CTO at Forward, recounts how he introduced processes for continuous improvement and thus creating a more psychologically safe working environment.

Impact
Productivity
Coaching / Training / Mentorship
Peter Berg

Peter Berg

Founder / CTO at Forward

The Quick Fix to a Slow Team: A Consultant’s Perspective
30 September

Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.

Delegate
Productivity
Team processes
Agile / Scrum
Peter Berg

Peter Berg

Founder / CTO at Forward

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.