« To Exit Quietly | Main | Getting your Eclipse SWT Shell »

February 10, 2005


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?

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.

RUP *is* agile process.

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.

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.

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
-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


The comments to this entry are closed.