Mike Cottmeyer spoke at Agile Carolinas last night. And 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, at the other extreme, 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 barely a vision, and we discover 'what we want to be when we grow up'. Barely a vision, and only a minimal, inadequate sketch of the scope. And we innovatively get a bucket of money to go discover some business value in that general area.
Predictable means that the managers feel, at least, that the scope and the business value are pretty well defined. They feel, at least, '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.'
Now, in practice, if you constrain a poet into sonnet format, give him a scope or domain of love and summer time, still, 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. But let is avoid for the moment the contradictions of creativity, beauty and innovation.
***
His (Mike Cottmeyer's) main point is that in large organizations, the agile teams are given mostly more 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 no knowing up-front. Everything can and will change. Everything is unpredictable. So, virtually any up-front planning is useless.
Which raises the issue we are driving at.
How useful is any up-front work?
And 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.
So, 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. If we took the time.
The key point: We know a damn sight 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 timebox. 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 layers or people involved, learn how to manage in this 'partially known/partially emerging' situation.
Part of the learning is how to become more predictable, at least at some level. And how to manage innovation and disruptive learnings. These may seem very opposite skills, but in fact they are similar.
But let me go back and say it again. If we know nothing today that will remain true through the effort, then almost any up-front planning is waste. Maybe not completely, since we must acknowledge man's irrational need to believe he knows and is in some control of the universe and his own life. So, even if we know nothing that will remain true, maybe, just to satisfy this human fantasy, we need to discuss some things upfront. Or the morale of the team will suffer. But mostly any upfront planning is waste.
Again, 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. 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.
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, at the other extreme, 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 barely a vision, and we discover 'what we want to be when we grow up'. Barely a vision, and only a minimal, inadequate sketch of the scope. And we innovatively get a bucket of money to go discover some business value in that general area.
Predictable means that the managers feel, at least, that the scope and the business value are pretty well defined. They feel, at least, '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.'
Now, in practice, if you constrain a poet into sonnet format, give him a scope or domain of love and summer time, still, 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. But let is avoid for the moment the contradictions of creativity, beauty and innovation.
***
His (Mike Cottmeyer's) main point is that in large organizations, the agile teams are given mostly more 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 no knowing up-front. Everything can and will change. Everything is unpredictable. So, virtually any up-front planning is useless.
Which raises the issue we are driving at.
How useful is any up-front work?
And 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.
So, 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. If we took the time.
The key point: We know a damn sight 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 timebox. 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 layers or people involved, learn how to manage in this 'partially known/partially emerging' situation.
Part of the learning is how to become more predictable, at least at some level. And how to manage innovation and disruptive learnings. These may seem very opposite skills, but in fact they are similar.
But let me go back and say it again. If we know nothing today that will remain true through the effort, then almost any up-front planning is waste. Maybe not completely, since we must acknowledge man's irrational need to believe he knows and is in some control of the universe and his own life. So, even if we know nothing that will remain true, maybe, just to satisfy this human fantasy, we need to discuss some things upfront. Or the morale of the team will suffer. But mostly any upfront planning is waste.
Again, 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. 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.
No comments:
Post a Comment