Tag Archives: kanban

Use a WIP Limit During a Sprint to Avoid the Cataract of Stealth

Posted on by

Mike Lowery – a fantastic Scrum coach – has written a post called It might look like rapids, but it’s still a waterfall. This is part of Mike’s series on Scrum coaching patterns (or team anti-patterns) and in this post he concentrates on the “The Cataract of Stealth”.

Mike starts by outlining how a sprint should look: “you should see a sort of tag team effect where 1 or 2 stories are in flight, as they get close to being finished the next stories are kicked off”. In contrast “The Cataract of Stealth” means the team start too many user stories at the same time thus risking finishing any of the user stories at the end of the sprint. Often this is caused by team imbalance, e.g.. too many developers for the number of testers.

The cataract of stealth is a real problem and I recommend people have a look at Mike’s post for more detail including his very sensible solutions. (It also has shades of the Overcommitment Bear Trap.)

I just want to add one thing. What Mike’s post highlighted for me was a (small) convergence of Scrum and Lean/Kanban thinking. The constraint on having “1 or 2 stories” in flight during a sprint is work in progress (WIP) constraint – a concept straight from Lean/Kanban.

New Agile Teams and the Overcommitment Bear Trap

Posted on by

The most common problem I’ve seen with software development teams is over commitment. Invariably individuals and teams are overly optimistic about what can be done in a certain time period. There are any number of reasons for this including arbitrary management deadlines and the team not pushing back, the developers desire to please, and just the fact that estimating in software development is hard.

Agile development teams are just as prone to this problem as any others. Every team I have helped transition to Agile has stepped into this bear trap almost immediately. And forewarning them doesn’t help. I now see stumbling into the trap as a valuable lesson and an essential step in the process of getting more mature about software development. I don’t mean maturity in the sense of the SEI’s Capability Maturity Model, I mean maturity in the sense of growing up, being realistic and accepting the limitations in themselves, their team and the organisation.

The difference about Agile, compared to traditional approaches to software development, is that Agile offers techniques to avoid the over commitment bear trap.
Continue reading →

Agile: I Prefer Hype to Ignorance

Posted on by

The good news is that Agile has crossed the chasm (Moore, 1991). On the down side there has been, and is, a lot of hype and hyperbole around Agile, Lean, Scrum, XP and Kanban, etc, etc. In particular, and despite the Agile Manifesto, the meaning of the term "Agile" has become very diffuse. So much so that there are many people, like a colleague of mine and one time Agile fan, who now says "I don’t talk about ‘Agile’ any more; it doesn’t mean anything".

I find the hype annoying, and Agile’s loss of meaning exasperating, but I also think it an inevitable part of progress.
Continue reading →

Declaration of Interdependence

Posted on by

In 2004 some people met to define what agile project management should mean. In February 2005 they published a statement called the “Declaration of Interdependence” (DOI). According to David Anderson (Kanban and the DOI), one of the signatories, the intent was to:

  • define a value system by which modern 21st Century project managers should live and
  • galvanise a community around general application of agile project management

Continue reading →

Minimum Releasable Feature

Posted on by

There are a variety of terms in use for chunks of functionality that are worth releasing and the requirements that describe them. Desirable characteristics for these features include being minimum, releasable, and valuable. At the moment I am using the phrase Minimum Releasable Feature (MRF) so I thought I’d explain why and some of the alternatives.
Continue reading →