Velocity!!

---

"At every turn, leaders chose velocity and production over efficiency, thrift, safety, and even prudence"

Ian Toll, Historian

Well, of course, Toll is describing the build-up in the western Pacific in the closing year of WW II. Most, but not all of us, will not have projects in which velocity is prioritized over safety.

Most of us, but not all: In the last 20 years, such has been the case in not a few project instances, in support of wartime emergencies.

Velocity is just a rate

For the math inclined among us, velocity is a rate: something per something else. 

For those with a little calculus training, it's the first derivative of the steady state, expressed as: dx/dt, a small change in the steady state during a small change in time

Velocity is throughput

But for the PMO, velocity is about throughput: Project input -- not especially valuable to the end user -- integrated and transformed into something that is especially valuable.

How fast can you do that? Whatever the answer is, that's "velocity". The rate at which value is produced for the end user. 

Velocity at what cost?

Now, back to Mr. Toll's observation: Apart from safety, it may be that the project office is willing to suffer lots of rework, blind alleys, cost incentives, inefficient process, and inefficient redundancies in order to get some throughput at an high pace.

So be it. But when it comes to safety, we enter a new realm of risk in which the penalties can reach all the way to the criminal. 

But if not criminal, there still can be unimaginable costs: One can only wonder if the Challenger and Columbia would be in a comfortable retirement if only safety were not subordinate to some element of velocity.

---

Buy them at any online book retailer!

Innovation or efficiency

---

For F.W. Taylor, the scientific management guy, success was to be found in efficiency. He was the guy with the process stop watch and the job descriptions. But recently, efficiency has given way to innovation, even in PM. Traditional methods, honed and efficient, have been displaced by agile and empirical methods, not particularly efficient they are, but resilient with failure, to be sure.

WW II  and innovation
Now, it may seem that a war that ended some 60 years ago this summer is a bit distant to connect to contemporary dots. But no! WW II ushered profound changes into the culture and society of the United States that is fuel for the innovation fire.

• WW II empowered 50% of our workforce for the first time. Women entered the workforce in large numbers doing jobs never open to them before. They have never looked back
  
  WW II beget the 'GI Bill' that sent millions to college and all but invented the modern middle class from which yet more innovation, inventiveness, and entrepreneurship has arisen.
  

The scope of WW II projects was unprecedented, leading to the military-industrial complex that defined and codified program management, system engineering, risk management, analog simulation, and a host of other project practices heretofore unknown or undefined.

• WW II unleashed innovation as no other world event. The modern research university was empowered. During the war, the laboratories at MIT and CalTech and Stanford were at the forefront of new ideas, inventions, and applications. Since then, a multitude of research universities have been drivers of the innovation explosion in the United States.
• Although the war drove atomic science, atomic science drove quantum mechanics, an understanding of the sub-atomic structure. From this we have all manner of semiconductors that have in turn been the underpinning of the information age.

Throughput won the war
The enormous industrialization of WW II all but put defined process control on the map. Repeatable process and process control gave us unprecedented throughput. Who knew you could build 55K ships and 600K aircraft in four years?

And now, we have "throughput accounting" which many say is the only way to value projects: the value is in the "add", ignoring the infrastructure and permanent staff sustaining cost that gets allocated into the project overhead.

The "good" war?
It sounds like "...there's nothing like a good war".  But that's not the case.  The emergency of warfare has always raised the bar.

Before the U.S. civil war in the mid 19th century, railroads as a means for tactical support for forces was unheard of; so also electronic messaging ... the telegraph in those days ... changed not only the timeliness of reporting, it changed forever the influence of "high command" on the tactics of the moment.

What we can say:
Innovation, as a consequence of great national emergency, is the sidebar that always gets a boost.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

That velocity thing

Jim Highsmith, a guru in the agile space, has an interesting post on that velocity thing. Velocity, you will recall, is the agile name--originally an XP name--for the rate throughput can be delivered to customers, or, if not delivered to customers, the rate at which throughput--finished deliverables--can be queued for rollout according to some rollout strategy and workflow.

 

