Highly-Paid Developers As ScrumMasters? 434
An anonymous reader writes 'At my company, our mis-implementation of Agile includes the employment of some of our most highly-paid, principal engineers as ScrumMasters. This has effectively resulted in a loss of those engineering functions as these engineers now dedicate their time to ScrumMastery. Furthermore, the ScrumMasters either cannot or do not separate their roles as Team Leads with those of ScrumMastery and — worse — seem to be completely unaware that this poor implementation of Agile development is harmful to our velocity. To date, I have chalked this up to poor leadership, a general lack of understanding of Agile, and an inability to change from traditional roles left over from the waterfall development mode. In addition, I have contended that, for a given Scrum Team, the role of ScrumMaster should be filled by someone of lower impact, such as an intern brought in specifically for that purpose. But I would like to put the questions to Slashdotters as to whether they have seen these same transitional difficulties, what the results have been at their respective companies, or whether they just plain disagree with my assertion that principal engineers should not be relegated to the roles of ScrumMasters.'
Hurl (Score:4, Informative)
You're missing the problem (Score:2, Informative)
Re:WTF does this mean??? (Score:5, Informative)
And yes, you are absolutely right. I couldn't entirely understand the article either.
View from the Dark Side (Score:2, Informative)
It immediately cuts the time these developers can spend doing actual project work - something they grouse about constantly. On the other hand, we also have an army of young first- or second-year analysts, all of whom embrace our governance, and generally perform the project administration side of things far better than their more-experienced colleagues.
On the other other hand, I have noticed that the younger consultants lack the project experience to plan creatively and come up with ways to make the process work for them. They would if they could, while the older ones can but couldn't be asked. I fear that over time the negative attitude towards governance that lingers from the older generation will infect the new guys.
Our company recruits annually, and is always running a number of internal projects. What I advocate is that the new consultants spend a while running small internal initiatives during part of their time, and then spend their second year as the administrators on client projects, before being able to "earn" not having to worry so much about all the extra overhead that comes with that sort of thing. It might also help with retaining experienced staff.
Clearly a targetted post: (Score:5, Informative)
At any rate, to respond to the post:
The best method of handling who is the scrum master I have encountered is by not giving the job to one single person. A rotation every 4 sprints seems to work well (we do 2 week sprints), as it spreads the load of scrum master around and it keeps us from getting into a rut when doing sprint planning and retrospectives, as a different person is running it every 2 months. You're right that giving your strongest developer the task of scrum master is asking to have your strongest developer not code as much, but if you have your intern running scrum, you may find that lack of understanding of prioritization will impact your velocity quite a lot more than giving extra work to your lead.
One additional thing to note is how efficient you are in scrum master tasks... if you're hand writing stickies to put on the scrum board, you're probably wasting time. Any half decent script monkey should be able to write a script to parse your backlog and generate stickies for you.
Re:Wrong all wrong (Score:5, Informative)
instead of forcing them to play silly mind games.
That's why I like Joel's [joelonsoftware.com] approach.
Re:Velociraptors (Score:5, Informative)
"harmful to our velocity" WTF is that supposed to mean?
In Scrum, tasks/stories are estimated using a common metric (e.g. story points, hours, days). Velocity is the rate at which the team do these - e.g. "20 story points/day". If you're into Earned Value Management [wikipedia.org], you could see it as the rate at which EV increases. You can find an interesting paper about it here [solutionsiq.com].
The problem for the original poster is that they just jumped onto a buzzword not really knowing what it is, and not utilizing it properly. There are no silver bullets. If the project is organized in a way that means the scrum master is doing project management, they need a real project manager - and definitely not an intern with little authority. That way lies disaster. If one of the senior developers want to change into project management and is doing it well, good - but then he is not a developer anymore, and should not be counted as a resource.
Re:You're missing the problem (Score:3, Informative)
No, just like GP said, a scrum master isn't a manager. Of course he can't decide to change the methodology since he isn't a leader with authority to make decisions like that. (Most likely questions like that aren't in the hands of the team either.)
If a scrum team is spending significant time in meetings because of "scrum", you aren't doing it properly. The daily meetings shouldn't take more than ~15 mins each. Yeah, it's easy to go over that if you start talking all kinds of unnecessary stuff in the meetings instead of being to the point, but it's part of the scrum master's responsibilities to take care that it doesn't happen.
Re:Long standing agile developer (Score:3, Informative)
Managers should never be scrum masters, as often scrum masters need to go against management in order to get the team through blockers.
In management terms this is called managing up, it is the hardest but most important part of being a manager as it involves convincing people on merit alone. Managing down is easy as the people under you have to do what they are told as you set their wages and are ultimately reponsible for their continued employment. Managing up often means going to bat for the team and explaining to upper management why things need to be done a certain way to succeed, even if they do not want to have it done that way. Just because someone has a job title of developement manager does not mean they always have to take upper managements point of view.
In short, a good manager can go against his own management above him in order to get the team through blockers. They will probably not do it in front of junior staff though as this undermines confidence in upper management. Management might appear to be a united front, but that is just an appearance to those who are at the bottom of the ladder.
Re: Scrum? (Score:3, Informative)
Meanwhile all the other members of his side of the scrum, try surreptitiously to beat up the other team - under cover of the "scrum", without the referee noticing. It's a very physical, bruising way of achieving possession, but an art form to get right.
On agile programming, it's roughly the same - except there's no ball and no referee - and there aren't really teams - everyone's looking out for themselves.
Re:why use scrum in the first place (Score:2, Informative)
There are a lot of cretins posting in this thread. The above post is a shining beacon of non stupidity.
A couple of point. ScrumMaster is not a team lead. They are a new role crossing a dash of coach with a large serving of facilitator. ScrumMaster is NOT a low value role, but it is a different role.
Full time, good team facilitators/ScrumMasters are essential and will be drawn from the entire department. Dev, QA, testing etc. What matters is that they are a people person with high integrity. Which is rarer then you would think! Coding ability is irrevelant. It sound like your org has mapped Scrum rather than actually changed to use it (as everyone recommends)
sm is not an intern role. It is not a paperwork role, it is a high value servant leader role that requires the aforementioned skill set.
Ignore every other post in this thread - most people are ignorant and blisteringly stupid.
Agile is much more then Scrum (Score:2, Informative)
Re:Scrum master = Project manager!!!!! (Score:3, Informative)
If your Scrum Master looks anything like a traditional Project Manager then you're doing it (very, very) wrong.
It's a very different role. There is no directly mapping role of Project Manager in the Scrum method as the responsibilities of a traditional PM are split across the Scrum Master (facilitator and process enforcer/advocate), the Project Owner (project direction, task priority, release planning), and the Team (accountability, communication).
Re:The answer is obvious... (Score:3, Informative)
The second is as complete a list of FUNCTIONAL requirements as possible.
Scrum explicitly rejects the idea that this is a useful way to spend time. Complete requirements may not be possible, may not be feasible with limited effort, and will most likely change over time.
Instead it advocates getting enough high-priority requirements written down to get you going, and getting the most-desired part of the system done (as much as can be done in a "sprint", a week to a month), and iterating with the next most important item. Not only does this deal with change, it allows new requirements to be uncovered in an orderly way rather than causing a conceptual train wreck ("but the functional requirements are done"), it allows value to be taken from the existing software as soon as possible, and design flaws (e.g. "system does everything we want, but doesn't scale past 100 users") to be uncovered and corrected much earlier.