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.'
Re:WTF does this mean??? (Score:3, Interesting)
Despite not understanding the article, the grandparent managed to translate it into mmorpg-speak pretty darn accurately. I'm not sure what to make of that, but I thought that was remarkable.
Re:Wrong all wrong (Score:5, Interesting)
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 (Score:4, Interesting)
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.
The answer is obvious... (Score:3, Interesting)
A problem is defined by the difference between the way things are and they way you want them to be. You have not adequately defined the problem, or problems, here. This seems to be common among "Agile development" aficionados, and particularly in the case of SCRUM (which accepts as a given that the requirements are not complete before starting on the project).
The two things that usually help straighten out this type of mess: First, a business-case justification for the project. This means that if the project is not useful it isn't implemented. Need to learn how to make a good business case for a project and/or a solution? A good place to start is the book, "businessThink" by Marcum, Smith and Khalsa http://www.amazon.com/businessThink-Rules-Getting-Right%C2%96Now-Matter/dp/0471219932 [amazon.com] .
The second is as complete a list of FUNCTIONAL requirements as possible. And remember, each functional requirement is subject to the same case analysis as the whole project. (Re-read "businessThink".)
I get a sense from your post that you are not in a position to initiate any action, and your role is to criticize and whine. Don't. If you can adequately describe the difference between the way things are and the way they ought to be, then someone with authority will listen to you.
Good luck.
Re:Wrong all wrong (Score:3, Interesting)
There are always inherent risks in product development. There are always risks in hiring people to do work for you. This scrum methodology is not the only method that uses deadlines and checkpoints. I recall some of my earliest experience in IT where weekly meetings were held where people would simply state what they were working on and where they are with it while the directors and managers took notes and asked questions and was able to track progress and performance. It's simple and it works. At what point can you say a developer is not apt to do the job? That's for carefully observant leadership to determine.
From what I have read, scrum methods lend themselves to the notion of disposable production teams. "Get it done, do it fast, see you later!" They want short-term hires to come in, "work some magic" and then disappear from their payroll system when they are done. They want to reduce the "overhead" of middle management and other leadership roles.
I'm not sure when business first started to see IT as generic, interchangeable and disposable, but someone needs to inform the C-level people out there that software is NOT a bunch of Lego bricks snapped together and that good and talented people need to be maintained not only for now, but for the unforeseeable tomorrow. The methods and hierarchical structures that have evolved over centuries were no accident and should be given respect as something that works, but consumes money. The hungry greed for lower overhead processes and quicker production fails to care about the results in the product.
"Oh, if only I could get things done better by wishing harder...!"
Re:Yikes (Score:2, Interesting)
Sounds like we need a /. poll on this. Personally, I'd have to rate "Scrum" as a worse name than "Extreme Programming", though they're both way up there.
Re:Agile (Score:5, Interesting)
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.
Re:Velociraptors (Score:3, Interesting)
And a team that works together, is largely self-organizing, and doesn't deliberately screw other teams is worth its weight in gold without scrum, too.
No, you really don't. You need the other ingredients: a self-organizing team that works together and with the other groups in a company. You add scrum to that, you've got a great team. You add a few bits of scrum to that, you've got a great team. You add some standard corporate culture to that, you've got a great team. Are you seeing the pattern here?
I'm a big fan of a team following good processes (testing your work, gathering feedback, being realistic in schedules), I'm a big fan of a team being invested in their work, and I'm a big fan of open communication. Scrum argues for some of the same things, and it's good that these scrum proponents are arguing for all of these things. But you don't need a scrum master to get the good stuff, and I don't think scrum will turn a bad team into a good team - it will just turn a team that isn't doing scrum into a team that isn't doing scrum right.
Re:why use scrum in the first place (Score:4, Interesting)
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.
Re:why use scrum in the first place (Score:3, Interesting)
Re:why use scrum in the first place (Score:3, Interesting)
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.
Isn't that kinda applicable to "agile" as a whole? If you ask any agile adherent why it didn't work for project X, his immediate reply will be that "Agile is a set of principles, not a strict methodology", and that project X required some adjustment to common techniques. If there were some adjustments, then they are immediately shot down as "not in the spirit of agile". And when you ask what "the spirit" is, you get a few things that are really common sense (and that everyone is doing anyway), and a bunch of buzzwords with no well-defined meaning.
From personal experience as a developer, it seems that success or failure of the project is defined much more by the skill of developers and project manajer (the latter is really important: good devs + bad manager deliver a mediocre product at best), and that best project managers have the gut feeling on how to approach everyone particular project, without regard for or adherence to any specific methodology.