<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1639769139832878&amp;ev=PageView&amp;noscript=1">

How a Waterfall Era V-Model Found its Way into an Agile Retrospective

| 19 Jul 2020

v-model-dk

 

In the software development world, the discussion around Agile or Waterfall isn’t new, and one could argue there are many variations of each, including hybrids that try to blend the best of both. And certainly these methods or techniques aren’t just for software development teams, as any type of project or work effort can benefit from the ideas and concepts associated with these delivery approaches.

This post doesn’t attempt to define when to employ Agile or Waterfall, or spend time explaining what these methods are. This is a simple story showing how the value of bringing together people with different backgrounds and experiences can have in a retrospective and the value of a implementing a good model.

This story is about an infrastructure project. It was completed on-time, on-budget, for the most part the key stakeholders were happy, and the technical team felt good about the outcomes. Agile style retrospectives were done throughout the project. They are sort of like project close-out if you’re more familiar with traditional software development life cycle (SDLC) approach, but are done after each sprint.

This project had several sprints, and during a recent sprint demo there was a disconnect between what was presented and the expectations of a key stakeholder. During the What could be improved? portion of the retrospective for this sprint, there was good discussion around testing and the misunderstood stakeholder requirement. To clarify a point, one of the team members drew the V-model on their whiteboard and re-positioned their camera for the group to see.

Part of the discussion was around how the team had traced things from requirements through design, and then test and validation. Some of the team members weren’t as familiar with the V-model as others, and the simplicity of how the model emphasizes the different levels of testing and verification. This insight helped the team hone in on what could be improved next time.

I hadn’t heard anyone talk about the V-model in a good while. I recall first hearing about it years ago when I worked at Andersen Consulting (Accenture).   I checked Wikipedia to see when the model was first introduced. Seems like “The V-model first appeared at Hughes Aircraft circa 1982…” (source: https://en.wikipedia.org/wiki/V-model).

The value of an easy to understand model, and the benefit of bringing people with different backgrounds and experiences together to drive continuous improvement were two key takeaways for me, and I wanted to share this experience.

Thanks for reading! Rob