Highly-Paid Developers As ScrumMasters?

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.'

Comments

why use scrum in the first place

[Anonymous Coward]

Do without all the agile scrum diddle doo, and you'll be just fine.

you seem to be wasting your time with implementing a particular coding methodology,
instead of doing actual useful coding.

Re:why use scrum in the first place

[beelsebob]

I don't disagree that scrum can end up a mess, but what you're describing is actually the exact opposite of scrum. For scrum to work, you *have* to have good documentation and good test cases/proofs. If you don't have these, you can't check that your code does what is intended, and hence you can't ever refactor.

If you have no idea what your code does and why, then you'll be too scared to go near it with a refactoring stick, or to rewrite large chunks of it. That's why you've *got* to have good methods of determining if your code is doing what it should.

Re:why use scrum in the first place

[Matthew Weigel]

No, it's not. "I know you tried to do scrum, but you had a failed project, so you did it wrong."

In my experience, scrum is just snake oil. I don't think it's very good to begin with, but worse is that a) everyone modifies scrum to some extent to fit their organization and b) if a project using slightly modified scrum fails, it was because they modified scrum.

Of course, the solution always seems to be hire more good scrum masters, who are "rarer then you would think!" That's really the part that is snake oil, in my mind. It's a business model for consultants, and the trainers of those consultants. This is even more clear with the scrum model's insistence that a scrum master has a "pig" role.

Maybe all the scrum organizations should promote the idea that every time a scrum project fails (yes, even with modifications, which is how it always works), the scrum master gets fired. Here, "fails" should probably mean over budget or over schedule, by a dollar or a day. That might give the scrum master a role where they feel like their bacon is on the line. But of course that won't happen; scrum masters aren't team leads (as you point out), they're not managers, they're just coaches... one more person not doing the actual work who has to be involved, but with less accountability and more power than anyone else in the project.

Wrong all wrong

[Anonymous Coward]

Everyone does it wrong. Every single place that I've worked has done it differently and failed similarly. Agile + Scrum + Ruby seems to be an epic combination of fail.

Re:Wrong all wrong

[Haeleth]

You probably meant that to be sarcasm, but it's actually the correct response. Let's give up on looking for silver bullets. Let's abandon the stupid idea that slavishly following the latest fashionable religion^Wmethodology is going to produce perfect code.

Instead, let's recognise the truth: development is hard, and the best programmers are orders of magnitude better than the worst. Let's employ the best, pay them decent wages, give them decent work environments, and let them get on with the goddamn job instead of forcing them to play silly mind games.

WTF does this mean???

[PontifexPrimus]

Could we please get some explanatory links in here? This reads like a mix between a corporate nightmare ("harmful to our velocity"? SERIOUSLY?) and the rantings of an MMORPG nerd ("I was a level 72 ScrumMaster specced for Agility, but then they nerfed that and our Team Leads couldn't afford the new +5 leadership crafts, so we completely tanked at the Waterfalls of Development, even though we hired N00Bs as cannon fodder!").
Jargon, people! And don't chastise me for not RTFA - there is no FA to read!

Velociraptors

[Runaway1956]

"harmful to our velocity"

WTF is that supposed to mean? You're losing money, and you wish to lose money more rapidly? Or, you're not coding fast enough?

Sounds like one of those buzzwords. Did you buy that from the vendor, as well?

Re:Velociraptors

[arkhan_jg]

"harmful to our velocity"

WTF is that supposed to mean?

It's a scrum term; velocity is how much work a team can handle in a sprint (short development period to accomplish a particular goal or series of goals) - harmful to our velocity in scrum terms means - "we're not getting as much done as we would like".

To answer the original posters query; I've worked with scrum, and it sucks. It only works if people work together, are largely self-organising, and don't deliberately chuck roadblocks into other teams paths to get them off their own joblist. Oh, and if management can largely get out of the way and not constantly interfere with the process, i.e. unilaterally adding stuff to the burn-down chart in the middle of a sprint!

The scrummaster is more of a phb role than a senior engineer role; they basically need to have enough weight to stave off senior management interferance, moderate customer input, and have enough authority to crack the whip to developers who are slacking off. Definitely not an intern role. Whoever is the manager of your dev team, the manager who's on the next rung above your senior engineer are the ones who should be scrummaster; the ones that want status reports, talk to customers, and run interference between senior management desires and what your team can actually deliver; not your chief coder, certainly.

Agile

[Frankie70]

In my opinion, Agile is a great tool for managers, not developers.
Every manager in the end wants to ask for status reports every day.
But they can't do so, because people working for them will be upset.
Agile is an excellent way for Managers to ask for status reports
everyday.

In my opinion, TDD (test driven developement) is the only good thing
about Agile.

Here is Scott Adams about Agile.
http://www.globalnerdy.com/2007/11/28/dilbert-on-extreme-and-agile-programming/
http://www.flickr.com/photos/cote/63914774/

Re:Yikes

[religious freak]

