Twin Peaks: Unified Process and Agile and the valley between

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

IIS to Sql Server Login Failed when not on same domain

Thats happened a few time already (over the past few years). IIS likes to know who you are before it lets you talk to SQL server. So a nice blog here if you are connecting to a Sql Server db from IIS and the two machines are not under the same AD domain.

http://beyondthispoint.blogspot.com/2006/04/setting-up-iis6-application-pool.html

Do the steps, it works! This post is like an extended book mark!

Can we get any more virtual ?

I am stuck with the virtualization question for a bit. To virtualize or not ? Have to.. its in the work I do. So here is a little list. Help me fix it, but I'll throw it in for a start:

I want to..	So ..
Develop on my Win XP/Vista/2003 machine or laptop.	Use VMWare Workstation. Why? You get much better interactive performance when developing.
Keep my personal and business stuff separate from my everchanging-upgrading-munging development work stuff	The host keeps all your basic apps - email, business, skype, fun, etc so you don't have to run vmware to access 'everything'. The host can also run the main dev db server and subversion (cause it's just faster I/O). But its in the background (right!).
Setup my VM for development	Use VMWare Workstation to run a development IDE in a Win2003/8 VM.
Test with my VMWare	Use VMWare Workstation to run as a test server in Win2003/8 VM. Real benefit is you can take a snapshot of your test vmachine and/or create a virtual test environment to handle an n-tier emulation, i.e web server+app server+db server. Just try to keep the test data (files+dlls + dbs) de-coupled from the Test VM so you can just roll back to the full Test VM for a new test run. If you have spare hardware use you can VMWare server 2.0 as it can run the stuff in the background and you can access it from your main terminal (laptop, etc). But then you need to consider setting up DNS/DHCP somewhere. Still prefer the VMware Workstation all-in-one setup.