Deliver Fast

Speed is the absence of waste.

If you diligently work to eliminate waste, you will increase the percentage of time you spend adding value during each process cycle. And you will deliver fasterprobably much faster.

This fundamental lean equation works in manufacturing. It works in logistics. It works in office operations. PatientKeeper provides a good example of how this works in software development.

PatientKeeper

Five years ago a killer application emerged in the health care industry: Give doctors access to patient information on a PDA. Today (2006) PatientKeeper appears to be winning the race to dominate this exploding market. It has overwhelmed its competition with the capability to bring new products and features to market just about every week. The company's 60 or so technical people produce more software than many organizations several times larger, and their software is certified to manage life-critical data. They don't show any sign that complexity is slowing them down even though they sell to a variety of very large health care organizations and support several platforms that integrate with multiple backend systems.

A key strategy that has kept PatientKeeper at the front of the pack is an emphasis on unprecedented speed in delivering features. For the past three years, PatientKeeper has delivered about 45 software releases a year to large health care organizations using simultaneous overlapping iterations (or Sprints) (see Figure 5.1). Every iteration ends in a live release at a customer site. Every one is delivered on time.

Figure 5.1. Simultaneous overlapping iterations running through one set of development teams^[1]

^[1] From Jeff Sutherland, "Future of Scrum: Parallel Pipelining of Sprints in Complex Projects," Research Report, Agile 2005. Used with permission.

PatientKeeper CTO Jeff Sutherland explains how this works:^[2]

^[2] Posted on [e-mail] on September 25, 2005. The fourth point is from message 9404, August 5, 2005, message 8849. Used with permission.

• All Sprints result in a production release of software.

• QA starts testing as soon as development updates the first code. They can independently kick off the build process and direct it to any QA server.

• By mid-Sprint, the install team deploys Release Candidate1into the customer's test environment. Now the customer is testing along side internal QA.

• As soon as customer starts feeding back issues, they are addressed by development along with any other issues QA finds.

• Functionality which the customers view as essential to go live continues to surprise us right until the end of the Sprint. We embrace those surprises as it makes the product better faster for all customers.

• It typically takes two or three Release Candidates to go live. All development tasks are complete, all QA issues addressed, and all customer issues completed. QA has run a regression test on the entire system.

• Everyone goes live together at the end of the Sprint. Could be a multi-hospital system with hundreds of physician PDA users and thousands of Web users. We typically take 35 customers live at the end of a Sprint.

• Done means all customers are live with no outstanding critical issues. Note that in this scenario, the customer and installation teams are as tightly in the loop as QA and development.

At PatientKeeper, product managers are responsible for deciding exactly what customers want and creating fine-grain definitions of features that are ready for coding. That means, for example, that the product manager has verified a user interface capability through prototypes and possibly focus groups, and made final, detailed decisions on how the interface will work. No attempt is made to distinguish feature requests from defects; they all go into an automated backlog. The product manager is responsible for assigning backlog items to releases.

Development teams are assigned to releases, which consist of assigned backlog items. A developer takes an item from the backlog, breaks it into tasks, and estimates each task. The estimates are entered into the system and rolled up automatically to the backlog item. At the end of each day, it takes no more than a minute for each developer to enter into the tracking system the time spent on each task and its estimated percent complete. With this data in the tracking system, anyone in the company can obtain solid information about how much more time is necessary to complete every release under development.

The rule is that all releases must be on time, so if the system shows that there is too much work, backlog items are removed from the release to match required work to the capacity of the development teams. Because the tracking system gives accurate, up-to-date information about the time to complete any collection of backlog items, tradeoffs can be accurately identified, and valid decisions can be made. Priorities are resolved at weekly meetings which are attended by all the relevant decision makers, including the CEO. Program managers implement the decisions by changing the assignment of backlog items to a release, and development teams self-organize to resolve any problems.

PatientKeeper is fast: It can deliver any application it chooses to develop in 90 days or less. It will not surprise anyone who understands lean that the company has to maintain superb quality in order to support such rapid delivery. Jeff Sutherland explains that rapid cycle time:^[3]

^[3] Posted on [e-mail] on November 21, 2004, message 5439. Used with permission.

• Increases learning tremendously.

• Eliminates buggy software because you die if you don't fix this.

• Fixes the install process because you die if you have to install 45 releases this year and install is not easy.

