Friday, June 04, 2004

World Class Velocity

The American media is winding itself up for the feeding frenzy that will be Lance Armstrong’s attempt to win a record breaking 6th Tour De France this July. Meanwhile, one of his rivals, the somewhat Scottish David Millar spent a month on a voluntary ban from cycling whilst his team was investigated for drug taking. Millar gave this interview to Scotland on Sunday to express his feelings about it. The important words for me are…

It upsets me to think that people assume every pro is on drugs. Just because people can’t comprehend the level of fitness and ability that some riders have, they now assume they all do it on drugs.

It really is difficult for ordinary folks to comprehend how guys like Millar - the World Time Trial Champion - or Armstrong, can ride a bike for long distances at average speeds exceeding 27 miles per hour. In fact in time trials, both Millar and Armstrong regularly top 34 miles per hour for a distance of 30 miles.

Now I’m no slouch on a bicycle on my day, and back at the time of the Singapore project I was riding mountain bike races in Indonesia, Malaysia and Singapore. On one race, I came in (a distant) 15th, behind a winner who just the previous month had picked up the gold medal in the Commonthwealth Games for the road race. Another regular racer, an Australian, had a gold medal from the olympics (for speed skating). Now these guys were about 15% faster than me - and that is a lot believe me, its huge when you have to chase after it. In turn, neither of them could have lived with the European pros who are perhaps 15% faster again, and most of them can’t stay with a Millar or an Armstrong who are maybe 5% faster when it suits them to be.

These days I get around Seattle on my bike at about 22 mph. Armstrong can happily scoot around his home town of Gerona, Spain at 34 mph - a better than 50% productivity improvement over me - and people think he is doing drugs.

So is it any wonder, when I tell people (indeed, show them with metrics) that agile development team A is 5 times more productive than team B who in turn are twice as fast as team C at another location, that people don’t believe me? After all, these programmers are only human - right? How can it be possible to go 10 times faster? Just what kind of drugs do you take to make that possible? Is it time we banned these prescriptions with names like FDD or TDD or XP in order to level the playing field for everyone else? Perhaps some police raids to dig out the story cards and some spy equipment to detect morning stand up meetings? It is disgusting that some developers can go so quickly. It has to be stopped!

[Update: July 7th, 2004 - In rather sad reports recently it turns out that David Millar has admitted to taking drugs on at least 3 occassions over the past 3 years and he is likely to be suspended for at least 2 years as a result of his admission. There is speculation that his career as a top cyclist is over.]

Thursday, June 03, 2004

Quality as a Competitive Weapon

Recently, I was putting together an article for the Cutter IT Journal which will appear over the summer. The article is essentially a re-write and update of Chapter 8 - The Agile Manager’s New Work. If you want a sneak preview then you can pull the draft down from the Yahoo! group files section. It will be there for another week or so.

Without giving the story away, the article contains this diagram - Donald Wheeler’s States of Control matrix derived out of the work of Walter Shewhart.

This chart can tell us almost all you ever need to know about the Six Sigma approach to continuous improvement. The rows show the difference between assignable cause and chance cause variation (these are better known by Deming’s terms - special and common cause variation). However, Shewhart’s original terms are perhaps more useful to us when considering agile management.

Assignable cause. Something which has an assignable cause is identifiable. You can point to it. As such an assignable cause problem which has not happened yet, is a risk and should appear on a risk management plan. As assignable cause problem which has happened should be on an issue log. Chance cause. Variation which is endemic to a process and cannot generally be identified as having a root cause is chance cause variation. Chance cause is the idea that Feature 167 with Complexity 2 took 1 hour and 40 minutes to design, whilst Feature 168 with Complexity 2 took 2 hours and 10 minutes to design. Chance variation in the interaction of the team discussing the design problems at hand.

The columns are named after quality but the meaning is more general than most associate with the term. Conformant quality from a project management perspective might mean “all functionality, delivered on-time, with a defect level below 20 bugs per hundred features”.

