Not Exactly A Capability Team But Close!

One of the holy grails of Agile in software development and other business scenarios is how to organize so that stable teams are efficient, effective and safe. The great preponderance of organizations use some variant of an organizational model that groups people by specialty and then allocate them to project teams.  This creates a matrix in which any practitioner will be part of two or more teams, which, in turn, means they have two or more managers and serve two or more masters.  People, like desks, chairs, and laptops, flow to the area of need, disband, and then return to a waiting pool until needed again.  One of the basic assumptions is that within some limits people are fungible and can be exchanged with relative impunity.  This approach has problems.  Ariana Racz, Senior Quality Assurance Analyst, provided a great summary of what is wrong with the idea that people are fungible in her response to Get Rid of Dynamic Teams: The Teams.  Ariana stated, “A resource on paper is not a resource in application.” In most circumstances, dynamic/matrixed teams reduce the productivity of knowledge workers.

An operational solution to using a dynamic/matrixed approach (we will return to where dynamic teams make sense – later) to build and manage a team is to adopt the idea of a capability (also known as a functionality) team.  The version of capability teams I espouse was influenced by an article written by Karl Scotland (What is Capability, Karl also appeared on SPaMCAST 174 to discuss Kanban Thinking).

A capability team is the group of roles needed to address and deliver a set of technical or business outcomes.  For example, to script, record, edit, post and promote the weekly Software process and Measurement Cast podcast there are five primary roles.  These roles are played by a fixed team of three people. This team has been together on this project for approximately 11 years with only a few minor tweaks in membership.  Each person in this small team has a specialty but can perform or support the roles of other members.  The podcast capability team can take the podcast from idea to delivery.

There are several important attributes of a capability team:

  1.      The team needs to include people that can perform all of the roles need to deliver functionality from idea to production.  A SaaS application capability team would include the roles of architect, business analysis, configuration, coding, testing, security and release management.  Many roles might be played by a single person or several people might play a single role depending on the work being addressed by the group.
  2.      The team reports to a single manager. The capability team represents the most important work team each member belongs to.
  3.      Membership in the team changes slowly based on the evolving context of the business (barring externalities such as people leaving the team).  Every team will change over time, however, in capability teams, change happens through evolution.  When teams need new knowledge the team members find a way to acquire that knowledge and increase the capability of the team.
  4.      A backlog of related valuable work is available for the team to draw work from.  This generally requires an organization to take a product view rather than a project view of work.  A product view recognizes that there is a need for enhancements, changes, and support continuously across the entire lifecycle of a product.  This flow does not easily conform to arbitrary start and end dates that are part of the definition of projects.
  5.      Capability teams dissolve or are repurposed when they are no longer needed.  No team is forever. When the value of the backlog of work they are serving is less than the cost of the team, they need to dissolve or find something else to do.

Capability teams are not a new invention. Capability teams are the norm in some industries.  My brother Nick builds custom homes in Baton Rouge, Louisiana.  Nick employees several capability teams.  For example, he has two crews that roof houses.  Each crew has people to perform all of the roles needed to successfully roof the houses Nick designs and builds. Team members rarely change and Nick says that it is impressive to watch them work as they seem to be able to anticipate the needs of other team members.  As impressive is the safety record of long-lived teams. Capability teams represent an approach to address one of the holy grails of increased efficiency and effectiveness promised by Agile: long-lived stable teams.

Next: Implementing: Capability Teams