A feature team is a cross-functional and cross-component team that can pull end-customer-valuable items from the product backlog (i.e., “features”) and complete them. One approach to creating feature teams is to combine people with experience in each of the components that needs to be “touched” onto the same team. So, for example, if a team consistently needs to make modifications to five different components to produce customer features, then one approach to forming a feature team is to pull an individual from each of the five component teams onto a single feature team.
This approach can work at reasonable scale. However, at large scale, in an organization with a lot of components and many products, there may not be sufficient component team personnel to move them onto feature teams. Imagine component team X with eight people on it and the company has 15 products that all frequently make modifications to that component. In this case there aren’t enough specialists on team X to assign a person into 15 different feature teams.
You could rightfully argue that there are any number of impediments that might put an organization in this situation. For example, maybe the company shouldn’t be working on 15 products at the same time (e.g., too much WIP). Or perhaps, it really does need to work on 15 products to meet its business objectives, but it just doesn’t have enough people. Or maybe organizationally the company has done a poor job of structuring its applications/systems/components and their associated teams resulting in a crushing load of dependencies.
Most organizations would be best served by stepping back and looking at the big picture to see if rebalancing the demand/capacity equation or restructuring technical architecture or teams is an appropriate first step to getting the right people working together to achieve the fast, flexible flow of customer value.
Since restructuring is often time consuming and can involve significant organizational change, many companies prefer to start with a less invasive solution to see if they can improve their situation. One such solution is to T-shape people on existing teams. T-shaping is a metaphor used to describe a person with deep vertical skills in a specialized area (such as UX design) as well as broad but not necessarily very deep skills in other relevant areas (such as testing and documentation).
A benefit to T-shaping people on a team is that it makes the team more resilient when something goes wrong. For example, if only one person can do a particular type of work and she goes out sick during a sprint, then the team may fail to complete its sprint goal. Having people with T-shaped skills makes it likely that at least one other person on the team can also work in the same area and can pick up the work from the sick person. T-Shaping has many other benefits such as allowing the team to adapt to the variability of the work from sprint to sprint. For example, this sprint there might be more database work, and next sprint there might be more UI work.
In the context of our current discussion, T-shaping might better be thought of as poly-skilling since the goal is to train people to work across multiple component areas. Using our example above of a team that needs to work across five different components, the goal would be to train the people on an existing team to collectively be able to work across all five components. To be clear, I am not saying that every person needs to be able to work across all five components, but rather that the team as a whole has the skills to collectively work across the five components.
Overall, this is a very sound approach. It certainly resonates well with the people who advocate shared code ownership – rather than one component team owning the code, T-shaped skilled people collectively share the ownership of the code.
There are times when this strategy can and will work well. However, in large organizations there are frequently other complications. See the diagram below.
To help people on the feature team become T-shaped, let’s say we temporarily move a component team specialist up onto the feature team so he can help pollinate a couple of other feature team members with knowledge of Component 3.
Now to work in the Component 3 code base, the two newly T-shaped people will need access credentials to the systems underlying Component 3. In several larger organizations I have coached, the component team management will not grant access privileges to anyone who is not a “trusted” member of the Component 3 team.
One common reason for denying access is because the company bureaucracy is structured in a way that should a failure ever be traced back to the Component 3 code, then the Component 3 team and its management will be reputationally and financially responsible for the costs of any failures.
The end result in these companies is that the option of T-shaping feature team members to work in component code bases is basically a non-starter since the component teams won’t take the financial and reputational risk of allowing “third-parties” to modify their assets.
To summarize, T-shaping is an important strategy to help companies form feature teams. However, in some companies it just won’t work if a company's bureaucracy makes people unwilling to give feature team members the credentials to access component code. This is yet another impediment that companies face when trying to organize around feature teams.
As you have probably encountered in your company, unless you take a big picture end-to-end organizational approach, you are unlikely to significantly improve your value flow by only locally making changes to teams.
So, what do you see in your company? Can T-shaped people get credentialed access to the component systems? Leave your comments below. Also, if you want to get notified when I published new articles, please sign-up for my periodic newsletter.