So now let’s consider the 4 states of control. Chaos, says that we have assignable cause variation and we have chance cause variation which is producing non-conformant quality (e.g. our estimation isn’t accurate enough). Brink of Chaos, says that we have our chance cause variation under control but our assigned causes mean that anything can happen. In other words, we aren’t running down issues fast enough before they hit the critical path, or our risk mitigation policies were insufficient. The Threshold state is saying that we have eliminated assigned cause variation but our chance cause variation is still not under control. Finally, an Ideal project has eliminated assigned cause variance, whilst demonstrating that chance cause variation is within tolerance and the product is conformant with our measure of ultimate quality.

Consider, Philippe Kruchten’s observation of the near linear progress, from  Facilitating Near Linear Progress, in my CFD from a recent project.

This project would be considered to be in the Ideal State. As I stated in Facilitating Near Linear Progress, the project used the morning standup meetings to surface issues early and the team leads and project manager did a good job of running them down before they became critical. So assigned cause variation was eliminated. By focusing on the basics of the FDD method and doing the design, design review, code review and unit tests properly, the code quality was high, and the granularity of analysis and estimation was accurate. The Critical Chain probabilistic buffer based on uncertainty meant that the project was delivered on-time, with the agreed function with almost perfect quality.

So how do you use this framework for competitive advantage?

Well it all depends on what you define as “conformant quality”. Have you ever considered what it means when a world class golfer says that he is “rebuilding” his swing? At that level of golf, a player can go hit balls all day with regularity. The idea that assigned cause problems affect play is rare. Clubs don’t break, bees don’t sting in mid swing, low flying aircraft pass by very seldom. Most problems in golf are chance cause problems involving the system of swing. The horizontal barrier between the Threshold State and the Ideal State is defined competitively. For example, it used to be good enough to drive 275 yards and land the ball in the fairway 75% of the time. Since the arrival of Tiger Woods, a top player now has to drive 290 to 300 yards and land the ball in the fairway around 80% of the time or better. If they can’t do that then they can’t be competitive. Players who can’t do it are in the Threshold State - the don’t deliver conformant quality - which for them means they don’t win any tournaments. In order to move right to left on the diagram they need to change their swing - their system of hitting a golf ball. They need to change in order to reduce the chance cause variance whilst delivering the new higher standard of conformant quality. In golf, Tiger Woods moved that bar to the left and pushed his competitors into the Threshold state.

Moving the process right to left on the Wheeler chart is what the Six Sigma DMAIC (Define, Measure, Analyze, Improve & Control) process is all about. There is a separate Six Sigma process for eliminating assigned cause variance - or as team behind Ford Global-8 call it, “recovering from a special cause situation” - which is designed to drive a process vertically on the Wheeler chart.

Application to Agile

So consider what agile methods are doing for software. Processes like Scrum try to eliminate assigned cause variation through the communication mechanism of morning standup meetings. Scrum is all about moving a software development team vertically on the Wheeler chart. Whilst Unit testing, Test First and Refactoring, are mostly about eliminating assigned cause too - they do offer some contribution to the process consistency which improves the chance cause variation. However, in order to reduce chance cause significantly, we need better analysis mechanisms and better ways of sizing functionality, assessing complexity and assessing the unknowns - the uncertainty. To get to the Ideal State we need to have methods for codifying this. This is where Peter Coad’s work with Domain Modeling in Color and the Feature Template really helps. Hence, attempts like Mike Cohn’s to codify XP story writing in User Stories Applied give us a chance of moving eXtreme Programming from the Threshold State to the Ideal State. It is only by doing both - by addressing the chance cause through better analysis, planning, feedback and reflection - as well as addressing the assigned cause variation through better day-to-day management and elimination of issues, and execution discipline - that we move a project into the Ideal State. Businesses operating in the Ideal State can use their conformant quality as a competitive weapon.

Tuesday, June 01, 2004

Motorola Symposium

If you work for Motorola, you will be able to see me speak at the 2004 Software-Systems-Simulation conference in the Chicagoland area July12-15. I’ll be giving my paper on Transparency, Alignment, Productivity and Governance for software engineering in large public companies. Those of you who follow the Yahoo! group may have seen the draft earlier this year. [The event is open to employees only.]