Agile: Simple But Not Easy (?!?!?)

 

It is often said about Agile and Scrum: It’s simple, but it’s not easy. Hogwash! Certainly it’s not easy. Teams everywhere will report that they are not good at agile at first, even experiencing a loss in productivity when starting out. It’s also not simple. Scrum advocates like to tout that the Scrum Guide is merely 13 pages long, but within those 13 pages are dozens of rules, covering ceremonies, roles and artifacts. SAFe is so unsimple that the train-the-trainer guidebook is roughly the size of Mozart’s Complete Piano Sonatas.

This state of affairs can be discouraging. Indeed, while thinking that agile is simple, teams become quickly overwhelmed with all of the things they need to deal with at the start. So, let’s narrow things down a bit. Here are five big things to keep in mind about agile.

1. Work on the most important things first
   “There is no value in squandering precious resources creating crap that nobody cares about. Value is not in producing more things. Value is in producing worthy things.” ¹ If you’re anything like most of the teams I’ve talked to and worked with, your team probably has more work in its backlog than can reasonably be expected to tackle without violating the laws of time and space. Accept the fact that you can’t work on (much less complete) everything. Accept the fact that most of the stuff in your backlog is useless and will likely deliver no value. Find a way to prioritize the work, by whatever criteria you establish, so that you first work on the things that will add the most value now.
   
   
2. Limit work in process (WIP)
   As agilist Uncle Bob Martin once said, “the nightmare scenario is to get to the end of the iteration with 90% of the tasks complete, but no stories complete.” ² The game is about delivering value, not just being industrious. And you can’t deliver value unless you finish what you start. And you can’t finish what you start if you work on too many things at once. Many agile and Kanban teams set a limit for how many stories each person can work on at once. This practice is called limiting work in process (WIP).  A common WIP limit is 2. Yes, that seems like a ridiculously low amount of work items, but research has shown it to be ideal.
   
   
3. Frequently deliver in small increments.
   The power of agile is expressed in (among others) the first of the Principles Behind the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Rather than taking 6 months or a year producing your output without getting feedback, find a way to develop and deliver products in small, more frequent deliveries. This way, you can get feedback from your customer and adjust accordingly. Remember, on that day when you create a huge project plan that covers many months of work, you know less about the work and how your customer will receive it than you will at any point after.
   
   
4. Make it a team sport
   Many organizations starting off in agile start using the terminology, having the meetings, and putting work in an agile planning tool without really changing the way that they work. This is called being “Agile in Name Only (AINO).” A common symptom is having people work alone on the same work they worked on before becoming AINO. Then the larger organization reinforces these patterns by evaluating and reward performance as individuals. Agile is team-oriented, and agilists believe that the best results come from working as a cross-functional team.

5. Continuously improve
   Regular cycles of inspecting and adapting work output and team collaboration are essential. Scrum teams typically conduct a retrospective meeting every two weeks, and make commitments to improve something in the way they work every time. It should be obvious that discussing team health fortnightly rather than annually will yield better performance.

If you want to simplify agile, keep these things Five Big Things in mind at the beginning of your journey, and your team will avoid many of the pitfalls that discourage teams and make them give up trying to be agile.

Please add comments below or tweet them to be @TheBobWinter.

References

¹Winter, Bob. Agile Performance Improvement, Islandia, NY: Apress, 2015, page 210

²Martin, Robert C. Agile Software Development: Principles, Patterns, and Practices. Upper Saddle River, NJ: Prentice Hall, 2003. Page 22. I