[obflink-image link=”https://content.tuleap.org/ebook-scaled-agile-how-to-implement-transformation” id=”229039″ alt”ALT” class=”my-image” target=”_blank” size=”large”]
The V-cycle is a series of project stages
It’s difficult to compare a V-cycle that’s “project-oriented” with a scaled agile approach that’s “organizational.” Let me compare the V-cycle with an agile practice such as Scrum, for example. The V-cycle is a series of project stages, each of which is validated in FILO (First In Last Out) mode, so ultimately, it’s a sequence of stages.
Integration OF TEAMS ORGANIZED IN V-CYCLE into the synchronization milestones is always tricky
A V-cycle is still a structure based on the predictability of solutions, in which user feedback will have difficulty being heard as people won’t take the risk of questioning forecasts, or will do so only to a marginal degree. A scaled agile approach integrates the customer so as to guide functional objectives and take account of the other important factor: allowing the product to be adapted as it’s developed.
It is possible to envisage organizations at scale with a few teams organized in V-cycles on the margins, but integrating these into the synchronization milestones is always tricky, even if they are based on mini V-cycles.
Organizing sprints into mini V-cycles in this way is a perversion of agile, especially when it predominates, in that it organizes developments in sequences (development specifications—testing— production) without the teams actually being multifunctional. This way of organizing things is fairly quickly exposed by visual management practices (Kanban), in which there’s a requirement to track the stages.
We should see a real difference and remain truly agile if we’ve scaled up intelligently.
Ha-ha, good question—sounds like it’s based on real experience! Obviously, these ought to be quite different, as my co-authors have explained.
In reality, and especially at large scale and with top-down approaches, the two techniques aren’t that easy to distinguish.
For example, you might find yourself doing SAFe with a specification PI (Program Increment), a development PI, and a validation PI. And given the magnitude of the task, and at risk of being booed by the whole agile community, that can be a way of starting. Prioritizing collaboration between teams above frequent and incremental delivery is one possible approach. The next step might involve working on a prioritized portfolio, linked to offer and solution strategies, while integrating customer feedback. Another might consist of investing in integration flows, verification, validation, and continuous rollout in order to frequently deliver increments.
With a bottom-up approach, we should see a real difference and remain truly agile if we’ve scaled up intelligently.
Applying approaches based on the assumptions is often akin to building a house of cards
Let’s keep in mind that the V-cycle or waterfall (cascade) cycle is an approach that seeks to systematize project implementation in view of the methodological experience acquired over time, and in particular in line with two key assumptions: that we know what we want to do, and that we know how we’ll do it.
However, in our digital world, where technologies evolve very rapidly, and where needs are not defined or only poorly defined and change even faster, applying approaches based on the above assumptions is often akin to building a house of cards. You just can’t define everything in anticipation of something you don’t know. Or rather, in order to be able to define things beforehand, you have to choose to work with obsolete technologies and not innovate too much. I’m not sure it’s a recipe for success.
