Wednesday, June 30, 2004

Lessons Learned from Eli #3

Don’t Assign Blame

Don’t assign blame or point fingers when complaining about (ah hem, explaining) your delivery problems. It’s all too easy to point the finger at someone elsewhere in the value chain and say, “I can’t get my job done because _____ doesn’t deliver _____ for me.”

Eli Goldratt would prefer that we teach managers to express this in a less confrontational style using the language of variation and conformant quality. “I can’t deliver to expectations because my inputs suffer from [this] excessive common cause variance and [these] specific special cause variances.”

What Goldratt is effectively asking us to do is to plot each element in the value chain in relation to Wheeler’s States of Control matrix. Hence, we might get explanations which look like, “I can’t deliver an architecture with conformant quality expectations because my input, the requirements, exists in the Brink of Chaos State.”

This concept asks us to define the notion of “conformant quality” at each step in the value chain. Remember, we get to choose the definition of “conformant quality”. If we want to conform, we can always lower our standards. The agile movement requires us to do this. The industry standard for “success” when used in the context of “How many IT projects are successful?” is defined as “on-time, on-budget, with the required scope”. The agile movement argues that there is always too much uncertainty in the scope for it to be brought under control. Hence, we should accept, the notion of “on-time and on-budget, with most of the scope” as the new standard for conformant quality.

How might it be possible to tighten up our definition of conformant quality and maintain that “on-time, on-budget with agreed scope” definition? Simple, as I pointed out, on Monday, reduce the batch size. With a smaller batch size, it is more likely that requirements will not change during the processing time and hence, the system will remain under control and delivering conformant quality. If we increase the batch size, the system moves out of control forcing us to lower our standards.

Tuesday, June 29, 2004

Lessons Learned from Eli #2

Resistance to Change

Eli Goldratt described some of the reasons why people resist change and what it is about the culture of an organization that creates an environment that molds such people. I realized that he was talking about what Jerry Weinberg has described as Level 1 and Level 2 organizations - the hero developer level and the hero manager level. The hero is cast in the role of firefighter and they are the hero because they deliver. They deliver by putting out fires. As a result they are rewarded for putting out fires and praised and admired by their colleagues as a champion firefighter. The more fires, the better practiced they become at putting them out and the more admired they become for putting them out. As a result, they measure their self-esteem by the prowess at putting out fires.

Hence, the hero firefighter learns to thrive on chaos. Chaos is the norm in the organization and the hero is the master of chaos. The one who parts the seas and delivers the team from the perils of chaos and delivery of non-conformant quality.

A hero does not want to move to a controlled state because their self-esteem will drop as they are no longer praised for being a hero. A controlled organization is one that no longer needs heroes!

What is the injection which solves the core conflict here? The senior management must start to reward people for behavior which is congruent with controlled performance and they must build self-esteem around that behavior. The heroes must be coached and assisted to adapt to a new pattern of behavior - one which anticipates and absorbs uncertainty rather than one which heroically reacts to it.

Monday, June 28, 2004

Lessons Learned from Eli #1

Last week on July 24th, Eli Goldratt gave one of his Viable Vision Tour seminars here in Seattle. I picked up a number of little insights from some of his more subtle comments. I’ll be documenting these over the next few days.

Small Batch Sizes

It was Donald Reinertsen who taught me that small batch sizes (coupled to a focus on quality) are often enough to bring in big results. In other words, forget gathering data, identifying the constraint and so forth, simply reduce the batch sizes and focus on quality assurance (not quality control) and things will improve immensely - and, ergo, your client (if you are a consultant) will be happy.

Eli Goldratt put it this way, “often reducing batch size is all it takes to bring a system back into control”. This ought to have been obvious to me - a trained control systems engineer - because I learned it in college. To bring something back inside the control envelope simply reduce the amplitude of the signal. In this case, the amplitude is the batch size in the process. In layman’s terms, when you are going too fast, take your foot off the gas and slow down.

