Scrum your Improvements back within 4 Sprints

“Make everything as simple as possible, but not simpler.” 
          – Albert Einstein

I am going to tell you a story of continuous improvement and how we have enabled those recently in our team of teams… I have picked this story up because situation at many companies is often quite similar:

The Problem:

Although many of them understand need for continuous improvement it gets hard to plan those together with features… and in practice implementations are often missing or poor:

• There is an increasing demand to deliver..
• Development teams are treated as “feature factories”,
• And no time to improve, no time to “sharpen tools” to be more efficient
• More pressure… risking improvements

And all this creates: feeling we are stuck, frustration, demotivates, affects efficiency and quality in longer run… and gets more complicated in multi-team environments… as it also includes agreements and collaboration factors between several teams…

We have tried many things and eventually were inspired by Jeff Sutherland’s Cycle of Scrum Master from Scrum@Scale …and here is what we have done …

But let us understand circumstances first… and how does process look from a single team perspective:

• Development team plans and runs their 2 week sprint…
• That ends up with DONE product increment
• And a delivery of it together with other 5 teams
• These 6 teams are sharing codebase, decisions, tooling and environments together + they deliver in the same cadence
• They talk regularly as Team-of-Teams to Inspect & Adapt their delivery process aka Team of Teams Retrospectives
• In the past they were trying to implement findings of those retrospectives, immedeattely but only few were really managed…

Sprint 1: so this made us thought how we can Scrum those improvements back in sprints…..

• We have obtained an agreement with Product Owner team to let each team pull at least 1 SMALL Task from that backlog per team / sprint and that this task shall be prioritized as a part of the default sprint goal 
• We have also agreed within teams to file their improvements as tasks marked accordingly that comprise so called Kaizen Backlog

We have put these decisions into actions and felt results almost after a sprint…

Sprint 2: why we must wait to come up with improvements?… 

• Apart from those any team at any moment can propose an improvement and for that thy can use SoS to share their ideas with peer teams
• Those ideas after acknowledged by other teams are also parked in the same backlog

Sprint 3:  how to make sure Task is READY? Development of that lead to…

• Distribution of tasks happens latest 1^st Scrum-of-Scrum of the sprint for the sprint after current. This we have done for creating enough pace for the teams to refine / groom those and size them so that they are SMALL.

Sprint 4: after a while we have noticed that it would be good to prioritize that backlog…

• Besides regular intervals ToT also joins forces in validating this backlog, checking prioritization, etc. This we call “Kaizen Triage Meeting”. After a while we have looked together at this backlog and understood that we have there 4 types of improvements:

1. • ProdQuality – Quality of Production (Live Product) is ensured, i.e.Monitoring, Logs, Live Tests
   • DevQuality – Quality of Development (or soon to be released) is ensured…
   • Efficiency – Saving Time for Development, …
   • ProdPerformance – Performance of the product for end users

On top: We have also thought about some symbolic celebration …

• After team implements an improvement task, they get a STAR
• Default expectation 1 star per team per sprint, but in practice some try and did more…
• After each sprint we acknowledge how many STARS we have produced all together!

Results are:

• Many small practical improvements fast
• Feeling of continuously “steering” our technology
• Increased motivation and feeling of ownership in teams
• Was measured by tickets inflow / outflow + happiness

This worked because:

• improvements were small, easier to plan, implement and deploy them
• therefore, they are also less risky to do
• process is simple lightweight, easy to follow
• shorter improvement cycle allows faster response
• queue of the backlog is short and manageable