Wednesday, March 22, 2006

Lean vs. TOC - No Conflict

I have to comment on Pascal Van Cauwenberghe’s interesting post on the conflict between Lean’s focus on reducing waste and TOC’s focus on improving the bottleneck in a process flow. I feel that Pascal’s post is based on a misunderstanding of the Five Focusing Steps in TOC. The 3rd step tells us to “subordinate the rest of the system to the decision in step 2” and step 2 “decide how to exploit the bottleneck.”

What is generally misunderstood here is that the exploitation of the bottleneck nearly always involves changes elsewhere in the process or system. These changes often involve the elimination of waste because no one wants the waste to be processed through the constraint. In addition, subordination almost always involves the removal of policies that create waste. [Note: Eli Goldratt no longer uses the term “policy constraints”, policies that affect the performance of the bottleneck are outdated subordination decisions and must be changed in the subordination step.] I demonstrated these ideas recently by taking an updated version of my XIT Sustained Engineering paper from the TOCICO in Barcelona to the Lean Design and Development conference and recasting all the exploitation and subordination steps as waste reduction instead. [So I guess I have to post that presentation up now, huh? another day perhaps] Technorati tag: Agile, David+Anderson, TOC, Lean

Sunday, March 19, 2006

Postscript on the HP story

Just a quick postscript on the HP story from last week. How come Brett and Sterling got a 3.4x improvement when Dragos only managed 1.55x (without extra headcount) at Microsoft’s XIT Sustained Engineering team?

I think the answer to this is quite simple. Brett mentioned it in his presentation - HP got a quality boost from simply reducing WIP and batch sizes. Defect level fell significantly - by at least a factor of 2x. Meanwhile at XIT the vendor was already a CMMI model level 5 shop using the PSP methodology. They had very high initial quality so there wasn’t a quality improvement available to boost productivity. The bottom line is that there was more waste to squeeze out at Hewlett-Packard and Brett stated that he believed there was more to come. He wants to push the batch size down from 8 weeks closer to 2 weeks. Technorati tag: Agile, David+Anderson, Lean

Friday, March 17, 2006

When Genchi Gembutsu goes Wrong in Software Design

As a follow up to yesterday’s post, I thought I’d share this…

In Singapore in 1997, I was the user interface architect on the first Feature Driven Development project at United Overseas Bank. This is well known. Much of how I conducted the UI design effort was captured in papers I published at uidesign.net but not all of it. It isn’t widely known that I went “to the scene” (Genchi Gembutsu) style and sat and watched bankers working and asked them questions about their work environment and what they were doing. I built several studies from which we derived requirements for the system and the user interface.

However, it wasn’t a total success. The anthropological study revealed several aspects of how the bankers worked that hadn’t been captured by the business analysts that wrote the original requirements. This on the surface looked like a flaw in the requirements and initially I was heralded as the guy who had uncovered the truth. However, it turned out that many of these were in fact aspects of a badly broken paper based system and had they been implemented as I’d recorded them, then they would have led to increased complexity in the system and would have digitally institutionalized inefficiency. The analysts had understood the depth of the banking system and had designed out these inefficiencies when they’d written the requirements. As the new guy on the scene doing surface deep user interface observations, I had merely sought to recreate their environment. We had to go back, rework the analysis, and devise a domain model that was optimal and a UI that would be intuitive and optimal. To do that we had to use our imagination. Going to the scene wasn’t enough. It produced a local optimization because my visibility was local to individual users and not system wide. It took me several months to fully understand the wider banking system. Technorati tag: Agile, David+Anderson, Lean

Thursday, March 16, 2006

Go to the source or use your imagination

I’ve noticed recently that many in the Lean community have moved their thinking beyond elimination of waste. The two hot topics are Genchi Gembutsu (‘go to the source’) and Set Based Design (on which more in another post.)

This idea of going to the actual scene and experience problems for real interests me - because we do it so seldom in software development (particularly product development.) But we have found a way of compensating, we use our imaginations. The techniques of Personas, Lifestyle Snapshots and Usage Scenarios, that we’ve included in MSF v4.0 were all developed to allow software people to use their imagination to envisage real people, doing real things with a product that doesn’t yet exist. I believe that these imagination based techniques deliver more than an 80-20 payback, i.e. for 20% of the expense of “going to the scene” and observing what’s actually happening, we can get 80% of the user experience results by using our imagination.

In any event, the idea of “going to the scene” does already exist in the literature of our industry. The concept of (the misnamed) ethnographic study has existed in usability engineering for 20 plus years. These are misnamed because they are really anthropological study of specific situations rather than ethnographic studies but somehow the wrong word stuck and is in wide usage in the literature.

So to those who are about touting that Genchi Gembutsu is the next big thing in Lean software development, I’d reply, it’s not a new idea - we’ve had an equivalent idea for a very long time. However, it is not in wide usage because it is expensive and difficult to do. Instead we have developed an alternative utilizing our imagination and artistic flair. So I’d argue that we achieve the essence of Genchi Gembutsu in software through imaginative techniques like Personas and Usage Scenarios and not through physical appearance at the scene. [see related post, When Genchi Gembutsu goes Wrong].  Technorati tag: Agile, David+Anderson, Lean

Wednesday, March 15, 2006

HP gets 3.4x productivity gain from Agile Management techniques

These guys are awesome - Bret Dodd and Sterling Mortensen. Last year they attended Lean Design and Development and watched my presentation. They were so impressed and felt it was such a good fit for their process for development of printer firmware that they went back to HP and plotted the historical cumulative flow diagram. Here it is…

Look at the growing WIP. The thin blue line at the bottom is the “complete” stuff

This is what happened next (right after Lean D&D last March)...

WIP is under control and flow is smooth

What these charts don’t show is the real improvement. I wish I could share the whole slide deck. I’ll find out if it is going to be posted on the Web. So here are the numbers. A 10x reduction in inventory in the system. A 5x reduction in WIP. A 3.4x increase in productivity with no new money, resources, people or any change in the way software engineering (development and test) were conducted. These figures are even better than my Microsoft XIT Sustained Engineering project results. Now here is the real kicker - a reduction in lead (cycle) time from 9 months to only 2 months. Printer firmware development at HP was never this good. Imagine what this means for the people. They now go home early on Friday afternoons, they don’t work overtime, they have rediscovered their social lives, their families and their passions.

What this case study really proves is (1) these techniques really work, (2) David Anderson doesn’t need to be in the room or involved as a coach for them to work, (3) it’s all in the book, reading it, internalizing it and living it is all that is needed.

Actually, the whole story is fascinating. The guys went through the same learning curve I did since 1997 (for them it was 2002 until now) that first you need to abandon task centric planning and embrace a feature-driven approach. This enables you to start thinking and using Lean and Theory of Constraints thinking. There total productivity gain was over 8x but the first 2.8x improvement came prior to them reading and implementing my material on cumulative flow and managing with queues.

I sat in the room watching this unfold yesterday afternoon, humbled and proud at the same time. It makes me realize why I come in to work in the morning and why Microsoft called me and offered me a job. Thanks guys! You made my day, my week and my year. It’s good to be alive and working on software engineering process improvement. Technorati tag: Agile, David+Anderson