What Have We Learned?

Before we set out to change something, it is always a good idea to survey useful ideas that already exist to see what we can learn from them. Here we will look at two initiatives: Six Sigma and Theory of Constraints.

Six Sigma

One of the initial problems with Six Sigma initiatives, one that has long since been resolved, was an attempt to apply practices that were appropriate in manufacturing to development processes. As it became apparent that in development variation is a good thing and failed experiments generate as much learning as successful ones, companies have recognized that Design for Six Sigma (DFSS) is the right variation of Six Sigma for software development. With its strong focus on discovering the voice of the customer and clear emphasis on data-driven problem solving, DFSS has a lot of good tools to offer a development team.

Process LeadersNatural Work Team Leaders

Where Six Sigma programs differ from the Toyota Production System is in the role of change agents. Six Sigma programs often recommend that about 1 percent of the workforce be trained as Black Belts, process leaders who are not supposed to have line responsibility. But it is relatively silent on the training that first-line supervisors should receive. Instead of focusing on process leaders or change agents, Toyota focuses its training efforts mainly on the natural work team leaders, believing that these people should both lead and be responsible for the results of their work teams.^[10] We believe that a lean initiative should closely track the Toyota approach and focus on training natural team leaders in preference to process leaders.

^[10] TPS vs. Lean and the Law of Unintended Consequences, by Art Smalley, www.superfactory.com/articles/smalley_tps_vs_lean.htm.

ToolsResults

We know of a case in which a plant showed dramatic improvement on all bottom line results measured by the company, but when the plant was assessed by the corporate process experts, it received a very low scorebecause it had achieved the outstanding results without showing evidence of using the corporately sanctioned process improvement tools that the experts thought were essential. This is clearly an improvement initiative gone astray. Every toolincluding value stream mappinghas been developed to address specific kinds of problems. If the problem at hand is not best addressed with a tool, then it should not be used. The work team and work team leader should be trained in experiential problem solving and trusted to use the appropriate tool to solve their most important current problem.

Theory of Constraints

Eliyahu Goldratt, who coined the term Theory of Constraints, starts his audio book Beyond the Goal^[11] with the proposition that technology can bring benefit if and only if it diminishes a limitation (removes a constraint). If you accept this proposition, then you face the obvious fact that people were functioning quite well before the technology appeared, because there were rules or accommodations in place to deal with the limitation. For example, the Boeing 777 was developed before there was broadband or the World Wide Web. Phones and faxes were heavily used, but who uses faxes any more? Boeing created FTP sites and supported some of the earliest intercompany e-mail.

^[11] Beyond the Goal, by Eliyahu Goldratt, Your Coach in a Box Series, Gildan Autio, 2005.

Just introducing a new technology will not necessarily remove the limitation it was designed to remove, because the accommodations made to deal with the limitation are so woven into the fabric of the company that they are not even recognized. For example, when e-mail became widely available from Internet service providers, large companies took years to open their e-mail systems to the outside world. We were sending e-mail to our college-age children from home long before we could communicate with vendors through our work e-mail systems.

The problem in removing limitations is that we not only have to overcome the constraint, we also have to recognize the accommodation that we were making to live with the constraintalways a difficult taskthen we have to remove the accommodation and finally, replace it with new rules.

To successfully adopt a new technology, Goldratt says that we must answer four questions:^[12]

^[12] Ibid.

1.	What is the power of the new technology?
2.	What limitation does the new technology diminish?
3.	What rules helped us to accommodate the limitation?
4.	What rules should we use once the limitation is replaced?

Consider Enterprise Resource Planning (ERP), once a new technology that gives managers access to a vast amount of information to help make better decisions. Before ERP, decisions were made based on rules that created local optimization, because there was no data to make system-wide decisions. For example, manufacturing mangers tried to optimize efficiency of machines, and sales managers used product costing formulas to decide how to price products. Making decisions based on local optimization was an appropriate approach when it was the only alternative. These decision rules created much better results than random decisions. However, once ERP provides the data to make better systemwide decisions, local optimization rules must be abandoned or else the potential of ERP will go unrealized. Many of the failures of ERP can be attributed to a failure to remove the accommodations and revise the rules from pre-ERP days.^[13]

^[13] Ibid.

Changing the Rules

