Sunday, June 11, 2006

On Scoble’s Departure

It’s been all over the blogosphere this weekend. Robert Scoble is leaving Microsoft. I’m personally saddened by this news but I felt it was inevitable. I wanted to post a few of my own thoughts.

I think that Robert is a star. I think he has done an incredible body of work for Microsoft. I think his management deserve credit for hiring him and for driving the program that he was part of. Together that entire team has changed the public face of Microsoft and encouraged other divisions such as my own to make regular blogging part of their strategy. My own VP, Somasegar has embraced blogging and in Developer Tools division we have hundreds of bloggers providing transparent access for our customers to product teams.

Scoble and the team he is part of have changed Microsoft forever. Scoble’s departure will not change that. The genie is out of the bottle and the company understands the value. Microsoft is by far the most naked, most transparent organization compared to any of its nearest competitors.

Meanwhile, I think that Robert will go on to have a stellar career. I think he will be a household name in years to come - we’ll be watching his TV show some day soon. Well we already are but it is a podcast. Ultimately, what Robert came to Microsoft to achieve has been completed and for him personally it was time to move on and develop his own career. Good luck, Robert! We’ll be watching your ever growing success. Technorati tag: Microsoft, MSFT, Robert+Scoble, David+Anderson, Blogging

Asian Tour

I’m always concious that I should keep my readership aware of my travel schedule. Too often people have asked to meet me sometime only to find I was in their city only days or weeks earlier. I’m actually traveling a lot this summer. I’m typing this from the Seattle-Tacoma International Airport while I wait for my flight to Chicago for the Lean Management Summit. Next week I’ll be in Houston visiting a customer and the following week in Detroit at another customer - keynoting at their internal project management event. I’ll be in Naples, Florida after the July 4th weekend and at the Agile conference in Minneapolis at the end of July. Most of these trips are whistle stop with little time to meet anyone. Though do look for me if you are at the Agile conference.

I know there has been a lot of interest from Asia in my work with MSF for CMMI Process Improvement and the concept that it is possible to build an agile CMMI method. I’m doing a 3 week tour of Asia in support of this. Mainly I’ll be training our channel marketing, sales and consulting folks and meeting with some customers. Here is my itinerary. If you’d like to get together on my tour please drop me an email.

Taipei - August 13th - 18th
Singapore - August 19th - 22nd
Kuala Lumpur - August 23rd and 24th
Hanoi - August 25th - 28th
TechEd Japan in Yokohama - August 29th - September 1st Technorati tag: Agile, David+Anderson, MSF, CMMI, TechEd+Japan

Tuesday, June 06, 2006

Superstition and Boiling Frogs

A lot of what I teach nowadays revolves around the idea that management has the power to change policies in an organization and that policies control a lot of the sources waste (muda) and bottlenecks (constraints). [Note to the knowledgable TOC readers: Eli Goldratt has abandoned the idea of policy constraints and I agree with him. Instead policies are thought of as the result of subordination decisions to support the exploitation of a capacity constrained resource.]

Hence, the puprose of tracking customer-valued work (using a product like Team System) and reporting on it transparently for everyone to see, is to provide an opportunity for open objective discussion about problems and the policies that may be causing them. Surprising large amounts of waste are caused by policies. The case study from XIT Sustained Engineering showed that almost 60% of capacity was being wasted through policies that were within the power of management to change.

There are two particularly common problems which can be non-obvious to everyone in an organization that are easily exposed with transparent data.

(1) Boiling Frogs

Peter Senge used this analogy in The Fifth Discipline to describe a common systems problem. If you put a frog in cold water and gradually heat it up, the frog will not know that it is being cooked because it cannot detect the gradual temperature change. By the time the frog knows it is boiling it is too late.

XIT Sustained Engineering had this problem. They were trying to schedule change requests and always the schedule would turn out to be inaccurate (wrong) and things would change. The result was that the business asked for more accurate estimates in order to make the schedule for accurate. [It was assumed that the schedule was wrong because of poor estimation. This was a wrong assumption.] So the team spent longer on estimating, but the problem with schedule accuracy didn’t go away, and so they were asked to do more accurate estimates and they spent more time on estimation. By the time the frog was boiling they were using 40% of their available work time on estimation rather than doing customer-valued work.

(2) Superstition

