Melvin Conway developed an adage stating, “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” The adage has become known as Conway’s Law, and it articulates how, over time, an organization’s structures for creating value mirror its communication structure.

The value Creation Structure of an organization refers to the formation of teams, dependency management, required coordination, and communications.

Often, the value creation structures morph to accommodate the next project or big thing that the Stakeholders want. They are typically focused on a single product vs. all the products in a value stream and driven by management reporting structures. Over time efficiency degrades, and the structures become ineffective. Figure 1 represents high impact attributes of ineffective structures.

Figure 1: Ineffective Value Creation Structure Attributes

Handoffs, the more of them we have, the more loss of information we have. When a handoff occurs, and the work is defective or incomplete, a hand-back takes place. A decision must be made whether to context switch to the handed back work or to keep going with work in process, resulting in wait time for the handed back work.

Handed back work is analyzed, and if it requires additional effort, the result is costly rework.

Wait time within a team, in-between teams, or from someone external to the team increases the cost of delay.

Infrequent integration of work within a team often contributes to rework as well as wait time. This situation is significantly compounded when teams focusing on just their work or the work of a single product do not integrate with the work of other teams in the value stream.

Too much work in progress, technical debt, process debt, and lack of alignment also contribute to delays, rework, and accumulated risk.

Figure 2: Common Team Formations
There are many team formation options; figure 2 represents common ones. All have benefits and detriments. Depending on the complexity and size of a product, options are evaluated for the best fit.

Depending on the team structure, dependencies will increase. Figure 3 depicts cross-team dependencies based on type.

Figure 3: Cross-Team Dependency Range

Disciplined Agile provides a wealth of guidance for coordinating activities and managing dependencies. However, the goal is not to become super-duper at accommodating dependencies! Instead, the goal is to eliminate dependencies through options.

Cross-functional teams, the gold standard, has the fewest as those teams have all the skills and experience needed for value delivery. They are desirable but costly and rarely do we see genuinely cross-functional teams in practice. At the other end of the range are scaled teams. By the very nature of a team-of-teams approach, significant coordination and dependency management are required.

Teams are almost always formed or evolved with a single product in mind vs. a value stream. So let’s look at some of the scenarios we will be faced with and options to solve the problem.

Figure 4: Varying Complexity MBIs

The idealized value stream is shown in figure 4, with an example of minimum business increments (MBIs) of varying complexity. One MBI requires enhancements in a single product by a single team. A more complex MBI requires enhancements in multiple products by multiple teams.

During look ahead value flow planning as well as grooming of the business backlog, we must look to the work that is going to be most valuable as well as possible to deliver. When shifting the focus to managing the flow of work in the value stream vs. a single product, we explore other options to increase the flow by eliminating cross-team dependencies.

Figure 5 represents a scenario that we can use to examine the best fit value creation structure.

Figure 5: Example Initiative Decomposed into Multiple MBIs

Initiatives are decomposed into the MBIs required to achieve the desired outcome. In this example, many MBIs have been identified. This will be a common scenario; each initiative will have two or more MBIs that contribute to the overall success.

Figures 6 and 7 depict the varying levels of complexity in the MBIs and other types of work: minor enhancements via several stories, paying down technical debt, quality improvements, etc.).

Figure 6: Series of Complex MBIs
Figure 7: Less Complex MBIs and Small Enhancements

Next, let’s look at a typical value creation structure and what options we have to move from a single product focus to a value stream focus. Figure 8 represents the value creation structure that was in existence.

Figure 8: Semi-Cross Functional Teams Supporting each Product

We start with semi-cross functional teams. All regularly require support from various shared service areas to augment their skills and experience. All products have teams sized to handle the project work funded over the past few years.

The Direct to Consumer Sales Portal product has been the most enhanced and currently has two teams supporting it. In addition, they manage dependencies as a regular practice.

Looking at the series of MBIs in figure 6 with a forecast of approximately 18 months to implement them, what options do we have? One is that we consider those MBIs our “big rocks” and have the teams in figure 8 implement them, filling openings in each team’s respective capacity with enhancements in figure 7, the “little rocks.”

Another option from a value stream perspective is to look at the teams and identify which team members are needed to implement the series of complex MBIs. Figure 9 represents how this would look.

Figure 9: Complex MBI Series Required Skills & Experience

We have identified the team members needed and can create a new team using the Focused Solution Team (FST) option. Figure 10 depicts how this would be an improvement in the value creation structure for this value stream. We have a single team, the FST, that can implement the MBIs that require enhancements across the multiple products while the remaining semi-cross functional teams can take on the less complex work.

Figure 10: Improved Value Creation Structure

The Focused Solution Team option is a strategy where we create a single team with all the skills and experience required to implement either a series of complex MBIs or potentially one large one that cannot be broken down any smaller.

Figure 11: Focused Solution Team (FST)

The FST in figure 11 is a strategy that removes cross-team dependencies and coordination. FST’s have the following attributes:

  • One single team
  • Larger than a “typical” agile team with 15-30 people
  • One Product Owner
  • One Architecture Owner
  • One Team Lead (DASSM)
  • Self-organizes to implement each new complex MBI
  • Fosters shared ownership as a single team
  • The single Product Owner is now as close as we can get to an “MBI owner”
  • We do not need Chief roles in the structure, such as Chief Product Owner

The FST is a compelling value creation option as we transition from a single product focus to a value stream focus. For additional information, I did a LinkedIn Live stream on this topic: ATDA Miniseries Ep 8 of 12: Value Creation Structures.

We help implement lean and agile methodologies to streamline processes in a context-sensitive manner.

Latest Posts

Project Manager to Value Delivery Manager

Here we have a common problem. The “agile team” comprises a product owner, team coach, and team members. Far too often, I hear something like, “there are no project managers in agile.” Agile teams are empowered to make decisions and determine how to get the work done....

read more

Training

Get Social

Contact Us