Getting higher velocity! Take 2

I posted yesterday these 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

To 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 a Retrospective at the end of every Sprint. Or they are bored doing the same ole pluses and deltas.  Again.

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

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

Good-sized?  Well, not too big (“world hunger”) and not too small (one biscuit for Mary).  Something that will, when fixed, give a meaningful improvement to team velocity. An impediment that can be improved in 2 weeks or less.

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 and a plan to implement the fix.  AND, it means attacking in an aggressive way, (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.  Everyone can add to the list and argue about 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 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 creative 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.

a.    Help 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 we had more fun.”
b.    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 or will 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 more creativity.

    Better Business Case

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

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

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. Typically they must address the benefits and the costs.  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.

One example of the A3 format I use is: Problem, Solution, Benefits, Costs, Action Items, Measurements.
All of these must be addressed briefly on an 11×17 piece of paper, according to a typical A3 approach.

This last section (measurements) is important.  This tells the manager that you will prove later 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.

 

« « Getting higher velocity! || Nokia Test: Know your velocity (7) » »