There are those who believe that implementing a capability team is as easy as identifying a group of people, putting them together, and then doing a few team building exercises. Instant team! In the simplest terms possible – they are wrong. There are four complicating factors that have to be addressed.
The first is identifying the capabilities required to deliver consistent value. One approach is to perform a value chain analysis. Value is generated through the transformation of raw materials into a new form, which is represented by a value chain. The value chain concept is generally applied to whole organizations but can be applied to an individual business unit or a specific business function. Once the path is mapped the roles required to transform the raw material will be identified.
The second factor implied in this factor is a consistent need. Capability teams, while not permanent (even granite is not permanent) are long-lived teams. The backlog or flow of work needs to be substantial enough to keep the team busy delivering output that is more valuable than the cost of the team.
Third, once the value flow and the roles have been identified, the people needed to perform those roles need to be reorganized into a capability team. All members of the team need to “report” to a single leader or manager. The capability team is a team member’s most important business team. This typically requires breaking up hierarchies based on specialties. For example, in a recent organization implementing capability teams, the product owner, and BAs resided in the business, programmers, and testers in development (although separate teams) and release management personnel in operations (which view themselves as separate from development). The capability team required personnel from each of these specialties. The team when formed reported to a business operations unit. The change required many managers to agree to give up resources and disrupt teams however they recognized that techniques life matrix management would reduce the value delivered to the overall organization, which in the end was more important than internecine squabbles.
Breaking up the specialty-driven hierarchy is easily the hardest and most continuous of the changes need to adopt capability teams both from middle and senior managers and practitioners. Middle and senior managers see their power base being eroded. Solving this problem requires strong sponsorship, consistency of purpose and an overriding belief in the purpose of the larger organization. In a recent LeadX podcast, Kevin Kruse interviewed Dan Pontefract (author and Chief Envisioner of TELUS Transformation Office) who suggested the best performers had a role-based mindset. A role-based mindset allowed people and organizations to pursue their purpose more effectively. The concept of capability teams and role based mindsets are linked. When you focus on organizing by role artificial hierarchies based on specialties stop making sense because they impede an organization purpose. At a practitioner level, one complaint is that the specialists do not get the intellectual support they would ostensibly get when organized by functional specialties. Organizations that adopt capability teams often adopt communities of practice or programs like hackathons as a way to ensure intellectual support for specialties.
A fourth factor that needs to be addressed is backlog management. A capability team requires a backlog to draw work from (otherwise they do not need to be a long-lived team). Backlog management requires processes for how work gets on the backlog, how that work is prioritized, how that prioritization changes and when an item should be removed. These are just a sample of the processes needed to keep a backlog groomed. Backlog management is even more complicated when multiple functional areas are being serviced by the capability team or by more than one capability team. For example, when multiple functional areas are being supported by one or more capability teams, a product owner council is often a required to balance the need to multiples product owners.
Implementing a capability team is not as simple as waving a magic wand. However, the factors that have to be addressed should be addressed in any type of organization. Often the impetus to address these factors is the need to become more effective and value driven which leads us back to capability teams. Although a bit circular, the payoff promised from adopting capability teams primes the pump for change and keeps it moving!
Software Process and Measurement 
April 28, 2017 at 2:14 pm
I find this topic to be very interesting. As a member of a dev team (but not a manager), I often hear bits and pieces about how teams are formed. Most often, this amounts to “so and so is moving to this team” and “such and such will now be a function performed by this team.” Given the sometimes herculean efforts that employees apply to make these team adjustments succeed, I do wonder whether detailed analysis of need and skill set is accurately done prior to any changes. My question is: what is the ideal role of the employees in contributing to these types of value analysis exercises and at what stage of the game? Often, I see that the employees in the trenches have a firm grasp on the complexities and the needs of the work set; it would be advantageous for management to leverage that expertise. Thanks in advance Tom.
May 3, 2017 at 8:38 pm
Excellent question! I have seen mature teams use group interviewing techniques to determine who they wanted or needed to join. Another technique I have used is to have the team review the backlog (let’s say 90 days worth) and then determine whether they think they have the capabilities needed to deliver. Adjustments can be made if not. As importantly, a leader needs to be looking at future and helping the team to develop internally in the long run so they have the capabilities when they need them.
Thoughts?
April 28, 2017 at 2:16 pm
A second question would be: how does the hiring process fit into this team building model? I would think that the company would want to integrate their model into the hiring procedure in order to get the best fit for the teams as they open positions…
May 3, 2017 at 8:43 pm
Excellent! I think the answer depends on the size of the organization. For a small organizations I think the team needs to be in active communication via it’s leader with the HR function that is doing the hiring. Communication and feedback needs to go in both directions with the team and the HR function sharing information. In larger organizations this generally has to be done via a manager role . Regardless teams need to be able to provide information that information that needs to be consolidated and fed to HR with a feedback loop that his every layer. The larger organization the more controlled it needs to be due to the number of people needed.
May 11, 2017 at 11:40 pm
[…] Next: Implementing Capability Teams […]