This chapter is from the book
This chapter is from the book
This chapter is from the book
Reliable, Not Repeatable
Note that the word “repeatable” isn’t in the agile lexicon. Implementing repeatable processes has been the goal of many companies, but in product development, repeatability turns out to be the wrong goal; in fact, it turns out to be an extremely counterproductive goal. Repeatable means doing the same thing in the same way to product the same results. Reliable means meeting targets regardless of the impediments thrown in your way—it means constantly adapting to meet a goal.
Repeatable processes reduce variability through measurement and constant process correction. The term originated in manufacturing, where results were well defined and repeatability meant that if a process had consistent inputs, then defined outputs would be produced. Repeatable means that the conversion of inputs to outputs can be replicated with little variation. It implies that no new information can be generated during the process because we have to know all the information in advance to predict the output results accurately. Repeatable processes are not effective for product development projects because precise results are rarely predictable, inputs vary considerably from project to project, and the input-to-output conversions themselves are highly variable.
Reliable processes focus on outputs, not inputs. Using a reliable process, team members figure out ways to consistently achieve a given goal even though the inputs vary dramatically. Because of the input variations, the team may not use the same processes or practices from one project, or even one iteration, to the next. Reliability is results driven. Repeatability is input driven. The irony is that if every project process was somehow made repeatable, the project would be extremely unstable because of input and transformation variations. Even those organizations that purport to have repeatable processes are often successful not because of those processes, but because of the adaptability of the people who are using those processes.
Herein lies a definitional issue with project scope. With production-style projects, those amenable to repeatable processes, scope is considered to be the defined requirements. But in product development, requirements evolve and change over the life of the project, so “scope” can never be precisely defined in the beginning. Therefore, the correct scope to consider for agile projects isn’t defined requirements but the articulated product vision—a releasable product. Product managers may be worried about specific requirements, but executives are concerned about the product as a whole—Does it meet the vision of the customer? When management asks the ever-popular question, “Did the project meet its scope, schedule, and cost targets?” The answer should be evaluated according to the vision, value, and totality of the capabilities delivered. That is, the evaluation of success can be encapsulated in the question “Do we have a releasable product?” not on whether the set of specific features defined at the start of the project was produced.
Agile Project Management is both reliable and predictable: It can deliver products that meet the customer’s evolving needs within the boundary constraints better than any other process for a given level of uncertainty. Why does this happen? Not because some project manager specified detailed tasks and micromanaged them, but because an agile leader established an environment in which people wanted to excel and meet their goals.
Although APM is reliable, it is not infallible, and it cannot eliminate the vagaries of uncertainty, nor the surprises encountered while exploring. APM can shift the odds toward success. If executives expect projects to deliver on the product vision, within the constraints of specified time and cost, every time, without fail, then they should be running an assembly line, not developing products.