A Note on the Kanban & Retrospectives Post by David Andreson
David Anderson wrote an interesting post on Kanban & Retrospectives. David observes that some seasoned Kanban teams ceased doing “official” retrospectives. To quote David:
Some mature Kanban teams did drop the use of retrospectives. No one told them to do it. They just did. Retrospectives were not adding value in their lives and hence were seen as a wasteful activity that could be eliminated.
David carefully examines retrospectives in the Kanban context. His concluding recommendation is as follows:
Kanban can enable a team to reach a level of maturity where they may choose to eliminate retrospectives (or not.) It’s a choice! Every situation will be unique. The important thing is not to see elimination of retrospectives as wrong or bad or “not agile.” Equally, don’t rush in and eliminate retrospectives. Don’t proscribe retrospectives. Let the team make its own decision when it is ready and embrace the evolution of process that comes with continuous improvement.
I certainly understand where David is coming from and the sound logic of his reasoning. However, the question on my mind is whether core Scrum practices could be reduced without jeopardizing the method. The following excerpt from a recent Cutter Consortium post entitled Breaking the Facade of Truth: An Introspective View into and a Case Study About the “Apparent Truths” of Agile by David Spann nicely summarizes how minimalistic Scrum is:
Scrum, as a management methodology, is elegant in its design, requiring only three roles (i.e., product owner, ScrumMaster, and self-organized team), three ceremonies (sprint/iteration planning, daily Scrum/debrief, and sprint review meetings), and three artifacts (product and sprint backlogs and the burndown chart) — just-enough practical advice so agile teams do not overcomplicate the development lifecycle with too much ceremony and documentation
Can one meaningfully drop a core practice of a just-enough method?
Opinions please!
The Agile Executive 
I submit that a team which has either stopped doing a retrospective or has never done one is doing one of two things:
1) not continuously improving itself by failing to give itself the opportunity to talk through what they think is or is not working well for them
2) continuously improving itself, not by setting aside some time at the end of a timebox to talk through these things, but by continuously making improvements.
I postulate that the teams David Anderson is describing are doing the latter; rather than setting aside time at the end of timebox, every moment of every day represents an opportunity to talk through improvements.
I would hazard to guess that any team doing the former is not a team that any of us, or the customers to whom they are working to deliver value, would deem successful over an extended period of time.
Brad Sherman
March 21, 2009 at 3:23 pm
The problem comes in presuming that Scrum’s practices are the essential minimum without considering the context of the team, project, organization, and culture that it’s being used in.
Whether or not a “core” practice can be dropped from Scrum isn’t really as relevant as whether a team needs the practice. Our predispositions to the answer to this question shows us whether we’re following the methodology, or using the methodology.
At some point, a team will have enough maturity to not be empowered by just following a methodology. Admittedly, that point comes later in the cycle, but it does come.
I find it interesting as well that this issue of retrospectives in Scrum have become such a big deal in the past two years when we didn’t really hear so much about it before then. This timing also coincides with the mainstreaming of Scrum, which is the time when the Scrum population grew rapidly with the addition of many new beginners.
Scheduled retrospectives are a useful tool to provide structure at the outset. It’s not that reflecting is a necessarily bad thing or a necessarily good thing. I think a more important issue is the consideration of the appropriateness of the scheduling and timeboxing to all teams at all levels of learning and advancement.
Reflection is good, but regularly-scheduled reflection isn’t necessarily better. Unless, of course, reflection isn’t natural to the team yet and they need to exercise reflection. At which point, we’re specifically exercising, and these exercises can be helped by the structure that prescriptive scheduling brings.
Scott Bellware
March 21, 2009 at 3:54 pm
Israel,
To take this back to the Kanban context, dropping regular retrospections because the team is doing daily improvements strikes me as odd. I don’t see how one replaces the other. For me, they serve two different purposes. The daily inspection removes the evil of delayed feedback and addresses bottlenecks/impediments as they occur. These issues are not allowed to get stale; the data around the bottlenecks is not allowed to get stale; and, the team can act quickly and decisively to attack the bottleneck.
In contast, I wouldn’t use a retrospective to “remove bottlenecks”. Rather, a long-term retrospective is our acknowledgement that we must take time to step back and “See the whole.” This is fundamental if we are to work in and gain the benefits of real systems thinking and, as something of a subset, Lean thinking. Both trains of thought ask organizations to gather as many insights as possible and see the whole in order to aggressively support continuous improvement and innovation.
In my humble view, innovation doesn’t occur just through daily inspection. Wearing long-term goggles is an added and necessary component for innovative spark.
Jean
Jean Tabaka
May 26, 2009 at 5:31 pm