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
PostAgilist
Post Agilist 
Hi PostAgilist,
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.
PostAgilist
PostAgilist,
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.
PostAgilist
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.
PostAgilist
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
PostAgilist
PostAgilist,
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
The way it worked on a project I was involved in in 2012 is that there were no job-titles as such, but certain people from time to time might be designated scrum-master, architect, or whatever. Everybody should be able to do every job was the philosophy and they were “all paid the same”.
It wasn’t true, and effectively seniority was determined on an ad-hoc basis depending on much pay you actually got to take home. It worked like this:
1 – The company paid the same flat hourly rate for all staff on the agile team.
2 – Most staff on the team were external hires on temporary contracts
This does not mean all members of the team took home the same pay. Mostly they were hired through body-shops with the payment made to the body-shop not the employee. A few independent contractors were also hired through recruitment agencies.
Actual take-home pay depended much more on how you had been hired than your experience. The company paid $1,000 per day for every person on the team. The body-shops kept $600 for themselves, agencies only got to keep $200. So two guys on the same team doing the same job earned $400 and $800 respectively irregardless of their skills, experience, or productivity. There simply was no incentive for the $800 guy to do more than $400 worth of work, and even less of an incentive for the $400 guys to work any harder. They, the $400 guys, could effectively double their salaries overnight not by improving their skills or experience, but simply by having somebody else represent them on the project’s billing list. Naturally the project’s contract terms forbade them to do this. So they pretty soon figured that if it took them twelve hours to finish a task they could have done in eight, they get paid 50% more for it.
That’s very interesting on a number of levels. What country was this in by chance? What type of development?
PA
Interesting thread. We had an retrospective the other day about just this topic. As a self organizing team, we usually take on tasks of a story that we are generally good at, unless the type of work isn’t available, or we wish to go outside our comfort zone or to improve on something we need experience on. Some people are better are doing testing activities, some are better at developing this type of component over another, requirements analysis, design, etc. So these tasks get decomposed and self organized during mini developer planning meetings after our standups. Performance affects each team members REPUTATION amongst the rest of the team. We realized that, since we all have the same position (we all have the same classification, and have pay scales based on years of experience in the role), all we have is reputation. If you fail to perform at a task, this affects your reputation to the team, and perhaps the next time a task comes up that you want to work on that is similar to one you failed at earlier, the team takes that into consideration to improve the velocity of the software development to agree to have someone who’s faster/better at doing that actually do it – ego gets in the way of this a lot too, which is human I guess. But, we also balance self improvement, so we let members of the team go outside their comfort zone as it makes sense to do so, as we understand it will lead to improved velocity in the future (in our never rending effort to become line replaceable developers – reduce bus factor). Also, if you’re good at something, the self organizing team is less reluctant to agree on the idea that you should work on it, which is what we use in our team to provide incentive. If you want to do certain types of tasks over others, do them well and it’s more likely you’ll get other tasks like that in the future.
Opinions?