Friday, March 18, 2005

More brains than agility

Stephen Hawking is on record as saying that you can optimize your brain for intellectual capacity or for quick wittedness. Think of it like an athlete - you can have one great big muscle bound monster between your ears, or you can go for a svelte, lithe, quick, agile model with less intellectual horsepower. James McLurkin seems to be one of the former. In fact he’s so muscle bound by intellect even his monthly schedule lacks flexibility.

James McLurkin might be off-the-scale brainy but he’s an old paradigm thinker. In order to get everything done, he plans his daily schedule to the minute. But his girlfriend complains that he gets up to 2 hours behind schedule in a typical day. Why? James has no theory of variation in his scheduling. For all his brain power and focus on complex adaptive systems and robotics, he hasn’t discovered the theory of variation or realized that his daily life suffers stochastic common cause variation, and uncertain special cause variation.

He’s also got cost accounting syndrome. He’s fascinated with efficiency to give himself more time. James knows that time is his constraint. There are only so many hours in the day. So he doesn’t want to waste time doing laundry. The answer - save up 6 weeks of laundry at a time and do it all in one night. Yep, he went out and purchased enough clothes to last for 6 weeks. He also had to get a bigger closet and presumably a bigger house for that bigger closet. Yep James has a lot invested in clothing inventory.

So he’s really smart - right?! Well, I wouldn’t doubt it. I’d be lucky if MIT let me in for a tour, never mind a PhD. But I know that if I need my favorite Helly Hansen (North West chic) casual shirt for an evening of beer, sushi, good company, pool and dancing that I won’t have to wait 6 weeks for the large batch of laundry to process. In order for James’ efficient life to work, he must be able to plan with accuracy. There must be low uncertainty in his life. He must not play much sport. I wouldn’t leave a pair of my sweaty cycling shorts for 6 weeks before I washed them.

So here is the lesson - large batch sizes may be the algebraic answer to efficiency but the cost is large investment in inventory, high carrying costs, and a lack of ability to cope with variety, or change and uncertainty. Not to mention the embarrassment of being unfashionable because you can’t afford the replacement cost of such a large wardrobe- after all, to be efficient you must keep the clothes for longer or the cost per wearing - remember, each outfit is worn only once per six week period. - will look ridiculous… ridiculous… ridiculous… ridiculous…. [is there an echo in here?]

Badly Burned C Level

I don’t often use blog space to link to others postings. However, I’ve added Tom Evslin to my blog roll. Tom is a real software management success story. I clearly can’t teach him anything. He’s clearly much smarter than me. However, he’s stuck in a rut badly burned from years of running development groups that gave him no insight into their methods. I’m sure he doesn’t trust a software developer as far as he could throw one. He lives in a world where he can’t even imagine the type of transparency of reporting, accuracy of estimating, near perfect quality and high level of productivity possible on a well run agile management or FDD project. If I showed him some of my work, he’d think he’d gone to sleep and woken up in a parallel universe - what do you mean, you can see all the development work in action, as it happens? Tom’s writing in Managing Programming for CEO’s is very amusing, very real and very readable. I’ll certainly be following it regularly. But Tom, (sing along now) it doesn’t have to be that way…

<!—StartFragment—>If you’re the CEO or are ever going to be, you’ve got to know when things are going to be DONE.  Nothing else matters; you can’t sell or use half done or 95% done.  As I blogged the other day, “95% done” is programmer-speak for the remaining 5% will take 95% of the total elapsed time.  You are asking for trouble if you try to manage by the percentages.

[Tom, there is warm welcome at Building 25 any time you want to come and see what can be achieved with Visual Studio Team System, MSF v4.0 and the agile management reports available out of the box , David]

Thursday, March 17, 2005

Agile Estimating

So a few of you have realized that I was being mildly flippant (well perhaps more than mildly ) when I suggested that you should STOP ESTIMATING! But I hope I got your attention.

By asking you to stop estimating, I’m suggesting that traditional forms of estimation - take a list of tasks, ask for a level of effort for each one (in man hours or days) - is a waste of resources. It’s better to have some form of inventory measure. A fine grained one based on some quick, broad and cheap analysis would be ideal - like Features in FDD - but anything else is just fine too, for example, Change Requests, Bugs, Scenarios, Use Cases, User Stories. Now don’t estimate them, but measure the velocity - how many you can do in a given time, and measure the variation in the velocity. Use this to estimate the mean time to complete a given batch of inventory and the required buffer for variation. Or flip it on its head and buffer an iteration appropriately and then use the mean velocity to calculate how many units of inventory you can take into the iteration and guarantee to complete them all within the given time.

