Select the Right Flavor of Agile to Succeed

The Standish Group’s CHAOS research indicates that agile software development projects are 65 per cent more likely to succeed and, therefore, guides organizations to use agile methods to develop software. As an agile practitioner and fan since 2006, I am pleased and unsurprised by the finding. However, the same survey indicates that 12 per cent of agile projects failed and 45 per cent were challenged. How can this be? As an agile consultant, I have heard numerous organizations claim they are implementing agile methods, but, in fact, are not. I have also seen some organizations implement one type of agile software development method when others are more appropriate for their project’s situation. To improve chances of project success, one should select the appropriate “flavor” of agile and implement it fully.

Dozens of different agile methods have been used over the past 50+ years – Rapid Application Development (RAD), Test-Driven Development (TDD), Spiral, Crystal, Rational Unified Process (RUP)/Unified Process (UP), Scrum, Dynamic Systems Development Method (DSDM), Evolutionary Development (Evo), Extreme Programming (XP), Feature-Driven Development (FDD), Kanban, Lean, and others. Each has its own character that imbues it with strengths and weaknesses.

Which Flavor is Best?

It depends on the type of project, the project environment, the skills of the development team, and others. Several important factors that affect the selection of a development process are summarized here.

In small projects there may be only one significant stakeholder. In this case, Scrum is appropriate. In other small projects, there may be a few stakeholders who are in the same location as the development team. Here, XP is appropriate. If the project has a large number of stakeholders flung far and wide, then UP or Evolutionary are more appropriate.

Projects with a large dose of systems integration present much higher risk. The other systems are usually beyond the control of the development team. They may be unknown “black boxes” that are never illuminated to the project team. For these types of projects, risk-driven development processes such as RUP or Evolutionary are most appropriate. For projects without significant systems integration, customer-driven approaches like Scrum or XP are more appropriate.

Systems that integrate with others outside the enterprise tend to require more accountability and documentation. So too, do systems developed for the healthcare industry, the financial industry, or government -- they usually face more scrutiny and regulation than those of other industries. Managers in these environments cannot afford to deploy systems that are not documented. In these cases, more ceremony and documentation are quite rational. Some agile development processes are better suited than others for these environments. XP would not be my first choice to develop an enterprise electronic health record (EHR) application.

Some software development teams use combinations of processes. For example, a team might use a risk-driven approach like UP for the beginning of a large enterprise project with stakeholders spread nation-wide. After the system has been architected and its significant risks have been retired, the team may want to use a Scrum process. After the team is well practiced in its development, it may want to switch to a Kanban process to take advantage of its higher level understanding of agile.

Keep in mind the many agile processes that have been developed and proven to deliver great software.