Scrum: How should developer promotions be handled in a scrum team?

Question

We have a scrum team. The developers demand clear guidelines for promotions. AFAIK, there's nothing like defined developer roles for a scrum team but people feel:

1. People who contribute more should be promoted faster: If someone is moving a fast pace and started contributing to architecture designing, he/she should be promoted to SDE2. Is it good to keep such segregation in a scrum team?
2. Recognition from outside world: Many developers believe that promoted title would help them when they switch job/move to higher studies.
3. Hike with each promotion: Most of them look for zoomed increments along with promotions.

Has anyone faced similar challenge? Any suggestions, how should we deal with this?

Answer 1

This is a common problem with traditional development teams that have started to adopt Scrum.

A lot of traditional development teams use job titles and commendations (such as bonuses) to differentiate seniority.

In Scrum there are just three recognised roles: Product Owner, Scrum Master and Development Team member. This can be problematic for organisations who are used to much greater differentiation using job titles.

I'm not sure there are any easy answers, but I think the best approach is to:

• Recognise and reward success primarily at the team level
• Where recognition is given to individuals, reward them for collaboration and showing leadership by example
• If the organisation uses job titles to recognise seniority, try and avoid titles that suggest management such as Development Lead. Instead, use titles that recognise capability, such as Principle Developer
• Make it clear to people that the job titles are to satisfy the needs of the organisation and that they do not impact on the principles of Scrum

Answer 2

Regarding your point 1. I think there's no controversy there: if someone contributes more this person should be recognized, it's not segregation, it's meritocracy. However it could be wise to find some recognition system also for those who just started contributting more, or had a better performance in a short term, as a motivation. Otherwise the trend is that those who perform better will be the only ones capable of receiving promotions.

---

Regarding the point 2., I think there's a line there between the Scrum team structure and the company structure.

A Scrum team can be built with Developers (from different seniorities and titles), QAs, UX Designers, etc, all of them being part of the Development Team. You don't need to have them all titled "Developers", but in the Scrum team they need to work collaborativelly as one, towards the iteration goal.

On the other side, as a company, I have that senior QA that knows the product from upside-down, and the Junior QA, their experience is different and it doesn't seem offensive or anything to have a higher title for those who know more. Even that I agree with @Barnaby Golden that Lead/Manager titles aren't the best titles from the Scrum perspective, I guess having them aren't a sin for the methodology :)

PS: In a preparation course for an Agile certification that I participated this topic was approached, there was a common sense that this is something that is still not defined (and probably won't in a short term), as companies have different opinions on what could be right or better when promoting people in a lean environment.