• Improves the upgrade process because there is a constant flow of upgrades that are mandatory. Makes upgrades easy.

• Forces implementation of sustainable pace….. You die a death of attrition without it.

Although this mode of operation seems natural at PatientKeeper, it amazes outsiders. One of the keys is that everyone in the company works together in a spirit of trust, respect, commitment, and continuous improvement. Teams include product managers, developers, QA, and product support. The lead architect is the most experienced and trusted engineer in the company.

Time: The Universal Currency

Everything that goes wrong in a process shows up as a time delay. Defects add delay. Complexity slows things down. Low productivity shows up as taking more time. Change intolerance makes things go very slowly. Building the wrong thing adds a huge delay. Too many things in process create queues and slows down the flow.

Time, specifically cycle time, is the universal lean measurement that alerts us when anything is going wrong. A capable development process is one that transforms identified customer needs into delivered customer value at a reliable, repeatable cadence, which we call cycle time. It is this cycle time that paces the organization, causes value to flow, forces quality to be built into the product, and clarifies the capacity of the organization.

A lean organization makes sure that processes are both available when work arrives at the process, and capable of doing the job expected of the process.^[4] You can find out if your processes are available and capable by looking for the red flag called "expediting." Expediting happens when work arrives at a process and gets stuck in a queue, but someone thinks the work is so important that they personally "push it through." If requests are regularly pushed through the system by an "expediter," something is wrong. Either the process is not available when work comes in, or it is not capable of doing the work.

^[4] See www.lean.org.

What does this mean for software development? Consider a software maintenance department that has guaranteed response times of two hours for an emergency, one day for a normal problem, and two weeks for lower priority changes. When an emergency occurs, the department can promise a two hour maximum response time and probably deliver a lot faster. When other requests arrive, it can also promise a reliable response time compatible with the type of request. Since the department has a reliable and repeatable cadence of work, it has established a predictable level of work that can be done. When this threshold is reached, routine requests are turned down or backup capacity is engaged.

Lean organizations evaluate their operational performance by measuring the end-to-end cycle time of core business processes. The value stream maps in Chapter 4 mapped an end-to-end process that started and ended with a customer. They laid out the steps and totaled up the time from concept to launch (for products), or from customer request to deployed software. Excellent performance comes from completing this cycle with as little wasted time and effort as possible.

The best way to measure the quality of a software development process is to measure the average end-to-end cycle time of the development process. Specifically, what is the average time it takes to repeatedly and reliably go from concept to cash or from customer order to deployed software? The idea is not to measure one instance of this cycle time; measure the average time it takes your organization to go from customer need to need filled.

But size varies all over the map. There is no such thing as "average" for us.

If you can treat your work like a product, the best approach is to establish a regular release cycleevery two weeks, every six weeks, every six monthswhatever is practical for you. Make it as short a period as you can possibly manage. Then determine how much work you can do in a release, and don't accept any more than that. Never delay a release because something isn't readytake out some features and be careful not to take on so much work next release. Pretty soon you will know how much you can accept in a release.

It helps to divide work within cycles into fine-grain items the same way Patient-Keeper does. In Chapter 8 we discuss how to divide work into "stories," which are one to three days worth of development work. Over time a development team will complete these stories at a reliable, repeatable velocitywhich is the demonstrated capacity of the team.

If regular releases don't make sense in your world, tryvery hardto put an upper limit on project sizesix months is a good targetno more than twelve. It has been reported that for many years, Wal-Mart and Dell have limited IT projects size to approximately nine months; surely you can too.

Having set an upper limit on project size, group your projects into two or three groups: emergency, small, and large or some similar categories. Then try to reach a "service level" for each category.

Our projects are far too big and too unique to think about cycles. They go on for years.

No matter how big a development effort is, it gets done in small steps. We used to look at these steps sequentially and create a lot of partially done work at each step. Instead, figure out how to divide up that big effort differently. Divide it into increments of demonstrable value or minimum useful feature sets. In Chapter 8 we will show how a version of the Polaris submarine was launched just three years into a nine year development program. Surely there is a version of your system that can be demonstrated in one third of the overall development time.

Next, try to establish smaller cyclessix weeks to three monthswhere everything available up to that point is integrated, any existing capability is demonstrated and evaluated, and appropriate decisions are made. Then you have a cycle of no more than three months, and your goal is to deliver a repeatable amount of working software, reliably every cycle.