Getting higher velocity! Take 2

I posted yesterday that these things listed below would lead, or at least could lead to higher velocity (higher productivity) in your new product development teams....

* Better retrospective meetings
* Better impediment lists
* Better business cases to management
* More effective action (get approval and implement one 'fix' until you get results)
* Better use of velocity numbers

More many of you, I suppose this seems like just saying "work harder", with no real clarity on what to change from what you are doing now.

So let me add a few comments.

• Retrospective Meetings

Too often I hear that a team is no longer doing them every Sprint. Or that they are bored doing the same ole pluses and deltas.  Again.

First: what is the goal of the meeting?  The key goal is to identify and attack one good-sized impediment.

Frankly, if we have a public impediment list, identifying the top impediment should not usually take that long (more on this later).

Good-sized?  Well, not too big ("world hunger") and not to small (one biscuit for Mary).  Something that will, when fixed, give a meaningful jolt to team velocity.

Attack? This is usually one of two things: (a) a business case to one or two managers, to convince them to approve the fix, or (b) a design of the fix and a plan to implement the fix.  AND, it means attacking in an aggressive way both of those (getting approval and then implementing the fix) until the velocity improvement is realized.

I discussed Retrospective meetings earlier.  You may want to look at that post.

I also recommend the two classic books on Retrospectives: Agile Retrospectives by Derby and Larsen and Project Retrospectives by Kerth.

• Better Impediment List

The first thing here is a public list.  So everyone can add to the list and argue about the prioritization.  All the time I see no public impediment list.

Let me be clear.  Until the team is perfect in everything is does, there are always the top 20 things to fix (make better).  PS. I have never seen anything close to a perfect team. Some very very good teams, yes, but nothing close to a perfect team.

The second thing is getting everyone creative about identifying the most useful things to change.  Far too often the best ideas are not identified because people can't imagine them being changed.  So, they never make the list.

There are many ways to get more creative.  I will suggest two for now.

1. Help them give themselves a challenge. Something like this: "What would we have to change around here, assuming anything could be changed, to enable the team to go from a velocity of 20 to 40 in 6 months?  Assuming we only worked a normal work week and that we had more fun." 
2. Get an important manager or two to talk to them and say something like this: "I am willing to consider changing anything around here, assuming you make a good business case and assuming the velocity improvement or other benefit usually turns out to be real. Anything.  I can't guarantee I can approve everything, but I am willing to consider it. If you guys are not trying to break the rules, you're not trying hard enough."

Those two might start them being more creative.

• Better Business Case

I find teams do not know how to make a good business case to a manager.  Sometimes a manager will see their point (that a change must be made) but usually it is the manager actively reaching out to help, rather than the team convincing the manager in the manager's own language.

I recommend that the team must learn how to make a business case.  For eveyone's sake.  (Yes, I know they only want to do the 'real work' of building the product, but they still must learn the basics of making a business case to improve things.)

They can use any method. I like the A3 format and approach, but that's not the only one.  And it might not fit every case. They must address the benefits and the costs.  And usually estimate (project) these in money terms.  The managers typically want a 6:1 ratio.  Because they know you are lying.  They know the benefits will be less and the costs will be higher.  After you develop a good track record, then they will likely accept 3:1.

If you know the velocity of the team, if you can estimate the expected change in the velocity, if you can estimate the cost of the team and if you can estimate the expected money return in NPV (net present value) over the forecast period of the product (say, 3-5 years), then you can estimate the money impact of a small change in velocity (say, a 10% change).

Yes, these estimates may make us feel uncomfortable.  More on this later.

The A3 format I use is: Problem, Solution, Benefits, Costs, Action Items, Measurements.
All of these must be addressed briefly on an 11x17 piece of paper.

This last section (measurements) is important.  This tells the manager that you will prove later that the 'fix' was successful.  If nothing else, this shows him or her that you are willing to be measured.  It tells them 'this person really believes in this change'.  Which is a good indicator for its success.

In a recent year, Toyota did 1 million A3's.  I think this means 1 million were implemented. That's one per person per month.  So you see some firms find this a productive approach.  (Yes, I wish Toyota had not made the mistake of going for an anti-lean goal of being the largest auto manufacturer.)

Let me stop there for today.