I think Warren Buffet said it best when he said "if you can't explain it in simple terms, you don't understand it". He said "young kids" (he's 80+, so who knows what he considers a young kid) come in pitching ideas using the fanciest of terms but when he asks for clarification, he can't get it, because they don't understand the fundamentals. And though it was a major pain in the ass, working at a helpdesk for a year taught me a lot because you NEED to distill things down to their core components and strip away all the crap. Stripping away crap == understanding fundamentals == true understanding. When you have a fundamental understanding, then you can add the bells and whistles

Honestly, it sounds to me like OP hiding behind lingo without actually understanding what's really going on. Yeah, he's saying something (and I understand it, I guess) but he's got so much crap, perhaps he can't see the forest from the trees.

PS. Scrum == worst. methodology. name. ever

When you cut through all the gibberish

[petes_PoV]

You've got a development team. The senior members have been promoted to team leaders.

No matter how you want to spin this, or wrap it up with neologisms, it's the same old stuff, with the same old problems and (it seems) the same old organisation - just with different names. In the end you (or your team / scrum call it what you will) still has ti turn out a product. Those who help get the praise, those who hinder get the promotions :-(

Just like every development methodology before it - and no doubt, the ones to come - if you have talented people, they'll get the work done. If you have indolent people, no techniques: agile or not, will help you. Stop worrying about scrums, roles and all that malarkey - get on with the job of developing your product.

Everyone in a company has problems to overcome. How you deal with them is the olny measure of your worth.

Re:Yes, use experts as scrum masters

[Delkster]

I conclude that the top people should be the scrum masters, because if you bring in someone inexperienced to be a scrum master (i.e. a project manager), all your projects will go to pot.

I agree that a scrum master should have experience of project work, but he doesn't necessarily need to be a top developer. Also, a scrum master isn't technically just another name for a project manager. A scrum master doesn't make decisions; he's basically someone who makes sure that the team doesn't have to waste their time on unnecessary problems ("impediments") and that the whole thing doesn't break down into chaos.

Can't do your testing because of some network problem? Or you aren't exactly sure about a detail of the requirements? Bring that up in the scrum meeting and the scrum master should solve your problem so you don't have to interrupt your work because the scrum master will run the errand for you.

Did a meeting break down into an argument between two team members about an implementation detail? It's the scrum master's job to intervene and get the issue solved between the two rather than needlessly waste everyone's time in the meeting.

Got a design issue and you have to decide which approach to take? That's not up for the scrum master to decide. The decision should be made by team concensus, or if they don't have the expertise to decide, get help from an actual manager or expert from outside of the team (architect, or what you have).

I would recommend seriously reconsidering whether getting a better pipeline of events and allowing work to stretch past 'daily scrums' would be better.

I don't know exactly what you mean to say, but I think you've misunderstood something. A daily scrum is more of a status meeting. It doesn't mean that you have to switch tasks as a result of each meeting, though it would be good to have tasks divided into small enough chunks that you can usually complete them within a day or two.

Oh, for fckn, sake...

[KZigurs]

Forget all about agile, forget all about scrum and forget all about management. The only places where I have seen some good code actually being written are the places where there were no 'process', there were no 'evangelists' and it was absolutely normal for managers and devs to swap roles in who is managing who - naturally.
No process will improve on a (welcomed) shout across the room and reply coming back in 5 seconds.

It's like AD&D

[Spazmania]

It's like Dungeons and Dragons. Follow the rules too rigidly and you're so busy rolling dice that nobody has any fun.

Doesn't improve everything, but are benefits

[Webcommando]

I've lead scrum projects for a few years (actually introduced the technique to a few). It is a great tool but hardly is a silver bullet. Over time, there are tweaks needed to meet organization style and needs--including the kinds of products, release standards, regulatory environment. If you try to use as-is I think you'll find issues and ultimately fail.

I think scrum has some very nice characteristics (not necessarily unique to scrum):

- Lessons developer stress by allowing them to focus. You define the work for a sprint up-front and the developer knows their stories and can attack them as necessary. Everyone knows the stories and tasks (they are in your face..either in a tool, on a white board, stickies on the wall, whatever) and can trade or help as needed.
- Helps drive results of working software. With the sprint concept, the team is expected to demonstrate the work product each cycle (3-5 weeks). This doesn't have to be software but you have to be able to show something specific. I think this helps eliminate the month long development grinds only to find nothing works right when integrated.
- Gets the developers talking. The stand-up meeting (what is done yesterday, what is planned for today, what help is need) is very valuable to get the developers interacting. Very easy for software people to sit for long periods banging out code and banging their head against the wall. The daily meeting helps to uncover duplicate effort, solutions to problems, and allow an opportunity for senior developer to recognize where people are struggling.

Just remember: scrum isn't an excuse to code first, design later or ignore gathering detailed and real requirements (a story isn't enough).

Scrum master = Project manager!!!!!

[node159]

Scrum master = Project manager!!!!!

Scrum master is a fancy word for project manager! If people start realizing this you wouldnâ(TM)t have the shit that the poster mentioned going on. Who in their right mind would make their technical lead or an intern a project manager...