Validation Vee

I honestly divide my software development life into the period before I had heard of the ValidationVee and the period after. <g> Thanks to AlistairCockburn for developing it, and to JamesCollins for sharing it.

Imagine a large "V" as describing the lifecycle of your project. Regardless of the names applied by the methodology or development approach you are using, you go through several common stages.

Going down the left-hand side of the V are Analysis, Design, and Coding. As software professionals we like to tell ourselves that by producing a formal Requirements document and forcing our users to sign it, we have validated that we got the requirement right. Ditto for design. And with a formal code review we know that the code is perfect. But these are false validation points. They only prove that we *think* we've gotten things right, not that we actually *have* gotten them right.

Going up the right hand side of the V are Unit Testing, System Testing, and User Acceptance Testing. The reality is that until we start climbing up the "right hand side of the V," we get no real world, meaningful validation of anything. Unit test is our validation that we got the code right. System Test is when we find out if our design is really stable, scalable, and performant. And it is not until we get all the way up to UAT that we get validation of our understanding of the requirements.

In a "typical" software project, the width of the V has been 18 - 24 months. Guess what: even on the off-chance that you got the requirements right, they are no longer right. <g> Plus, any time you actually deliver software to your users, their understanding of their own requirements changes. This is not because users are sloppy or dumb in expressing requirements. This is because of some fundamental Heisenbergian-type factor where delivering on requirements changes the requirements.

At the top of the V, when you actually deliver, you learn a lot more than whether your requirements-gathering was successful. You learn about your team, about your users, about your tools, about the infrastructure, about your development approach, etc.

The idea is to break that great big V down into little v's, each incrementally delivering more and more of the system functionality. These little v's should be 8 weeks wide or less. When you stack a bunch of these little V's side-by-side, they look more like a series of W's... I think this model was originally referred to as the V-W model.

The right hand corner of each little v represents an actual delivery of working software (not prototypes, god save us!) to users external to the team. It also represents a chance for:

Reprioritizing requirements
Changing the organization of the team
Changing tools/platforms

This has several major advantages:

You establish a regular rhythm of delivery, which helps the team's confidence and morale and builds your users' trust. If you don't get to the last piece of functionality in the v, your users know it is only slipping 8 weeks, and they believe in your ability to deliver.
Because you give your users frequent formal chances to reprioritize their requirements, you can be very flexible and EmbraceChange. Each little v is like a peton driven into a rock face -- you won't fall all the way back to the ground if conditions change dramatically in the middle of the big V.
Because you are only asking your users for the requirements for delivery 8 weeks from now, you can have a much more reasonable discussion about what those requirements are. If you are asking for their requirements for delivery 24 months from now, they're going to demand everything including the kitchen sink.

In fact, if you are building in HorizontalStripes, delivering groups of use cases in their entire end-to-end glory, your little v is actually made up of several micro-v's, and you get most of the same benefits at a smaller scale, too. I have even run on-boarding activities where new team members are brought into a "nano-V" workshop -- if you're working in 8-week cycles, collapse them down to a single day. Each hour represents one week. Take a very tiny user story, walk it all the way through the V and deploy it. Its an eye opening way of illustrating how differently work flows through this kind of delivery approach.

This model is so rooted in my subconcious that I can hardly talk about software development projects without making a V with my hands. I know many of my customers think the gesture is part of some strange eastern cult... :)

ref. the V-W paper [http://members.aol.com/acockburn/papers/vwstage.htm] (broken link; I think the following page replaces it: [http://alistair.cockburn.us/Using+VW+staging+to+clarify+spiral+development]

There's a MilStdSpeak? poster version of this V titled "Technical Aspect of the DoD Project Cycle (MIL-STD-1521B Compliant)" that I picked up at a project management class many years back. The left downstroke of the V is labeled "Decomposition and Definition," and the right upstroke is labeled "Integration and Verification." There's lots of scary detail in the poster, but stripped of MilStdSpeak?, it's as Bill describes above. I pull the poster out every so often to scare coworkers. --DaveSmith