Recently, I wrote about team-based decision-making as an essential and difficult skill that teams must master to become truly self-organizing. The keys to effective decision-making include sharing a common goal, good facilitation, limiting team decisions to policies, and the use of consent to balance the need for speed with the collaboration needed for getting real alignment on decisions. That seems fine for a team of 3 to 9 people. What about when multiple teams need to work together to deliver a product or service? How do we make decisions that maintain the sense of autonomy that a single team feels? How do we flow information effectively so informed decisions can be made?
Most knowledge work today is too complex for an entire organization to consent on all policies. Therefore, some technique must be used to create levels of abstractions to simplify the process These levels help to focus the scope of the decisions at the different levels of authority and areas of abstraction. A traditional hierarchy is one way to do that. An alternative to the traditional hierarchy is to authorize the agile teams to create a dynamic network of coordinating teams based on the current needs.
Let’s explore these by looking at an example. Let’s say we have 40 people working together to deliver a system. The group is divided into 4 delivery teams of 7 each, we have 2 Scrum Masters and 2 Product Owners (each taking 2 teams), and a top level group of a leaders responsible for the release, including a development manager, a test manager, a product manager, and an architect. We also have a set of limited supporting skills represented by a technical writer, a build engineer, a UX designer, and a DBA.
The Team Structure
Let’s examine the makeup of the top level team. In most chain of command structures, it only includes the leaders. Sometimes the Product Owners and/or the Scrum Masters are included as participants, not decision makers. The decisions are usually made by some combination of the managers on the team and include when to ship, how to deal with the defects, and commitment to cost and schedule. How might the teams feel about this? Where did the self-organization and autonomy go that was alluded to by the agile movement?
The first step is to treat the top level group as a self-organizing team. It has a common goal, deliver high quality value to the marketplace. Now we install consent as the decision making framework of this top-level group. All members consent to these important decisions. This enables all voices to be heard, and objections to be dealt with and not dismissed out-of-hand. Once established, we have a self-organizing top level team driving decisions to 4 self-organizing delivery teams. That is not enough though. This is still a “chain of command” structure. To change this, each team elects a representative to the top level team who participates in the consent decision making. This election process establishes the “chain of consent” from the individuals on the delivery teams to the top level team making the policies that effect those individuals. This maintains the sense of autonomy in the scaling model. This is real empowerment!
Specific Examples of Challenges
Now let’s explore two particular challenges that face programs like this and how a chain of command might handle it compared with a chain of consent approach. The first challenge is maintaining the same level of quality across the 4 delivery teams. The second is the system architecture must be designed, maintained, and implemented across the 4 teams.
The Common Quality Challenge
The solution to the quality problem in Scrum is pretty straight-forward: create a shared Definition of Done (DoD). Many tradition organizations would have the project leadership team craft the Definition of Done and present it to the delivery teams. The teams would then be held accountable for achieving Done each sprint. We have a common Definition of Done across the program created by “the chain of command”. How likely is compliance? How committed are the team members to this Definition?
The alternative is to acknowledge that policies that effect people should be created by those people. So in our example, the leadership team would commission a new team to develop the Definition of Done. Each team elects a representative and the leadership team elects the development and test managers. That new team has the shared goal to create a Definition of Done that is complete and represents the current level of the organization’s engineering practices. This establishes a chain of consent from the teams to the policy. Instead of getting all 40 people to agree, we have 6 that are elected by the others to represent their needs. Once the Definition of Done is established, the DoD team can be disbanded.
The Architecture Challenge
Let’s look at a more complex issue, that of the system architecture. In most traditional chain of command organizations, the architect is held accountable for the architecture. Often this leads to the architect designing the system architecture, presenting it to the teams, and then establishing a policy that all code must pass an architectural review before it is done. This creates a bottleneck at the architect. How likely is the architecture understood by the team members? How likely will it be complied with? How adaptable will it be as the true nature of the problem and solution is discovered?
In the chain of consent model, we recognize that the architecture effects everyone. We also recognize that everyone has blind spots, so a team of self-organizing developers would create a better architecture. That is principle number 11 of the Agile Manifesto. The architect leads a new team and each delivery team elects a representative to collaborate and develop the architecture. They make all architectural decisions by consent, meaning that each elected member has a real say in the decisions. Now each delivery team has an expert in the architecture so compliance is improved, reviews are not needed, and discoveries from any team can be brought back to the architecture team for consideration. Better solutions are more likely to emerge.
Summary
Chain of Command structures have three primary flaws. The first deals with the flow of information. The information is richest at the bottom of the hierarchy, near the work. That information needs to flow transparently to where decisions are made. As many people experience, this is not very effective in the traditional model. The second flaw is that most organizations are very static and do not adapt quickly to changing conditions. The third is the reduction in team autonomy and empowerment as management makes the decisions. This last one is the most damaging to an agile transformation.
The Chain of Consent technique addresses all three flaws of the traditional hierarchy. It is dynamic, allows a better flow of information across the organization, and empowerment is maintained through the election process.
No matter how you decide to scale your delivery of value; either through SAFe, LeSS, DAD, Scrum@Scale, or a home-grown method; the use of the “chain of consent” principle will lead to more empowered, well-informed, and long-lasting policies that enable the effective flow of value to the marketplace.
Comments are closed.