It’s lightweight estimating - weigh the number of value units and multiple by velocity, and buffer for variation. An agile estimate should have a number of value units, a velocity, an end date and a buffer (or a measure of variation in velocity). That’s it. You shouldn’t be estimating anything individually. Fine grained individual estimates of effort are waste - muda! Just say “No!”

Wednesday, March 16, 2005

MSF for CMMI

So the cat is out of the bag, with respect to the work I’m doing for Microsoft. Last week at the SEI’s SEPG convention, we announced MSF for CMMI(R) Process Improvement - an MSF process instance which is enacted in Visual Studio Team System. We got a very positive reaction to the concept from convention attendees. We got some positive reaction from the press too - see this Yahoo article.

It’s been a learning experience for me. When you set an agile guy loose on a formal traditional software engineering problem such as CMMI conformance something unusual is bound to happen. For me, it was the discovery that the CMM was inspired by the work of Edwards Deming and the realization that levels 2 through 4 are all about special cause variation with level 5 being about continuous improvement (or reduction of common cause variation). Coupled to the transparent traceability of work items and work products, this opened the door to the agile management solution for CMMI. MSF for CMMI(R) Process Improvement will be a lightweight process. We’ve taken a stretch-to-fit approach by stretching our MSF for Agile Software Development process and adding just enough to meet a CMMI Level 3 appraisal. We’re targeting Level 3 this year and will go for a Level 5 solution later.

We’re going to be using a lot of agile management techniques including velocity, cumulative flow and uncertainty buffering with unplanned work charts. Anyone familiar with the material at this site will know that I’ve done a lot of the groundwork on a Deming style solution for software engineering. To further break with tradition, we won’t be offering time on task estimating and tracking, earned value and critical path or much of any other traditional PM guidance as standard elements. We do recognize that there are many people in the market who need these things - particularly through government mandate. So we’ll be providing guidance on how to swap them in and users who want EV, CPM and time tracking can still do it with the MS Project interface to Team System. However, out of the box, it’ll be a lightweight, agile approach to CMMI.

Because this is quite radically different and threatens to actually deliver a truly democratized CMMI process for the rest of us, we’ve had to pull in some heavyweight advisors and collect data points from other respected members of the community, to ensure that we’re not crazy and that we can meet the spirit and the letter of the CMMI law (err, goals). This is one of the cool aspects of working for Microsoft which wouldn’t be possible for me as an independent consultant. I get to work with people like Mike Konrad who looks after the CMMI model for the SEI and Jack Ferguson who guides the appraisal side. I’ve taken other data points from Bill Curtis who owned the SW_CMM for a long time and now through the recent acquisition of Teraquest, is Chief Process Officer at Borland, and Watts Humphrey who started the whole thing off 17 years ago with a dream of delivering a Deming solution for software engineering. Overall I’ve had a very positive reaction from these experts. It’s validation that it may be possible to deliver an agile, lightweight, low overhead, low bureaucracy CMMI solution. [Naturally, there are lots of others providing input and guidance on this project and they all know who they are.]

So now I need to deliver on the promise. Time will tell whether I get it right. I’ll be saying more about this publicly around TechEd in July.

Monday, March 14, 2005

Drive Variation out of your Constraint

This is the fourth piece in my recent series which might have been called Drum-Buffer-Rope for Software Development 101. The first three steps were step 1, Measure the capacity, step 2, Subordinate to that capacity, step 3, Exploit that capacity by stopping estimating.

Step 4 involves driving variation out of the capacity constrained resource. I harp on this a lot. In fact so do most of the TOC community. You must drive variation out of your constraint. Why?

Well the most obvious reason from this thread, is that it will make your planning more accurate. If you can say, our capacity is 100 Features plus or minus 4 per month, that is a lot better than saying 100 Features plus minus 20.

The second reason is that wide variation means that your constraint may not be stable. If your bottleneck resource can fluctuate upwards in throughput significantly then it may cease to be the constraint. When this happens, all bets are off. If you have a different constraint then your plan based on throughput at the constraint has been invalidated.

The final reason why low variability in the constraint is important is that it facilitates consistent, reliable multi-project critical chain scheduling - for the same reason as explained in my second point.