Tuesday, October 30, 2012

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.

Friday, October 19, 2012

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.