In my final year of university a few years ago when I was applying for jobs I was really keen to join the (then) Reuters Graduate Technology program.
The thing that appealed to me the most was that over the 2 years you were on the graduate program you would have the opportunity to be placed in 4 different roles within the business. The website gives some examples:
Technical architect, Project manager, Infrastructure service manager, Business analyst, Product & development manager, Software engineer, Implementation engineer, Desktop design consultant, Technical specialist, Deployment project manager, Training
What I really liked about this idea was:
- It gave you an opportunity to try different things and see what you liked best.
- Regardless of what you eventually chose to do you now had a broader perspective of the world from having done the other 3 roles.
I was reminded of this a couple of weeks ago when I was having a conversation with a colleague about whether everyone on an agile team should have to learn how to do all the roles (Developer, BA, QA, Iteration Manager, Project Manager).
Why learn all the roles?
The main advantage of having people who have the ability to work in different roles is that it provides a team with great flexibility and helps to increase the team’s bus factor.
From my experience on agile teams it is often the case that there is a single Business Analyst and if they are on holiday or absent then there is not necessarily someone else on the team with the skill set to cover them. When these type of situations arise it would be useful to have someone who could play that role for the day.
Having experience across different roles gives you a different perspective when playing your current role. Certainly developers would be much more inquisitive about the business value a particular story is adding if they had experience working in an analyst role and and analysts who have been developers have a better idea about the types of things that developers need to know to complete a story.
As individuals we learn much more quickly when we are operating in beginner’s mind, a state we would be able to achieve with much more frequency if we are learning different roles. The natural inquisitiveness we display when learning a new skill can also be beneficial to the rest of the team as it will bring up assumptions which may not necessarily be correct but which wouldn’t have been exposed otherwise.
I’ve heard the argument that the skill set for BAs/QAs is quite similar and I have certainly worked with colleagues who are able to perform both roles. Many project managers I have worked with have performed another role previously, so maybe it is only natural that you will end up with some people with multi role skill sets on any given team.
I think if we are to become skilled across multiple roles in a team then we need to become careful that we don’t have the situation where we become a jack of all trades and a master of none.
In agile teams the idea of having generalising specialists is encouraged so we would need to make sure that we retain some areas of specialism while also having the ability to fill other roles rather than spreading ourself too thinly across all roles.
This seems to indicate to me that a certain amount of depth is required in our principal role which mainly comes from spending time doing it. I think this is the same principle which holds when learning programming languages – it’s better to gain a solid understanding of one type of language before trying to learn other ones from my experience.
The idea of being skilled in multiple roles also seems to go against the idea of playing to your strengths encouraged by Marcus Buckingham in his book ‘Go Put Your Strengths to Work‘. If we have already found what we love to do and can do it well then there may not be that much benefit in trying to change, although it is always useful to step outside your comfort zone once in a while.
I think it is good to have people with the ability to play multiple roles on a team but I’m not sure whether every single team member needs to be able to do this – it is certainly useful to have some people on a team who are purely experts in one role.
I’m sure I haven’t covered all the potential arguments here but I find it interesting to see how far the generalising specialist idea should stretch – where is the limit of when having greater depth in one area becomes preferable to spreading our abilities across different ones?
As Lachlan points out in the comment we should be looking to increase the bus factor on the project rather than reduce it. My mistake.