It is sensible to want to avoid the head-butting sort of competition—that is, arguing for the sake of arguing. But, differing opinions and styles can be a good thing. Competitive forces have driven markets, innovation, and civilization for millennia. Here, Jurgen Appelo takes a look at some of the various approaches to agile development and what they bring to the table.
It is sensible to want to avoid the head-butting sort of competition—that is, arguing for the sake of arguing. But, differing opinions and styles can be a good thing. Competitive forces have driven markets, innovation, and civilization for millennia. Here, Jurgen Appelo takes a look at some of the various approaches to agile development and what they bring to the table.
There are few games without competition and few systems without conflict. Our world wouldn’t be interesting without some dissenting views. Fortunately, there is plenty of healthy competition within the agile world, like Scrum versus Extreme Programming, Scrum versus Kanban, and even Scrum versus Scrum! But, the various agile methods are not the only players in this game. There are a couple of powerful and promising contestants offering ideas that are sometimes analogous, sometimes complementary, and sometimes downright contradictory.
One of the bigger players is lean software development, which is a translation of the concepts of lean manufacturing to the domain of software development. The seven principles of lean [1] are based on the fourteen principles of the Toyota Way (the management philosophy of the Toyota corporation) and the fourteen points for Management by W. Edwards Deming. There is significant overlap between the worlds of lean and agile, which is why they often play on the same side, with the same experts, sharing the same fan base, and being covered in the same blogs, magazines, and TV shows. Lean software development has made considerable contributions to the agile world from a managerial perspective, with its clear focus on removing waste and optimizing the whole. And, though lean joined the software development league a few years later than agile, the lean movement has caught up by evolving its own conferences, consultants, coaches, and consortiums.
A smaller but capable player is the Software Craftsmanship movement, guided by the Manifesto for Software Craftsmanship (see figure 1), which is said to both challenge and extend the original Agile Manifesto. The software craftsmanship proponents take the stance that software developers are not engineers but craftsmen and craftswomen. (Some people draw on the apprenticeship model of Medieval Europe as a fitting metaphor.) The craftsmanship movement can be seen as the nimble and fearless new co-player of agile and lean, with its own (smaller) events, books, and forums. Together, on the lightweight side of software development, the three of them seem to form a great team—despite the occasional fist fights in the locker rooms.
Figure 1: The Manifesto for Software Craftsmanship
But, the heavyweight methods and frameworks have not remained idle either. Possibly the most famous of these players and one of the most controversial is the Capability Maturity Model Integration (CMMI). Since 1987, it has been developed and maintained by the Software Engineering Institute, a research and development center headquartered at the Carnegie Mellon University. It started out as a process improvement description for software engineering, but it has grown into a more abstract framework that now covers other professions besides software development. The CMMI is an approach that aims to provide guidance by describing five maturity levels and twenty-two process areas. The CMMI only tells you which process areas can be addressed in your process improvement efforts. It doesn’t prescribe how to implement them. For this reason, some agilists believe that the CMMI, even though its full description spans many hundreds of pages, is still compatible with agile software development, because agile methods complement the CMMI by describing the “how” of process improvement. But, agilists wouldn’t be agilists if they didn’t disagree with each other. And, thus, there are some who believe that the gravity of the CMMI, despite its good intentions, pulls organizations in the direction of bureaucracy and crippled teams—with high ratings for looks and outfits, but low scores for actual gameplay.
Similar conflicting signals have been heard about the Guide to Project Management Body of Knowledge (PMBOK), which is published and maintained by the Project Management Institute. Interestingly enough, this guide started as a description of best practices for project management in general. But, since its first publication in 1987, it has been revised several times and has been made more “agile” in response to successes achieved by agile project managers. Contrary to the CMMI, the PMBOK specifically suggests—using fourty-two processes—how project managers can do their jobs. And, though the suggested practices don’t always fit well with agile principles, many project managers actively try to resolve the discrepancies. Though, it must be said, most of the PMBOK covers very different territory than agile. Exactly the same can be said for PRINCE2, a project management method in a similar vein, published and maintained by the Office of Government Commerce in the UK and mainly practiced in Europe.
Last but not least, there is the Unified Process and its better-known refinement called the Rational Unified Process (RUP). It has been developed since 1997 by Rational Software (now IBM). The RUP is to software developers what the PMBOK is to project managers. It defines a considerable framework of processes which can (and should) be tailored to specific project situations, but its documentation is delivered in such a way that the whole framework is often seen as bureaucratic. Agilists believe that a process should be grown throughout a project, beginning with a bare minimum of a few practices. While RUP tried the opposite approach, defining many practices and then suggesting that the unneeded ones can be removed. (I have often compared this approach to the purchase and subsequent dismantling of a Boeing 747, with the purpose of turning it into a bicycle for shopping. For many projects, it seemed smarter to me to simply use a bicycle.) Not surprisingly, in response to agile’s many victories around the world, several more agile alternatives to the RUP have been proposed, including the Agile Unified Process (AUP), the Open Unified Process (OpenUP), and the Essential Unified Process (EssUP). But, none of these players seem to have fared well in the global league of agile methods.
This article is adapted from the book Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo, published by Addison-Wesley in Mike Cohn’s Signature Series.
References
- Poppendieck, Mary et.al. Leading Lean Software Development. Boston: Addison-Wesley, 2009.
