I wanted to return to Dave Laribee's post from the weekend, Introducing Kanban at Xclaim. I'd like to bring your attention to discussion below involving Derik Whittaker, Steven Harman, and Dave concerning retrospectives. For a long time I've not found project and iteration retrospectives particularly useful and until I read this I'd failed to articulate why that was.

It was this comment from Steven that triggered my epiphany...

I can totally see how the retrospective can be viewed as wasteful in the context of Kanban - where every developer has the ability to Stop The Line the minute they detect a problem.

Steven is pointing out that a Stop The Line approach encourages root cause analysis of special cause variations (or issues external to the process (as designed by the manager or team)). I teach that issue management is a crucial skill for successful agile teams. Issue management is what keeps things flowing. I emphasize this much more than typical agile authors do. For me, issue management goes beyond simple flagging of impediments. Often with teams I encounter, I find that team leads or scrummasters are good at impediment removal when the impediment is internal to the process or the team or is under direct control of the lead/scrummaster. When an issue is external, the process is often undefined and is ineffective. The result is that teams often struggle to complete work blocked by something external. This affects their productivity/burndown and the net result is under-delivery of scope for the iteration. Hence, I coach issue management and resolution and make it a responsibility of the project manager.

For basic maturity, raising issues, logging them, tracking them, assigning them and resolving them is essential. But the resolution can be tactical. It can be just enough to keep things moving. It can be a work-around. For higher maturity, I expect to see root cause analysis and elimination of the problem so that it doesn't re-occur. Interestingly, the CMMI sees it the same way. Basic issue management is hidden in the Risk Management (RSKM) process area that appears at Level 3 and advanced root cause analysis, Causal Analysis and Resolution (CAR) is a high maturity Level 5 behavior.

In addition to issue management, my agile management technique emphasizes the use of an organization level, operations review every month. This was described in my book, written 6 years ago. The chapter on operations review was considered sufficiently differentiating that Prentice Hall released it as the sample chapter to promote the book. You can find it here on my site.

So, Steven's comment on Dave's post inadvertently gave me the epiphany that when you have a regular operations review to look at the organization's performance along with a strong culture of issue management that matures into a Stop The Line culture, then you have both common cause and special cause process problems covered. This leaves very little for a project or iteration retrospective, and hence, I don't find them terribly useful.

[I should point out that I don't actively discourage teams from holding project retrospectives. If the team recognizes them as waste and discontinues the activity that's fine. But if they want to hold a retrospective and find value in it, then I encourage this. All opportunities to reflect and adapt are valuable in my opinion.]  Technorati tag: Agile+Management, Lean, Kanban, David+Anderson, Dave+Laribee, Software+Engineering, Project+Management