The (not so) secret ingredient — prioritising continuous improvement

By Maneka Menon, Chief Scrum Master at Macquarie Group

Transparency, Inspection and Adaptation — it is the cornerstone of Agile. Yet often, prioritising time to reflect and improve is put to the side. If Production is the number one feature, should Continuous Improvement be the second?

During school I gravitated towards STEM, and perhaps thankful for the 286 PC my parents bought when I was a child — albeit to mainly play games, it was no surprise to ultimately choose to do a Software Engineering degree. Entering the workforce as an Analyst / Programmer (translate to the current term of Engineer) I always found it hard to describe what I did in those “BBQ” situations. Fast forward to more recent years, as a Scrum Master and now as a Chief Scrum Master, I get even more puzzled looks (and sometimes I wonder whether they are picturing me on a Rugby Union field) when I mention my title, and find myself launching into some ramble involving the words “IT”, “supporting a number of teams” … but the item, and probably the most important one, which I see the flicker of universal understanding in their eyes is “continuous improvement”.

Whilst a Scrum Master adds different kinds of value to a team depending on the team’s level of maturity, arguably the most important role they play is serving as a mirror to the team, and helping the team learn to value the mirror as one of their most vital tools. Although focusing on improvement seems obvious, it takes discipline.

Stop to go faster

Since I was first introduced to this Henrik Kniberg cartoon, I have loved to share it with others. It speaks volumes, but most importantly for me, it talks to the importance of creating space for inspection and adaptation. How long is something taking to get done? Is it very manual and do we repeat it often? Is there something else which already exists that can help us be more efficient? Do we need to invest in building something which will help us in the long term (e.g. automate)? This last one I like to describe to the teams as the slingshot effect — arguably we are slowing down / pulling back initially, but ultimately it will propel us forward.

Ideally, space and capacity should be created frequently to reflect and improve, however we don’t always have that luxury. Some tips for teams are:

• Never de-prioritise the team’s Retrospective. This ceremony is devised to create the space to inspect and adapt. If you don’t find your Retros useful anymore, dig deeper into the root cause. Is it that you talk about the same issues every time? Is the format a broken record and not conducive to fresh thinking? Maybe a Retro is needed on your Retros to get to the root issues and create the needed change to make this as useful as they should be!
• Have a Continuous Improvement board (or Epic). A place where the team prioritise improvements needed, just like everything else. If actions from Retros aren’t tracked, prioritised and actioned, this is probably one of your issues in the above point. One of the key DevOps principles is Measure Everything, this also applies to team health and maturity, and any improvements need to be tracked centrally. Capacity will only ever be finite. It is also important to prioritise the list of improvements to focus on and tackle.
• Articulate the value of the improvement. As with any Epic / Feature / Story (think increment of change) the intended outcome and value needs to be clear. Have OKRs (objectives and key results) for your improvement focus areas. As with any prioritisation, this will help determine where in the backlog this sits and will help your stakeholders understand why it should be tackled before proceeding to something else shiny on the list.
• Ensure the team has a voice. The team should be contributing to the backlog. They know the product and system(s) well. They know what will help make things efficient. A good Product Owner will take input from all stakeholders, including the team, and order the backlog based on value.
• Initially force the space. If the team is not yet able to make it a regular occurrence — force their hand with things like Innovation Days or an Open Space carved out and agreed early. The added benefit here is that you can also organise this across teams or the organisation to try and harnesses reflection and innovation at scale, not to mention the ability to collaborate across teams. Techniques like mobbing and similar activities, also allow for improvement at scale.

We recently ran our “Spring Forward” Innovation Day which ticked several items above in one go. We announced a day that all the teams should set aside to work on improvement ideas from their backlogs. Teams used their voice to raise or prioritise value-based initiatives. Running a competition didn’t hurt either, in terms of ensuring the value of the initiative was clearly articulated! There were some great results — ones that automated manual processes and reduced risk, ones that increased self-service (including one that could reduce 40 hours a month of support), and ones that introduced greater simplification and an enhanced developer experience.

Try something on for size

The focus on improvement is just as important on a broader scale. As more and more organisations start or ramp up their Agile Transformations, allowing space and strategies for inspecting and adapting is key. There is no one size fits all. Even teams at scale need to understand what works and doesn’t work for them.

Our Enterprise Agile journey started over 6 years ago, first in one space, and as the benefits came to light, gradually spread out to the rest of the division. We experimented with different things along the way, some worked well and some failed fast. We are constantly challenging thinking around structure and frameworks and we continuously learn and improve. This is our Agile way.

After learning about the concept of the “adjacent possible” recently, it was interesting to reflect on the trueness of this in my observations. Implementing change at a grand and forced scale can easily allow for the ‘rubber band’ effect to take place and I could imagine why some organisations may throw up their hands saying it wasn’t working and retreat back to what felt normal, or perhaps just habitual.

The adjacent possible talks more to small areas of change and evolution in a positive direction, and teams gravitating to what they can see from the outside as working well, and not too different from where they are now. This type of small and welcomed change will more easily stick for the long haul.

This helps explain why, I believe, our piloting of ideas and change, communities of practice and collaboration helps with the continual evolution. Teams experiment at small scale and then share where it works (and also importantly where it doesn’t), and other teams come knocking at the door to understand the learns and take the goodness back to their own team. However, once again, this takes discipline to create the needed structures to allow for broader reflection, collaboration and execution of improvements.

Hold the mirror regularly

If we don’t know where we are, how do we know where we are going? Reflection, measurement, curiosity and plotting our goals, cannot continuously be put to the side. Although it seems obvious, we need to have continuous improvement constantly flash like a neon light in our heads.

Whilst continuous improvement, in the same vein as Agile Transformation, is never ending (and the reason our teams’ continuous improvement board is called the Infinity Board), the need to continue to evolve is vital for any high performing team or organisation.

Whether your team is a dog chasing its tail, a snail or a cheetah — it is in your hands.

References

Macquarie embraces DevOps, Ellis, Matthew (2019) Macquarie embraces DevOps, Lessons from Macquarie’s journey to DevOps.

Macquarie’s Mobbing journey, Jabbour, Dany (2019) Master Mobbing, How Macquarie has leveraged mobbing to great effect.

The adjacent possible, Snowden, Dave (2016) The adjacent possible, Cognitive Edge