Now, the idea of throughput is not an agile thing, per se. Go back to the mid-1980s to Eliyahu Goldratt's Theory of Constraints (TOC). TOC is all about optimizing at the enterprise or project level  maximum throughput to customers. Velocity was not a Goldratt idea, but Eliyahu certainly focused on cadence, using the metaphor of the drum-buffer-rope.

 

Of course, project managers may know Goldratt for his theory of the "Critical Chain", a risk management strategy for insuring on-time delivery. Critical chain is an outgrowth of TOC, and it's Goldratt's idea of how to put some of his throughput management ideas into the body of knowledge for project management.

 

I digress--as often happens here at Musings--so back to Highsmith's lament: he says that having positioned velocity as a calibration metric on team performance, project managers should not then count on teams to achieve the predicted performance because a emphasis on performance may then trump quality, the ultimate goal of an agile project. Even the customer may become part of the problem. In his words:

 

• Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.
• Focusing on volume detracts from the quality of the customer experience delivered and investing enough in the delivery engine (technical quality).
• Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine. 

Dean Leffingwell makes a similar point in his book "Agile Software Requirements: Lean requirements practices for teams, projects, and enterprises". He says that if the velocity metric is turned back on the team by managers, the team will do one of three things:

1. Practice continuous improvement to meet management objectives
2. Sacrifice quality in the name of speed, or
3. Sandbag estimates to create velocity buffers

Of course, my point is not to use the metric to amp up productivity, (that's Highsmith and Leffingwells's fear) but to use the metric as an expectation suitable for estimating. If you can't estimate, what's the point of the metric?

And, they've got a point about sacrificing velocity if quality is the ultimate driver. But that puts 'better' as the nemesis of 'good', and puts in question the real advantage of agile that, in my mind, is delivering best value (which could be different from best quality, though I've not thought that all the way through).

And, you ask, what's my idea of best value? Simply put:

 

• Best value is the most valuable outcomes achievable, as judged by the customer, for the investment available from the sponsor
• Best value is the most bang for the buck, a best compromise of scope and quality in context of fixed investment and a critical need date.

By the way, I'm all about throughput. You really can't do a decent job as a agile manager unless you can benchmark for throughput and then hold teams accountable.

 

The issue is: accountable for what? I say the answer to Highsmith's issue is to get the iteration backlog right with the customer and the project team at the point of release planning. Once planned for best value, then bring on the throughput!

 

 

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Throughput accounting

Throughput accounting is a form of earned value measurement and it is closely aligned with the Theory of Constraints [TOC]. Throughput accounting can be summarized this way

Throughput accounting measures the value added to the business, process, or entity by virtue of project accomplishments

Value added is only measurable as an accomplishment, presumably an operational difference in the business, process, or entity that makes a meaningful difference.  In effect, what is being measured is how much more valuable is the entity now than before. If expenses are lower, than the business is a more valuable transformer of revenue into profit. If a public sector mission is more effectively accomplished, then the entity is a more valuable contributor to public "welfare".

Value added is a "difference calculation"; in EVM terms, it's a variance. The absolute values of each factor in the difference are less important that the difference itself.

So, what's not accounted for in this variance calculation? Answer: operating expenses [OE] of the project...expenses traditionally called 'actual cost' [AC]. Why exclude AC? The idea is that PMO's and project shops, particularly IT shops, have more or less fixed operating costs. If not this project, then some other will absorb resources. Also, most IT projects involve contributions from non-IT sales and operations staff that are 'fixed costs'. Unless there is some direct incremental expense, like a special tool or facility, or a direct contract for services...like a consultant...then the day-to-day OE of the project is not included in the value difference. If there are such direct and incremental expenses, then they are included as part of the value variance.

The figure below gives a pictorial of this idea. "A", "B", and "C" refer to different projects

What's the tie-in with the TOC? TOC is about managing limitations to throughput, where throughput is defined as something a customer or stakeholder would find valuable. Insofar as a constraint can be minimized or mitigated, throughput increases. Thus, the need for throughput accounting.

Some AGILE practitioners have adoped this idea also. In fact, there is a pretty good book on the subject: David J. Anderson's 2004 text "Agile Management for software engineering -- apply the theory of constraints for business results"

 Bookmark this on Delicious

Are you on LinkedIn? Share this article with your network by clicking on the link.