Ways of working: T shaped people

As a term, this is in danger of falling into business speak, something you should try and avoid at all costs. At the heart of any good agile project is transparency, and business terms have a habit of occluding the reality behind jargon and needless rhetoric. However, this term, I feel, has validity. It can perhaps best be expressed as 'fill your team with experts, but make sure all team members are generalists as well as specialists'.

This may feel counterproductive. After all, you want a team of specialists such as developers who code brilliantly and UX folk who live and breathe service design and customer-first approaches. Yes, you do. Absolutely. But whilst specialists are valuable, I'd argue that their abilities to add to the team in other ways is just as important.

Let's look at how this might work in practice. In the following scenario (which is taken pretty much verbatim from the way my last team worked) we have a relatively typical delivery team, working in a blended approach: scrumban, multi-disciplinary, iterative approach based around user research and data. 

This team consists of experts in design, user experience, content editing, development (one front-end, one back-end), testing and a scrum master. The product vision comes from a product owner not embedded in the team, and it falls to the scrum master to communicate the vision to the team.

All the team members are very, very good at what they do. Within the team there's about 10 years' experience of working on this or a very similar product. They deliver on time, to budget, and despite the constraints of the system they work in (senior management's less than stellar grasp of transformational agile approaches, a disengaged and remote product owner), they continually produce very good products that iterate from release to release.

However, what makes this team work so effectively isn't any of the above (although it certainly helps). What does is the ability of each team member to take on responsibilities and work that necessarily within their structured remit. Three examples:

• the front-end developer has been coding for 10 years and has a huge knowledge of how css, javascript and html all work to create beautiful, modern, responsive websites. He has also amassed knowledge and experience of more typically back-end code bases, such a Ruby. So far so good. However what makes this guy a cut above your average developer is the other things he knows. He understands how the content management system works so can work closely with the content editors to help them get their work in faster, and in some cases, assist them with their work. He has an eye for design so can collaborate with the designer in making design pattern choices. He has an idea about testing so can liaise with quality assurance to make sure his work is passed across with minimal defects, and conforms to what the tester expects
• The tester has development experience. She gets involved upfront with story creation, helps to shape acceptance criteria and works with both front- and back-end developers to ensure consistency and quality. She’s got an interest in how user research sessions are run and assists the scum master with sorting the data capture 
• The UX person also has video editing experience, and runs user research sessions. This allows for easy demonstration of user journeys in user testing, working closely with the designer (who also has UI/UX experience and knowledge). He's able to guide users through the product, gaining vital feedback of what works and what doesn't. After the sessions, he uses his knowledge of video editing to cut together snapshots of the user feedback into bite sized chunks that can help demonstrate to stakeholders why decisions have been made

Each of these team members brings more to the team than just the thing they were employed to do. This helps the team function better as a whole, and means that each team member gets involved in other areas they are interested in. It also nudges everyone in the team to work even more closely with each other, overlapping and dovetailing where possible. This is the idea of a 'T-shaped person', one that has deep knowledge and expertise in a key area (the vertical stroke of the T), and also has shallow experience and knowledge of many other disciplines, areas etc (the horizontal bar of the T). It looks a bit like this:

With this level of flexibility on your team, two things happen. The first is your team becomes better, organically. Developers learn from testers how they work, the problems they face, and are less likely to chuck substandard work over. This speeds up development time. The test team gets involved in coding, helping the coders to anticipate problems before they arise. Content editors and designers swap ideas on how to express core concepts. An agile team should always be more than the sum of its parts, and having this deep knowledge shared through a team means this happens, as well as alleviating strain at critical times. 

And this is the second thing that happens: testers won’t just sit waiting for work to flow to them - they’ll get actively involved, helping content editors to proofread, helping designers find images and so on. By doing this, they help free up blockers, help the team function more effectively, and help the team bond (who can not respect and appreciate a colleague who has helped you not have to work late?).

As a last example of how this can benefit any team, I draw on my recent experience in two ways. The first way was helping our design and content team source suitable images for the rebuild of the start4life website. For this we needed about 150 images to help illustrate the various articles. Neither editor or designer really had the capacity for this in the timeframe, and as a scrum master, the project was ticking along well enough for me to have some free time to help. So I did, albeit with a little upfront guidance from the experts. This took the pressure off them and helped them to get on with what they were best at, while keeping their part the iterative cycle on track.

Secondly, while building a new CMS, I made sure that everyone in the team had an input, despite the key user requirements being driven by the content editors. Every new iteration was given a good going over by everyone to make sure nothing was missed. In this way, the multiple different view points and experiences of the team came to bear on the new system. Of course, the main users (the content editors) got the final say, but lots of things got picked up that they thought were useful that they wouldn’t necessarily have thought of themselves. 

This took maybe half an hour of time per team member per week. It helped me as a delivery manager understand better what we were trying to build now, what we might want to consider later, and what wasn’t viable or necessary, as well as what the team actually wanted from the system. It helped the team in general come together - argue resolve, agree, and move on, building a better product in the long run as well as more importantly, a better team.