Scrum and my garden
To be honest with you, I’m not much of a gardener. I like our garden, but don’t like to put in too much maintenance work. So we decided to keep things simple. Some bushes, some hedges and grass. My partner takes care of the flowers (in pots). Together we do the necessary to take care of the rest. Even though our is garden simple, it still requires us to maintain it. Without gardening the grass would grow too high, the hedges would explode and the weeds would start to take over all the rest, if not everything.
While looking out of our kitchen window this weekend, I realized how similar our garden is to Scrum.
Scrum is a simple framework to build and manage complex products in complex environments. It is beautiful in its simplicity. It does take a lot of hard work to master it and most importantly it needs very regular maintenance.
For most organizations starting with Scrum brings a load change. The “doing” or process to start and especially the cultural and behavioral change at all levels — the “being” —is where a lot of organizations struggle. But let’s not dwell on this too much. For the sake of this article let’s say your organization has adopted Scrum and by doing so has been able to regularly deliver value to its customers and stakeholders.
There! Achievement! You did it!! Congratulations. Does this mean you can sit and rest on your laurels? I believe not.
For some reason we human beings tend to fall back into old habits when we stop paying attention. We choose the path of least resistance. Or at least, what we think to be the path of least resistance. So, why work with a Product Backlog if I can just barge into the Development Team’s workspace and ask them for a feature adjustment on the fly? Because it seems easier to do. We don’t care about the time loss of context switching or the overall indirect cost. Our request is communicated and will be picked up soon. That’s what counts! Right?
The above example is one of many dysfunctions I’ve witnessed in the past. One of the weeds that would overgrow the Scrum garden if allowed to. And exactly a very good reason to apply maintenance to your Scrum.
So how can you maintain your Scrum?
First and foremost, you have a specific event that is intended for this, the Sprint Retrospective. A formal moment to inspect and adapt on all necessary elements of your Scrum. This can be the process, the team, the members, interactions with the stakeholders,… anything that needs addressing.
From your Sprint Retrospective you will get actionable items or tasks that can help you to improve. That’s nice.
Still, there’s a second thing I would like to mention.
“ Don’t limit your Scrum maintenance to just your Sprint Retrospective”
Don’t forget about quick wins, low effort/high impact actions and small behavioral changes that can help you move towards better Scrum.
Those can probably be addressed immediately when they surface. The sooner you can remove the small, sprouting weeds, the less effort it will usually take.
The Scrum Guide also points this out.
“…the adjustment should be made as soon as possible.” and “The most impactful improvements are addressed as soon as possile.”
Basically meaning: If you see the weed and you can remove it, do so. A relatively large part of your Sprint time should be invested in collaboration and converstation. This is exectly where your maintenance fits as well.
The conclusion
- Even when you have succeeded in adopting Scrum, you will need to maintain it.
- The Sprint Retrospective is your formal event to inspect and adapt on the whole of your Scrum
- Don’t limit yourself to the Sprint Retrospective only. Improvements can be made all the time.
