The Agile Architect
The Benefits of T-Shaped People on Your Agile Team
Our Agile Architect talks about the benefits of T-shaped people in agile and the dangers of stressing broad knowledge and participation over deep expertise.
- By Mark J. Balbes, Ph.D.
Agile teams are best staffed with T-shaped people: those who have areas of deep expertise but can also work broadly across all aspects of a project.
Before diving further into the advantages of T-shaped people, let's look at the advantages and disadvantages of composing a team of experts focused only on their areas of interest.
For the purposes of this discussion, we are considering an expert to be someone that works extremely well in one specialty area but either has no ability or no interest in engaging in other areas of a project. Examples might be a database administrator that only works in the database, an architect that spends all their time drawing diagrams or a developer who has no interest in story writing or QA activities.
Having a team of people who only work in their areas of expertise creates a false need for efficiency. What do you do with a database administrator when there is no database work to be done? Inevitably, they will invent work for themselves to use their time "efficiently.' This is at best a waste of time for the individual and at worst, a distraction to the rest of the team.
The T-Shaped Person
The T-shaped person can focus on their area of expertise when there is work to be done. When there isn't, or when other work has a higher priority, they can participate in those areas. This flexibility allows the team to optimize for effectiveness rather than efficiency.
The effectiveness of T-shaped people increases dramatically when using agile collaboration techniques. By having the experts collaborate with non-experts, the team's level of expertise is quickly raised.
The Fallacy of the Horizontal-Line Person
In moving from experts to T-shaped people, organizations can go too far and end up with horizontal-line people. That is, people that want to dabble in everything but can't do any of it with any depth.
When T-shaped team members are constantly encouraged to over-collaborate on all aspects of a project, they may find themselves constantly working outside their area of expertise and quickly lose their edge.
For less experience team members, they may never have the chance to dig in and develop an expertise if they are constantly encouraged to participate in every activity the team has.
Let's move away from the individual and focus on the team for a moment. What we really want are filled-rectangle teams. That is, teams that have a depth of knowledge in a wide variety of areas as required by the project. You can't achieve this with a team of horizontal-line people but you can achieve this with a team of T-shaped people.
As individuals, it's very difficult to transition from a horizontal-line person to a filled-rectangle person. Without any area of expertise, and continuing to focus across all aspects of a project equally, you don't have enough time to learn any one area really well.
On the other hand, if you focus on being a T-shaped person and gain expertise in one area, it becomes easier to maintain that expertise after attaining it. This gives you capacity to go deep in another area. Over time, you can build up expertise in a wide variety of different areas. It takes time. It takes patience. But it is very satisfying.
Dr. Mark Balbes serves as Vice President, Architecture at WWT Asynchrony Labs, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.