By and large, geeks don't like Road Runner behavior! Why?

I've heard this bleat a few times in recent months, "I've been under utilized on this project" - interpretation, "I had slack time". Hmmm, let me think. Maybe you weren't the constraint!

The problem with this, I believe, is two fold. Firstly, software developers are used to being the constraint. They work more, software is done earlier. They work better with higher quality, software is done earlier. They work faster, software is done earlier. Secondly, they like bigger batch sizes because it allows them to work on their own without interference from bozo project managers or analysts for longer periods. I called this Intellectual Efficiency. They also like localized due dates for those batch sizes so that they can choose when and how to goof off or work on something else. It's a freedom - a rite!

Once kicked out of this mold and into a focus on production rate and percentage complete, most developers soon get used to being busy and often like it. Even small batch sizes aren't too bad. But what happens when there is no immediate work to do - Gee, they realize, "I wasn't prepared for that. I'm not ready to do anything else. And my friends aren't free for a game of Foosball!"

I personally hate task switching. My old brain moves slowly from one frame of reference to another. So I'd relish the down time. But I don't appear to be typical. The answer for geeks unlike me, who seem to be able to switch from one line of thought to another in a heartbeat, and who get immensely frustrated with the slack time in a Road Runner environment, is to give them planned bench projects or bench activities such as a reading or learning program. Bench projects get done when they have a plan and are executed against that plan. The plan doesn't need to have a schedule but it sure does need a feature list. A manager can also work with an individual to devise a training and self-learning schedule. Slack time can be used for this too. And it starts to pay back very quickly in improved quality and fresh ideas.

Tomorrow I'd like to post my thoughts on the conflict between geek work (as Paul Glen called it), and Road Runner behavior which I discussed as a necessary prerequisite to a Critical Chain implementation, yesterday. Today, I'd like to talk about what road runner behavior means.

Road Runner behavior is common in some other lines of work. One that jumps to mind is emergency services. Take fire fighters as an example. When they get the call, the must respond at the fastest safe speed. They are measured by how long it takes them to respond to a call. Readers in the UK will know that the government measures the ambulance service this way too. In fact, since the John Major government there have been standards for the number of minutes which are acceptable in which to respond to call. As a result, slightly more remote parts of the UK, where there isn't an ambulance base within a reasonable distance (in time) have extra ambulances parked often in the street in case of an emergency. So that an ambulance can attend an emergency quickly and provide paramedic care as soon as possible. For emergency services Road Runner behavior is essential. The metric of the Road Runner is lead time. No one counts the slack time.

So what do these fire fighters and paramedics do when they are road running? Do they sit around the fire house and play cards as popular culture would have us believe? Do they goof off during those slack periods? Or do they busy themselves with day-to-day maintenance, inspecting fire hydrants, providing fire prevention consulting and in training?

Tomorrow, Geeks and Road Running...

Yesterday, I attended the Puget Sound TOC Update 2004 Learning Event at the Coast Hotel in Bellevue. I'd like to thank Steve Dightman for putting it together. I really enjoyed it and the content was excellent. There certainly is a strong TOC community here in Seattle - and they don't all work at Boeing :-)

Skip Reedy was the first speaker. His topic was transitioning to a Critical Chain multi-project (PMO) solution at Boeing. His main theme was that you don't just turn off the old way of doing things and switch to Critical Chain. You can't. All the projects in the portfolio simply don't finish on the same day to allow a clean switch over. At the beginning there will only be one CC project in a portfolio of traditional Critical Path projects. His key insight was that you need to change the way the organization thinks and talks about projects as a first step to switching over. He needed to change the mindset! His solution - let many projects run in CP mode but switch the reporting to a more CC friendly fashion. Kick the organization out of a focus on Due Date reporting. Working to Due Dates encourages multi-tasking and undermines the move to a prioritized pacer/constraint driven project portfolio. If you are reporting Due Dates you just can't change to CC! To change the mindset and the reporting approach he asked for a change in behavior to road runner behavior and reporting input and delivery rates. He did this by asking traditional projects to report as project days late or early (rather than Due Date) and percentage (of the Critical Path) complete.

What I took from this was the behavioral change to kick people out of the old mindset. My epiphany was that if road runner behavior is desired then you are asking the individuals and teams to focus on lead time and if input and delivery rate are being reported then you are focused on capacity (or productivity) of the constraint (whatever it may be) and the rate of input to the system. These are the control points which drive the Drum-Buffer-Rope solution. With DBR, the main control mechanism is the capacity of the constraint (or the rate of production through the constraint) and the rate of input into the system, plus a buffer based on the variance of the constraint - as I explained yesterday. The buffer is inventory and inventory is directly related to lead time - from Little's Law. Hence, could it be possible that implementing a DBR solution is the route to transitioning to a multi-project Critical Chain (CCMPM) solution?

To answer this we must consider what I've been doing with FDD and how I describe the process of Agile Management in the book.

First, I focus on quality and batch size. This frees up capacity in the constraint. Then I develop a Drum-Buffer-Rope production solution using Cumulative Flow to identify and track the constraint. This is basic FDD without much of Step 3 - Plan-by-Feature. Put another way - get a big list of Features for a release and build them tracking the Feature Milestones with the Cumulative Flow Diagram (CFD) and keep the WIP inventory small and the lead time under 2 weeks by monitoring the CFD. Focusing on keeping lead time short is asking for Road Runner behavior. Lead time is the metric of the Road Runner. How long did it take him to cover the distance? Only when you can do the DBR solution (FDD steps 2, 4 and 5) and show that it is stable is it really worth spending time on Plan-By-Feature and building a Critical Chain schedule by Feature Set. This squeezes extra productivity - or more accurately better value delivery - out of the system. It communicates a plan for partial value delivery of Feature Sets, or put another way, downstream batch transfers, to the quality assurance group and beyond. Moving to CC scheduling of Feature Sets facilitates a move to a multi-project solution with a managed shared resource as the overall system constraint.

So there are four steps

1. Free capacity in the constraint by improving quality and reducing batch size (you can do this blind without identifying the constraint)
2. Implement Drum-Buffer-Rope for the flow of value through the system of software engineering
3. Implement Critical Chain scheduling once the DBR solution is stable
4. Move to a multi-project Critical Chain scheduling solution as each project in the portfolio reaches step 3 in the transition

It's interesting to note that two of the most popular agile methods eXtreme Programming and Scrum essentially never get beyond the DBR solution. First they restrict batch size to 2 or 4 weeks of work and with XP there is a heavy focus on improved quality with Test First and Pair Programming. Next, they identify the velocity, treat development (a mass of analysis, design, coding and testing) as the constraint, stem off the flow at the input to the capacity of a 2 or 4 week iteration, and stabilize the system at that. The lesson here is that TOC would suggest that there is a lot further to go in squeezing the profits and return on investment from software development activity and agile development is only the beginning of that journey.

Over the last few evenings, I've been acutely reminded of how variability affects a Drum-Buffer-Rope flow solution for TOC. It's been pretty nice weather here in Seattle recently and the evenings have often been blue skied and sunny. Every evening after dinner and before I write this weblog, I take my dog for a walk. In summer my daughter comes too. She is now 22 months and very insistent that riding in the stroller is only for babies and she prefers to walk. So she comes along, walking on her own. She also likes to hold the dog's leash (ah hem lead, if your reading this in English). Now Nicola is 25 lbs and the dog is 45 lbs. He is very strong and pulls a lot. He was, after all, half-bred to herd sheep down a mountain with the other design to pull carts around China - definitely not the ideal combination to mix with a fragile toddler. Meanwhile, my daughter is still a novice at walking and wobbles a lot. So dad has to be very careful and keep the dog on a tight leash - see graphic...

As shown, dad is acting as the Drum because my daughter, the constraint, is too young and weak in comparison to pull from the system input, the dog. The Rope is the leash. The Buffer is the slack in the leash between dad and daughter. Often times, the buffer is twice the length of the rope between the input and the drum. However, it takes very little variance in the constraint - the rate at which a not-quite-two-yet can walk - or variance (in the strength of pull) at the input to cause the whole system to become unstable and have to stop and reset. This makes overall productivity - the rate at which ground is consumed in the direction of the park - very low.

In this example, the rope is only a total of 6 feet long and between input and drum it is only 2 feet. However, the desired production rate is perhaps 2 feet per second, or even more. The system is inherently unstable because there is insufficient rope and insufficient buffer in comparison to the desired production rate. In order to stabilize the system, either the production rate has to be lowered to a snails pace - and I have tried this and it works :-) or the variability in the constraint needs to be greatly reduced - try telling that to a not-quite-two-yet toddler! An alternative solution would be a much longer rope (leash) to provide for a much greater buffer.

So there it is! With the Drum-Buffer-Rope solution, production rate can only increase in a stable fashion,  if you either (a) increase the size of the buffer or (B) decrease the variability in the constraint whilst avoiding moving the constraint somewhere else in the system.

Pujan Roka is a good friend and one of my former staff. He is also a great comic artist. His latest venture is called Unibug and you can catch it regularly at ComicSherpa. I liked this one from March 8th...

Strategy + Business Magazine offers us this article by Koehler and Weissbarth, The Art of Under Engineering. It underscores a message at the heart of the agile movement - the best way to be agile and the best way to deliver better shareholder value is to avoid developing features the consumer does not value.

The summary offers these key observations...

1. The need for end-to-end tracking of ideas. A point I also made very strongly in my book.
2. The need for transparent reporting. Again I point I made in Agile Management. I think the essence of this is that transparency allows "what the customer truly values" to be communicated cleanly.
   Where I disagree with the author is on "benchmarking". Many authors of continuous improvement literature such as Deming do not believe in benchmarking against competitors, rather they believe that an internal focus on improvement is better. However, I see big American companies benchmarking all the time and set "cost goals" based on those benchmarks.
3. The need for a cross functional team which communicates closely and works together. This is definitely the approach taken by Lean manufacturers such as Toyota. In any knowledge work industry - any type of product design - there is a need for close cross functional cooperation and sharing of knowledge. Without it, it is impossible to gain a full system view of a design. Without a system view, individuals tend to locally optimize designs and the result is sub-optimal for the whole.
4. Management commitment is clearly necessary. When you try to change a culture the management needs to be instrumental in creating the new culture. Deming really understood this.

The 4 points above are derivative requirements from the main message that you should only design what the consumer truly values. The 4 observations represent what  is needed to create an environment for communicating true consumer value. So many companies build things which they "think" the customer needs because they didn't validate their belief with objective market research and don't have controls in place to insure that the internal communication is honest. Without these, every salesman will always tell you that their hottest prospect's pet feature is a "must have" to close the sale.

[Thanks to Glen Alleman posting in the Agile Management Yahoo! Group for this topic]

So America sat glued to its TV sets on Thursday night to see Bill, the entrepreneur, win and Kwame, the Harvard MBA, lose in the final episode of The Apprentice. As The Houston Chronicle reports, it is really hard for us in the audience to judge the result due to the shows editing. We clearly didn't have all the facts. However, it was very obvious in the end why Kwame didn't win. He lacked leadership. It was a theme over several shows. His cool, unflappable, trained manager, Ivy League MBA style might have been full of delegation and empowerment, but he wasn't prepared to provide the leadership, direction and example when it mattered. When his team was flustered and confused filled with ambiguity, uncertainty and doubt, Kwame didn't step in and show them how he wanted it done.

Management is an essential skill in business but it cannot go without leadership. The season of The Apprentice showed us why and how leadership matters. What does this teach us in the software business?

I discussed this once before - my belief that all good software development managers have to have come from a strong coding background, whilst some others believe that the problem with managers in software development is precisely because they did come from a development background and have no management training. I feel The Apprentice has reinforced my belief that leadership is essential and in software to be a leader, you need to carry the respect of the geeks who work under you. To do that you need respect as a technically accomplished individual who can step-in and show them how and why. Managers can be trained. I'm not sure that is true of leaders. I feel leaders are born. So perhaps the correct recipe for a good manager in software development, is to find the talented developer with born leadership skill and train them as managers - coached by a mentor, someone who has learned good management practice and can provide Kwame-like coolness, delegation and empowerment, whilst maintaining the ability to jump-in, analyze, design and architect with the best.

It's a few years since I read any of the Microsoft Solutions Framework material. This latest stuff would sound familiar to readers of Jim Collins or someone trying to apply the principles from Peter Senge's The Fifth Discipline to software development.

Founding Principles

• Foster open communications
• Work toward a shared vision
• Empower team members
• Establish clear accountability and shared responsibility
• Focus on delivering business value
• Stay agile, expect change
• Invest in quality
• Learn from all experiences

Meanwhile, this is what it has to say about agile development...

Agile methods, such as Lean Development, eXtreme Programming, and Adaptive Software Development, are software development approaches that embrace practices that are adaptive versus predictive, people/team centric, iterative, feature- and deliverable-driven, communication-intensive, and require direct business involvement. In comparing these attributes to the MSF foundational principles, MSF and agile methodologies are very much aligned in both principles and practice for software development in environments that require a high-degree of adaptability.

I had dinner with Johanna Rothman, here in Seattle, on Monday evening. We got to talking about the problem of individually measuring developers. She sees this often with her clients. It typically comes just after the organization is beginning to stabilize. It is possible to measure velocity, to estimate capacity and to stem off the input to a rate which can be processed by the current team. Now that it is possible to measure, the boss turns his thoughts to how it might be possible to increase the productivity.

All managers know that software development productivity is closely related to the ability of the individual. We've all known this since the early 70's. And we also know that the productivity differences can be huge. Sackman reported this in the late 60's. So managers start to think about how to identify the weaker links and hopefully eliminate them.

THIS IS SO WRONG!

You simply cannot measure developers individually. Why not?

Software development is a knowledge work business. Knowledge is about information. The more knowledge and information available about the problem domain then the better off we all are. When you start to measure developers individually, you incentivize those developers to hoard information for themselves. Why share when you will get rewarded for keeping it to yourself? Why share when doing so allows your colleagues to go faster? Whether it is information about use of a language, or skill in UML, or knowledge of unit testing techniques, or domain subject matter knowledge, or just plain use of the IDE, it is all useful knowledge that can help a team go faster. Knowledge sharing is a key to success. To elevate the system of software engineering, you need to encourage more, not less knowledge sharing.

Individual measurement is anti-team working. Groups of individuals typically perform poorly compared to a good integrated team.

Individual measurement is also demotivational. We live in a world where geeks grow up to be conspiracy theorists. For their protection, their government spies on them in many forms, commercial companies spy on them particularly on the web. Their privacy is invaded day and daily. The unlucky ones may even have a spouse or children or parents who spy on them. The last thing they need at work is a boss who also spies on them and punishes them for under achievement - however that is defined. Knowledge worker productivity is directly related to motivation. If the developer is a little coding machine, then that machine works harder when pumped with the right motivation.

Individual measurement is demotivational. Poorly motivated developers under perform. Good leaders motivate! Bad ones don't! Managers who measure individuals aren't good leaders.

Martin Geddes brought this story on Slashdot to my attention. It seems that the market is beginning to wake up to the issues with the UML. Perhaps it is because it is too big or perhaps it is because it lends itself to the pursuit of intellectual efficiency (big batch sizes of artifact generation) but I really hope that managers everywhere are going to get the message - UML is a tool and engineers must learn to use that tool effectively. If you use a tool to do UML, such as Together Control Center, then you have to learn the tool, but you aren't learning how to use UML. Hence, giving engineers training in the tool is not enough, they need training and preferably expert mentoring in use of UML for analysis and design. As Alex Bell writes...

Shape shifter fever. Victims of shape shifter fever demonstrate raging affliction by sending people to brief design tool and language syntax classes with the expectation that they return as experts in best practice. Afflictees mistake the ability to navigate "File New Class Diagram" dropdowns as the signature quality of a software designer. The symptoms of shape shifter fever are particularly exacerbated when classes on tool and language usage are taught out of context from how they will actually be used on a program. As some believe "clothes make the man," afflictees of this fever believe "UML makes the designer."

It takes experience to know how much of the UML is needed to generate just enough knowledge before code can be written. It takes experience to know which parts of the UML to use and when.

An agile approach to UML is the identification of the minimal set of diagrams in the minimal set of circumstances required to reduce uncertainty and generate knowledge such that coding can start and reviews can be performed against the design after coding is complete

It is just this focus of approach which Peter Coad and the rest of us took when we created Feature Driven Development. In fact an entire decade of Peter's career (in the 1990s) was dedicated to devising approaches to modeling, analysis and design which facilitated agility - the ability to cope with change - and lean development - the elimination of waste through the reduction of artifact creation.

In the first article, Death by UML Fever, Alex Bell of Boeing argues that much use of UML is waste - it's plain artifact generation. It's not Lean and it's not agile! Much of what Bell writes is of course accurate and yet it is so easily overcome. You simply must put in place a management method which tracks the flow of value through the system of software engineering. My technique of using Cumulative Flow Diagrams to track client-valued features through the system, would illuminate the problems described by showing that lead times through analysis were too long, and that WIP inventory in analysis was too large. In other words, end-to-end traceability is the antidote to UML Fever. When determining whether a UML artifact is waste ("muda" in Lean terminology) ask

• Who, further down the value-chain consumes this artifact?
• What uncertainty did this artifact eliminate?
• Did this artifact enable us to write code, or get significantly closer to writing code?

If you can't answer all three questions positively, then don't produce the artifact. Eliminate this piece of UML from your process.

I'll give the final word today to Grady Booch who in reply to Alex Bell writes...

Many ... organizations, however, have not enjoyed the successes they assumed to be implicit by merely using the UML. Success with the UML requires thought and planning accompanied by an understanding of its purpose, limitations, and strengths-much like the usage of any technology. It is only through such awareness that an organization is most capable of applying the UML to address its unique needs, in its own context, and in a value-added manner. Blind adoption and usage of technology for technology's sake is a recipe for disaster for any technology.

...

The entertaining tenor of "Death by UML Fever" should not be inferred to suggest that UML fever is an imaginary ailment. It is genuinely real, it is thriving, and its presence is causing cost and schedule trauma on many software programs right now. Furthermore, the root causes of this fever, in general, have nothing to do with the UML itself: Rather, this fever and its various manifestations are largely symptoms of deeper ills in an organization's software development practices. Software organizations should consider launching self-diagnosis campaigns to assess the presence or extent of UML fever on their programs and plan rehabilitation strategies as necessary. Developing good software is a difficult enough task without having to endure the preventable and often painful complications of the dreaded UML fever.

Whilst I was writing the book, and publishing the drafts on the Web for review, I got some feedback from a reader who said, "As an agile guy I'm surprised to hear you advocating end-to-end traceability. That seems the antithesis of light weight to me."

I realized that end-to-end traceability meant something very different in this reader's mind than it did to me. In fact, anyone from the defense industry probably thinks of end-to-end and documentation in the same thought. The term "end-to-end" really relates to the audit trail of documentation, who touched it, when it was modified or updated and how one document relates to another.

When I'm talking about end-to-end, I'm talking about being able to track value throughout the process. End-to-end means being able to identify the feature a developer is coding or tester is testing and to unambiguously trace that back to a requirements definition in a Product Requirement Document, a Request for Proposal or some analysis artifact such as a Use Case. The purpose is to communicate the potential value being created in the system of software engineering. Such that the consumer, the customer or the product visionary can know how much of the desired product or service exists at any given point.

I track the flow of value with cumulative flow diagrams (CFDs). It's important to be able to relate the inventory in the CFD to the other artifacts in the project so that the data can be communicated project wide and not just to the development team. It's not important for value tracking to have the audit trail of documents but it is important to know the milestone progress of each unit of inventory derived out of the initial requirements.

I found this summary [PDF] of Lean Six Sigma by Michael George on Jon Strande's weblog.

Some people have described Lean Six Sigma as "doing quality quickly" - which may seem counterintuitive. Intuition tells us that the faster we go, the more mistakes we make. Lean Six Sigma works not by speeding up the workers or machines, but by reducing unneeded wait time between non value-added

I've been asked quite a few times recently whether I believe that the Business Rules Approach (or something very like it) has real potential.

I've written a lot about the influence of business rules on agilemanagement.net. Possibly the biggest validation of the concept that business rules can be separated is the recent announcement of a forthcoming RFP from the OMG. Ron Ross is promising us an update on this activity in the next edition of the Business Rules Community Journal.

Another highly encouraging development in the field was the publication of an academic paper in 2003 describing how to implement encapsulated business rules using aspect oriented programming. Read the original paper [PDF].

Peter Coad first described how to separate business rules into classes - he calls them "descriptions" - in a seminal 1992 paper at OOPSLA when he presented his Item-ItemDescription pattern. To my knowledge, the first recorded "pattern" in OO literature. This pattern is still seen in his latest work the Domain Neutral Component published in 1999. Collaborators of Coad's, Jill Nicola and Mark Mayfield dedicated a whole chapter of their 2001 book Streamlined Object Modeling to separating business rules in OO systems. Read Chapter 4 - Collaboration Rules [PDF] The same authors explore the topic further at The Coad Letter #91- Object Oriented Business Rules . Another Coad collaborator, Stephen Palmer, added the most recent material with his Getting the Blues Coad Letter which is now reproduced at his own site.

I have used the Coad, Nicola, Mayfield and Palmer techniques extensively in the last 5 years and found them to be useful but wanting. I firmly believe that business rules would be easier implemented in an aspect oriented fashion or even better in a semantic agent fashion. The resulting rules would be much more decoupled and re-usable than they are in a traditional OO system.

I firmly believe that re-usable business rules are possible and so does Ronald Ross, author of The Business Rules Approach. On page xviii of the introduction to his book he writes...

"We are on the verge of a huge new wave of technological innovation focused on the knowledge capabilities of the business. Think of business rules (which I collectively call business logic) as a first - and in many respects relatively modest - step in that direction.

The plain truth is that such a technology has never been a significant part of mainstream business IT. Expert systems made a minor foray into that realm in the 1980's but had very little impact. There are many reasons why, but perhaps the most important was technological. Computing architectures then (and since then until recently) were basically monolithic, and they provided no easy way to accommodate "outside" services.

Without going into detail, that fundamental barrier is now being eliminated, and plug-in services are becoming easier and easier to incorporate. And what better service to incorporate than direct knowledge support?"

Has anyone else noticed the release of the Microsoft Professional Series of books? Some big names from the agile community are amongst the list of authors including Ron Jeffries and Jim Newkirk, not to mention Ken Schwaber who seems to have switched allegiance from Prentice Hall.

If I were a conspiracy theorist I might be wondering if Microsoft was about to embrace agile. But my initial instinct - to look for horse rather than a zebra - is that it is just a profitable line for the publishing division. Nevertheless, when Microsoft pays attention to something, it is an indication that it is a genuine trend rather than a fad. I said something about trends versus fads in my book introduction (on page xxxi)...

Agile software development is really about a change in working practices and a change in management style. Agile methods understand what management truly is. They understand that management is more than economics and engineering, that it is very much about people. "Rightly understood management is a liberal art, drawing freely from the disciplines that help us make sense of ourselves and our world. That's ultimately why it is worth doing" [Magretta 2002, p3]. Because of this basis in existing experience, I firmly believe that the agile approach is a genuine trend, a change in working practices and a paradigm shift in how software is produced. It is not a fad.

[Magretta 2002] Magretta, Joan, and Nan Stone "What Management is! - How it works and why it is everyone's business", Free Press, New York, NY, 2002

You can't model uncertainty in Excel! And that's a problem! [Thanks to Martin Geddes for the link]

There are two ways that spreadsheets, as we know them, distort our thinking and lead to bad decisions. The first distortion is the use of point values and simple arithmetic instead of probability distributions and statistical measures. So far as I know, there's no off-the-shelf spreadsheet product - certainly none in common use - that provides for input of numbers as uncertain quantities, even though almost all of our decisions rest on forecasts or on speculations.

In a world where our software development methods need to embrace uncertainty and cope with common cause variance, our project managers are trained to use a tool which does not understand the meaning of uncertainty or variance. Excel is the weapon of deterministic practices against the insurgence of probabilistic principles.

[Update April 8th] David Carter wrote to me with this...

I wanted to post a comment on your latest weblog entry on Excel & uncertainty, but can't seem to do so. There are add-in products available for Excel (and MS Project) that let you model with uncertainty.  @Risk is one that's been around for quite a while - I used it when I was working on my MBA from 1988-1991. http://www.palisade.com/html/risk.asp

[Update April 9th] Jack Vinson wrote...

I am familiar with Crystal Ball, which is an Excel plugin that lets you do Monte Carlo-type simulations. It lets you specific a distribution on just about any variable and then runs through simulations to give you distributions of the results. I haven't looked at the product in many years, but five years ago they had a nice range of distribution models to choose and you could pick a different one for every variable.