Starfish Shaped People
Something I hear a lot of people struggling with when building Agile teams is how to deal with specialisms. It started out years ago with separate test teams the big culprit but most organisations now seem to have ‘got it’ when it comes to integrating testers. It’s important to have everyone contributing to building your software working together, without the dreaded silos, collaborating well. The job of the team is to build the software we need.
Every person on the team has skills and experience that they contribute, turning the requirements into the best possible increment possible for them.
Ken Schwaber
So, we might agree that we need a good mix of skills in our team. Let’s get the testers in, let’s get the analysts in, this is usually where things start to break down. How many testers vs devs vs analysts do we need… What about the architects, the UX designers, the sys-admins… Often these people end up as shared resources (poor guys) outside of the team, outside of the process.
Cross Functional Team
The nirvana of a cross functional team is where everyone can do everything. Anyone can pick up any piece of work and do it, ideally equally well. I’m far from convinced this is possible in most cases but thinking about T Shaped People is a good step towards the right kind of team.
The idea here is that looking at the skills of an analyst, a developer and a tester we want everybody to have a little bit of everything. A person might be a developer first and foremost but has some skills in analysis and some skills in testing. The same goes for your testers and analysts. There might still be a best person to do a piece of work but everyone can muck in if necessary. A common example of this might be helping out with testing at the end of an iteration of work.
The problem we get is one about the perception of the value the team delivers.
It seems obvious that the best thing for your expensive lead developer to be doing is indeed developing. If she’s turning her hand to testing it might suggest something’s wrong and there’s an imbalance in your team. Sure, it might, but how often is the shape of your work so predictable you can get that balance just right.
The temptation here is to start the development on a new piece of work (story, backlog item, requirement, whatever’s your poison) and let the testing struggle on. This just makes things worse, piling up work behind a bottleneck. You shouldn’t be bring in more work at this point, the team should be pulling together to properly finish the work they said they would complete. Succeeding as a team or failing as a team.
Ok, your lead developer may not be as good a tester as someone who sees that as their main skill but they can contribute towards the goal of completing what you’ve started. It’s all about flow.
Something I came across last year was the game GetKanban— a board game about software development. Sad I know but I loved it. The dice in the game represent your analysts, devs and testers with the larger number on each face showing how much work they get done for their main skill and the smaller numbers showing a reduced amount achieved for the other skills. During the game you very quickly see the value of people being able to contribute a number of different skills when needed.
Many Arms
We’re getting there with some skills but what about the others? I’m always being asked how other people fit into Agile teams. UX designers, architects, sys-admins, even baristas.
One of the challenges is often that some skills are only needed part time, perhaps we just can’t have a dedicated UX guy in every team (no matter how much we want that!). One solution is to take the idea of T Shaped People and go a step further towards Starfish Shaped People.
Testing and analysis skills are key to delivering software, as key as the development and people are just starting to accept that. We now need to realise that there are many more key skills and we need to find a way to get the people in the development teams to be able to show those skills when needed.
Barriers saying that only people in this specialised team can do this kind of work hinder progress and make it harder to collaborate well and build great software quickly. I’m not saying we need a free for all but I’m saying we need to broaden the idea of what people’s roles are and embrace being generalists.
In Scrum we often refer to people as Development Team Members, I think this is what we need instead of Database Administrator or Senior Specialist Analyst Programmer (a real one I remember). We’re all responsible for the software and should try and grow as many arms as we can.