Every state in the United States and every province in Canada has a system for registering liens against property. When property is offered as collateral, a lending institution can check the system to see if the property is free of liens and then register the new lien. Almost all aspects of these systems are governed by state or province laws.

In the late 1990s I worked with a company that was automating property lien registration systems in several US states. The idea was to supply states with an imaging system to scan in the legally required paperwork and thus automate the workflow of data entry and collecting fees.

I was on a team that had two subject matter experts from British Columbia. "We considered an imaging system," the experts said, "but we decided it would be better to do away with paper and go to a Web-based data entry system. Since the law required a paper system, we drafted model legislation that would allow us to get rid of the paper and lobbied the lawmakers to get the new laws adopted. It took well over a year, but the laws passed, and after that, moving to a Web-based system was relatively fast and easy. Now all of the provinces in Canada are adopting the same legislation."

To my dismay, no one in the US considered adopting a similar paperless system. The laws requiring paper were so woven into the fabric of government work that it didn't seem to cross anyone's mind that paper was an accommodation that could easily be removed, even when prodded by the people who had changed the laws in Canada. The resulting imaging systems were very expensive to implement and continued to require manual data entry from images of paper forms.

Mary Poppendieck

Critical Chain

Critical Chain is Goldratt's term for the application of the Theory of Constraints to projects. Goldratt believes that the key constraint of projectshe considers product development to be a projectis created when estimates are regarded as commitments. People working on a project are asked to estimate the amount of effort that each activity will take, but they have to guess, because projects are unique endeavors, so by definition, they are filled with unknowns. Since the estimate will be regarded as a commitment, the estimator accommodates by including a large amount of "safety" time in case things go wrong. However, even if things go well, the estimated time will be used up anyway, since estimators don't want to look like they over-estimated.^[14]

^[14] Ibid.

Goldratt recommends that estimates be acknowledged as just thatestimatesand the safety margin attached to individual estimates should be removed from the activities and accumulated in a project buffer. With this approach, individual activities will be completed much faster, and the project buffer can be spread across all activities to absorb variation. In the book Agile Estimating and Planning,^[15] Mike Cohn explains in detail how to do this for software.

^[15] Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2006, Chapter 17.

Note that project buffers will not speed up overall project execution until accommodations to past practices that are embodied in the expectation and reward mechanisms are changed. In order for Critical Chain to work, everyonefrom senior management to those doing the estimatesmust abandon the expectation that activities should be delivered within the estimated timeframe. In fact, if half of the activities don't take longer than their estimated time, the system will not achieve the desired improvement.

An additional problem with using Critical Chain for software development lies in the assumption that all of the activities needed to complete development should be known in advance and that dependencies among them are understood. As we have seen, these assumptions are inappropriate for most software development. First of all we need to abandon the idea that all requirements should be known at the beginning of a development effort. Secondly, we should focus our creative efforts on breaking dependencies.

At a high level, the Critical Chain project buffer may make sense, but at a detailed level, it is an accommodation to the past. If we break dependencies and have a dedicated team develop in small, deployable increments, we no longer have the problems that Critical Chain was designed to solve. A master in the Theory of Constraints would recognize this as a natural result of the application of the Theory of Constraints, scrutinize the accommodation embedded in the Critical Chain approach, and develop the new rules to use now that the constraint has been removed.

Accommodations

Hidden in our practices, processes, and rules are a large number of accommodations put there to deal with real or imagined constraints. These accommodations are so ingrained in the fabric of our lives that we usually do not realize that they are there. Many of the practices we have in place were put there to deal with specific problems that are no longer relevant or were never relevant to our particular situation. For example, the early definition of cost, schedule, and scope is largely an accommodation to a funding mechanism which commits all money at the beginning of a project. When projects are funded incrementally, as most new product development is funded, there is no reason to fix these parameters at the beginning of the development cycle.

The development environment of 30 years ago, 20 years ago, even 10 years ago is entirely different than it is today, and the accommodations we made to deal with limited memory, processor power, communication capability, and software options are no longer appropriate. Object-oriented development, automated unit and acceptance testing, service-oriented architectures, topicoriented documentation, and innumerable tools for small-batch development have recently appeared and are being constantly improved. The Web has spawned innovations ranging from Open Source development to powerful search capability to Voice-over-IP. In an environment that is changing so rapidly, we would do well to be alert for the accommodations that we continue to make for constraints that are no longer present.