Unified Process

Unified Process and (worse still) Rational Unified Process have always sent a chill down my spine. I worked with both before I arrived in ThoughtWorks. First as a freelancer for IBM Ireland in ‘98 on an early Swing project with RUP. Just before ThoughtWorks though, I spent seven weeks at Valtech in London where Valtech’s Unified Process was the way. RUP/UP was not for me as Agile and XP were what I wanted, and I was slowly jumping the flaming hurdles (interviews) that TW put in my way to get hired. TW immediately placed me in an architectural role helping the software arm of a large ‘Energy Trader’ go Agile. We leveraged XP of course, though discretely as the client already had a larger process that was home grown. Never for a second did any of the project teams we set up consider UP or RUP. And never in the four years since has it been suggested at any other client I’ve been involved with. ThoughtWorks of course considers itself an Agile methodology pioneer, perhaps suggesting that nobody works for us that burns a candle for Unified Process. Times change though: I hear Valtech likes XP nowadays, and also that IBM are about to dump swathes of the Rational product and ideas suite on the Eclipse Foundation.

So I wonder what the buzz is about Agile Unified Process (AUP). My gut instincts tell me it’s not Agile as I know it. First some more background:

Bayes’ Theorem is applied to methodology

I’ve been saying this for years (for humor value) in the context of choosing a methodology:

If you have a long development time frame and expect to lose a number of your staff along the way, choose UP.

If you have a short development period and expect to see little turnover in staff, then choose XP or one of the other Agile methodologies.

And then if you mis-apply Bayes’ theorem (this is little to do with probability after all) and attempt to transform the above you get the following:

If you choose UP for your software development methodology, expect to lose members of staff along the way and for the development to take some time.

If you choose XP/Agile, expect that the vast majority of developers will stay for as long as they can, and that the development period will be short.

You see, whereas Agile/XP energize and invigorate developers, UP and other heavy processes drive them insane. Even when staff have departed (to save their sanity), the allegedly valuable artifacts given to newbies quickly drive them insane as they try to catch up with the project team and indeed the non-obvious stage the project is at.

There is a company called Connextra in London. At some point in its fabled past, an XP team completed a major phase of their project. At the same moment the business changed (Agile embraces change right?) and many of the core team moved to new pastures, leaving a new and smaller team to look after the code. As it happens that code they left was fully in conformance with Agile principles and practices, meaning no loss of knowledge happened with the departure of the first team, and the continuance of a second one. Rachel blogs about a reunion here . Anyway the point is that starting late on a good Agile project is a joy, not a slow discovery of more and more of the previous architect’s hidden mistakes. XP makes people like working on a project and look forward to coming into work. It makes people stay in close contact years after they have gone their separate ways.

Agile unified Process and Agile Model Driven Development

Refer - http://www.ambysoft.com/unifiedprocess/agileUP.html and http://www.ambysoft.com/unifiedprocess/agileUP.html

So it is with great skepticism that I peruse the new materials that Scott Ambler has produced to promote AUP. Scott has done great service in the last few years to the Agile community. Most particularly with his Database Refactoring book (co-authored with Promod Sadalage from ThoughtWorks).

I appreciate that Scott has a UP past, but I wonder why he reactivates that in the Agile age. We have XP for the most perfectly of commissioned small projects, and Scrum&DSDM for the largest of ‘enterprise’ projects. What was the need for UP to rear its ugly head again, not withstanding the dX (delta-X) from some years ago?

Perhaps it is something to do with many corporations doggedly hanging on to a RUP or UP way, and that AUP is sellable into those forums whereas XP is not. Maybe those enterprises find greatest familiarity with UP phrasing and the most cunning mechanism to infect staff with the joys and success of Agile is via Agile Unified Process. Perhaps I am so far removed from those companies these days that I do not see the light at the end of the tunnel that AUP potentially represents.

Similarly the related Agile Modeling Driven Design (AMDD) suggests it is a spin on Model Driven Architecture (MDA). This is a very contentious topic for the hard-core Agile community.

I read further and further looking for a nugget that I could latch on to. Perhaps this is it:

**‘TDD speaks to programmers whereas AMDD speaks to data professionals.’

I find it relevant because I used to be beholden to DBAs in an age when they ruled systems design- “Oh you want a hair-color field on the Person table do you?” (three weeks pass by) “I thought about what you need was and added a new field to the Person table called hair color ..” (thanks!). That age passed, perhaps brutally so, when large component designs came to the fore in the late 90’s. Luckily we are back to a collaborative approach that does not trash the relation design (as that early component-age stuff did). Collaboration now means DB skilled people working in teams of developers adding some value and pushing SQL skills around the team. At least we do in Agile/XP teams.

The “AMDD speaks to data professionals ..” stuff still, to me, seems to defend the different-team mentality. I just don’t need it for the XP teams I see working very effectively. They have no need for models guiding development; when joint code ownership, high test coverage, Test Driven Development, Continuous Integration etc keep things fresh for them.

I’m left confused as to the need. No doubt smarter colleagues will point it out.