Comments on: Miles Per Gallon

By: Alan Shalloway

Alan Shalloway — Sun, 12 Jul 2009 16:53:48 +0000

see reinertsen’s work – managing the design factory, and principles of product development flow
Womack and Jones’ – Lean thinking
These have much of it.

True that our descriptions of what is going on is not exactly the same as what is going on. But they can still be useful.

By: stochasticresonance

stochasticresonance — Sun, 12 Jul 2009 16:50:25 +0000

I’d love to see the rules/laws articulated but I believe trying to codify them is an exercise in futility.

Please prove me wrong…

the Tao that can be spoken of is not the Tao…

By: Alan Shalloway

Alan Shalloway — Sun, 12 Jul 2009 15:41:26 +0000

If you don’t understand the theory (aka rules/laws) underneath product/software development, measurements are very likely to be misleading. Unfortunately, several leaders of the Scrum community resist that such a theory exists. If you embrace theories that have been demonstrated by decades of work that support product development, then measuring things like cycle time, delays from error to detection, and a couple of others, can be very useful.

Software development is a very complex endevour. It can be hard to understand, but that does not mean it is not understandable.

By: stochasticresonance

stochasticresonance — Mon, 24 Nov 2008 17:05:38 +0000

Israel,

(I appreciate the comment)

I might not have made it clear in my writing, but what I’m pondering is sustained efficiency as much as velocity.

I believe anyone who works with technology would recognize that higher quality enables higher velocity.

To extend the auto analogy, the engine, brakes, transmission, steering and tires can all help increase the safely achievable speed.

But for any given automobile, the style of driving effects not only the velocity but also wear and tear.

In some situations, such as a race with a clear finish line, ‘winning’ might justify driving without concern for anything but that goal, but it costs quite a bit to maintain a race car. Sometimes that is a justifiable cost.

The question becomes what you are trying to optimize and what you are aware of. If you are just trying to get across town, do you know the right velocity to time the red lights or do you cycle between acceleration and braking because you are ‘in a hurry’. Both approaches get you to the same place at roughly the same time.

One has a much lower long term cost, but it is difficult to measure that cost moment to moment.

By: Israel Gat

Israel Gat — Mon, 24 Nov 2008 03:59:17 +0000

in a recent Cutter Consortium Executive Update, Jim Highsmith has made the following observation with respect to velocity and quality going hand in hand:

“A number of quantitative studies done in recent years by Cutter Senior Consultant Michael Mah attest to the higher quality of many agile projects and the positive impact on scheduling.”

By: Working Together… with Techology « fate = will && choice || circumstance

Sun, 28 Sep 2008 07:33:08 +0000

[...] not even sure where that would lead. I do know that new information enables optimization, both specific and systemic improvements. (but hopefully not draconian notions of productivity… [...]

By: James Turnbull

James Turnbull — Fri, 15 Aug 2008 06:15:38 +0000

I am also interested in the conjunction of velocity and quality. Too many projects measure velocity without monitoring quality. Doesn’t matter how much velocity you have if it doesn’t deliver the functionality.