Category Archives: Release Planning

Predictable project or innovative project?

Posted on by
Reply

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.

They still want us to deliver too much in too little time!

Posted on by
Reply

In a class, we had a large group of people from one company.  And the company is doing or getting close to doing mostly Scrum.

But the managers and the Board have not been to a Scrum class.

In any case, ‘management’ is still asking the Teams to try to deliver too much in too little time. And say both the scope and the date are inflexible. Or at least, that is how it is heard.

What is the solution?

This is one of the hard problems of our work.  There is no easy answer.

I think it boils down to this.

1. Customers want things quickly. And time itself has a value.  For example, we must get to market with our new product before the competition.

2. On the other hand, as they said in Latin some 2,000 years ago, to predict is difficult, particularly of the future.

So, we (the Scrum Team) must make predictions, and try to make them real.  AND, we must get everyone to understand all the changes that will happen. And all the variability in our ‘predictions’.  When we think the next release will be done and how much will be in it.

These are not easy conversations. Usually. People mis-understand each other.  Nonetheless, you must have the conversation.

Sometimes we say: we have a fixed time, a fixed scope and a fixed budget.

But always this is never completely true (in my experience).  There is always some proposed small features or featurettes in the work that do not have to be done in the current release.  This gives us an incentive to break down the features smaller, so we can identify small things to move to ‘later’.

Always there is a value to delivering fast. Usually, even before the current ‘date’ would be real good. Often very very good. (Which gives us yet more reason to reduce the number of small features in the release.)

And usually cost is NOT the main driver. There is (or should be) a huge ration between benefit and cost, so that being stingy about cost is silly. Especially when time is so important.

Lastly, in this too brief discussion, we must mention impediments. In Scrum, we want the Team to identify their biggest impediments.  Things that, if we fixed them, we could double (again) our velocity. Not by magic, not by working harder, but by fixing impediments. In the wetware, in the random carbon units, in the automated testing, in the management culture, whatever.  And often fixing impediments costs serious money.  So, we need good judgment to spend wisely.

Finally, we need to use Agile Release Planning to start to identify a reasonable scope and date, initially.  And, as things change (and everything will change at least some), we can revise and revise and revise it, and do the best we can to innovate in the time boxes we ultimately decide to give ourselves.

***

Managers must learn that if they pressure the Team (to deliver more in a given time), the Team usually hears two things: (a) cut quality, and (b) work high overtime.  So, the Team and managers (or customers) must talk about this.

Almost always the managers do not want reduce quality or overtime (bad quality of life). What they want is ‘creativity’.  Someone to cleverly see a simpler way to do things. How to remove an impediment. How to do fewer features. Something. Something unexpected that we might not have imagined without a challenge.

So, talk about this. Start to understand each other better. You need each other.

Question: How to order Stories in the PB

Posted on by
Reply

Question from a former Class Attendee:

Another question, this time about ranking user stories.
In the recent Scrum Master course, you indicated we should rank stories in the PB (Product Backlog) by Business Value and then do them from the top down. In the Product Owner course back in 2011, you had us calculate R = BVP / SP to arrive at the cost / benefit value and then rank by R. This would have the effect of doing longer items ahead of shorter items that have somewhat less business value.
What do you recommend now? What are your current thoughts?

Reply:

I explain this at a decent length in my small book on Agile Release Planning.

I am still a fan of the R factor.  AKA cost benefit analysis. (Business Value Points divided by Story Points.)

And a fan of making stories small.  To me, all epics eventually must be broken down so that we can get 8 items (stories) in a sprint.  So, if we have a velocity of 20 for a 2 week sprint, then items average about 2.5 story points in the sprint.

So, as stories rise to the top and get broken down, we have to re-point (both BVP and SP). And thus the R and the ordering will change.

Not quite sure what your concern is, but I think that resolves it. (Although I can imagine follow-on questions.)

The order can never be ‘purely’ business value.  We have other things to consider (which we might also call business value, but to me it gets too complex to put it that way….).  Things like Risks, Dependencies, Learning, MMFS (minimum marketable feature set), and Other factors.

So, I like to use R factor. Rank by that. And then have the Team discuss changes to that ordering.

Remember that to me the most important thing is that the Team together see the same elephant.

In the long term (or short term??) the PO wants to maximize the business value delivered out of the Team to the customers.  I think.  As a contrasting example, the PO is not optimizing the ‘efficiency’ of the Team (that each hour is used ‘productivity’).

Does that help?

Latest ‘Agile Release Planning’ ebooklet

Posted on by
Reply

I am pleased to announce that I have completed a full edit of the booklet.

