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.'
why use scrum in the first place (Score:5, Insightful)
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: (Score:2, Insightful)
Second two, scrum, bigger projects, lots of random pressure for features during a sprint, no documentation, extremely difficult to add anyone to team because everything was on unreadable post it notes. Result sprawling, unfocused and expensive projects.
To declare interest, I'm old enoug
Re:why use scrum in the first place (Score:5, Insightful)
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 (Score:5, Insightful)
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.
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:4, Insightful)
I'm not going to argue against the value of test-driven development, but lack of test-driven development doesn't doom any project. Letting bugs get out the door can doom a project, but there are many-many ways of preventing that other than compulsive unit tests.
Yes, yes, if a project is agile but modified the Holy Process as defined in some book, and then failed, the failure is because they didn't follow the process. I covered this already. However, you make clear even in this one sentence that you aren't prepared to argue the opposite - that a survey of successful agile projects will show them using scrum (or XP, or...) precisely and without modification. The danger, as you put it, comes from cutting "too many" corners.
Simple question: do you agree that scrum masters should be fired if their project fails? After all, clearly the project wasn't following scrum properly, and it's the scrum master's job to make sure they are, so clearly the job was not done. In fact, the scrum master's failure caused the failure of the entire project! So, what should be done with the scrum master of a failed project?
Re: (Score:3, Insightful)
Ahh, the ol' "It didn't work for you because *you* didn't understand it" argument. The same one trotted out by every snakeoil salesman, con-man, religious leader, and self-proclaimed expert since the dawn of time...
Re: (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 o
Re:why use scrum in the first place (Score:4, Insightful)
Excellent post. From my experience as well, snake oil is a great description.
Here's one easy test for snake oil business/engineering practices: can the concept be described just as easily with normal, everyday vocabulary as the ridiculous technobabble, buzzwords, and metaphors commonly used? If yes, then there is a good chance it is a methodology created for its own sake (and as you said, the sake of the consultants).
Example: "the x-rays show a wedge compression fracture of the C7 vertebrae" is a bit more helpful to a doctor than "looks like he broke his back!" Not snake oil. "Moving the team leader to scrum master is harmful to our velocity" - translation: "making our most experienced programmer a project manager is slowing us down" - yep, snake oil detector going off!
Re: (Score:2)
Re:why use scrum in the first place (Score:5, Funny)
Re: (Score:3, Interesting)
Scrum master = Project manager!!!!! (Score:5, Insightful)
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...
Re: (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: (Score:3, Insightful)
'I personally think that it works as presented only in env where intelligent, skilled, knowledgeable and well meaning people work,...'
So, not in the real world? ;^)
Re:why use scrum in the first place (Score:4, Insightful)
it works as presented only in env where intelligent, skilled, knowledgeable and well meaning people work
Or meaning it works rarely. And more to the point, any methodology works in these circumstances..
Hurl (Score:4, Informative)
Re:Hurl (Score:5, Funny)
I can see it now. Several years from now, a developer who has been working, doing heads down coding, doing his job, and getting the projects finished, goes for an interview...
"Have you any experience being a ScrumMaster"
"A what?"
"A ScrumMaster"
"I'm sorry, I don't play those online fantasy games"
"No, that's not what I mean"
"Oh...well, I don't play rugby either."
Wrong all wrong (Score:4, Insightful)
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 (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.
Re: (Score:3, Insightful)
Agile is not supposed to make you faster, though that is a common side affect, what it is supposed to do it make you aware of what you can and cannot do so that when things change you can manage that change and it sounds like that is exactly what it is doing for you.
Re: (Score:3, Insightful)
Doesn't improve everything, but are benefits (Score:4, Insightful)
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).
It's like AD&D (Score:5, Insightful)
It's like Dungeons and Dragons. Follow the rules too rigidly and you're so busy rolling dice that nobody has any fun.
Re: (Score:3)
But, I have been on teams where the thought of smashing the crap out another team member would have been a great idea.
Re:Wrong all wrong (Score:5, Insightful)
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.
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: (Score:2)
Yeah, but at which point can you say the developer is not apt to do the job? How many weeks and $YOURCURRENCY can you invest into that? That's why you have to make some deadlines and checkpoints in your project (iterative or not).
Hoping for the best won't do it, as you say, it is hard and a too large share of projects don't meet the expectations.
Re: (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
Re: (Score:3, Insightful)
Silly mind games? Like these:
Please take five minutes to read over this three-page requirements document, and then produce a to-the-hour precise estimate for me without taking any time at all to look at the existing code or produce an implementation plan. Once I have the estimate I will make client-commitments based on it, and hold you to it.
Or
Ok fine, do your research and take a long time to make the estimate. I will therefore expect it to be God's Holy Truth accurate, and hold you to it, even though I
"Restrictive agile"? (Score:2)
If you are particularly tied to "Scrum" as a methodology, and want to bet your house on it, then your ScrumMaster should be someone who knows Scrum inside and out. However, if your intention is to be actually agile, rather than legalistic and restrictive, though, then it's usually good advice to put someone well-respected (eg, the team lead) in the position of holding the team to account, rather than getting an outsider just because they have the right keyword ("Scrum") on their CV -- external keyword-hiri
WTF does this mean??? (Score:5, Insightful)
Jargon, people! And don't chastise me for not RTFA - there is no FA to read!
Re:WTF does this mean??? (Score:5, Informative)
And yes, you are absolutely right. I couldn't entirely understand the article either.
Re: (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: (Score:2)
I think this article made me understand wikipedia deletionists .
Re:WTF does this mean??? (Score:4, Insightful)
I recognized words that have meaning in English, but the person asking the question clearly had no intention or ability to combine those words into any language spoken by human beings.
Re: (Score:2)
I wasn't even sure "Scrum" was a real English word. Turns out it's some kind of sports metaphor for some sport we don't play around here.
If I ever make a programming methodology fad, I'll name it broomstacking, and the leaders will be called drawmasters. Or maybe malletheads and flagmen.
(Disclosure: We use Scrum where I work. It's buzzwordiness is groan-worthy, but in practice it's mostly good common sense. It's also true what the article says, that there's little reason for using your most experienced deve
Re: (Score:2, Insightful)
Re: (Score:2, Funny)
Re:WTF does this mean??? (Score:5, Funny)
Could we please get some explanatory links in here?
While this is not my area of expertise, I think I can explain. His team leaders/scrotum masters are poor leaders. They don't seem to understand flexibility. He on the other hand, he thinks he understands flexibility. And he wants an intern to be the scrotum master.
The only part that I find confusing is that interns are usually the slaves, not the masters. Somehow, this guy thinks that a new slave can suddenly become a master just like that. That, I don't think so. So I'm either misunderstanding something, or this guy is missing the bigger picture. The issue that the team lead is overburdened is probably a very real problem, that I don't doubt. But it seems to me, this anonymous poster would just be trading one problem for another. An intern doesn't have the experience. An intern doesn't have the authority. One might as very well leave the scrotum alone if there is no one there that can handle it.
Re: (Score:2)
The only part that I find confusing is that interns are usually the slaves, not the masters. Somehow, this guy thinks that a new slave can suddenly become a master just like that.
Well put!
flamebait? (Score:4, Insightful)
Re: (Score:3, Funny)
Could we please get some explanatory links in here?
Slashdot has been trolled.
In fact, the whole article is written in gay BSDM porn jargon and has nothing to do with computers or programming.
If you want to know what a ScrumMaster is: imagine a half-naked fat hairy guy in black leather with studs. I don't want to go into the details on "interns", "Agile", "principal engineers" and worst of all "waterfall development mode". Really, goatse is like a meadow of beautiful flowers compared to this.
If you misread it as ScumMaster... (Score:2)
...it all makes perfect sense.
Re: (Score:3, Insightful)
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
It reminded me of EST-speak. Psychotic ramblings...
Re: (Score:3, Funny)
It basically sounds like Scientology developed its own coding methodology. He was trying to do a sprint to burndown some backlog, but he got stuck in a process and got enturbulated, so he had to get the ScrumMaster to audit his code for engrams so he can make some big wins and move up the bridge. The best part is that under this system, you pay your boss to write code for him...
Try before you buy? (Score:5, Funny)
I wish I could try this scrum in a safe environment, I need some sort of ScrumVM.
You're missing the problem (Score:2, Informative)
Re: (Score:2, Insightful)
This here is the problem.
The scrummaster (who should have learned this in his training) is a team member who's job is to organize the meetings and help "enforce" scrum practices. The scrummaster is not the product owner who sets direction for the team. The scrummaster is just another developer on the team.
In our implementation of scrum the scrummaster's only real job is the setup the meeting announcements. He is also usually the first one to reign us in during standup to keep the meeting to keep it short
Re: (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 meeting
Re: (Score:3, Insightful)
You suggest that a person with limited or no authority - or for that matter seniority - should take responsibility for telling his more senior peers to STFU.
In theory it makes perfect sense to appoint a junior person as ScrumMaster but, as with many things, there is a difference between theory and practice.
Yes, use experts as scrum masters (Score:2)
Based on my 12+ years in the field and from reading the description of Scrum at wikipedia just now, 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.
However, I wonder if you know that scrum basically looks like a pretty framework on top of the lowest level of Capability Maturity. I would recommend seriously reconsidering whether getting a better pipeline of events and allo
Re:Yes, use experts as scrum masters (Score:4, Funny)
Well done, you've just managed to be even more confusing than the original article.
Re:Yes, use experts as scrum masters (Score:5, Insightful)
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.
DTFT! (Define That Fucking Term!) (Score:2)
Seriously, somebody add some wiki-links to the story posted here... Those of us that code for a living as contractors / corporate drones have little to no idea what the fuck you are talking about.
Guessing by context, I'd say that having your best coders become code-overlords who don't actually write code anymore is a bad idea.
Finding someone with people skills and management experience and appointing them as co-director of a project, with an uber-coder as his fellow co-director, is the way to go. Let
Re: (Score:2)
This is not a wiki.
Re: (Score:3, Insightful)
Velociraptors (Score:5, Insightful)
"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 (Score:5, Insightful)
"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.
Re: (Score:2)
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.
I believe the latter of those in particular gives away pretty bad organizational problems, scrum or no. They would probably manifest themselves just in a different way if you tried to do things different on the surface.
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!
Yeah, that can be a problem. The thing is, scrum isn't a magic incantation that will make your projects and teams work just by uttering it. You actually have to do it more or less properly for it to work. Your organization clearly isn't scrum-compatible if management is coming and adding stuf
Re: (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
Re: (Score:3, Insightful)
. 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!
You are aware of how strongly that is discouraged in scrum, right? Right? Your final option is stop the sprint and plan a new one with the new stuff prioritised in. (management gets to chose the priorities). If management consistently cannot business priorities stable until the end of sprints, well then your sprints are too long
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: (Score:2)
"this poor implementation of Agile development is harmful to our velocity"
Just sprinkle with synergy and you'll be okay. But don't forget to execute!
"Our mis-implementation of Agile includes.." (Score:5, Funny)
"Our mis-implementation of Agile includes.." ..is a pretty good idea for a ThinkGeek t-shirt.
Re: (Score:3, Funny)
"... Lotus Notes and a machine gun. It is the finest available."
Sorry, I just couldn't help myself.
scrum, isn't that a rugby term? (Score:2, Funny)
For all the players putting their arms around eachother and kicking everyone else in the shins. At least that sounds like what the poster was talking about.
Re: (Score:2)
Yep, and bite each other's ears, punch each other's noses, etc..
(Also, I hope whoever modded you troll gets punished in m2).
Yikes (Score:3, Funny)
"...seem to be completely unaware that this poor implementation of Agile development is harmful to our velocity"
Oh, for fucks sake...
I'll say this once:
Chop the little pointy horns of hair growing out of the side of your head, and get the fuck back to writing code, you stupid monkey.
Re:Yikes (Score:5, Insightful)
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
Re: (Score:3, Insightful)
shhh! There are lots of jobs at stake here. The 'methodology of the month' is little different from the patent medicine scams of 100 years ago. Just smile and be glad you passed on that nice juicy worm. Next time, it might be you dangling from a hook.
!rugby (Score:5, Funny)
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 o
Re: (Score:2, Insightful)
"Governance" what the hell does that mean? Does every project need a governor to slow the velocity??? Or perhaps it means a governor, as in the executive branch of a state. From what I can tell this is another nebulous peace of corporate jargon managers use to justify their existence without anyone really understanding what the term means or everyone has a different understanding of the meaning because it is so vague.
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: (Score:3, Funny)
Bingo, sir. [dilbert.com]
Re: (Score:3, Insightful)
[T]his post is crazy off the wall nuts.
There. Fixed that for ya. That should have been the entirety if your post.
This article/post contains the most ridiculous joke-like conglomeration of pointlessly obscure buzzword phrases that I have ever seen in my ENTIRE LIFE. This includes all of the actual jokes I've heard where someone has purposefully tried to put together as many idiotic buzzwords as possible for comedic effect. This post tops them all and the poster is actually serious and works in an apparently serious section of the computing indust
Re: (Score:2)
Agile (Score:5, Insightful)
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/ [globalnerdy.com]
http://www.flickr.com/photos/cote/63914774/ [flickr.com]
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.
What the hell? (Score:4, Funny)
Re:What the hell? (Score:4, Insightful)
What the Fuck is This Shit? (Score:2)
How about determining what you need to accomplish, figuring out what bits need to be done to make that happen, have people do those bits, and WRITE SOME CODE?
Playing rugby is even worse than playing WoW - at least with WoW you have computers that 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.
Re: (Score:2)
He admitted to that in the story. Why he expects to be able to fix it by rearranging a few people is beyond me.
If your fail is getting hit by a train while skateboarding on train tracks, changing your olly technique is not going to solve the problem.
Re: (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
When you cut through all the gibberish (Score:5, Insightful)
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.
ScrumMaster? Isn't that an official WankWord? (Score:2)
ref: http://steve-yegge.blogspot.com/2007/09/ten-tips-for-slightly-less-awful-resume.html [blogspot.com]
I think you and your team should start focusing on developing software for the client you have to write the software for, i.o.w. back to square 1 of Software Engineering. You and your team seem to have moved yourselves into an organizational mess which takes more time to manage than the actual software development.
Mind you, your client doesn't give a hoot HOW you created the software, which language it is written in, or
Stacked slang (Score:3, Insightful)
I had to do deeper background research just to read the article and have it make any sense.
My flash impression was that Agile and Scrum were products of some sort and I was also a bit confused by the name as I have no real knowledge of rugby and never had any familiarity with the term before now. Some googling led me to some references that explained a lot of things but left more questions... "pigs"? Why? "Because their bacon is on the line!" What the hell?! "Bacon" meaning what? Their asses? Why can't people simply say what they mean? Are they so bored with their language that they have to play such games? Learn a foreign language for god's sake! Stop twisting and convoluting a standard and common language to the point that outsiders can't know what is being discussed. A little slang here and there can be forgiven as context typically lends and hand in assisting people to understand what is meant. But slang upon slang mixed with highly regional sports terminology? I suspect if American football terms were used instead, it would be perfectly understandable for people like me, but to the rest of the world would be just as meaningless and confusing.
The process itself is confusing as it departs from natural hierarchical management structures that have existed throughout the history of animal behavior and asserts the notion of a team sport, which is well known for its danger and potential for injury. I'm beginning to see why more modern software is buggier than older software. With so much focus on "completion" over careful engineering, a lot of details get missed along the way. I wonder if the people who support these methods would feel okay if their next car was patched together using bailing wire and duct tape?
Buzzword Bingo (Score:4, Insightful)
Oh, for fckn, sake... (Score:5, Insightful)
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.
I thought it was common knowledge (Score:2)
Everyone knows that engineers make lousy rugby players...
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: (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 imp
question... (Score:3, Funny)
Did it impact your speed or direction?
Agile, Scrum and fashion sense (Score:2)
What is amazing to me is that some folks actually think that applying one methodology over another is the be all fix all for a bad development team, poor work habits, and/or poor management. The lack of a plan can't be fixed with Agile practices, although agile can overcome a poor plan. Agile is hot right now, just like capri pants were a few years ago. It's fashionable.
A lot of developers love it because they hate writing documentation and think anyone that looks at their code should be immediately enl
The Mythical Man Month anyone? (Score:3, Insightful)
My boss, one of the best developers on my team, now has about 1/4 to 1/8 of the time he used to have to write code. I've found that I've had to step it up and take charge of a lot more work (which has been a great growing experience for me) since he's going to meetings every 30 min. to an hour.
All I can say is that some people seriously need to read The Mythical Man Month [amazon.com].
On a somewhat of a side note, I think too many institutions (college or trade) simply don't effectively teach (or don't teach at all) industry best practices such as:
-source control - every project you do in school should have to use source control
-build scripts - rather than turning in a binary, graders should checkout your code from your source control and be able to build and/or run it in one step
-bug fixing - project deadlines should be in phases where you are given a certain number of times you can have your program reviewed by others (TA's or other students) and bugs submitted against your, or your team's, bug database
-team work - once you get past the weeder courses a lot more work should be team work. If you are having your students use source control and a bug database, the graders and professor can easily see who did what and what the dynamics of the team were (if any). I'd say you could even go further (if it logistically made sense) and tell students to use an email system for the class for communication with their team about the project. Then these emails could be part of the grade since they are being graded on teamwork. Plus, having teams would mean projects could be bigger and more rewarding (ie: fulfilling to see run)
-documentation - for team projects, provide a wiki for each team to document what they are doing and communicate
Universities or trade schools are doing their graduates a disservice by sending them into the real worlds without experience in these areas.
No love for Agile and scrum on slashdot? (Score:4, Insightful)
I'm not exactly feeling a lot of love for scrum and agile in these comments. Agile was created to manage change in large software projects. So if you don't use agile methods, what do you use on large projects - some kind of waterfall process? Prince2? Good old "sit down and start coding"? How does that work for you? What is the bug rate? What percentage of these projects actually make it into production?
Also, when did the slashdot crowd become so aggressively ignorant, hostile to new ideas?
Re: (Score:2)
PS I need a new job :(
Sounds like that, unfortunately.
Scrum where management doesn't actually understand a thing about scrum just won't work, at least without sacrificing your sanity -- and the pattern seems to be unfortunately common. (Not based on experience but on stories heard.)
Re: (Score:3, Informative)
Meanwhile all the other members of his side of the scrum, try surreptitiously to beat up the other team - under cover o