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

Re:Wrong all wrong

[eulernet]

You are so right ! In my company, we use Agile since a few years.

If you try to apply the rules exactly, it's doomed to fail.
We only apply a small subset of the rules, and only very few of them seem to work:
  - pair committing (pair programming doesn't work with experienced developers)
  - stand-up meeting (10 daily minutes to explain what we need, what we will do and what has been done)
  - project planning (we give a note to all the tasks the product management assigns us)
  - assigning tasks (before, we were assigned impossible tasks to code in the given amount of time. Agile helped us reduces the amount of stress).

What doesn't work:
  - our velocity is almost zero: mostly because pair-programming is MUCH slower than one man coding
  - the bad focus: if you focus on the code quality or on Agile methods, you lose the goal which is to code faster. We have such a focus on code quality that any simple task requires days to code. It's ridiculous.
  - all the theoretical methods: if you try to apply every new method, you'll spend your time on trying them, instead of doing real work.

From my experience, Agile methods only reduce the amount of stress, since we only work on the most important features, due to the fact that the coding is super slow.
Otherwise, I don't think these methods work.

Long standing agile developer

[intranation]

Seems to me there are a few issues here:

• The team leads as scrum masters is a conflict of interest. Managers should never be scrum masters, as often scrum masters need to go against management in order to get the team through blockers. Additionally, they can put undue ("you report to me") pressure on team members during scrum. That balance needs to be maintained;
• Scrum masters, if picked from the development team, should be rotated to avoid keeping people out of the loop; but
• Ideally they should be someone who is from a project management background. If you're doing agile a lot you'll want a dedicated scrum master. I never really bought into the idea that developers should be scrum mastersâ"they should just be trained in the right skills so they know how it works, but their core skills are unlikely to be organising people.

If your company is "doing it right" you can raise these issues in the retrospective and hope they get picked up. If they're not doing or respecting retrospectives then they're doing it wrong, and all bets are off.

Re:Agile

[wurp]

I think the best thing about Agile is TDD, but it's not the only good thing...

TDD is far better if your tests are written to emulate a user using the features they care about. That's a User Story focus, which is explicit in Agile.

TDD enables you to refactor mercilessly, which Agile points out and encourages.

Not related to TDD - Planning Poker as an estimation process gives the developers a stake in estimation, which gives them a feeling of responsibility for being done on time, which keeps them motivated to get done quickly while working their task. The actual estimate gives them a stretch goal to strive for, then the adjusted estimate (using the team's velocity) gives them a realistic goal, and lets them know when to start being worried that they're going too slow.

Personally, I find it very motivating to have a time goal for a task that I helped set, and to know both how I'm tracking against my ideal estimate and against the realistic, adjusted estimate.

In Agile, you should only be tracking completed sets of features that the end-user cares about when you estimate progress. This helps you track your real progress, as opposed to the typical "80% done" forever state you end up in with seat-of-the-pants estimates of progress.

Focusing on reasonably short sprints (usually two weeks) and strictly disallowing changing the workset during those sprints helps you stay focused on something long enough to actually get it done. It helps keep managers from fucking everything up by changing your focus every few days.

A very short, targeted "what I did, what I'm doing, and what's holding me back" meeting with only developers helps keep developers focused on getting done, lets people see when they have special knowledge that can make someone else's task easier, and keeps everyone aware of (and hopefully focused on fixing) any impediments.

Yes, most of these things are obvious, and many developers left to their own devices will mostly do them. However, having a plan that focuses on things that everyone can agree are important to do a good job is obviously better than flying "seat of the pants", and developers aren't left to their own devices - managers interfere, and finally, managers like methodologies.

Obviously, a methodology is a way to keep you doing things you think are smart. If conditions arise where the methodology tells you to do obviously wrong things (or not to do obviously right things), you diverge from the methodology. If the company sells the division you were writing some feature for on this sprint, you should probably abandon the sprint. Etc.

A methodology is not a replacement for brains, but it's a nice augmentation.