There are lot of discussions about capabilities (technical, business domain) and maturities of developers and entire teams that gets circulated today. Sometimes, information is too confusing and terminology gets mixed up. This summary is an attempt to pull together a few very important concepts and make them easy for everyone to follow.
Feature Team Adoption Map (FTAM) and Definition of Done (DoD)
Firstly, the most original/authentic and easy-to-understand definition of a team’s gradual maturity, moving from being just a delivery team (mostly, optimized for output) to a fully capable, product centric feature team (optimized for outcome) can be found in the body of knowledge, collected by Large Scale Scrum/LeSS (books and web site). The images below, illustrate how:
- LEFT: expansion of intra-team functional capability/cross-functionality (X-axis) enables a team to expand its work scope (Y-axis)
- RIGHT: how gradual expansion of Definition of Done (DoD) supports the above mentioned team capability expansion
Feature Team Adoption Map (FTAM)
|
Definition of Done (DoD) Expansion
|
The article “Following FTAM By Expanding DoD VS. Becoming A Hostage To Traditional Org Structure” – explains this in detail, contextually to organizational design implications.
It is also important to note that there is some misunderstanding/misguidance in the industry that makes a false distinction between fully capable, end-to-end product-centric feature teams and product teams. This false dichotomy is explained in the following two posts:
Developer Skillset Expansion Map (DSEP)
Secondly, we should look at Developer Skillset Expansion Map (DSEP). For simplicity and visual consistency with Feature Team Adoption Map (FTAM), it is also plotted on a X-Y-axis pane. Here, the X-axis shows gradual expansion of a developer’s knowledge (from purely tech to biz-tech), whereas the Y-axis shows types of teams, where developers with particular knowledge can be, most likely, found. For example:
- I-shaped developer, who possesses knowledge of a single technology domain, is more likely be found on a delivery team (component/application)
- T-shaped developer, who possesses knowledge of a multiple technology domains, is more likely be found on a narrow specialty feature team
- M-shaped developer, who possesses knowledge of a multiple technology domains that could be further integrated into a business solution, is more likely be found on a wide specialty feature team/product team
Team Capabilities, as a Function of Developers Capabilities
Thirdly, another area of confusion that needs to be addressed is how developers’ individual capabilities define overall teams capabilities, and how this relationship looks from a perspective of cycle time and hand-offs (costliest waste known in product development):
- For example, I-shaped developers that all possess only one and the same kind of knowledge (e.g. single technology domain), together, constitute a team that is deeply specialized only in one technology domain. This is known, as a functional team and although it may work fast and have a lot of cohesion and synergy, internally, from the standpoint cross-team dynamics, when interacting with other functional teams, it has to deal with lots of dependencies, including frequent explicit hand-offs, very long cycle time, high integration risks and low learning opportunities (across teams). A functional team cannot deliver end-to-end customer-centric features.
- On the other hand, I-shaped developers that possess knowledge of complimentary single technology domains, together, constitute a team that can be specialized in multiple technology domains. This is known, as a cross-functional (c/f) team that can, eventually, deliver end-to-end customer-centric features. A c/f team, usually, has a shorter cycle time, lower integration risks and higher intra-team learning opportunities. However, a c/f team that is made of I-shaped developers only, still has to deal with implicit hand-offs and many implicit (invisible) intra-team dependencies.
- Further, T-shaped developers that possess knowledge of multiple technology domains, together, constitute a cross-functional team that can be, even more effectively, specialized in multiple technology domains, have no hard internal or external dependencies or hand-offs, and be characterized, by having shortest cycle time, lowest integration risks and highest learning opportunities. Importantly, long-lived c/f teams, initially made of T-shaped developers, create opportunities for developers to organically evolve into M-shaped developers that are capable to effectively integrate their cross-functional knowledge into business (customer) solutions.
Summary
To summarize, let’s take a look at the two extremes that are least and most ideal, respectively, for product-focused, customer-centric, large-scale product development.
Least ideal:
A delivery team, composed of single-function specialty/single technical domain knowledge (I-shaped) developers, of the same type (e.g. everyone is a back-end developer or everyone is a back-end/database developer). A team like this will, most likely, be able to work on a very narrow in scope technical solution/source code and require a lot of external supervision, management and coordination with other teams. There will be also a lot of emphasis on efficiency, productivity, speed of delivery and rate of output.
Most ideal:
A feature/product team, composed of multi-function specialty/multi-technical domain knowledge developers, of different types (balance of overlapping and complimentary skills). A team like this will, most likely, be able to work on a wide in scope technical solution that leads to business problem solving. A team will require no external supervision, and will be capable of self-management and self -coordination (both, internal and external). There will be a lot of emphasis on business solutioning, customer value delivery, outcomes and ROI.