Agile vs. RUP - Practicing Resonance: Part 2

While Agile and Unified Software Development-style processes  claim to be iterative and adaptive rather than defined and predictive, they both have limitations when it comes to efficiently producing software in medium sized teams.  This particularly true when these span multiple geographies.  However, they can both teach us how to achieve what I'm calling 'resonance' (see part one of this series). 

Note that the Rational Unified Process (RUP) is the official IBM refinement of what is essentially the Unified Software Development Process (Jacobson, Booch, Rumbaught).  As background, I'll first proceed with this embarrasingly incomplete review of the Agile and RUP practices.

The RUP is "use-case driven, architecture-centric, and incremental and iterative".   Each iteration is part of four overall 'phases': Inception, Elaboration, Construction, and Transition.  Iterations occur in each phase.  Activities in iterations are focused on one of the four activities: gathering requirements, analyzing, designing, implementing, and testing.  Each of these activities place a more or less important role as the project moves from phase to phase.  As Craig Larman points out, RUP is not the dreaded 'waterfall' approach.  It's the mis-application of its myriad of optional workflows and documents that tend to promote that illusion.  Here are some personal observations about how it works in practice.  RUP practitioners are:

• document-centric - they labor to produce detailed documents whose prescribed purpose is the necessary outcome of many of the activities in the overall process
• perfectionists - since they move only once from phase to phase, it is imperative that the artifacts (code, documents, etc) they produce be perfect.  In theory, iterating within the phase should allow for mistakes and trend towards more and more perfect artifacts.
• cautious - RUP practitioners cannot afford to design or implement a mistake because it will destroy the integrity of the overall plan that was established during or even before the first phase.
• independant - some might unjustly say "isolationist".  The truth is, they trust the RUP process 'framework' within which they expect the right information to be available in order to  get their specific job done.  Well defined interfaces between all the components, allow each person to work in relative isolation and then later plugin their individual pieces.

Agile development is more of ethic than a process (the founders refer to it as a  "manifesto").  To get a feel for what a completely "Agile" process might look like, take a look at Xtreme Programming (XP).   In essence, to be agile in software development is to quickly and appropriately react to new information in the development cycle in a way that best satisfies the customer.  To best make this happen, Agile practitioners are:

• customer focused - they insist on having the customer highly involved in each aspect of what is being produced.  The customer's regular feedback is immediately incorporated into the development effort, even it if means significantly changing what had already been produced thus far.
• real - they don't try to make guesses and purposeful keep the scope of their efforts small.  They explore often to get the information necessary to continually make small steps forward.
• intuitive - they rely on experience to guide them through the process and try to minimize activities that 'just don't make sense' for the task at hand.  If a comprehensive design specification doesn't get the job done, then they don't attempt it
• communicators - they try to 'peer program' as much as possible.  They try to convene strategic and tactical thinking in the same activity by having someone 'drive' while their peer 'navigates'.

The "independant" and "communicator" characteristics in  each of the previous lists are the ones most worth focusing on in order to achieve resonance.  Part three will consider RUP and Agile practices' techniques for dealing with independance and the basic communication issue, the very heart of resonant practice.  Most importantly, we will consider exactly what this means for geographically disperse teams.  Stay tuned!

Comments

[Craig Pfeifer]

I like the Agile practices for clients who "think they know exactly what they want" but in fact have no idea, but how is it possible to do an agile project on a firm fixed price development contract?

[Ben]

Whether more 'heavy' or 'agile', resonant practice clearly communicates as much about the end goal as is necessary. This highest-level sketch is essential. Sometimes, it may include only a few use cases. To the extent estimates are based on this (and priced accordingly), there is no conflict. However, as you say, the customer often thinks more can be defined in advance than is truly possible. Options include:

1 - defining the customer documents (their format, etc) yourself
2 - prototyping ahead of estimates. This may involve getting more advance notice when the RFP goes down.
3 - being honest about what you don't know now and how some potential scenarios will affect the outcome

The last item can end up being a longterm source of revenue for the contractor who can bundle these things as 'improvements' on the initial design. You and I know this is simply the effect of iterating (btw, RUP iterates as well) and being 'agile'. If expectations are managed appropriately, this will appear as 'above and beyond' due diligence.

A way around burning up fruitless hours to write useless documentation is to 'extract' customer-focused documentation from actual development artifacts (story cards/use-cases, scanned prototype sketches, etc). The key is getting your development artifacts in an electronic format, allowing for automation of the extraction. Some of the existing RUP tools make this a snap. Without these tools, combine a Wiki, a creative 'extractor', and a little XSLT and problem solved. This is one way to fit your agility into a frustratingly repressive use of the RUP.

Lastly, government projects are being done using agile practices. Not sure how many are being done with consulting contracts or in-house. I'm sure they've had to deal with the RUP requirement.

[Michael]

RUP *is* agile process.

[Ben]

RUP is open-ended. It can be 'agile.' Applied differently, it can also look like a waterfall. Problem is, uninformed people tend implement it assuming they must use *all* (or as much as possible) of the described workflows and artifacts. So, in practice, prescribing the RUP as the process leads to process bloat. The Agile movement is a polar reaction to this.

[Craig]

RUP is an odd hybrid of waterfall and agile. It does iterate, but to the cost of making that changes to the artifacts can be prohibitive.

I dig agile, and I think it has a much better chance of getting the user what they actually want, but I also think it works best in an onsite environment where there's a lot of water-cooler interactions.

[Jeff Anderson]

Because RUP is a process framework, there is some room to make it more compliant with the ethics described in the agile manifesto.

A lot of the principles are also in alignment (between RUP and agile)
things like
-iterative
-model driven
-architecture centric

Can all be applied on agile projects as long as they are tweaked a little to be more lightweight.

You can dump a lot of the heavyweight process complexity in RUP to make it more agile and still be considered "compliant" with RUP. It is a framework not a process.

I talk more about this @ http://agileconsulting.blogspot.com/2009/01/agile-over-rup-my-preferred-development.html

Regards
Jeff
http://agileconsulting.blogspot.com