Re: [scrumdevelopment] Scrum and Career Ladder
- This depends deeply on how your organization is already structured. If you have an existing functional organization that assigns people into projects, then the existing career ladders within each functional group can remain unchanged: developers become senior developers become principle developers become architects and so on.If your organization is totally project-focussed, however, developing a career ladder is a challenge, and as others have pointed out, not necessarily a good idea. Some of the best government consulting organizations have long had only one title: Member of Technical Staff. This allows them to assign people to do whatever needs doing without regard to title or "career ladder." Scrum would merely perpetuate this.In this kind of situation, I would suggest using pay grades instead of titles, and tying those pay grades to demonstrable levels of technical (and/or managerial) competance.And in a project-focussed organization, the real plum in a lot of cases isn't pay, but what project you get to work on. The most important projects get the best people, and the people on them know it.On the whole, I suggest at least two tracks of career development: increasing technical skill, and increasing "management" responsibility. The "management track" may have two rungs on it -- worker and ScrumMaster -- but it gives people a chance to choose the direction they want their careers to go. And on reflection, there are more shadings of ScrumMastery: reflecting the degree and kinds of problems that they can help teams overcome, as well as how much they still contribute technically. (I'm not sure that represents a "ladder", but there's certainly room for an individual to find their place.) There is a third career direction that may be important as well: Product Owners. They deserve a career track of their own, reflecting their depth of product and market knowledge and their ability to work well with teams.Also consider that some people may work best when rotated through a role as ScrumMaster. It can be a "burnout" job for some, and then they'll want to return to individual contribution before doing it again. And there are some people who can fill both roles well and like the variety. These people are key resources and need to be fairly compensated and recognized. That doesn't work well in a "ladder"-driven organization unless you can be on several ladders at once. I think the real goal of career development has to be to fairly compensate and recognize people while giving them opportunities to grow in whatever direction they wish. So there may be more to it than a set of linear ladder steps.Your best resources in this area are actually HR professionals. You might want to talk this over with the ones in your company now, and any of your acquiantance. If they understand the situation, and have inventive, open minds, they can give you a wealth of relevant knowledge and research. The HR literature is another resource if you don't have the right people to talk to.Congratulations on tackling a tough nut; please let us all know what you end up with.Good luck,Robert HenleySoftware ArchitectCertified ScrumMaster----- Original Message -----From: Mark McCainSent: Wednesday, November 26, 2003 8:19 PMSubject: [scrumdevelopment] Scrum and Career LadderOne of the issues I have been struggling with is how we setup a career ladder in companies that use Scrum? Management has asked me to help them develop career paths in a new consulting enagagement I am doing. Im not that familiar with career ladders so Id appreciate any help with this.With self organizing teams it seems that less management is needed, so how does one advance in their career to the bigger bucks of management? Or does everyone here want to be a career cubicle dweller?Can existing traditional PM's become Scrum-masters and will they be happy in their new role? If a scrumaster isnt a programmer, doing testing or writing documentation, is being a full time scrum master going to be a satisfying role for them. What kind of person is best suited to be a scrum master. Im particularly interested in hearing from any scrum masters in this group. What was your previous role and what do you do know? How many hats do you wear and what are they.Mark
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
- --- In email@example.com, Mark McCain
> One of the issues I have been struggling with is how we setup acareer ladder in companies that use Scrum?
It's important to have a way to tie remuneration to work done... it's
one of the satisfactions we earn from our work. But I associate the
concept of "Career Ladder" with the Peter Principle... is there a
more flexible, more "agile" metaphor we could use? I find "career
path" equally troublesome. Both implicitly contain a "right" and
a "wrong" direction in which to be moving... but in my experience,
the best moves can sometimes be sideways.
In an agile team, people are encouraged to find their "niche", and a
niche well-filled is more valuable than many fancy job titles. And
over time, niches will come and go, just as technologies and
lifecycle stages do. I think there is a difficulty mapping to such
linear metaphors from within the somewhat chaotic, "emergent" nature
of agile teams.
Is there some kind of organic metaphor can we use?
from: The American Heritage® Dictionary of the English Language:
Fourth Edition. 2000.
Peter Principle, NOUN: The theory that employees within an
organization will advance to their highest level of competence and
then be promoted to and remain at a level at which they are
ETYMOLOGY: After Laurence Johnston Peter (19191990).
>Scott Ambler's concept of a "Generalising Specialist" may be
> In an agile team, people are encouraged to find their "niche", and a
> niche well-filled is more valuable than many fancy job titles. And
> over time, niches will come and go, just as technologies and
> lifecycle stages do. I think there is a difficulty mapping to such
> linear metaphors from within the somewhat chaotic, "emergent"
> nature of agile teams.
> Is there some kind of organic metaphor can we use?
pertinent here; one's knowledge becomes both broader
and deeper as time progresses, becoming more flexible
and more generally useful by learning the basics of a broad
range of skills, while also becoming more expert in a few
specialisations. Perhaps the concept of progression from
Apprentice through Journeyman to Master is appropriate,
without specifying those topics in which one may become