In most human endeavors we reward control under high amplitude conditions. We reward the fastest drivers, the fastest runners, the fastest mountain bikers, skiers, speed skaters and the list goes on and on. We intuitively know that control under high speed is hard. Control under any high amplitude signal is hard - so we base measurements for graceful subjective sports such as ice skating, diving, most X-Sports such as BMX biking for the style under the height of the jump and the speed of the movement or rotations. In industry and project management it is the size of the process or project which represents the amplitude in the control signal. Hence, maintaining control with large batch sizes is hard. When something is out of control then it is by definition, failing to deliver conformant quality and the customer isn’t happy.

Small batch sizes are the first step on the journey towards a TOC solution. [I’ve mentioned this idea before, Is DBR the transition step to CCPM?]

Wednesday, June 23, 2004

FDD Six Sigma #3:Global 8D

In the past two days posts, I’ve looked at the DMAIC and DMADV processes in Six Sigma which deal with essentially common cause systemic variation. Six Sigma has adopted a number of root cause or problem solving methods for dealing with special cause variation. Perhaps the most popular of these is known as Global 8D (or Ford 8D). The method was first documented in 1987 by Ford Corporation in a document titled “Team Oriented Problem Solving”. The idea is not new and advocates of Lean Manufacturing will recognize similar concepts exist in Toyota approach to management. The 8Ds are as follows:

1. Use a team approach
2. Describe the problem
3. Contain the problem
4. Identify/Define and Verify Root Cause
5. Choose Corrective Action
6. Implement Corrective Action
7. Prevent Recurrence
8. Reward (or Congratulate) the Team

There is a strong argument that 8D can also be used as a method for improving common cause variation where it exceeds desirable limits - when a process is in the right-hand column of the Wheeler matrix - in either the Threshold or Chaos states. Excessive common cause variance also has a root cause and root cause analysis and fix is at the heart of the 8D method.

Global 8D with FDD and Agile Management

I’ve written about why I introduced daily standups to the FDD process in, Morning Roll Call. This daily meeting was first introduced as a mechanism for recovering a project from a special cause variance. It’s a team meeting where each member of the team is encourage to surface issues impeding them. An experienced and knowledgeable chief programmer or project manager will be assigned to the issue. So that covers the first D!

”<!—StartFragment—>If help was needed, a more senior and experienced developer was assigned to help out for that day.”

The problem is described briefly in the standup. A subsequent meeting will be scheduled later if detailed description is needed. That covers the 2nd D!

The extent of the problem can be identified against the Feature List and the affected Feature Sets and Chief Programmer Work Packages can be identified and marked as “blocked” in the Knowledge Management System and an issue raised in the log with the assigned leader listed against it. Blocked developers can, if possible, be assigned new work, though this grows the DIP inventory. The problem has been corralled and contained. The 3rd D!

There isn’t a prescribed root cause analysis mechanism in FDD but there are tools in the toolkit - the TOC Thinking Processes and the use of the Domain Model as a communication tool. The 4th D!

Corrective action will be chosen by consensus amongst the Chief Programmers, project manager and other senior team members e.g. chief architect and development manager. Implementation will be worked into the Plan-by-Feature plan and corrective work allocated at a subsequent daily meeting. The 5th and 6th Ds!

What’s really critical to understand about the value of daily meetings is there preventative ability. If the team can see an issue ahead, then they can raise it before it creates a special cause variation. This allows the project manager to prevent it before it occurs. I’ve made this observation before in response to Phillipe Kruchten’s observation that my CFD chart, for a project earlier this year was near linear, Getting to Linear. This was possible because the team prevented special cause variation from affecting the schedule through early warning at daily meetings. The 7th D!

FDD has other ways to prevent re-occurrence of problems - the checklists for the ETVX templates for each of the 5 processes. For example, if there is a problem with tight coupling of the architecture which incurred refactoring late in a release and caused a drop off in the throughput on the CFD and usage of the Critical Chain project buffer then that can be addressed by introducing new guidelines in to the design and code review standards. These guideline review meetings are typically held once per month with all chief programmers and architects present. Someone is assigned to own the process templates and the guideline documents. Typically, I give this person a special role on the team - the process guru or lawyer. Everyone on the team knows who this person is and goes to them for guidance. The process guru is expected to schedule and facilitate the regular review meetings. The built-in progressive quality assurance in the FDD processes help to insure that recurrence of special cause variation doesn’t happen.