It covers:

* Vision
* Product Backlog
* Business Value
* Effort
* Risks, Dependencies, Learning, MMFS, and other
* Ordering the Work
* Drawing the line
* “Communications Plan”
* The Fix-It Plan
* Other things
* Release Plan Refactoring

I use these ideas in the workshop that I now do for every course. So, I know the ideas work.

And I am feeling better about how they are expressed in this booklet.

But I would appreciate your comments.  If you like it, and if you find things to be improved. Or if you have questions.

Please download the booklet here.  It is about 33 pages.

Do high benefit/cost work!

Posted on by
1

Tom DeMarco wrote an article a while ago: “Software Engineering: An idea whose time has come and gone?” (2009)  I guess I am just catching up on my reading.

One topic is: are metrics useful.

I think the real issue is: how useful is it that we ‘control’ projects?

His comparison is:

1. If we have a project that probably will cost $1 million and returns a benefit of $1.1 million, then we must control cost carefully. Or the project will be underwater.

2. If we have a project that probably will cost $1 million and returns a benefit of $3 million, then some variance in cost is not important.

His contention (and mine) is that there is plenty of work in category 2.

This does not mean have no budget and do no planning. It just means that we should not look at planning and control as the main drivers of success. The main drivers are: identifying the problem well, and delivering a truly innovative solution.

The term ‘release planning’

Posted on by
Reply

Mike Cohn has a good blog post about this, here.

I will agree and then slightly disagree.

Release Planning I think should normally mean planning the next release.  So, as Mike says, we are looking ahead a few sprints (1 or 3 or 10 or …), to get an idea what features we expect to include in that release. Or to see if the features we ‘need’ to release can be released by that date.

In agile, we assume nothing is fixed. In the sense that everything has some degree of negotiability. If it needs to. And we assume that everything changes, nothing remains the same. As the Buddha said 2000+ years ago.

But, when I (and others?) use the term we mean something a bit different.

We mean a set of tools and techniques, and a way of thinking, about how to plan the product.  Short-term and longer-term. And how this planning will feed the sprints (where we have ‘sprint planning’).  We do ‘release planning’ to feed the sprints.

‘Garbage in, garbage out’ we have heard many times. So we are trying to feed good stuff into the sprint, so that good working product comes out of the sprint.

***

I have to agree with Mike completely on this: More people are releasing faster now. Often every sprint. This is great, almost always.

So, does ‘release planning’ go away?  Well, the same tools and techniques may not be needed at all in some situations. This is true.

But usually, most firms have a lasting, evolving product. So ‘release planning’ (where you have one or more releases every sprint) becomes ‘product planning’ over multiple releases. And essentially the same tools, techniques and ideas apply.  ‘A rose by any other name would smell as sweet’ as Shakespeare said.

Do I want to stop using the term ‘release planning’? No. Because it is still useful to most people, I think.  But more and more I want to discuss the issues mentioned here, when I use the term.

For the longer view, Jeff Sutherland likes the term ‘product roadmap.’  He thinks most firms need a product roadmap that gives them an idea how the product will likely evolve over the next 12 months (some products less time, some products more time).  This seems like a sensible idea to me.

***

Guarantee, predict, estimate, commit, forecast.  Be very careful with these words.  Or similar words.  Do not mis-lead or mislead people.

‘To predict is difficult, particularly of the future.’ This was said in Latin some 2000 years ago. And remains true today, maybe more true.

Managers: It will not help you to drive a ‘death march’ or anything like it. Not to mention that it is immoral. They are not your slaves. Almost always, if you think they are lazy, then you have been too lazy to work with them closely.  Almost always, it is your fault that their work situation is so disrupted that they can barely get anything across the goal line for the customer.

Workers (if we may divide the world into managers and workers): Do not say things that the managers can easily mis-understand. Tell the truth. ‘No’ is often the right answer. Do not use weasel words that, to you, mean ‘no’, but to the managers are often heard as ‘yes’.

Early Warning System

Posted on by
Reply

I was giving a course today, and we were talking about whether to do agile release planning at the beginning of the effort.

(I guess I must add that release planning always means release plan refactoring every sprint. To whatever degree it is needed.)

My advice is that most teams that I see need agile release planning. For a day or two before they start sprinting.

So, one question is: why do agile release planning?  And there are many reasons.

One additional reason: Early Warning System.

The agile release plan gets reflected in a release burndown chart. And the release burndown chart can show the team if or when it starts to get into ‘trouble’ versus the stories they expected to delivery in this release.

And then, knowing that, the team can make adjustments.  But, they cannot know they are in trouble without an early warning system.