The Agile Edge: Unified and Agile

Those familiar with heavyweight processes may think it's impossible to marry agility to the Unified Process (UP). However, I'm here to tell you that the combined strengths of both could revolutionize software development. Over the years, our industry has continuously searched for ways to improve productivity and eliminate project failure—and we've made great strides. In fact, as the success of agile methods takes hold, things are ramping up in the Unified Process (UP) world.

But first, a recap: UP has a long and distinguished history, from its 1988 birth as Objectory through its subsequent evolution into the Rational Objectory Process (ROP) in 1996 and finally its emergence as the Rational Unified Process (RUP) in 1998. RUP quickly gained mindshare within the object community, in part because it was coming from Rational, but mostly because it described how to successfully develop software using object technology. My interest and involvement in RUP prompted me to work on extending the process (see "Enhancing the Unified Process," Oct. 1999), and in 2002, I introduced the Enterprise Unified Process (EUP).

In early 2001, I began exploring how to "agilize" RUP both online and in print. And I wasn't alone: In August 2002, Object Mentor developed a plug-in for RUP to make it look as much like XP as possible. Since then, others—in particular, Craig Larman, Gary Evans, Sinan Si Alhir and the RUP team at IBM Rational—have also focused on applying agile approaches to RUP.

My work has culminated in an agile extension to UP, the Agile Unified Process product (www.ambysoft.com/unified process), which I announced in September at SD Best Practices in Boston. Just a few weeks later, IBM Rational released the Eclipse Process Framework (EPF), an open source project for the development of a process editing and display tool and process guidance around agile and iterative development. The Basic Unified Process (BUP) is a core subset of RUP material, and the tool will be IBM's initial offering of EPF process material.

But what is AUP? It's a RUP-based, streamlined approach to software development. Like RUP, it's both serial and iterative in nature: The AUP lifecycle's serial aspect, depicted in "The AUP Lifecycle", can be seen in its four phases, and its iterative nature is expressed in its seven disciplines (see "Introducing Discipline"). As object technology teacher and consultant Gary Evans says, phases are the different seasons that a project goes through. Disciplines define related collections of activities within phases that development team members perform to build, validate and deliver working software that meets their stakeholders' needs.

The AUP Lifecycle The Agile UP lifecycle is serial in the large and iterative in the small, delivering incremental releases over time.

Something Old
AUP phases are depicted in "AUP: Step by Step". The names are the same as in RUP, while the descriptions reflect AUP's simplifications (more on this in a minute). Also, I've always believed that RUP's four milestone reviews, each of which require a go/no-go decision at the end of a phase, are among its most important strengths, so I included them in AUP.

[click for larger image] AUP Step by Step At the end of each AUP phase, the team determines if it makes sense to proceed to the next one.

Like RUP, AUP is also architecture centric. The Elaboration phase's primary goal is to develop a working, end-to-end skeleton of your system to prove that you have addressed your major technical risks. AUP is also use-case driven—use cases are the primary requirements artifact, although AUP does make it explicit that use cases are only part of your overall requirements.

Something New

The most significant change is simplicity. AUP is a dramatic simplification of "out of the box" RUP. AUP has a small number of deliverables—artifacts that you must produce, such as source code and a regression test suite, as part of your system. By streamlining the phases, you reduce time to market. Remember, agility aims to maximize the amount of work not done: Don't write a 50-page document when five pages will do; don't write a five-page doc when a whiteboard sketch will do. Similarly, few roles are defined by AUP. To be fair, IBM Rational acknowledges that you need to cut down RUP to make it fit your situation—unfortunately, few organizations seem willing to do that work..

RUP's Business Modeling, Requirements, and Analysis and Design disciplines are combined within AUP's Model discipline. Furthermore, AUP requires less up-front modeling. In RUP, the general advice is to complete your requirements model to the 20 percent level during the Inception phase, rising to 80 percent during Elaboration. In AUP, however, you do some initial modeling up front, perhaps taking your understanding of the requirements to the 5-10 percent level, and then you "model storm" the details as needed later in the project. You still model, but you do it just in time, enabling you to develop working software earlier in the process.

"AUP Amalgamated" depicts the workflow diagram for AUP's Implementation discipline. This diagram overviews the entire discipline—compare this with RUP's overview diagram plus five supporting workflow diagrams. AUP is based on the knowledge that developers are capable people who know what they're doing, but may need a reminder or two once in a while. And because most developers don't read detailed procedures, I described AUP's disciplines as simply as possible, with supplemental links for anyone who wants them.

AUP replaces RUP's Configuration and Change Management discipline with a Configuration Management discipline and subsumes RUP's change management activities into Model and Project Management disciplines. In the Model discipline, a change request or defect report is treated as just another requirement to be prioritized by the stakeholder(s) and put on the stack. Similarly, the Project Management discipline entails requirements estimated by the people responsible for implementing the requirement, an effort guided by the team's project manager. Both of these strategies reflect common agile techniques for change management.

Something Borrowed
The Implementation discipline adopts agile techniques such as test-first programming, code refactoring, database refactoring, continuous builds and continuous regression testing. The need for developers to work closely with both their stakeholders and the agile modelers on the team is also explicitly depicted. This discipline also makes database administration efforts more explicit, via the Agile Data method.

In AUP, the Project Manager role has evolved to reflect agile project management approaches. In agile development, the manager is a coach who guides, protects and empowers the team. AUP retains the RUP practice of making explicit the technical aspects of project management, such as developing the project plan and managing risk.

Something Blue
AUP isn't for everyone—no process is. You should adopt AUP if you're looking for a very agile and streamlined version of the Unified Process. If you want something with a little more meat, consider the forthcoming BUP. And for a well-defined, rigorous process, IBM Rational's RUP product (www-306.ibm.com/ software/awdtools/rup/) is a good option. Finally, if you want an enterprise-level process, consider adopting the Enterprise Unified Process (www .enterpriseunified process.com).

Scott W. Ambler is a Canada-based software process improvement (SPI) consultant, mentor and trainer with Ambysoft Inc. He has written several books and is a regular speaker at software conferences worldwide.