Team members should venture outside their role descriptions, engage in, and feel a shared responsibility for, the entire team's deliveries. In this article I will look at three ways of becoming T-shaped – a great goal on the journey to becoming a self-organizing cross-functional development team.
To be T-shaped means having deep knowledge in one area and basic understanding of many areas – being able to help out and understand not only your own area of expertise. This is somewhat of an over simplification as people often have more than one area of expertise, and various degree of knowledge in many areas. But it works well enough to illustrate the point.
Becoming T-shaped is a deliberate goal as an individual, team and organization. As a team member you need to want to work and deliver together, and for the team to succeed.
"Becoming a T occurs through experience and a personal willingness to learn about knowledge areas that do not always stand in close relation to your own specialization." -Klaus Leopold, Practical Kanban
Teams and individuals also need support from the organization. It needs to be ok to take the time to become T's. It needs to be a company priority and appreciated as something making the organization more effective.
Without further ado, here are three practices that help your team become T-shaped.
1. Estimate Together
When you estimate backlog items together as a team using relative estimates, for example story points, you estimate all work to get an item done and represent that effort with one number.
This might seem impossible as the definition of done usually includes many competency areas including programming, testing, design and documentation. How can a team decide on one number encompassing all of this?
Sure it can be awkward at first and there are plenty of pitfalls to fall into, but soon enough you become comfortable with, and proficient in, understanding the entirety of what it takes to get an item to done. Also, relative estimates is part of the secret sauce making this work.
Agreeing on one estimate per item, and estimating together as a team, is a great way to jell as a team and for everyone to understand all aspects of work – in the process learning about new areas and becoming T-shaped.
2. Pair and Mob Work
Pairing up with someone on a backlog item or task is a great way to share knowledge and increase quality. Pair programming is a subset of this – two programmers writing code together – but don't limit this to one discipline or only pairs.
Having a UX designer and a developer pair up on something, or a developer and tester, is great not only for becoming T-shaped and jelling as a team. It is also a great way to ensure cross-discipline concerns are dealt with early. For example to ensure the design is technically feasible or that the code is testable.
And why limit yourselves to only pairs? Why not get the whole team together and work on particularly tricky items – also known as mob programming – or to get on the same page with a new design or API?
If you're worried this is not effective – you might be surprised when you try it. As handovers and misunderstandings virtually vanish it more than makes up for time spent on pair and mob work.
3. Swarming
Related to pair and mob work is swarming.
Swarming put simply is a WiP (Work in Progress) limit on the team "in progress" state, and having as many people as possible working on the top priority story until it is done. The WiP limit should be considerably lower than the number of people on the team.
Doing this in extreme for a couple of iterations (setting the "in progress" WiP limit to one) can render interesting results. For example, you might want to adjust (improve) how stories are written or when/how you involve different disciplines.
In the video below Jeff Sutherland explains the concept of swarming in the context of Scrum.
"I've never seen a high performing Scrum team without swarming being a pattern that's implemented." - Jeff Sutherland, programmer and co-creator of Scrum
Final Thoughts
Having T-shaped individuals and teams (yes, teams should also be T-shaped) increases effectiveness, but the journey to becoming T-shaped is just as important and equally valuable.
The practices described in this post help create empathy and understanding, and are great activities on the road to becoming a true team – working and delivering together.
Briefly put: A goal to become T-shaped has the potential to make you a better team.
Interesting. Reading your view of T-shaped team members, I understand it as your main concern is to get the team members to learn other areas than their own area of expertise (i.e. avoid being I-shaped). But in the teams I've had, I've always found the problem being that everyone tries to be an expert on everything, and that everyone aims at being able to do everything on their own (i.e. being square-shaped).