Many “Agile Methods” such as Scrum and XP suggest (or command) that there shall be no job titles on the team.
What are the implications of this?
Although this “utopian” view suggests that all team members are equal, this would only really make sense if all the team members WERE equal, in terms of experience, ability etc.
That is a very rare occurance unless all of your team members are recent low level grads.
A typical team would be composed of junior, senior, and architect level developers.
Clearly all of these people deserve different pay based on ability, and a job title based on their abilities and pay.
Otherwise when they move to a new company or project, how will they be fairly compensated?
Even in their current team, how would they be fairly compensated? Is there one flat salary for all? Did junior engineers get raises while senior engineers took pay cuts?
I’m curious to how people implementing Scrum/Agile are dealing with the aspects of pay compensation and job titles…
As well how conflict is resolved while the team “self organizes”. Are you using a voting process? How are votes counted?
It seems irresponsible to me to foist an approach on a team unless fundamentals such as this have been worked out, communicated, and bought in by all parties prior to adoption.
Rarely do I see this happen on a Scrum introduction/rollout.
Feel free to share your experiences in this area
Jordan
Hi Jordan,
While I do not advocate one pay rate for all (I believe this was attempted before in a place call the Soviet Union, and currently in Cuba, not working out so well I understand), I know a company in Brazil called Semco has transparent pay. In other words team members understand different pay levels, and actually set their own pay. To me that might be a better way for self organizing teams to tackle the pay issue, if things like performance can be compensated for fairly. Although I have to admit I might be hesitant to try that approach, it may be worth investigating.
Right; I’m not suggesting there is “one way” to address this issue, but it seems like a fundamental issue that must be addressed.
There can be many different ways to solve it and it’s good to hear as many viewpoints as possible on this.
Jordan
Jordan,
You raise some interesting, relevant, and difficult questions.
I think you misinterpreted what that language in the Scrum Guide means, but I will readily concede that the language is not clear. If you read that particular section, you’ll see that it doesn’t say “job titles”. It says “titles”, then goes on to basically say that everyone chips on a team effort, and no one can tell anyone on the Dev Team how to do their work. In short, no one team member has “authority” over another. People can still be paid differently and have different “job titles” so long as they don’t have decision authority over another Scrum Team Member.
> As well how conflict is resolved while the team “self organizes”. Are you
> using a voting process? How are votes counted?
There are multiple strategies for this. The short answer is that the SM usually acts as a facilitator, helping the team come to a consensus. In that way, the SM is helping to remove impediments. Sometimes team members will say something like “I don’t agree with doing it this way, but I’m ok if you all want to try that.” or “I can live with that”, etc… The real answer is much longer than that. You might look into the “fist of five.” and similar facilitation and consensus techniques. I will also concede the Scrum Guide is a bit vague on this as well — however, the Scrum framework, probably rightly so, leaves it up to the team to determine how conflict is resolved.
It seems like a non answer. The team should work it out. If it’s up to the team to work everything out, why is it the team needs to follow the Scrum script to begin with?
Go read my post “Scrum as the New Command and Control” for more information. Scrum is hollow and banal in it’s prescriptions and the things that really matter are left as an exercise for the user.
I do not believe that senior developers should have equal vote compared to junior developers. I believe they deserve more of a vote.
One of the many, many things I think is wrong about the Scrum process.
Additionally while I think the team should “self organize” — up to a point — resolving conflict is a “people issue.” That means management.
Jordan
You’ll find that in most teams, senior developers almost always have more sway than junior ones. Some comes from automatic deference, and some comes from the fact that people are still appraised for pay/position raises outside of the Scrum team. I think that’s one point your forgetting in all of this. This “from the outside” accountability is what allows self organization to work. On a different note, this is one reason why Scrum does not work for all volunteer organizations, because there is very little “from the outside” accountability.
In my perfect world, a Scrum team members raise would be based on:
1/3 individual performance, as judged by the appraiser
1/3 team performance, as judged by the appraiser (which means the entire team would get the same appraisal)
1/3 team member performance, as judged by that person’s peer on his/her team
Neither Scrum nor Agile properly address these issues, so I believe you’re right to point them out. OTOH, Scrum specifically does not claim that it does address those issues, which in Scrum, means the team and organization is free to decide how to address those issues however they see fit.
Charles
Maybe on “most” teams that don’t do Scrum senior developers have more say, but when people start thumping the scrum guide then it says “everyone is equal.” That right away creates conflict, and if there are more junior developers than senior, the junior will overrule the senior and that is insanity at it’s finest.
So I think that without an upfront understanding of how conflict will be resolved, it is foolish to jump into Scrum.
I think training in self management and self organization would be far more valuable than training people in the “3 ceremonies” etc.
Although I welcome all comments on how appraisals should be done, my point is more abstract than that, which is: “Everyone gets paid. Everyone has a job title.” and yet “Scrum says everyone is an equal and has no title.” Now, this is clearly on a collision course with everyday reality.
Handwaving over that as an “exercise for each company to discover individually” seems quite irresponsible.
Jordan
So, while Scrum addresses the issue of “self organization” and “no person has authority over another on the Scrum team,” it does not address how conflicts are resolved, how people get pay or pay raises, etc … As such, it leaves it up to the organization to decide how to implement that effectively.
See above
Jordan
Jordan,
Thank you for raising this question. As an agile coach, I often work with companies who question how the job descriptions and pay scales within job descriptions should change to support agility. And while I also promote similar principles as Charles did in balancing the review across individual, team and organizational performance – when it comes to itemizing these in detailed descriptions to build an agile-based pay scale for team members becomes challenging.
I would be interested to know if there are any specific examples available where an organization has created a detailed pay-scale grade levels for agile team members which would reward a team-members performance across a balance of technical mastery, agile team leadership and collaboration, organizational accomplishments, etc.
Pete