Is release planning worth it?

In a word: Yes, if done professionally.

How is release planning, and release plan refactoring…how are they useful?

A few ideas:

• It enables the Team to share ideas
• It allows the Team to see the same elephant
• It enables knowledge creation
• It enables cost, benefit, time trade-offs to become apparent
• It enables everyone to start to distinguish minor decisions from major decisions

Any professional also knows that planning is not and never will be perfect. So, we must put areasonable time box on doing the planning.

It is also useful to plan with good ‘agile’ people. Meaning people who will use the information developed from planning in a useful way (eg, will not do the ‘stupid waterfall manager trick’ of expecting the Team to always hit the date they planned on Day Zero).

Let’s talk about this last one (minor versus major)…

To put things simplistically, there are two types of decisions, which I will call minor and major.  Minor decisions has a minor cost if we make them incorrectly.  If we are clever, we soon learn that we are wrong, and we correct the decision.

But some decisions are major. To change the decision later, it can be very costly in terms of money or time or reputation or some other factor.  Once we identify a major decision, we want to do our best to decide it correctly.  This means first being sure we have framed the decision question correctly.  Then, assuming this is a difficult decision, we want to make the decision at the ‘last responsible moment’.

***

Can planning be useless or worse?

Well, of course.  If you have people who will not learn.  If you have people who will take longer than the current knowledge can justify.  If you too many people who want to use the information for ‘stupid waterfall tricks’.

But if done with good people, using useful concepts, the Scrum Team (and others) can learn a lot doing Release Planning, followed by Release Plan Refactoring every sprint.

It is also true that we can learn by doing ‘real work’.  This is not to say ‘do only real work’…but one balances and shortens release planning (release plan refactoring) in the knowledge that we can and will learn some things faster by doing real work.

Who is Scrum For?

A few months ago someone I know and respect in the Agile community said that they do agile to make the world safe for programmers.

This phrase as stuck with me. I don’t know how seriously the person meant it. I suspect it was partially a joke and partially a stronger statement than one might think.  I suspect it is a real driving force for that person.

And it is true that many implementers have had terrible lives, at least often, and making the world better for them is a very good thing.

But I think we should strive for more than that.

We need to make the world better for everyone.

For example, the customers do not want software (usually), they want something useful that will make their lives better.  The managers need a better life.  The project managers need a better life.  The business owners need a better life. The testers need a better life.

Everyone around or affected by Scrum should be getting a noticeably better life.  And one easily noticed, in terms of the improvement.

This is happening, although it is not happening as much and for as many people as it should. And when it is happening, it is not being noticed and celebrated as much as it should.

Why?

Well, I think one fairly important reason is that too many of us are being selfish.  For example, we are so afraid that the programmer may have to work and be modest and admit failure, that we disable the mechanisms (velocity and demos, for example) that enable the customers and business people to collaborate with the Team.

Anyway: It is an odd request. We want everyone’s life to improve at the same time. No trade offs.

Can it be true every minute?  Well, perhaps not.  But can it be true every sprint, looking back at the sprint in total?  Yes, I think so.

Joe’s Agile Release Planning

I have written a new booklet that I want you to have (I think you will find it useful) and also to comment on.

It is about Agile Release Planning.

It proposes that agile release planning consists of these major steps (at least):

1. Assemble the Team and some business stakeholders
2. Agree on the Vision (of the release or maybe more)
3. Create the Product Backlog
4. Determine the Business Value
5. Estimate the Effort
6. Consider Risks, Dependencies, Learning, MMFS and other factors
7. Order the Work
8. Do the scope-date trade-off
9. Finalize the initial plan
10. Consider the ‘communication plan’

Note that the purpose of the work is not focused on the release plan itself. The most important purpose is the Team together with the business stakeholders start seeing the same elephant.

So, I wrote a booklet to show and explain how I teach teams to do each of these steps. And to address some of the ‘lessons learned’ in doing this approach in the real world.

I hope you will read it and comment. Please download it here. It is 28 pages.