Encapsulation of Value
Agile transformations are hard. Creating an ecosystem where teams with the appropriate skills and resources are able to organize around a well-prioritized backlog to build working, tested product sounds simple but can quickly become mired in the nuances and details that manifest as all sorts of complexities in product development organizations. Those organizations that invest the blood, sweat, tears (and money!) to get it right are rewarded with accountable, empowered teams with clear priorities predictably delivering quality product. So, imagine the frustration when, after seeing such team-level success, the business results are still just are not there. Velocity is stable, defects released into production are down, backlogs are full and well-prioritized, but adoption of new features is poor, revenue from new products is slow, and stakeholders are still waiting for the delivery of key initiatives. People are starting to draw the conclusion that “Agile doesn’t work.” What happened?
Encapsulation of Value Streams
In the above scenario, we have likely overlooked – or made concessions on – the encapsulation of value streams within our business. Despite the obtuseness of the term, the concept is rather straightforward: encapsulating value means intentionally establishing a clear governance process and organizational structure that facilitates an alignment of product development execution to defined strategic objectives.
The key takeaway from this simple visual representation of the encapsulation of a value stream is the explicitly cascading nature of work through the various tiers. This flow from investment down to user story is the backbone of “building the right thing.” Without it, an organization can get really good at building things fast, and building things right, but will not consistently be able to deliver products that affect the desired outcomes – especially when we are trying to coordinate and direct the coherence of myriad autonomous teams at an enterprise scale.
I think there are three main antipatterns that result in organizations getting off track with the encapsulation of value streams: conflating the encapsulation of value with the technological encapsulation of products; being too conservative with a “pilot” in the context of transformation, and treating epics as mere containers for a group of features. While the mechanisms of these antipatterns are slightly different, they all end up driving the same impact.
Encapsulation of Dependencies
One common pitfall is assuming that the technological encapsulation of products by breaking dependencies (through a loosely coupled architecture and a mature CI/CD pipeline) is a prerequisite for the encapsulation of value streams. While such encapsulation of dependencies certainly reduces the administrative overhead necessary to encapsulate value streams, at the end of the day encapsulating a value stream is possible even for an organization that is dealing with monolithic legacy code, it’s just a matter of putting in the proper governance structure – including the intentional (rather than reactive) orchestration of demand. Consider the below example:
In this instance, let’s assume we have an organizational objective that translates to an epic for the portfolio team shaded green; that epic breaks down into features distributed between the two product teams in green, and finally into user stories that get addressed by the four delivery teams in green. However, in order to deliver that epic, there are dependencies to the teams in grey on the left. It is tempting to throw in the towel and say that encapsulating the value stream is impossible without refactoring the code to eliminate those dependencies, but the reality is that encapsulation of the value stream is still feasible in this scenario. By taking a top-down approach to defining our value stream, we were able to identify those dependencies up front and we can actively orchestrate the dependencies at each tier:
It is more work to do this kind of orchestration but done properly it should not slow down our delivery teams, and the benefits of ensuring that we are building the right thing aligned to an impactful corporate objective are worth the effort.
Laboratory (Sterile) Pilots
When looking to take an organization through an Agile transformation, it makes sense to apply Agile principles to the transformation itself: we should do it iteratively, starting with a slice of the organization that will let us test our hypothesis about the benefits of adopting an Agile way of working before “productionizing” the transformation across the rest of the business. When curating that pilot, it is tempting to tee it up in a way that controls for organizational context and all the messy variables that come with it. While this kind of “Agile laboratory” environment stems from good intentions (we certainly don’t want to set a team up for failure), it is not very useful from a hypothesis testing standpoint. Worse, it can potentially lead to the misinterpretation of signals, codifying bad habits into our structure from the start. The problem stems from the fact that it is much easier to pilot an Agile transformation with the first slice of the organization than the second slice:
and actually, by starting with slice (1) and tracking localized (delivery team-focused) metrics, we will start to see measurable improvements. Assuming successful execution, rolling out Agile practices will result in velocity stabilizing, defects released into production decreasing, the team getting more consistent with their estimation of work, and becoming more predictable in delivery. This confirmation of the transformation hypothesis leads organizations to scale the implementation of Agile practices to other slices that mirror slice (1) and continue getting better and better at building (potentially) the wrong thing – albeit building it right and building it fast.
(Lack of) Alignment Between
Strategy and Epics
When we scale out our Agile transformation following the pattern established in a laboratory-style pilot, as outlined above, an additional antipattern that tends to emerge is the primacy of features, as opposed to epics aligned to strategic objectives. Since teams learn how to behave autonomously in an environment isolated from the broader context of the organization, it is nearly impossible for them to have the kind of strategic alignment we are aiming for by encapsulating value streams. That’s not to say the teams are directionless – usually, they end up filling their backlogs with features in response to direct customer requests. Consider the following scenario: being well-trained in Agile practices, teams prioritize features according to value and get on with executing. This results in a few releases with very little congruence in the feature sets going out to market; each feature on its own is “high priority” but there’s no guarantee that they are related to each other. The go-to-market team becomes frustrated about not being able to effectively craft a coherent value message to generate excitement among customers and prospects, due to the haphazard nature of the features being included. As a result, a well-meaning directive comes down that all features must be tied to an epic, leading the product teams to comb their backlogs for themes and create epics that are little more than containers for independent features with thematic similarities. In this scenario, even with all the pieces in place, we fail to achieve the encapsulation of a value stream because we lack the backbone of strategy that comes from intentionally parsing larger objectives down into executable chunks of work.
Encapsulate Early, Encapsulate Often
I don’t want to understate the importance of that last point – being intentional at every step when parsing larger objectives into the next tier down is what makes the encapsulation of value successful, and it is hard work! It is not easy to write an epic brief that has a well-crafted problem statement articulating an impediment to achieving our strategic objective; it is not easy to identify and orchestrate dependencies between features that collectively solve for the problem statement in the epic, and it is not easy to build individual solutions that effectively work in concert to deliver the functionality implied by those features. But getting it right enables even a large organization to find the kind of strategic alignment in execution that is so often missing. As a final, parting thought: remember that encapsulation of value streams is not a one-and-done activity. The product suite will continue to evolve, and the maturity of Agile processes will continue to increase as we iterate through a transformation initiative; it is important to revisit our value streams and the associated governance structures on a cadence, ensuring that we are maximizing our value stream’s alignment to strategy while minimizing the overhead necessary to orchestrate dependencies.
