Predictable project or innovative project?

Mike Cottmeyer spoke at Agile Carolinas last night. He said many good and useful things.

One thing he talked about is this:

What kind of project do you have?  At one extreme, do you have a project that is pure innovation?  Or, do you have a project that it completely ‘predictable’, and the main problem is good professional execution?

By ‘innovative’ we mean that the project or effort starts off with a vision, but perhaps not a solid one, and we discover ‘what we want to be when we grow up.’  Barely a vision, and only a minimal, inadequate sketch of the scope.  We get a bucket of money to discover some business value in that general area.

Predictable means that the scope and the business value are pretty well defined. They feel, ‘this is clearly what I want you to do….just do it.’  Usually at a fairly high level, but in their minds, it is a known predictable thing.  Nothing close to ‘pure R&D.’

Of course, what a manager may expect at first, and what turns out are often different.

Now, in practice, if you constrain a poet into sonnet format, give him a scope or domain of love and summer time; to him, he has realms and realms of room for creativity.  In fact, if you only said ‘write a poem’, he would be far less creative. Let us avoid for the moment the contradictions of creativity, beauty, innovation, and constraints.


Mike Cottmeyer’s main point is that in large organizations, the agile teams are given mostly predictable projects.

I would state the same thing slightly differently.  But it is really the same basic idea.

There is a continuum.  At one extreme, we know everything up-front. At least all the features needed.  Down to the sprint-sized story level.  And, if we were truly good, and all other factors predictable, we could accurately predict when the product would be released, or the next release.  A lot more accurately.  Etc.

At the other extreme, we know very little up-front. Everything can and will change.  Everything is unpredictable. Any upfront plan will be notably inaccurate.

Which raises the issue we are driving at?

How useful is any up-front work?

Mike Cottmeyer says (or I say he says), and I agree, that in large organizations, we at least think we know a fair amount up-front. (I am guessing that, if we used percentages, Mike might says we know 90% of what we need for a good plan.)

I will say most projects are between 30% and 70% known on Day Zero. By known, I mean as an example that we could identify 30-70% of the detailed stories accurately, for example.  And we have up to 70% of the total information we need, and it will turn out to be accurate information (despite changes).  If we took the time to gather this information.

The key point: We know more than zero. And still a damn sight less than 100%.  In my experience.

My conclusion: We must do some up-front planning. In a time box.  And, as we learn, we must re-plan.  I call the ‘re-planning’….Release Plan Refactoring.

And we must help the Scrum Team, and any other players involved, learn how to manage in this ‘partially known/partially emerging’ situation.

Part of the learning is for the Team to learn how to become more predictable, at least at some level.  And how to manage innovation and disruptive learning.  These may seem very opposite skills, but in fact they are similar.

Let me go back and say it again. If we know nothing on Day 0 that will remain true through the effort, then almost any up-front planning is a waste. But I find that never happens.

From the other side.  Any classic waterfall person or manager who de facto implies that we know almost everything upfront needs to be read a bedtime story and put to bed early.  That person is still a child, and we should get them out of the office.  They are a hazard. We never know enough to predict very accurately.

Will some effort on estimating and planning enable us to improve the probabilities of making some useful business decisions?  Yes.

Do we know enough to enable us as managers, in justice, to ‘hold the team accountable for their estimates’?  No, virtually never, at least for the Day Zero estimate.  And to try to do so is usually foolish, counter-productive, immoral and rather stupid.

So, again, I think we are in a middle state. We know well more than nothing and well less than everything.  And, in both ways, we must accept the consequences of this level of knowledge of the future.


« « A purpose for Agile || PO Impediments – Charlotte May 2013 » »


Leave a Reply