Three Ways How Scrum Unravels Complexity

Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people interfacing with the themes. If you aren't following me, then here is what you might have missed this month:

• Overproduction in Software Development
• The Cult of Done Manifesto
• Is Continuous Integration & Deployment Non-Optional?
• Cyberpunk 2077: The Agile Redemption Arc

Scrum shines when applied to product development in complex environments. Complicated systems, emergence, unknowns - these are some of the manifestations of complexity. Complexity in a business environment imposes risk on the venture and oftentimes the ways we try to mitigate these risks can be counterproductive. How is an elaborate long-term plan going to help with new findings popping up on a daily basis?

Instead, we use scrum. We create transparency, we inspect and we adapt. The more we understand about the product and our development process, the better we can change our system to incorporate our learnings and be more effective. That’s how the agile manifesto came into existence, by the way. Professionals uncovering better ways of developing software by doing it and learning about the aspects of their complex environment. It’s in the first sentence of the manifesto.

Let’s stop pretending we can foresee the future. Instead, you solve complex problems by formulating a short-term plan, executing that plan, inspecting the results and then adapting the way you work based on your findings. Plan, Do, Check, Act. At the end of the day, Scrum is just repeating PDCA cycles with a fixed timebox.

How does scrum deal with complexity?

Transparency

Based on empirical process control, scrum strives to maintain a transparent state of work and results. Our product backlog contains a strategic goal and all the work which needs to be done to achieve it (or rather, all the work we think is needed at any given time). Our sprint backlog reflects the current state of work towards a common goal and is refreshed and discussed by the team at least daily. Our increment is transparent by being usable and shippable, so it can be experienced. The definition of done gives us an idea about all the quality aspects our increment contains.

Order

Complex environments become manageable when order is applied to them. In scrum, our work is ordered in both a vertical and horizontal way. The product backlog is ordered by perceived value of the individual items, the topmost items being the most valuable and detailed to work on. Items from the product backlog flow horizontally into and through the Kanban board at the center of the sprint backlog until they are transformed into an increment. Any learnings while doing the work will be reflected by the state of both backlogs by refreshing them.

Validation

Any plan in a complex environment is based on assumptions. Emergent findings will regularly change our understanding of what needs to be done and how to do it. We need to validate our assumptions as quickly as possible to avoid going the wrong direction. This is why scrum has sprint cycles of four weeks max - most teams will decide on an even smaller timebox for the sprint. While the end of the sprint is not a release gate (value should be delivered to stakeholders as early as possible, don’t wait for the sprint review!), it is a built-in opportunity to inspect what has been created. Together with our stakeholders we see if our plan succeeded or not. We validate our assumptions.

Takeaway

How do we conquer complexity to build a great product? With scrum, for example. It’s certainly not the only approach one can take, but if done and supported well it will lead to success. Complex does not have to mean difficult. Remember the manifesto: Uncover better ways of doing it by doing it.