Agile Release Planning workshop - Comments

I have many comments to add to the blog, and many topics to discuss.  Let me start with this one.

Last week we had another Agile Release Planning workshop, in Montreal.  (We do one almost every week.)  The workshop is mainly about taking a real set of work (about 6 months of work for one team), and doing real agile release planning.  This is explained in this blog, and at LeanAgileTraining.com (for any specific workshop), and in my book, Joe's Agile Release Planning.

First, most everyone in the group said 'this is the best' or 'this is when it all came together'.  These are frequent comments from the workshop.

Today, let me talk specifically about Serge and his team, which were all from one company.

They took a brand new set of work, which the company has to do soon, and planned it out.

It was so good that Serge took the release planning information (the product backlog, etc, etc), back to the office.

***

They had two issues that struck me.

One:

They are used to developing the backlog in isolation from the Team, by one or two people.

And, to be fair, many of the people in the workshop were not members of what will be the real team.  Still, I think Serge started to see the value of creating the backlog with a Team.  And the team members did too.

And, later, all the individual detailed work could be done.  Research, cross-checking, etc.  So, the difference from what they used to do (have 2-3 'experts' develop the initial product backlog)....the difference ends up being mainly timing.  Now, the Team (with business stakeholders) does it first, and then the individuals can work on it later and make it better.

Why is this better?  Well, several reasons.  I will list two.

1. It greatly reduces the time before we start 'real work'...I'll call that real work 'writing code'.  And with code we can get feedback from 'the real world.'  So, instead of waiting 3 weeks before we can 'start', we can start the next day (well, honestly, usually it takes a few days more).

2. It enables the Team to have their hands in at 'the creation.'  This has two benefits.  One, it gets their creativity involved.  One consequence is that some of the 'missing' stories are identified now.  Two, it changes their motivation.  They no longer get the mushroom treatment.  And they start to see, by working on it, how all the pieces fit together.

The only downside is, this is a change, and to some degree some people may resist, and you have to explain it to them.  But I have always gotten people to do it fairly well the first time.  (Can you alone get them to do it the first time?  Maybe not.)

Two:

How to do Priority Poker?

In this case, the company has few 'business stakeholders' who will show up.  It is a small company, and one of the people who 'should' show up and do this is the CEO.  But he does not have the time.  And there is a sales person who also has some good insights, but who might take the Team in 'his own direction' ... we will say it that way.

And, Serge is right -- this is not ideal.  And, getting really good business stakeholders is hard and has problems.  Almost always, at least to some degree.

Still, we can get the ...well, best people we can get.  And then use the poker cards to vote, and then average the answers.  And put business value points on each story.

And, as is always the case, we will feel and in some sense know, that this is not perfect.  Except that, the BVPs are the best guesses by the best people we can get to do this at this time.

And then we can do things to improve the numbers.  Starting the next day, maybe.

One obvious thing in this case: Take the product backlog with the BVPs (business value points) and show them to the CEO, and then get his opinion.  And often he suddenly says something like "wow, I wish I had been there...I want to be there next time....but let's change the BVPs on these 10 stories."  And you realize that for 40 out of 50 stories, the CEO is agreeing we did a good job, and he is 'only' changing 10 of the stories.  And usually by not really that much.

AND...the exercise and the numbers enables the CEO to realize that he should act differently with the Team.  The information becomes evidence that causes him to change his behavior.

Well, I do not know that with these numbers and this CEO this has happened this time, but I do know that it can.  With the right CEO and with the right advocate.  (It may be that this CEO really really is too busy, for example.)

***

I hope these key observations (for me) also lead to useful thoughts and actions for you.

If you have questions or comments, please speak up (below or via email).