Last month, a client and I were sitting in a nondescript conference room in downtown New York.
My client was relatively new to software development, and I was explaining that, in traditional software development life cycles (SDLCs), it is absolutely critical to get requirements right. Why? Because if requirement errors and omissions are not caught until very late in the process, they can cost a lot of money and rework down the road.
To illustrate my point, I showed him a typical V Model illustration (focusing on requirements elements):
The V Model is certainly not new to the world of software development. It can be viewed as a simple evolution of a typical waterfall model that has the testing and verification phases bent up to form the shape of the letter V. When this is done, there is a correspondence between the phases on the left (that elaborate the product) and the phases on the right (that validate those earlier phases).
The conversation ended with my client saying, “All of this is good for you to know, but if you’re working in an agile environment, you won’t have to worry about it.” But, on the long train ride back to Washington, it occurred to me that this isn’t exactly the case.
Indeed, the V Model has a few things to show us agilists.It Highlights the Importance of Testing
The most obvious characteristic of the V Model is that it strongly favors testing and validation of all the work done earlier in the project. Yes, all the work, whether you are talking about unit tests validating a module’s code or project acceptance validating that the project delivered the business requirements.
But what is our real day-to-day consideration of (non-unit) testing? At most, it will usually be a quick “let’s run it by a couple (actual) users.” More often, we have testers (or even just the product owner) poking around at it and making sure it works. And that makes sense, because our next iteration is coming out in two weeks anyway, so we can effectively just have our users test the product in production. Right?
No! Not right! Remember that we are not just tasked with delivering software frequently, but also with “deliver[ing] working software frequently.” Too often, we can take an expedient view of getting the product out the door, and this can have a massive impact on our customers’ impressions of the product and indeed on our businesses.It Encourages Us to Question Test Coverage
Here’s the deal: There are two different definitions of “working,” and we need to hit them both.
What do we usually consider it to mean? First, that it’s bug-free, or at least has a low defect count. I’m certainly not going to challenge our traditional concept of quality, but this definition is less important that the second criterion, namely:
Does the product do what the customers want it to do?
Most of our agile teams don’t have any process in place to verify that the next release will pass this test. And that’s why we are frequently surprised when a particular version isn’t well received. We met our definition of done and acceptance criteria, after all.
Make no mistake: rapid iteration is not a solution to mediocre quality.It Shows Us Why We Do Agile
Have I talked enough about quality? Good! Let’s shift gears to focus on the V Model as the most effective marketing tool for agile development ever created.
The next time a customer or CTO asks you why they should switch to agile methods, pull out a copy of the trusty V Model, and you can’t go wrong. Simply follow this three-step process:Point out the lateral distance between “business requirements” and “project acceptance.” Tell them that represents time. Not project time, but real-world time in which their customers’ needs are changing and their competitors are working to beat them. Mention that, unfortunately, the project’s scope will be frozen during this period, unless they want write a new statement of work (SOW). Point out the distance between “functional requirements” and “user acceptance testing.” Tell them this represents the time gap between their providing requirements and their seeing the first version of the system. Business-technology collaboration isn’t written into waterfall processes during this time (although, it does kind of show up for non-agile iterative methods).
As you can see, the V Model has a lot to teach us – or at least to remind us. Good product development practices can often be found in the last place we’d expect to find them, and it’s worth taking a fresh look from time to time.
How about you? Do you see any other leverage points for the V Model in agile? Let me know in the comments below.