Are you iterating over waterfall plans?

Sources of misalignment

Alignment is a core value of the scaled agile framework. It is often used to convey the need to align teams with each other and with the business objectives. But there is another way in which alignment has important meaning. How as managers can we stay aligned to the teams that we have set on an agile trajectory? It can be easy to impede your agile teams by constraining them with waterfall-like expectations and traditional  approaches. Here are some signs and practices to watch out for. Do you see any evidence of these practices in your organization? If so, they could represent obstacles to greater enterprise agility.

A common manifestation of this problem is that two discrete threads emerge. One is anchored in waterfall thinking and the other in a more agile (iterative and incremental) approach. Both are given  sway in the organization depending on the day and the audience. Be wary of the dissonance which can be caused if this is allowed to happen.

Highly deterministic planning

… far into the future. As an organization you plan to a level of precision which is unattainable in practice. Trying to defend this plan once created will set you up for tension with an iterative and incremental approach. You need a plan at the appropriate level of abstraction (coarseness) but when projects plan far into the future with high precision they usually crowd out the possibility of inspect-and-adapt. The early need for and impact of BUFD means that a phase based and stage gate based approach is almost an inevitability. When that early big planning is occurring some will (understandably) be asking “when will we be done”. You will also expect that the initial investment in the highly deterministic plan will pay you back. In effect you have a waterfall template which is dropped over your execution.

The creation of a (seemingly) very precise and accurate plan will not only steal some of your early capacity (after all people are planning and forecasting as opposed to building) … but it can also instill a misplaced confidence. The illusion of control can be created when you have a large volume of impressive documents which are forecasting the future for us all. In a traditional approach you will experience an early sense of comfort. Contrast this with the agile approach which will hope to generate an early sense of urgency. This can set you up for some dissonance with your agile teams.

One of my favorite quotes is from Tom DeMarco: “A day lost at the beginning of a project hurts just as much as a day lost at the end”. I think the traditional (highly deterministic) approach is not so good at surfacing when days are being lost. It is just hard to know when you are overcooking your plan – especially as your horizon goes further out.

Single date focus

“Will you make the date?” is the prevailing question even though that date is far into the future. The value of intermediate milestones becomes diluted because they don’t seem as relevant as that big event in the future. The future go-live is more than just a big deal – it’s the only deal. The ramifications of missing that date become amplified and the organization adopts ever-more conservative practices and thinking to ensure that date is met. For example … contingency needs to be built in to be confident of making the date. But the reality is that the contingency time becomes folded into the overall plan. It is quickly ‘spent’ and not held in reserve. Through painfully acquired lessons most of us know this and so it becomes understandable that questions about “the date” are paramount even with 6, 8 or 12 months to go.

The reason to be wary of this though is that agile teams are going to want to say that of course they will make the date. After all, they have made every date on the calendar thus far. It is the scope they will want to talk about. Negotiating towards a successful outcome with the available capacity is a key practice in agile. The sooner that scope can be discussed the better (in the spirit of trying to turn a large ship with little rudder early rather than a lot of rudder late).

Estimates turned into commitments

An estimate is an approximation and must allow for/accommodate some uncertainty. Traditionally organizations have been very uncomfortable with uncertainty and have a tendency to try to plan it away (credit to Jim Highsmith for this insight). We can eliminate uncertainty (or at least the appearance of it) by converting  our estimates into commitments. We are driven to do this by the highly deterministic planning mentioned above. A few unfortunate things will happen though when we do this:

a) contingency gets layered on (trading money for certainty)
b) estimate inflation takes a hold (conservative behavior instead of measured risk-taking)
c) the actual act of estimating becomes a slow and expensive overhead
d) Parkinson’s Law kicks in to eat your supposed reserves
e) trust starts to break down

The most insidious of all is the final one. This is how you get to the point where you business partners are saying ” really? REALLY? 2-months to add a @#!$!#@ button!”. And it promotes a culture in which every estimate is doubted for its accuracy. And every plan become circumspect. And each time we meet we are asked “will you make the date?”.

All of this is anathema to agile teams. On occasion I observe agile teams taking an inordinate amount of time to estimate a 1-point story (with 5, 8 and higher stories waiting unattended) and the reason is largely a cultural one. Their estimates will ultimately become commitments … and they had better be right.

Decisions forced to be made unnecessarily early

Another aspect of the discomfort with uncertainty is that it can cause decisions to be made artificially early. Combine the thirst for high confidence with a detailed plan and you can find it necessary to make a lot of decisions up front – ones which will be difficult to reverse later. The agile method is to anticipate that many things will be learned throughout the duration of the project. Teams would like to use that knowledge to inform their decision making. But by forcing decisions early – that can be frustrated. Certainty comes at a very high price. The price is paid at the beginning when the early research and analysis needs to happen – but it also gets paid for at the end in terms of contingency time (buffers).

“Buffers trade money for variability reduction” – Donald Reinertsen

Infrequent updates

The agile team are iterating in 2-4 week cycles. The management team are being updated once per quarter. Because the cadence is mismatched, the most current PI or iteration being reported on is usually still inflight. This is going to cause two things to happen:

a) A ‘special’ update will need to be prepared for management (this is fine until your learn how much of your valuable resources go into this)
b) The off-cycle nature of the update means that conjecture/subjectivity is allowed to creep in
The latter takes the shape of “yes the prior PI was challenging, but we are feeling very good about the current one under way”. The agreed-upon metrics which would govern how you assess yourselves becomes heavily diluted if you do this. Instead of managing your teams and programs on facts you allow for the significant temptation to trade on hopes, dreams and wishful thinking. Agile teams don’t want and don’t need this ambiguity. Consider a tightly-defined definition of done and how that could be made to seem futile if nobody seems to be watching the metrics carefully.

Overly aggressive plan

“Somehow, the tactic of professing to be shocked, disappointed, and dismayed when you didn’t catch all the lucky breaks makes it okay to have followed a plan that depended on catching those lucky breaks. But depending on luck for success is not okay.” – “Waltzing With Bears”, Tom DeMarco and Timothy Lister

Here is the common behavior. Squeeze the plan until it is just barely feasible. Have everybody agree that the plan is ‘aggressive’. Make an appeal to pull out all the stops. This too often passes for the standard operating procedure. The outcome in waterfall was normally ugly. Code complete date reached but code is not done. We sign up for an ugly integration phase – one in which bugs are being found at a faster rate than they can be fixed. Either the date is pushed or serious concessions are made in order to still make the date (as an aside – it is interesting how quickly scope becomes negotiable in the final weeks of a large program). The project is eventually delivered but at the expense of more than just money.

In agile the experience is a little different but also not good. Teams will observe early that the (high level) plan is not playing out and will start to feel disenfranchised if management continues to ask them to hold to the plan. There is unnecessary tension generated when the feedback loops are not listened to. It is the plan which needs to change. Agile would like that to be a series of course corrections over time rather than a serious jolt deep into the project.

In both cases the core problem is that luck was required to be successful. But we should not be counting on luck in IT management – we can do better.


Question: What does PDCA usually refer to?
Show answer

Previous   Next
Translate »
%d bloggers like this: