Friday, April 30, 2004

Geeks and Road Running

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.

Thursday, April 29, 2004

Road Running

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…

Wednesday, April 28, 2004

Is DBR the transition step to CCPM?

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.

Tuesday, April 27, 2004

Variance and Drum-Buffer-Rope

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.

Monday, April 26, 2004

Unibug

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…