Agile Open. Day Two.
We planned to start day two with a re-planning session: look at the plan we made yesterday and adapt where necessary, based on new information. Raphael then asked the question if we shouldn’t try to go more with the “open space” idea, instead of having planned sessions. We decided to have a planned session in one track (the XP Game) and an unplanned session in the other track.
That meant I got to play an XP Game for the first time, after having hosted so many runs. I discovered I’m crap at inflating and putting knots in balloons. Halfway through the game I had to leave for the next session. This gave my team the opportunity to learn what you do when 1/4 of your team leaves: you reduce your velocity to 3/4 of what you produced in previous releases.
Metrics and Thoughput Accounting
I proposed this session to get some input. Throughput Accounting has basically three important variables, expressed in monetary terms for convenience:
- Throughput = fresh money coming in from sales
- Operating Expense = money going out to keep the company going. Once spent, the money is gone (wages, energy, rent…)
- Investment = money that must be put in to be able to generate value. This is the most tricky category to explain.
Of course, time is also involved. The longer the time it takes to generate throughput, the higher the investment will be. To emphasize the fact, I keep time as a separate variable. All these variables are pretty easy to measure at the company level. We want to align the work we do with an improvement in these company metrics: increase throughput or decrease time, investment or operating expense.
The goal of the session was to find some metrics or indicators at an individual (IT) project level. We brainstormed some potential metrics for each of the 4 throughput accounting variables.
The throughput accounting variables and formulas are very simple. The only problem is that all the variables are interrelated. If you change one component of I, it’s going to have an effect on t, T and OE. And vice versa. You can’t really create a mathematical model of a project, but you can apply systems thinking. The advantage of methodologies with short iterations or releases is that you shorten the feedback loops, thus making it easier to see the result of your action and react in time.
We didn’t come to a conclusion. I’ll have to do some more thinking about it. Expect some throughput accounting posts in the near future…
Pascal,
When you get done thinking, odds are you’ll come to the conclusion that most significant metric is cycle time. Taichi Ohno of Toyota described their system as follows:
“All we are doing is looking at the time line from when we receive the order until we collect the cash. And we are eliminating the non-value adding waste along the time line.”
I’ll betcha your more Goldratt-esque approach will ultimately take you to the same place.
Bill,
I expect that cycle time will be at the top of my list. But… “cycle time from requirement to something that satisfies that requirement”. Something that’s sellable.
The problem is that we still have some trouble getting to something that satisfies the customer, no matter how long we take. Most people tend towards the “common sense” solution of large batches and local efficiency. Because, you know, “better quality takes longer and costs more” 😉
As I say in my presentation comparing Lean to Agile Software development:
“Lean is about flow.
Agile is about flow.
Cash flow.
Next time you talk to your CFO or CEO, don’t talk about “agility”, responding to change, quality. Tell them what you’re doing to reduce the time between the customer’s need and you fulfilling that need. Tell them how you reduce the time between the customer’s need and the moment they pay you.”
That cash flow bit is straight out of the “Rebirth of American Industry” 🙂
If that doesn’t get their attention, I don’t know what will…