Scrum Master Career Path

Why do you want to impose a hierarchy? If being a Scrum Master isn't enough in your organization, why not? Why is the organization getting in the way of their success, which reflects their team's success?

It's not really a hierarchy as much as it's different career paths. I could add an Agile Coach or other type of role to the department that would allow for more flexibility. HR is asking me for the hierarchy to come up with salary bands. Plus, the people themselves want to have options. I'm new to the structure of Agile departments so I'm looking for actual career paths that people are seeing out in the market.

If you add roles like "Senior Scrum Master" then you are adding hierarchy.  And if you add a role of "Scrum Master Manager" then you are definitely creating a hierarchy.  

In the Scrum Guide there are 3 roles defined; Scrum Master, Product Owner, Developer.   These are not job descriptions, they are roles.  A person with any job title could fulfill those roles.  However corporations want to follow the old military style of hierarchy where each level has different job duties and responsibilities.  You can create whatever job descriptions/titles/positions that you want.  But the Scrum Guide will not provide any guidance.  

If your HR group wants to have separate titles/positions for salary bands and such, then let them suggest what they should be.  They are the ones that need to have the hierarchy in place.  

In all the companies I have helped transition to Scrum, I have not once created a job description of Scrum Master.  We typically were able to repurpose an existing job title from our days of waterfall project management to let people fulfill the Scrum Master role as defined in the Scrum Guide.

One of the things that agile practices justifies is that you do not need career paths.  When individuals are given the ability to manage their own careers, to work within a team that self-manages and self-organizes the titles are no longer important.  The importance is on accomplishing the right things and having the confidence of the organization to make the right decisions without someone "above you" approving.   Yes, people should be paid based upon the work they do and the contributions they make to the team/organizations.  But that can be done by using a wide compensation band.  

I have been asked to be the "HR manager" for agile teams and I have done it.  However, one thing that I raised as an issue every time is that I was not able to fairly compensate people for their work. I was limited to the bands and policies.  If I had someone that had less experience in the industry but was one of the most prolific contributors to the team, I could not compensate that individual as much as the people with more experience. 

In your original post you said:

I'm working on establishing an Agile department from the ground up at a successful technology company.

If that is true, then you should also be able to help the successful technology company understand that a department can't be agile if the rest of the organization is willing to support them.  I have never seen a successful transformation to any type of agile practice that did not also require changes across the entire organization. 

just add something a bit more pragmatic (but no doubt contentious), I don't think the industry or most companies are in a place yet where a flat hierarchy is actually achievable. We have a lot more coaching to do before we're there. 



However, having been through a similar situation I can tell you there are some ways to create the HR required salary bands, reporting lines etc, while still trying to guide the org in the direction of reducing hierarchy. 



For example, don't create senior SMs, just create a single role and ask for a large salary band to allow people to grow. 



Create something akin to a 'practice lead' who can be responsible for guiding the SM's (being an SM for SM's) as your 'lead' role, but make it ALSO an SM role, ie, they still work with a team and do normal SM stuff, they just also guide the practice) 





If your organization needs agile coaches, do NOT create them as a step above SM's. That's a recipe for disaster. Again, make sure the band is large enough so someone COULD move from SM to AC and get a pay rise, if that's their goal, but someone could also go the other way and still get a pay rise. 



Pay increase should denote further growth and learning, not moving 'up' a hierarchy. 



You can do something similar with PO's and Developers, and again, make sure that moving 'up' simply comes from growing further in one or more role. 



 

Last thing, try to get dedicated people leads. Don't have SM's reporting to other SM's or (god-forbid) to PO's. Make people management a dedicated role, and like the others, something a person might choose to grow into or not. Make sure the salary bands are capable of allowing someone to move into a role from any other role while still able to get a pay rise. 



Ultimately, when done right, the pay rise thing doesn't really matter to people, it just satisfies HR requirements.