Software Development Team of Teams

If a Team of Teams methodology can win a war on terrorism imagine the benefits our IT organizations would gain by applying its principles to software development. This article is part 2 in my series on Team of Teams. Part 1 highlights General McChrystal's transformation to a Team of Teams and its benefits. Part 2 focuses on strategies we can adopt to help transform IT organizations into software development Team of Teams.

Which intersection below most closely resembles a Team of Teams? A free flowing intersection with self-driving cars (see Figure 1) or a traffic light controlled intersection with traditional cars (see Figure 2)?

Figure 1. Self-driving cars

Figure 2. Traditional cars

 

Comparing self-driving vs traditional cars from a Team of Teams perspective

	Self-driving cars	Traditional cars	Notes
Shared Consciousness	Yes	Limited	Self-driving cars are constantly communicating their route and speed in realtime. Traditional cars are limited because they can only communicate their route via turn signals.
Trust	Yes	No	Self-driving cars have trust because of their constant sharing of accurate information. It's difficult to trust traditional cars because they are unpredictable and have limited information sharing.
Empowerment	Yes	No	Self-driving cars are empowered to proceed full-speed through the intersection because of their shared communication and trust. Traditional cars must wait for a green light (command structure) to proceed due of their limited trust and information sharing.

Why Software Development Team of Teams?

How efficient is your team able to release a small task to production? After adopting a Team of Teams methodology the General’s teams were able to go from intel to strike within an hour. Their efficiency gains allowed them to execute 17 times more raids per month. Our goal should be the same - from requirement to release within a few hours resulting in 17 times more releases a month. Let's review the top strategies we can apply to build stronger and more efficient software development Team of Teams.

Bake craftsmanship (continuous improvement) into the process

Do you think the General's teams didn't train, condition or workout? It's part of their lifestyle and built into their process. I classify craftsmanship in two categories: training and refactoring (enhancements, defects). The The Phoenix Project ( p229) recommended an allocation of 20% for continuous improvement activities. Create a backlog exclusively for these types of tasks and empower your teams to continuously improve their skills, process, and software.

Reduce batch size

When the task force launched a mission their goals were small, precision strikes. Small strikes improved their frequency (10 strikes a day). If your teams are fortunate enough to have the efficiency of a CI/CD pipeline then the only limiting factor to daily releases is batch size. Try releasing at least every iteration or more often (daily). Frequent releases promote speed to market, reduce risk, are simpler to manage, and produce quick wins building team morale. Teams must be empowered to reduce batch size. CI/CD pipelines provide little value if releases are monolithic.

"Power up" to improve team health

Have you ever played Fortnite? Many of the team strategies applied in this battle royale game apply well to software development. One strategy in particular is the “power up” strategy or boosting your teammates health when they are running low. On a software development team we can boost the health of the overall team by information sharing and paired programming. The most effective team I have been on was a client project in 2003. This project had around 30 developers and we were required to pair program 100%. Pairs needed to rotate drivers and a new partner was required for the the morning and afternoon sessions. Software quality was very high and knowledge sharing with a new partner was an effective way to "power up" the resources across the team. Paired programming improves craftsmanship (continuous improvement), reduces defects, improves information sharing, and builds trust.

Transparent leadership

Having a transparent leader that posts frequently on Twitter isn't all bad. Has our president read Team of Teams? General McChrystal said his transparency (all calls on speakerphone and O&I briefings with thousands) saved many lives. In addition, his transparency greatly improved trust and shared consciousness across all teams. Perhaps we should try the same techniques. Would transparency and trust improve if we removed all cubicle walls, removed all office doors, replaced all phones with speakerphones, and made everyones calendar transparent?

Build a liaison program

A liaison program was General McCrystal's primary strategy for building trust across his teams. From a development perspective, liaison programs are opportunities to join other teams for short-term projects or assignments. In addition to improving trust these opportunities also expose developers to alternative coding practices, techniques, and team dynamics. Furthermore, moving cheese or trying new cheese often sparks new learning and growth opportunities from a team and individual perspective. Teams without a mature shared consciousness will be very resistant to this type of change highlighting a flaw within their own team. Anyone adopting new cloud or platform technologies? What better way to learn than actually join their teams for several iterations.

Continuous gardening

Managers have the most important role in regards to tending our Team of Teams. In particular, they need to provide water, fertilizer, and weed control for the resources across the teams:

• Water - growing trust and transparency. Water is the most important ingredient. A garden will not survive without water and a Team of Teams will not exist without trust and transparency.
• Fertilizer - building "power up" opportunities for resources to learn and grow. Resources won't reach their full potential if they are not given the opportunity to grow and learn. In addition, incentivize developers to attend conferences or meetups, watch YouTube developer channels, or contribute to open source.
• Weed control - eliminate rubber stamps and command structures that reduce team productivity. Without weeds teams will become more empowered and efficient.

Build an empowerment radar

Does your team have high, medium or low empowerment? Document rubber stamps, command structure decisions, and shared consciousness limitations that impede a free flowing software development life cycle. Then, tend the garden to remedy those limitations. Remember, empowerment fuels motivation - an individual or team who makes a decision becomes more invested in its outcome. The goal is to eliminate these impediments so your team can become as efficient as self-driving cars.