Saturday, November 05, 2005

Agile Lifecycle Collapses the V-model upon itself

Many are familiar with the waterfall lifecycle model for software development. Fewer are familiar with the 'V' lifecycle model for software development.

These two lifecycles models are very similar. The main difference is that the 'V' model makes a deliberate attempt to "engage" stakeholders located on the back-end of the 'V' during the corresponding front-end phase:
  • During Requirements/Analysis, system testers are engaged to not only review the requirements (which they will have to test against), but also to begin developing the tests.

  • During architectural and high-level design, integrators and integration testers are engaged to review the design and the interface control specs, as well as to begin developing plans and test-cases for integration and integration-testing

  • at this point, hopefully you get the main idea ... at a given phase where deleverables are produced, the folks who are responsible for validating conformance to those specs are engaged to review the result and to begin development of their V&V plans and artifacts
When used in conjunction with Test-Driven Development (TDD), and especially with a lean focus on minimizing intermediate artifacts, the agile lifecycle in a very real sense makes the two sides of the 'V' converge to create almost a single line (instead of two lines forming a 'V'):
  • TDD attempts to use tests as the requirements themselves to the greatest extent possible

  • emphasis on lean, readable/maintainable code oftenlead to a literate programming style (e.g., JavaDocs) and/or a verbose naming convention style such that detailed design and source code are one and the same.

  • focus on simplicity and eliminating redundancy increases this trend via principles and practices such as those mentioned in the Principle of Locality of Reference Documentation and Single-Source Information)

  • Use of iterative development with short iterations makes the 'V' (re)start and then converge over and over again throughout the development of a release.
The result: using cross-lifecycle collaboration in combination with tests as requirements and self-documenting code as detailed design and writing tests before the code makes the ends of the 'V' model converge together so that each end practically collapses against the other in a thick, almost single line. Plus successive short iterations serve to increase the frequency of this trend.

The agile lifecycle tries to eliminate (or at least create a tessarect for) the distance between the symmetric points at each end of the V-model by making the stakeholders come together and collaborate on the same artifacts (rather than separate ones) while also working in many small vertical slices on a feature-by-feature (or story-by-story) basis. There are no separately opposing streams of workflow: just a single stream of work and workers that collaborate to deliver business value down this single stream as lean + agile as possible.

3 comments:

Brad Appleton said...

Thanks Glen! If you or anyone else finds a URL to a more suitable V-model diagram, let me know about it and I will promise to update the blog-entry to point to that instead.

BTW - for anyone else reading this, Glen's "Herding Cats" blog recently had some related entries on Waterfall and Agile and More Thoughts on Waterfall

A passionate IT Professional said...

Dear Brad,

I think the approach you described is more like a W-Model.

In V-Model, testing is focused on the software and test cases is developed based on work products from previous stages. The work products from different levels help to develop test cases at different level to test the system at corresponding levels.

Brad Appleton said...

Hi Francis! I have to disagree that the Agile lifecycle resembles a W-model. In the extreme case (XP) the requirements and the tests end up being the same physical artifact. In the less extreme case, it is more like a series of 'I' in sequence, like a set of sewing sticthes :)

Some have also described Agile as more of a vvvvvvvvv Model (lots of little v's). Again I would still argue that it is not just the shortening of the lifecycle, but the close collaboration which breaks down the phase boundaries and makes the requirements and testing progress concurrently at the same time by the same set of collaborating individuals (rather than handoffs)