Classic Development Model and Lean Model Compared

In the lean development model we change certain elements of the conventional development process, to allow the development organization to work more flexibly. Here is why.

Microsoft’s Model

In a recent article I read about the making of Windows 7.0. There I found some interesting information about the size of a typical development project. Windows NT for example was written by 800 developers, while 1400 worked on Windows 2000, and over 3000 developers were needed to create Windows 7.0.

A certain overhead is needed, to organize these quantities of persons to work in the same direction. Traditionally we used in the entire industry the waterfall method, and basically tried to work with the same process and timelines for the entire group of developers. With growing project size, we found that the flexibility diminished, and the number of problems increased. Agile development methods introduce a different setup to the development organisation, which make the individual teams more agile, and thus the development organization more flexible.

Responsiblity

In the classic development model, the product responsiblity is handed over from department to department. Multiple teams and individuals work on similar tasks, one after the other, and thus, skills and competencies are wideley scattered. The entire organization is controlled by reporting and status messages, which are aggregated to the highest level. Artifical organisational barriers exist, which make the entire organization volatile.

With the lean development model, the product responsibility is clearly defined and assigned to a team, which has the needed empowerment to decide on all aspects of the project. The project consists of all required skills, such as for development, quality assurance, or solution management. The team has a mutual understanding, and is self organizing towards the project success.

Organization

In the classic development model, we align the entire organization to several development deadlines, and deliveralbes. Thus, very complex projects need to deliver at the same speed than simple ones. As the development phases follows one after the other, it is impossible to to correct errors in the same cycle. For instance, if a complex project is not delivered, we need to deliver it with the next cycle, or with a specific patch.

With the lean development model, we use a synchronized model, which consists of self-regulating closed loop processes. The closed loop processes are synchronized towards certain general deadlines. In the rest of the time, the projects work independently.

Transparency

With the classic development model we have a low overall transparency, as the key performance indicators used can only be raw, and as the organization works with a single, intransparent development cycle. The quality is low, as quality control takes place after the development is finished.

With the lean development model the processes are self-controlled. The transparency is improved, as the value creation progresss is used to transport the development process. As quality control is part of the development, quality is build into the process.

Weiterführende Informationen

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

This entry was posted on Freitag, November 6th, 2009 at 9:51 pm. It is filed under Agile&Scrum, Thema des Tages and tagged with Agile Development, English Content, Rolle des PM, SCRUM. You can follow any responses to this entry through the RSS 2.0 feed.