Fueling Delivery Teams
I’ve started using an analogy to illustrate the importance of product owner teams in larger organizations. When working with organizations to do an agile transformation, almost always, a tiered model is used for scaling across the organization. The model looks something like this:
The top tier is portfolio management which is responsible for investment decisions and what initiatives continue to move forward. The middle tier is representative of the Product Owner role in Scrum and is where we often create program teams, sometimes called product owner teams. The bottom tier is where stable cross-functional teams reside that are delivering increments of value in some cadence such as every two weeks.
Stable Engines
I think of the delivery tier as the engine of the organization. Each delivery team is designed to operate at a sustainable pace in a very predictable manner. If we think of each team as an engine then we may find some operate at 2500 RPM, others 3500 RPM, regardless, they each operate at a RPM that is sustainable. If we can operate with little variance then we can start to become predictable and make promises on what can be delivered over time. If a team is running at 2500 RPM then I can determine how far that team will travel if that engine powers a car.
But, if we push the engine past a sustainable pace, or have them operate past the redline, then the engine becomes stressed, will wear out more quickly, and likely fail to deliver as expected and certainly become unpredictable.
Fuel for the Engines
Product owner teams represent refineries responsible for providing good fuel. They must understand the business goals and problems to be solved, collaborate with delivery teams to define capabilities to build, and further decompose those into clear backlog items that provide clean burning fuel needed by the engines.
Provide bad fuel – the teams sputter and are unable to run at a consistent RPM. Bad fuel will not allow us to make promises to the market or our customers.
Drilling Locations
I haven’t completely vetted this out in my mind, but when thinking about portfolio management I believe this is where we are making investments on where to drill for crude oil. We increasingly learn more about the potential initiatives, collaborate with the product owner teams, and possibly delivery teams to progressively gain more knowledge so we can make funding or cut decisions about where we will invest.
Wrapping Up
This analogy seems to resonate when I’ve used it over the last few months to describe the responsibilities of delivery teams and product owner teams. Turning crude into clean burning fuel is a big job and really highlights the challenge most organizations have in providing clarity to their delivery teams.
I would love to get your thoughts on how I’m thinking about this.
Comments (8)
Tim Uttormark
I use a similar compatible analogy where investment of team capacity towards non-customer-facing features (e.g., training, refactoring, reducing technical debt, tooling) is maintenance akin to changing the oil in a vehicle. You can get away with neglecting it for a while, but POs who refuse to prioritize and invest in these areas will find before too long that they have run their engines into the ground.
Rick Austin
Nice analogy. Before long the engine seizes and is impossible to move forward.
Colin Williamson
Hi Rick, I like your analogy.
I am involved with a similar model and would know your thoughts about the Agile Teams.
For an RPM to be known and an estimate of how far a team can go, does that imply that the teams have static members?
I am wondering whether having fixed teams leads to specialism thus leading to one team having a larger workload than others?
Colin, yes, it is critical that we create teams that stay together for the long haul. Create stable teams and bring the right work to the teams. Not doing that would be akin to rebuilding the engine after every sprint with different parts…
How one forms team is something to carefully consider. Sometimes we create product teams that are able to deliver any features for a product line. Other times, we create specialized teams that are considered component teams and/or domain teams. If we find some areas have more workload then we need to revisit team structure. If we find we need more capacity for certain areas then maybe we need to build out more “engines”.
John
In the last years the concept of Behavior Driven Development (BDD) was created for teams as an analysis tool. I like the name Specification by Example (SbE), where teams work collaboratively in specification workshops or 3 Amigos sessions to develop requirements together. Additionally, tools such as FitNesse (http://fitnesse.org/) or Concordion (http://concordion.org/) are suitable that also non-technical stakeholders can contribute to executable specifications.
How is this agile movement related to the model with the three layers you described?
We are increasingly finding organizations using aspects of BDD in requirements specifications. Especially as acceptance criteria for user stories. The given-when-then format is rich in describing behaviors and even if the organization hasn’t moved to executable specifications there is great value in using this format. The ability to identify additional scenarios and define behaviors that could be missed has been powerful.
When we work through the progressive decomposition of requirements, from epics to features to stories, the ability to tap into a richer language for requirement specifications helps reduce missed requirements and creates greater clarity and alignment across teams. That has been my experience.
Of course, you really turn the corner when you are using tools as you noted to create executable specifications that also become long-lived descriptions of system behaviors and help drive future regression testing.
Adam Myhr
I think of the Product Owners more as the ones providing the machine that the engine operates. I see it this way due to there being a two-way nature to the relationship. The Product Owner knows what the output should be and so provides the machine that the engine powers. The design of said machine is done in concert with the developers (the engine) to ensure a smooth fit and best output possible. If the PO provides a bad machine concept the engine output won’t be as good as expected. The developers are in control of how they connect to the machine to accomplish the relevant work. As such they can provide insight into possible alterations to the design of the machine, but the PO has the final say.
Portfolio Management is there to set a general direction. They know the larger strategic goals of the organization and possible new directions to try going. As such the PM group tells the POs what kind of output the machines need and may get into the general design of the machines.
The ten second version? Each dev team is an engine in a vehicle that is provided by the PO among a fleet managed by the PM group.
I like your alternate analogy and will have to think about that. Especially how you tie back to Portfolio Management. Good stuff!