Slashdot Mirror
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.'
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.
Seems to me there are a few issues here:
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.
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.
It is impossible to pick and choose parts of Scrum or other agile methodology without understanding 120% all the interactions between those parts. The most quoted example is write a test for the feature before writing code for the feature - if that thing is cut from Scrum, the project is doomed to fail because it make all other parts of Scrum be based on unreliable, untestable, unquantifiable foundation.
I have written a thesis about this problem - almost all project that "used agile development" methods and then failed, were trying to cut too many corners and modified a developed methodology breaking it in the process.
It is like this - even a 5 year old can use a microwave, but you should be very, very certain about your electronics and physics if you go in and start modifying your microwave (to boost power or to reduce the space it takes, ...). Same with development methodologies - Scrum is a microwave, don't expect it to work safely if you remove the Faraday cage to save some space on your kitchen table.
I've seen just this very thing happen where I work. We're still recovering from the results. Not that any of those programs are necessarily bad, per sey, it's just WHO does the implementing . . . you know, the sycophant dancing-and-prancing, ass-kissing, no-real-life-work-experience so-and-soes. I once heard a executive of a high-powered engineering firm doing some contract work for us state he's "never seen an 6-sigma blackbelt that wouldn't get his ass kicked in the parking lot." I agree. Recently due to the, um, economic downturn, a new senior management team came to town. Within a few months the new management plan was obvious: ax the blackbelts: check; ax the total quality leadership program and any other "total" programs found lurking about: check; reduce the LEAN department from many to one: check; try to mitigate the damage done . . . well, that's harder to do both from the perspective of the company's employees and our customers, some of them former customers.