The VSM will affect your team's delivery throughput, regardless of story complexity

2024-12-29

Context

I’d like to add what I think is an important point to a previous post about Inceptions.

In the context of delivering to value, estimation during Inceptions, or at any given time actually, must take the VSM into consideration. Without doing so, story estimation based on complexity alone will be in a vacuum, devoid of any situational context, rendering it a futile and worthless activity.

The need for a plan

Thanks to positive and collaborative team-dynamics and the motivation to get something done based on aligned values and priorities, part of the euphoria that follows an inception is the desire to put things into action by way of a short-term plan to “see it working”.
This is usually presented as a plan for the first two or three sprints, after rapid analysis of the needed infrastructure, but more importantly, some high-value product and business oriented goals.

A typical plan would include a thin slice across a few high-priority partially implemented Epics, to demonstrate the behaviour and benefits of the new system as much as possible. The plan is the result of prioritising the Epics and the stories therein, estimated based on relative complexity, and ideally ordered such that their development does not interfere with others’.

Great expectations

With the plan drawn and presented, and with high hopes, the team sets to start building the product and everyone is eager to see what the first sprint produces. For this article, I’m ignoring ‘sprint zero’, during which accounts and environments are set up, ‘ways of working’ sessions are held, and other admin and tech tasks are carried out.

Bear with me, I’m giving an extreme example to build suspense and drama: In some cases, the stakeholders will be actively involved with day-to-day operations, but more often than not, unless you’re on a transformation engagement, they’re likely to disappear for the most part, to resurface only for the showcase.

Meanwhile, back in the trenches

Development starts, hopefully using TDD, and developers are working their way up from Unit to Functional and Integration tests. Classic TDD mocks out all network and data connections, focusing on protocol and the design of domains that will implement the stories and features.

The pipeline is fine, since it was either created or validated during sprint zero, but for some reason, PRs are being rejected. I would like to write about PRs and their value in another article, but for the purpose of this article, I am marking this as a failure to understand the VSM that causes delays. Over time, the team will adjust their coding style to achieve a better flow, but for the next few sprints the team will likely be delayed delivering working software due to PR cycles.

• Our calendar-based sprint plan did not account for PR rejection loops because we did not study the VSM during inception.

As the developers climb up the testing pyramid, it’s time to run integration or functional tests, and its time to deploy to shared environments. During this phase, many issues may arise, based on the architecture and ecosystem in which the team’s product is integrated. The team would be in luck if they’re on a green-field project, and owning the complete end-to-end scope without any external dependencies. However, more likely than not, there may be delays due to needed dependencies, approvals, synchronisation, environment availability, test-data availability, and participating components’ observability capabilities.

• Our calendar-based sprint plan did not account for integration test loops because we did not study the VSM during inception.

Nearing production

As the software is deployed to higher environments, more pressures are applied to it, such as compliance, security, legal, support, operations, and stakeholder scrutiny. The software is now exposed to more teams and standards, adding points of infection to delivery process. While the team can try to mitigate these stressors by incorporating these aspects into the stories’ acceptance criteria, these facets of product integrity will affect the team’s capacity to deliver.

• Our calendar-based sprint plan did not account for compliance loops because we did not study the VSM during inception.

Conclusion

So the showcase will likely be a flop, without much to showcase. And the excuses…

There are more examples of product development process pitfalls, but for the purpose of this article, I think the point has been made that the VSM must be studied before any plan can be drawn. Not doing so will affect how stakeholders react to the initial (and ongoing) development sprint plans, causing friction with the development team and diminishing the trust gained during the inception.

To truly draw a viable and realistic sprint plan one must go through the exercise of VSM analysis, with all roles being represented. Put it to the test during Sprint Zero by developing a “Walking skeleton” from concept to production to get a sense of lead times to have a better estimate of the complexity needed for decisions in real stories.