Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Part 1: Introduction to Disciplined Agil... > Disciplined Agile Delivery in a Nuts...

Chapter 1. Disciplined Agile Delivery in a Nutshell

For every complex problem there is a solution that is simple, neat, and wrong.

H L Mencken

The agile software development paradigm burst onto the scene in the spring of 2001 with the publication of the Agile Manifesto (www.agilemanifesto.org). The 17 authors of the manifesto captured strategies, in the form of four value statements and twelve supporting principles, which they had seen work in practice. These strategies promote close collaboration between developers and their stakeholders; evolutionary and regular creation of software that adds value to the organization; remaining steadfastly focused on quality; adopting practices that provide high value and avoiding those which provide little value (e.g., work smarter, not harder); and striving to improve your approach to development throughout the lifecycle. For anyone with experience on successful software development teams, these strategies likely sound familiar.

Make no mistake, agile is not a fad. When mainstream agile methods such as Scrum and Extreme Programming (XP) were introduced, the ideas contained in them were not new, nor were they even revolutionary at the time. In fact, many of them have been described in-depth in other methods such as Rapid Application Development (RAD), Evo, and various instantiations of the Unified Process, not to mention classic books such as Frederick Brooks’ The Mythical Man Month. It should not be surprising that working together closely in collocated teams and collaborating in a unified manner toward a goal of producing working software produces results superior to those working in specialized silos concerned with individual rather than team performance. It should also come as no surprise that reducing documentation and administrative bureaucracy saves money and speeds up delivery.

While agile was once considered viable only for small, collocated teams, improvements in product quality, team efficiency, and on-time delivery have motivated larger teams to take a closer look at adopting agile principles in their environments. In fact, IBM has teams of several hundred people, often distributed around the globe, that are working on complex products who are applying agile techniques—and have been doing so successfully for years. A recent study conducted by the Agile Journal determined that 88% of companies, many with more than 10,000 employees, are using or evaluating agile practices on their projects. Agile is becoming the dominant software development paradigm. This trend is also echoed in other industry studies, including one conducted by Dr. Dobb’s Journal (DDJ), which found a 76% adoption rate of agile techniques, and within those organizations doing agile, 44% of the project teams on average are applying agile techniques in some way.

Unfortunately, we need to take adoption rate survey results with a grain of salt: A subsequent Ambysoft survey found that only 53% of people claiming to be on “agile teams” actually were. It is clear that agile methods have been overly hyped by various media over the years, leading to abuse and misuse; in fact, the received message regarding agile appears to have justified using little or no process at all. For too many project teams this resulted in anarchy and chaos, leading to project failures and a backlash from the information technology (IT) and systems engineering communities that prefer more traditional approaches.

Properly executed, agile is not an excuse to be undisciplined. The execution of mainstream agile methods such as XP for example have always demanded a disciplined approach, certainly more than traditional approaches such as waterfall methods. Don’t mistake the high ceremony of many traditional methods to be a sign of discipline, rather it’s a sign of rampant and often out-of-control bureaucracy. However, mainstream agile methods don’t provide enough guidance for typical enterprises. Mature implementations of agile recognize a basic need in enterprises for a level of rigor that core agile methods dismiss as not required such as governance, architectural planning, and modeling. Most mainstream agile methods admit that their strategies require significant additions and adjustments to scale beyond teams of about eight people who are working together in close proximity. Furthermore, most Fortune 1000 enterprises and government agencies have larger solution delivery teams that are often distributed, so the required tailoring efforts can prove both expensive and risky. The time is now for a new generation of agile process framework.

Figure 1.1 shows a mind map of the structure of this chapter. We describe each of the topics in the map in clockwise order, beginning at the top right.

Figure 1.1. Outline of this chapter


The Big Ideas in This Chapter

  • People are the primary determinant of success for IT delivery projects.

  • Moving to a disciplined agile delivery process is the first step in scaling agile strategies.

  • Disciplined Agile Delivery (DAD) is an enterprise-aware hybrid software process framework.

  • Agile strategies should be applied throughout the entire delivery lifecycle.

  • Agile teams are easier to govern than traditional teams.


  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint