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

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.

Management on the Ground

You have to keep your feet on the ground when others want to put you on a pedestal. After a while on a pedestal, you stop hearing the truth. It’s filtered by the henchmen, and they read you so well, they know what you want to hear. You end up as the queen bee in the hive, with no relationship with the worker bees.

Bill Burns, CEO of Roche Pharmaceuticals
quoted in Goffee & Jones (2006), p. 43

One of my project managers recently mentioned that, despite being a programme manager, my own management style is quite "hands-on". In the sense of being on the ground with my team rather than in the technical sense although the two often come together. This approach has held me in good stead over the years.

Others, like Bill Burns quoted above, have realised dangers of being distant from the people doing the work and the corresponding benefits of being on the ground. I thought I’d take a quick look at some of these previous advocates of being on the ground:

  • Military Commanders on the ground
  • Management by Walking Around (MBWA)
  • Toyota, Lean and Genchi Genbutsu

I’ll wrap up by having a quick look at the Agile practices that help me be on the ground.
Continue reading

Two Types of Post Implementation Review

Recently people at work have been asking my advice on how to run post implementation reviews of major programmes so I thought I’d write up my thoughts. I believe there are two types of post implementation review and I recommend doing both. The first type happens in Project Closure and the second happens after the project has finished, i.e. Post Project.
Continue reading

Agile Quality Management

Quality Management, in a project context, is concerned with having the right processes to ensure both quality product and a quality project. This article describes Traditional Quality Management, Agile versus Traditional Quality Management, Agile Product Quality, Agile Project Quality, Agile Product Quality, Agile Quality Assurance and Control, and Agile Quality Improvement.
Continue reading

Agile Project Estimating

Estimates are an essential part of Agile Project Planning.  Software estimation has always been problematic and people have proposed many different ways to do estimating.  Different methods are on a spectrum from formal to informal and from supposedly objective to seemingly subjective.  Different methods also get individuals estimate or groups.  And some methods estimate size and derive effort while others estimate effort directly.  Estimating in the Agile world has settled a certain approach which might be characterised as expert group estimation of size. this article covers Traditional Project Estimation, Agile versus Traditional Estimating, Estimating User Stories, Estimating Tasks, Contingency, and Agile Ballpark Estimates.
Continue reading

Agile Project Execution

Executing is one of the five project management process groups in the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (2004).

Project Execution is where you build the project deliverables and hand them over to your customer, i.e. where you build and deliver the software. This is where most of the project effort is invested. Agile Project Planning says what you intend to do, when, and Agile Monitoring & Control helps you stay on track but Agile Project Execution is where you do the business.
Continue reading

Agile Project Monitoring and Control

No battle plan survives contact with the enemy

Field Marshal Helmuth Graf von Moltke

Life is what happens to you
while you’re busy making other plans

John Lennon

Agile Project Planning tells us what we expect to do, but, to paraphrase the quotes above, plans often turn to custard. The job of the Agile Project Manager is to guide the team to successful delivery despite the challenges the world throws at the project. This article is about monitoring the project against the plan and intervening when we notice things going off track. In particular it covers Traditional Project Monitoring & Control, Agile versus Traditional Monitoring & Control, Agile Project control, Agile project metrics, Agile Project Reporting, and Agile Project Monitoring.
Continue reading

Agile Project Planning

No battle plan survives contact with the enemy

Plans are nothing, but planning is everything

Field Marshal Helmuth Graf von Moltke

I believe that Agile Project Management provides certainty of delivery. Planning is what lets us answer the question “When will you be finished?”. Planning is, however, just the start of the process. As Moltke pointed out planning is more important that the plan because once you start the project you’ll find the plan is wrong and you have to adapt. All plans need revisiting and you will have to use Agile Project Control, Agile Change Management, and Agile Risk Management to get the promised certainty of delivery.
Continue reading

Agile Project Scope

According to Wikipedia: Project Management project scope is:

The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.

We can talk about what is “in-scope”, i.e. what the project is meant to delivery, and what is “out-of-scope”, i.e. what won’t be delivered.

Typically the project scope is a subset of the scope of the product under development.
Continue reading

Agile Project Initiation

One company I worked with called the start of the project the “Blueprint” as it is about roughly shaping the project and product. “Inception” is another common term for this phase in agile projects. This article outlines traditional project initiation then delves into more detail on Agile Project Initiation.
Continue reading