As for the 8th D! Why do we need that in a process definition? My process is something I learned from IBM - the recognition lunch!

Tuesday, June 22, 2004

FDD Six Sigma #2:DMADV

A few more thoughts on FDD and Six Sigma process…

DMADV

The Design for Six Sigma (DFSS) process is known as DMADV - Define, Measure, Analyze, Design, Verify. This process is generally used for product design before manufacturing. The DMAIC process is then used to refine the manufacturing process through reduction of common cause variation. The DMADV process is designed to remove variation between what the customer wants and what actually got designed. It’s a different kind of variation perhaps but it is still variation. We get variation from uncertainty and change. There is potential conflict between DMADV and the agile movement. DMADV seems to take the traditional approach of eliminate variation by “getting it right first time” rather than “responding to change”. However, we could take a more liberal view of DMADV and say that we are still DMADV compliant if we can accept change late in our design. We need to be able to accept change late in order that our design matches what the customer wanted. Hence, you cannot achieve good DMADV results without accepting change in the agile fashion.

DMADV in Brief

1. Define: Initiate, scope and plan the project.
2. Measure: Understand customer needs and specify client-valued functionality
3. Analyze: Develop design concepts and high level design
4. Design: Develop detailed design and control/test plan
5. Verify: Test design and validate it meets customer requirements

<!—StartFragment—>DMADV with FDD and Agile Management

Now it ought to be somewhat obvious that FDD includes many of the features required for a DMADV complaint process with its analysis and modeling, design and verification steps. But it is also clear that FDD puts a twist on it. DMA becomes more like AMD - Analyze, Measure and Define. Perhaps DMADV truly needs to become AMDDV in order to embrace the uncertainty in design problems and to acknowledge the variability inherent in design problems.

Define:
In FDD we define the overall scope as a set of Subject Areas in which we’d like to develop a system. However, the scope is not agreed until after process 1 - Modeling - and process 2 - Build a Feature List - are completed. Both of these processes are defined using an ETVX (Entry, Task, Verification and Exit) template. Hence, there is quality assurance built in to the method which is compliant with the spirit of Six Sigma and DMADV. After process 3 - Plan by Feature - there is an agreed scope and plan for the project. Hence, FDD achieves a DMADV compliant Define step as an exit criteria from process 3 - Plan By Feature.

Measure:
In FDD we measure Features as the basic unit on design in process (DIP) inventory and the basic unit of client-valued function. A Feature List - a definitive list of what will be measured in the project - is an exit criteria from process 2 - Build a Feature List. Process 2 has an ETVX template and has quality assurance in the spirit of Six Sigma designed into the method.

Analyze:
FDD process 1 - Develop an Overall Model - is the analysis step which enables the precise definition of the scope and the identification of Features for tracking and measuring the project. The domain model provides a high level design and equivalent interaction architecture modeling for the UI completes the design concepts. The exit criteria for process 1 provide Analyze step for Six Sigma.

Design:
Process 4 and 5 in FDD - Design by Feature and Build by Feature - represent the Design step for DMADV. Again both process have ETVX templates and quality assurance is built in to the process.

Verify:
All 5 FDD processes have verification steps in their ETVX templates. Inspections and cross-functional review are present at each stage in the process. Ultimately quality control testing is applied to validate that the agreed scope was delivered in the working software.

My overall feeling is that FDD is very compatible with DMADV though it can’t be mapped to it precisely. I feel that FDD’s 5 processes are more attuned to the agile goals of responding to change and delivering frequent, tangible, valuable working software. DMADV seems like a traditional “big requirements up front” process which denies the underlying variability and uncertainty in design problems. AMDDV - Analyze, Measure, Define, Design and Verify - might be a better Design for Six Sigma (DFSS) process because it better reflects the roots of Six Sigma in the fundamental understanding or variation.