In my last role as a Project Mentor (something of an architect, lead and a coach, don't ask!), I was thrust with a very large responsibility of taking a very large organisation and its very diverse teams out of a failing gold-plated waterfall process towards 'any' better process. Yes, I had help (Thanks, Pete). Some of the lessons I learnt there after over 600 hundred pages of process definition, ISO audits and an almost visible CMMi level 3 on the horizon were both enriching and permanently damaging. Let me explain a bit.
I came from a UP background but always felt a serious gap. I loved XP, but these two were like chalk and cheese, yet under the hood they spoke the same lingo. Keep it iterative! Yet, UP was prescriptive (and dont even talk about RUP). Working with another large team in the past, I discovered that if you use UP (or a similar doc heavy process) at the top, it keeps a good overall structure in place, but at the implemetation level, since they are iterative, you can apply Agile to manage chunks of a large project. And it works. How? Well it just does.
So this is the valley between. How do we use agile for larger projects. Over time, a good piece of work came around called AUP (Agile Unified Process) and it helped bring the two closer. Yes, yes I know you die-hard agilents out there, you hate UP, but the truth is that this valley exists and someone has to do the dirty work. Take the cumulative results of all the work and put it into a frame of reference. Human beings don't like chaos (and no, developers aren't human! joke). So it's better to cater to humans who need to see a phases, milestones, commitments, penalty clauses, risks, etc managed in a language thay can understand.
How:
1. UP has the phase of Inception or Iteration 0. This means you can do some work like get an inventory of use cases, a candidate architecture, infrastructure needs and some high-level estimates then kick-off into a quick prototype to mitigate risk. This is often overlooked or informal in Agile, giving it a bad name in some 'well paying' circles because they simply can't 'see' what they are getting into.
2. UP has a phase called Elaboration, where most of the use cases are 'elaborated'. Yes this is hated by most agilents et moi. I have burnt my fingers often in this phase finding it difficult to ever reach a perfect close to this phase - 80% use cases done! not always possible on large projects. And what is done mean anyway. Better to change this to 90% of the high risk use cases prototyped.
3. UP expects to have a Contruction phase but you see, if we have been constructiong from the start, its really a misnomer, so we might as well call it an 'alpha testing' phase or 'regular client demo' phase or any other really clever name.
4. Then there is the Transition. Now, agilents, what really is transition, is it deployment, we can do that in a few hours, our stuff is all scripted up, yeah! And we release all the time. I hear you. But its more. For large projects many more things come into play, support setup, user training, data migrations, more data migrations, union approval (yes, it happens), health and safety (yes, this also happens) and other varieties of speed bumps. So take transition seriously, because this is where you get to impress or lose your clients. Plan for transition throughout the project. It's called 'starting with the end in mind'.
Here's a little article that reminded me of the old days (of UP) and told in much truth,
Heart of Unified Process
