Sometimes, Agile Teams have to be literally just that…
Some agile methods – such as Scrum and eXtreme Programming – advocate multi-disciplinary teams. That is, teams of generalists; developers that can write code, and can also do whatever other tasks are required.
In principle, this is a good concept because:
* A multi-disciplinary team never suffers from any bottlenecks, where the team is waiting on someone with particular skills.
* As a manager of a multi-discplinary team, you don’t have to try to work out the ideal profile of the team, anticipating in advance how many developers, testers, analysts, etc you’ll need at any given stage of the product’s development. This is challenging anyway, and changes over time.
However, in reality, setting up with multi-disciplinary teams is not always possible. And not necessarily ideal…
Many organisations already have specialists. For instance, designers, front-end developers, back-end developers, database administrators, business analysts, testers, project managers, product managers, etc. Unless you want to get rid of these specialists, and employ only developers, you need to put these people to work and you will definitely benefit from their specialist expertise.
And generalists that have all the required skills are rather hard to find!
You might find a developer that is really good at both front-end and back-end development. You might find a developer that can also do analysis. You might even find a developer that thinks like a tester. Although this one can be difficult, because we all know developers can’t test for toffee! 🙂 And, if you are lucky enough to find someone who really is good at all of these things, what are the chances of them also being good at UI/graphic design?! Maybe. But in my experience, generally not.
So what do you do?
Personally, I think you need a team with all of these skills. It’s a multi-disciplinary team by virtue of the fact that the *team* has all of these skills. Not because *everyone* in the team has all of these skills.
If you can find generalists, to minimise the number of specialists and reduce potential bottlenecks, great! Combining some roles can certainly help with this. For instance – in my experience of agile – the roles of analyst and tester can potentially be merged into the role of Test Analyst. And the more generalised role of Product Manager might combine the traditional roles of Project Manager and Business Analyst, as well as introducing some important product management discplines.
But in the end you will probably need some specialists.
In which case, it is very important for these specialists to be flexible. To be Agile. In the true meaning of the word.
You might be called a Tester, and might specialise in testing, but you should be prepared to help with analysis and any other tasks that you have the skills to do. You might be called a Developer, and specialise in development, but you should be prepared to test your colleagues’ work if it’s testing that the team really needs to get done. You might be called a Project Manager, and specialise in project management, but you should be prepared to help with analysis and testing if it helps the team to deliver.
This is, of course, a question of attitude. There’s no place for “jobsworths” in an agile team. In an agile team, you never want to hear that “it’s not in my jobspec”. It’s a question of team spirit. Completing your own tasks while the team fails to deliver is not success. Not for a team player. The team succeeds, or fails, as a team.