Scrum can be a very effective method to teach teams more Agile ways of working. It introduces topics such as small batch, working more directly with stakeholders and frequently inspecting and adapting ways of working and product plans.
Yet many teams I’ve worked with, and heard about, seem to exhibit a similar pattern after working together for a few months. The Retrospectives seem to lose their effectiveness. They run out of steam. Teams begin to surface only superficial problems, begin to cancel the event, or talk about the same items Sprint after Sprint.
Ever happen to you? I’ve always concluded that the team just needed to dig deeper, to find that additional knob to turn or button to push. But could this be a symptom of something else?
Scrum Cadences
Scrum has a number of cadences anchored by the main cadence, the Sprint.
The Sprint is a time box, typically 2 weeks, during which all activity occurs. It is bookended by Sprint Planning, to kick off the Sprint, and the Sprint Retrospective, which concludes the Sprint. Contained within the Sprint cadence are the Daily Scrum and the Sprint Review.
Cadences in Scrum:
- The Sprint – this the heartbeat of Scrum. It is typically a 2-week time box during which the team develops the product more fully.
- Sprint Planning – this event is where the team selects what they will work on during the Sprint. It formally kicks off a new Sprint.
- Daily Scrum – this is a daily event not aligned to the Sprint cadence. It’s where the team creates a plan for the day. If your team is having a status report rather than planning, check out this article.
- Sprint Review – this event is where the team showcases their efforts for review, including feedback, from customers and/or stakeholders.
- Sprint Retrospective – this event is where the team discusses their ways of working. What’s going well and what could be improved.
The Retrospective Event
One of the prescribed Scrum events is the Sprint Retrospective. The Retrospective is held once per Sprint. It’s typically a 1 hour meeting for 2 week Sprints.
During this event the team meets to discuss the current Sprint, which is about to conclude. It is a key Inspect & Adapt activity. The team reviews feedback from the Sprint Review and makes product adjustments accordingly. They review their ways of working to see if improvements can be made.
There are many formats used during the Retrospective. These range from a conversation to using different visual formats to inspect the current Sprint. All formats are attempting to answer these 3 questions, though perhaps asked in different ways.
- What went well during this Sprint?
- What didn’t go so well during this Sprint?
- What are we going to do about it?
The answer to question 3 forms the basis for adaptation. Typically teams will craft an experiment of the form “if we change this, we expect that to happen”.
Some teams leave it there and never actually get to the experiment. This dysfunction I call “inspect & forget”. But many teams do run the experiments, which are expected to finish within the next Sprint.
The Change Experiments
For new teams, or teams new to Scrum, the first several Sprints uncover a lot of challenges in their initial processes and product definition. There is a smorgasbord of findings they can address. Crafted change experiments may include items like:
- we need to tighten up our Definition of Done
- we should adopt pair programming (to improve quality)
- our team working agreement needs X, Y and Z
- and there will almost aways be something about story sizing and/or number of items selected during Sprint Planning.
There seems to come a time though, when the team begins to hit a wall during Retrospectives. “What didn’t go so well?” begins to get fewer items. Or the items are more superficial such as “we have too many meetings”.
Another indicator is recurring items each and every Sprint that are beyond the team’s ability to solve, systemic issues requiring management intervention or long timeframe changes.
In the past I would always encourage teams to “look further” or to “dig deeper”. I felt there was always another knob to turn or button to push.
But perhaps these ineffective Retrospectives were indicating something else.
Perhaps, because the teams were having this inspect & adapt conversation every two weeks, there was simply not enough time between such discussions. The team had solved most of the things they could solve within their current system and environment.
A Retrospective is a Technique!
As I mentioned earlier, Scrum is a great framework to teach teams more agile ways of working. Scrum includes the Sprint Retrospective as a means to implement the 12th Agile Principle.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Manifesto for Agile Software Development
In general though, a retrospective is a technique and not a formal event within Agile. While there may not seem to be much difference, there are many techniques to inspect and adapt. Scrum just happens to choose this one technique to include as a formal, cadenced event.
A Lean Alternative
One of the negatives of inspecting & adapting on a cadence is that, for a 2 week sprint, issues discovered would wait, on average, 1 week before being addressed. Unless the team is keeping a board of issues, or perhaps a Sprint diary, as time passes things are forgotten. Or at least misremembered.
After a team has been together a number of months, a 2 week inspect & adapt conversation may be too frequent. The team is moving along, no major surprises, value is flowing. And yet the team stops to talk, perhaps nothing new has been surfaced or the same things beyond their control are hashed over yet again.
Rather than continuing to meet every Sprint, for meetings that are proving to be largely waste, what if the team met only when issues arose? As issues are uncovered, the team calls an impromptu meeting to inspect & adapt. The problem is fresh in everyone’s mind as it is currently happening, or happened moments ago. There is no need to “save up” problems to discuss later.
Within the Toyota Production System, or TPS, there is a signaling system known as an andon cord. It is a physical cord that is installed on the production line that, when pulled, entirely stops the production line. Anyone on the process line is empowered to pull the cord whenever a process or quality problem happens. Once pulled, the production team meets to discuss and fix the error, correcting it so it doesn’t happen again.
There is a huge level of trust here. Management expects team members to pull the cord when an issue happens. Quality is everyone’s responsibility.
Wrapping Up
I’ve worked with a number of teams who have implemented the andon cord concept into their ways of working rather than having a Retrospective at the end of every Sprint.
At any time, a team member can call an emergency meeting to discuss and correct a problem right as it is discovered. No waiting, no permission needed.
Teams love this technique. The respect within the team that anyone can pull the cord, fixing problems in real-time. Something else all these teams also implemented is that, if there have been no andon cord events for 4 weeks or so, they held a formal Retrospective.
As teams begin to own their ways of working, they may choose to adapt away from formal Scrum. As they develop their unique way of working Scrum begins to dissolve. The building is taking shape and the scaffolding can be taken down.
Approach such change as a scientist. Form a hypothesis, define experiments. Inspect the results and adapt accordingly. In fact, this sounds like a great way for teams to completely embrace and embody continuous learning and improvement. Cheers, you’re demonstrating higher levels of agility!
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
