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 it’s 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 dysfunctional habits 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. The Scrum Guide states that your Sprint Backlog (your workplan for the coming Sprint) should contain at least one high priority improvement. That’s nice. Just don’t forget about quick wins, low effert/high impact actions and small behavioral changes that can help you move towards better Scrum. The sooner you can remove the small, sprouting weeds, the less effort it will usually take.
One of the things often happens in this maintenance regard is that Scrum teams limit the maintenance part to the Sprint Retrospective. And that’s the second thing I would like to mention.
“ Don’t limit your Scrum maintenance to just your Sprint Retrospective”
This is even exactly stated in the Scrum Guide:
“If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.”
Basically meaning: If you see the weed and you an 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.
- 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.