Summits versus Action Squads

Modern enterprise software development is primarily about communication. Softwares communicate with other softwares. These communication patterns also impact how easily new features can be planned and built. There are two very common approaches, and there is a much better approach. I will contrast these for you.

Conway’s Law states: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

Most modern tech organization are either split into silos categorized by feature type, or by problem domain. Some organizations have the misfortune of being split both ways.

This creates a LOT of communication overhead for implementing new software features. You can observe this occurring when you hear any of the following.

“We need to have a meeting with the UI people and the database admins.”

“We’re waiting on designs from UX. Then, once we’re done, we’ve got to hand this off to QA.”

“Did you loop the mobile team in on this? How about analytics?”

“We need to run this by the Shopping Cart team and the Payments team.”

Very few enterprise software projects involve fewer than 3 groups.

The successful and timely development of any new feature depends primarily on how effectively these groups are able to collaborate.

There are two common ways that management solves this problem.

1. Abdication / Delegation / Chaos
2. Cross-Group Summits

1. Abdication / Delegation / Chaos

The most common initial solution is simply for the business to find a single manager or product lead, give him responsiblity for the new feature, and let everything ride.

What typically happens is a disorderly, error-prone, and frustrating process.

• Some features die here, because they don’t gain enough traction
• Some features are delivered half-baked with glaring inconsistencies and holes.
• Some features consume 10-12x the time/money budgets, due to poor momentum and lack of accountability for people besides the project organizer

This occurs even to leaders who are very effective at developing features within their own team.

Organizations that have seen this enough times demand a solution, which leads to the second most common solution.

2. Cross-Group Summits

The second most common solution is to appoint Project Managers and use techniques from Scaled Agile for Enterprises (SAFe).

There are many names for this type of solution. You may hear words like: MAP Days, SCRUM of SCRUMS, PI Planning, and similar.

This type of solution results in a multi-group plan, illustrated by a chart like this:

The results are better than the Abdication / Delegation / Chaos approach. But there are still large problems:

• Communicating effectively to many is much harder than communicating to a few
• Cross-Team schedules raises the odds of project delays
• Siloed component development causes unanticipated integration challenges and problems
• Planning and orchestrating cross-team is very expensive

Many organization reach this point and then figure that this solution is about as good as it gets. It’s better than Abdication / Delegation / Chaos solutions, but it’s not ideal. The costs are very high and statistically it doesn’t improve feature delivery against cost by a very large percentage.

What’s a much better alternative than Delegation or Summits?

3. Action Squads

Assemble a team with skilled members from the different required disciplines/software teams and form them into a single action squad of 3-8 people. Task them collectively with creating and delivering the new feature.

Each new feature might require a different action squad, depending on the type of feature, the pieces of the business it interfaces with and the tech stack needed to build it.

This is a less common, yet more effective solution than the others.

What are the key advantages?

• Teams given shared responsibility outperform projects managed by one person
• Communication lines are efficient, and avoid the complexities of cross-team
• Everyone on the team has skin in the game, avoiding agency problems
• Minimal project management overhead, due to aligned incentive structures

Using Action Squads consisting of ad hoc teams assembled using the best talent able to tackle a given problem, with representatives from each business stakeholder group is one of the very best ways to build new features.

Summary

Given that most software organization have structural stratification that can’t be easily removed, there are only a few ways to manage creating non-trivial features.

1. Abdication / Delegation / Chaos
2. Cross-Group Summits
3. Action Squads

Delegation is entrusting one individual to be able to successfully do what the organization tacitly admits they are incapabale of doing. That’s a recipe for disappointment and failure.

Organization Cross-Group Summits run by amibitious project managers and leaders is a more team-oriented approach, and has better chances of delivering a feature, but it requires a lot more communication overhead, a ton of planning, and typically results in project delays as well as major feature deficiencies. This is where you arrive at the adage that every project is over-budget and behind schedule.

Action Squads are a more effective solution than both of these others. Assembling one small team of domain specialists and giving them shared team responsibility to manage and deliver the feature consistently yields the best results.

How do you manage challenging cross-team projects in your organizations?

Do you have any other approaches to solving the project management problem effectively and efficiently?

Share your thoughts in the comments.