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.

Two Levels of Agile Planning

Almost all firms that I work with have at least two levels of planning.  We can call them “high level” and “team level”.

High Level                     

At the high level, project or product ideas come in.  Someone has to prioritize these opportunities initially, to see which ones make the cut.  Often this is formally done once a year (not our recommendation).  Often this is done by a small group, sometimes called a committee.

Depending on the size of the organization, high level could be for the firm, for the division, or for the department.

The committee considers the benefits and the costs and maybe some other factors. Sometimes the benefits and costs are formally calculated, and sometimes they are just ‘discussed’.

But usually, the committee comes up with a 1 to N list of projects that should be done ‘soon’ (again, often this means in the next calendar year).

Some recommendations to make this more agile:

• Do it with greater frequency (eg, every month for the Top X projects)
• Expect the numbers to change over time
• Make the numbers explicit
• Do as ‘team knowledge creation’
• Get feedback
• Consider how accurate it is, can be, and needs to be

Team Level

We believe every project should go through ‘release planning’ after it has been assigned to a Team.

The Team should do release planning again (it is like what the committee did) for the following reasons:

• it is being done at a lower level of detail, on only high priority wor
• time has past, so information is likely to have changed
• the Team needs the detailed information
• it affects Team motivation
• it enables everyone on the extended Team to get on the same page

We also recommend that the high level results of the Team release planning should be given as feedback to the committee.  The committee may have questions and may raise issues that the Team neglected to consider.  But more likely, the committee will learn more about how badly they mis-estimated or mis-understood the work.  And this is useful feedback for them.

Something Unexpected

What do we do when something unexpected happens?

“The readiness is all”, said Hamlet.

And so must we be ready. Not ready to be fools and become silly. But ready to meet that new thing, that innovation, that crazy idea, that new person…more than half-way.

Yes, we may be skeptical. Yes, as Polonius says (careful grandmother that he may be)…we must try our friends well before we truly take them in. [Note below.] And so we must also for innovative ideas.

But first we must be open to them.  We must take a risk. And try.

As many a Zen Master has tried to open many a student’s mind to satori.

This all comes to me by way of a new friend made last night, rather unexpectedly.  Well, completely unexpectedly. We were forced together, sitting beside each other.  Rather than sit in stony silence (as they say) we talked.  Exactly why or how it happened, I cannot explain.  And, while I deserve little credit for it, it was an amazing and far-reaching conversation.  Very satisfying on many levels.  I will take some credit that I let it happen. And in part it happened because I had no expectations. I asked and said what I wanted to say at the moment…but I was not trying to win or convince or do or accomplish anything.  Well, occasionally I wished to be polite and kind and teasing (as some of you know, I like to tease my friends). But mostly I had no big goal, except to learn and discover.

And later, I was sad. Not sad to have had the conversation, but sad that it had ended.

So, I give myself that credit. And I take it away too. I did not follow up well. The friendship made, the conversation started…  But it may never happen again because I probably have lost contact.  I was too polite.

And this is true of our ideas about innovation as well. We must have the idea, let it in, remember it, and then do something about it.  See if it will fly.

So here and now. A moment to imagine in your mind the blue birds of your happiness. May they fly. Wonderfully.

***

Note: The reference above is to the famous speech by Polonius to his son Laertes, which I have copied here.  Polonius is of course proposing that his son be far more careful than I am suggesting in this post.  I am suggesting more openness, more readiness.  But I am not proposing that we be careless, either.

3 Methods to increase Business Value

Yesterday I enjoyed talking to Southern Fried Agile, the local one-day agile conference.  My topic was this: Three steps toward greater business value.

I was also pleased to see that many participants said they wanted to talk about this subject. So much so that the organizers decided to run the session twice. I am happy that this is considered an important subject. Certainly I think it is.

Some things we already do in Scrum to increase Business Value (or should do):

1. Better partnership between Business and Technology
2. Improve the Product Owner (and give him or her this job)
3. Use a prioritized Product Backlog
4. Order the Product Backlog to maximize the release of Business Value (over your chosen time frame)
5. Build working product each sprint (if we get cut short, at least we can field what we have so far)
6. Demo working product and get feedback from business stakeholders each sprint. Ex: “Did we build for you the most value stuff this sprint?”
7. Release more frequently

Could we be doing each of those better?  (Ok, sorry for the rhetorical question.)

In the presentation, I suggested three “big” additional things we could do.

A. Business Value Engineering…

This is a framework for continuously getting better at delivering business value. By mapping the process, by articulating the underlying assumptions, by taking a fact-based approach to proving which improvements would be better.

B. Priority Poker

This is an easy thing to add to Release Planning or to Release Plan Refactoring. Or relatively easy. You enable the “5″ best people on business value (in your specific domain) to learn from each other more about business value. By voting “business value points” on each user story.  And the rest of the group learns too.

C. The Pareto Idea

This is classic, and in some sense, almost everyone does it already.  Except they don’t do it enough. And they don’t take it as a basic, everyday, mindset.  So, we fight every day to separate more the gold-platinum-diamonds from the silver-copper from the dirt.

This is a lot of hard work, every day, that we do while we break down the stories into small sprint-sized ones. (I like about 8 stories in a 2 week sprint.)

***

There is much more to all 3 of these ideas.  To be discussed later.  But they attendees seemed to like the ideas. But the real question is whether they got enough to start taking action (if only to learn more).  We shall see, I hope.