Scrum Team Roles - are there really only 3?
I am trying to educate myself on Scrum as much as possible. It says pretty clearly that there are only 3 roles on the team:
- Scrum Master
- Product Owner
- Team Members
For a software organization, I assume that the Team Members part of the team include developers, business analysts and testers. But under the Scrum model, I believe that they are all supposed to pitch in and help each other. For example, I assume that this means that a Developer on the team shouldn't say, "I'm not helping with testing...that's your job". Rather, they should say, " I would be happy to help with testing, and while I'm doing it I'll learn more about what it takes to do proper testing. I'll also look for automation opportunities along the way."
I am assuming that one of the big benefits of Scrum is that everyone learns about each other's jobs and helps them out as much as possible and as much as needed.
So, my question is this. For big companies that have well defined job descriptions, do you literally change the agile team members' titles from something like "Senior Application Developer" to something like "Agile Team Member"? Or do the team members maintain their identity and specific job titles and just try to help each other out?
I'm interested in hearing from both companies that let people keep their job titles and their role identity as well as those which strip it away from the employees (if there are any of those).
I am also interested in knowing how important this aspect of Scrum is with respect to getting the full benefits of Scrum. The Scrum books are pretty clear that you need to implement all of Scrum or else it's not really Scrum and if you don't implement all of it your not going to get the benefits. I've heard this called "pretending to do Scrum".
So, do we really need to say to the agile team members, "Sorry, you're not developers, business analysts or testers anymore. You're Scrum Team Members and you can and should self organize and work on whatever you need to in order to achieve your objectives. There's an agile coach over there that can help you with this. Have fun!"
Speaking as a software developer, I would NOT expect my job title or description to change. Perhaps you could add some detail in there to mention agile/scrum but really whether I'm doing scrum or Waterfall I'm still a Senior Software Developer. I'm still responsible for requirements gathering, designing, coding, and ensuring good quality of code. Applying scrum doesn't change any of that for a developer.
Now for a QA tester and BA that's different. In an ideal world, scrum team members cross train each other so anyone on the team can pickup any task on the board. Since QA testers and BAs aren't typically trained technically their jobs would begin to change. E.g. at one point we began incorporating our QA testers on our scrum teams. Eventually they started to learn how to code automated UI tests instead of writing manually test cases which they manually conducted over and over again. In that case their job responsibilities and required skillsets started to change.
In my organization, job roles still exist. However, what actually happens is your job role in the organization may not directly align with your agile role. You can be a tester and a scrum team member. You can be a software developer and a scrum team member. You can be a BA and a scrum team member. Effectively, your job role is a specialization for your scrum role, but you hold both roles simultaneously.
So yes. You end up cross training. Your developers pick up some testing skills and help with automation. Your document writers learn to help out with testing during downtime. Your developers help maintain documents. But when a new document needs to be created, or an emergency bug fix needs to go out, it's owned and produced by the specialists relevant to the tasks, and supported by the other members of the team. You don't want to hand your code tasks to your document guy and let your developers continue to develop test cases. That wouldn't make much sense.
The message shouldn't be that from now on people lose their specialisms, because that would be a falsehood. Rather, the message should be that now they are expected to be joint members of a new role, which is that of the Development Team, and it is a role that has clear responsibilities. Organizational sponsorship of Scrum is often needed to make that expectation clear.