14955864_10154768928297276_8000508545464981060_n

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!

 

Advertisements