Blending agile and lean thinking for more efficient it development.

• Author: Kenworthy, Harry
• Position: Solutions

Governments' information technology projects don't always deliver the promised results. Combine performance problems with a reputation for being late and over budget, and it's easy to see why officials are often reluctant to take on major IT initiatives. The problem isn't inherent in government projects, however; it's caused by the traditional "waterfall" approach to project planning. And it can be minimized by using a different kind of project planning, a Lean approach known as "Agile" development. Agile development and Lean management can lead to more cost-effective, timely production of information technology that better meets users' needs.

TRADITIONAL WATERFALL DEVELOPMENT

Waterfall development has been the dominant approach among IT professionals for years. This approach is about trying to understand the customer's new needs and then working on the development for months, after which the final output is released--a top-to-bottom process. Customer feedback is given when the overall project is completed.

One study indicates that 45 percent of the features in a typical system are never used, and only 7 percent are always used (see Exhibit 1). And overall, success rates for IT development, based on a sampling of multiple publications and studies, are not good:

* Approximately 31 percent of projects get cancelled.

* Approximately 66 percent of projects don't meet customer needs and are therefore considered failures.

* More than 50 percent of projects exceed their budgets by 200 percent.

* Deliverables are not well planned or well managed.

* Project managers could use more training.

* Approximately 10 percent of the developed code was actually used.

* Approximately 82 percent of projects cite waterfall practices as the primary reason for failure.

Many articles have been written about chaos theory and how it relates to waterfall software development. This is because so many uncertainties and variables can come into play when software is developed. Also, some of the assumptions waterfall development makes are unrealistic, such as the idea that customer needs being clearly defined upon going into the project, and the needs of the client department are thoroughly vetted and agreed upon, and that the requirements can be accurately determined at the beginning of the project. Waterfall moves along a straight path, based on initial inputs and assumptions, so errors or miscalculations made at the outset of the project will be included in the final product. Waterfall also assumes that timeframes and budgets are easy to predict in the beginning; many waterfall developments fall in quarterly timeframes for progress and outputs, which is not nearly the frequency needed for reviewing progress and alignment with customer needs, and soliciting customer feedback (which is the final step in a waterfall process, after the project is completed).

THE EVOLUTION OF AGILE

In 2001, a group of 17 IT professional gathered to develop an alternative to the waterfall approach, which they called "Agile." (1) The group agreed to an "Agile Manifesto" (see Exhibit 2), which included several values aimed at making IT development more effective:

1. Individuals and interactions should take precedence over processes and tools.

2. Working software is the desired output, as opposed to comprehensive documentation.

3. Customer collaboration is superior to negotiating contracts with clients.

4. Responding to change is more important than blindly following a plan.

   Exhibit 3 illustrates an example of the...