Superstitions are things people do even though they cannot explain why they do them. Often the reason why has been forgotten. There was a joke went around the Internet via email a few years ago. The story is believably based on scientific experiment. It went something like this.

A troup of caged monkeys were able to press a series of colored buttons and receive a reward - a favorite food. One day one of the buttons was changed to give them an electric shock. Quickly troup members would rally to prevent others from pressing the button and receiving the shock. When no more monkeys were pressing the button the experiment was changed so that the button once again provided the reward. Gradually the monkeys in the troup were rotated out and new monkeys introduced. When each new monkey arrived, it would try to press the feared button and the troup members would scream and rally around to persuade the monkey not to do it. Eventually ever member of the original troup was gone and all the monkeys in the troup had never ever experienced the shock from the feared button. But each had learned the superstition that the button must never be pressed. That was the way things were done around here.

So imagine you have a problem in your team and management makes a policy change to fix the circumstances that caused the problem. Everyone starts to work the new way. Over time the reason for the management policy is forgotten. Equally over time the source of the problem may be eliminated. For example policies introduced because build integration is so painful may no longer apply if you have deployed a modern build tool such as Team Foundation Server. However, the policies associated with the problem may never be changed, because that is the way things are done around here! 

So if you are analyzing reports from work item tracking, looking for bottlenecks and waste, challenge old assumptions. Ask, is there a boiling frog in the room? or, are we following a superstitious belief? What was the root cause that prompted us to create this policy? Technorati tag: Agile, David+Anderson, VSTS, Management, Peter+Senge

Monday, June 05, 2006

CMMI Webcast

Last week I gave two webcasts presenting the MSF CMMI workshop that I previously presented for CMMI Lead Appraisers at the SEPG conference this past March. The presentation was split in two parts. Check out Part 1 and Part 2. Technorati tag: Agile, David+Anderson, MSF, SEPG, CMMI

Process Batch and Transfer Batch

I’ve found it useful to borrow another idea from manufacturing planning when it comes to understanding concepts and questions like, how big should an iteration be? The concept has two elements transfer batches and process batches.

A process batch is a batch of work that is done by a person, team or system. Process batches are grouped for efficiency or for reasons of other constraints, such as the size of a physical machine, or natural conditions such as hours of daylight. For example, if you ran a bakery, a process batch would be the number of loafs of bread that you can bake in the oven in a single batch. As I described last week, every batch has a setup and a cleanup cost. Process batches tend to be optimized for efficient use of resources, communication, costs or effort expended such as efficiency of time on task and time in motion.

A transfer batch is a batch that gets transferred down the value chain and passes to another set of workers or to the ultimate customer. Transfer batches are often bigger, that is several process batches make up a transfer batch. If you were in the bakery business then a transfer batch is the quantity of loaves you can load on to a truck to deliver to the grocery stores. Transfer batches tend to be optimized for the costs incurred by the next stage in the value chain or the customer. For example, the customer may need to train a sales organization or a help desk operation.

When I worked at the big phone company a big concern for us the cost of training the thousands of people in the retail stores and the thousands more who answered the phone when customers pressed *2 on their phone for assistance.

Other aspects can come in to play. For example, do you have to take your web site down to do an upgrade? Will there be an outage? Is your business seasonal and you only want to take upgrades and new functions at certain times of year? This latter concern mean that the transaction costs vary at different times of year.

The transaction costs associated with a transfer batch can mean that transfer batches have to be significantly bigger than process batches. Often many times bigger. In Feature Driven Development, the process batch is the Chief Programmer Work Package, and the transfer batch is a Release (or sometimes a Feature Set). Process batches are never bigger than 2 weeks worth of work. Transfer batches are seldom smaller than 3 months worth of work. The customer often can’t take delivery more frequently.

In much of the agile literature that talks about iteration size, there is no separation of the ideas of a process batch from a transfer batch. They are assumed to be the same. At the same time, there is no discussion about the transaction costs associated with the batch. We get advice like iterations should be one week, or two weeks, or four weeks, or even three weeks. None of this comes with any consideration of the transaction costs associated with process efficiency or delivery (transfer) efficiency. The reality is that iteration and release size will be different for every domain and potentially for every customer. It is a situationally specific problem.

What are the transfer batches and process batches in your process? Can you identify the transaction costs associated with them? Are they optimal? Could you reasonably make the batches smaller? Can you work to reduce the transaction costs? Technorati tag: Agile, David+Anderson, FDD