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

[hughbar]

Yes agree...I took the taste test in a large UK organisation that does broadcasting, three web projects. First small group, boss + traditional focus, result, something quite difficult delivered in a seven week deadline,

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 enough to have suffered under waterfall and that doesn't do it in the modern world either, but bad agile is actually a lot worse because it's unmanaged and undocumented.

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

[BountyX]

Keep teams small and independent with clear direction and goals. Release early, release often and of course, allow for easy peer review and contributing.

Re:why use scrum in the first place

[mh1997]

Too bad your company isn't into wrongly implementing total quality leadership or you don't have a few blackbelts to incorrectly implement LEAN. That would set you guys straight.

Re:why use scrum in the first place

[umghhh]

have you attended the course you would have known that it is not coding methodology. The course that my company sent me to was about managing the projects and the world methodology was forbidden by the course's chief master boss. I must admit that parts of it were very interesting and partially confirming what I have learned with my own sweat, there was a lot of project management techniques that I should have known before but never had time to learn, a lot of ways how to work in a team etc. There were also examples of big companies that use the scrum way. I personally think that it works as presented only in env where intelligent, skilled, knowledgeable and well meaning people work, it will not work where problems already arrive at basic definitions of even at command of used language.

OTOH the actual scrum in essence is just the time boxes, sprints, backlogs, scrum masters and all this such. Whether this is better than properly organized project I do not know but to me it looks like a production line and that is I met once in my life and I hated it so much that this was a huge motivation to finish university and become an engineer instead of production line worker. OC this is all sold to us as empowering, self-organizing etc but reality is that this is just another way of put a whip to developer's arse. They also spice it all up with some religious like zeal which I dislike.

Bottom line is that there is no silver bullet and companies that believe in it are just wasting the money (avoiding waste is one of scrum principles apparently). What the actual engineers do is to do their work despite efforts of management to screw (scrum???) it.

Funny part of the training was when the trainer mentioned the companies where he introduced scrum before. One of them was our competitor that collapsed AFTER scrum was introduced there.

Re:why use scrum in the first place

[Anonymous Coward]

There are a lot of cretins posting in this thread. The above post is a shining beacon of non stupidity.

A couple of point. ScrumMaster is not a team lead. They are a new role crossing a dash of coach with a large serving of facilitator. ScrumMaster is NOT a low value role, but it is a different role.

Full time, good team facilitators/ScrumMasters are essential and will be drawn from the entire department. Dev, QA, testing etc. What matters is that they are a people person with high integrity. Which is rarer then you would think! Coding ability is irrevelant. It sound like your org has mapped Scrum rather than actually changed to use it (as everyone recommends)

sm is not an intern role. It is not a paperwork role, it is a high value servant leader role that requires the aforementioned skill set.

Ignore every other post in this thread - most people are ignorant and blisteringly stupid.

Re:why use scrum in the first place

[Mikkeles]

'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

[ClosedSource]

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

Whatever you think of the usefulness of scrum, it is not by any stretch of the imagination a "coding methodology".

Re:why use scrum in the first place

[yabos]

Yep, I work in a place that does Agile crap and we waste 15-30 minutes every morning with this scrum BS. It does not help anything at all. I guess I should not complain that I get paid 1/2 hr for doing nothing.

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.

Re:why use scrum in the first place

[Unequivocal]

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

Re:why use scrum in the first place

[Dastardly]

I think it works if you understand what it is and what it is not. Scrum is more about project management than coding practices. It is primarily focused on addressing the fact that the Waterfall methodology is build on information the is mostly wrong. Yet, assumes that information is right. Scrum and Agile in general is about accepting that the information is bad and dealing with it. Man-hour estimates at the beginning of a project are always wrong. Schedules at the beginning of a project are always wrong. Requirements always change from what is documented.

Now the above can and should be combined with other Agile practices like Pair programming, test driven development, continuous integration and test, etc... for the coding side. And, the thing that I would not be surprised that many organizations miss which is the retrospective. My team does two week sprints and at the end of every two weeks we have to look at what worked and what did not. And, so over time we can accumulate a process that works for us.

Bringing this around to the OPs question we have actually switched who handles the Scrum Master role a couple of times trying to figure out what would work better. And, I am not sure that we have settled on the "right" solution, yet.

Re:why use scrum in the first place

[carnivore302]

I couldn't agree with you more. All these nonsensical debates about methodologies... every year somebody invents a new buzzword. I can't help wondering if this is due to the rent-a-coder firms that need to promote their developers with lengthy but empty resumes.

Just code the damn software, check with your client and repeat.

Mark.

Re:why use scrum in the first place

[Cable]

I agree often in my work teams I had to write documentation for programs that didn't have it and do the test cases/proofs myself. Many of my coworkers refused to do such things and it made the job harder. Not only that but they would skip the analysis and design phase and just start coding without a plan or clue.

Management had encouraged cutting corners to get programs done faster, but it would often come back to bite us later.

I often had to rewrite code that someone else wrote and many would leave the company because of the level of difficulty and coworkers cutting corners. I was able to handle it and got part of the legacy software development in cleaning up after other programmers.

Re:why use scrum in the first place

[AigariusDebian]

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

[AigariusDebian]

The thing is that half an hour a day can save a project from slip-ups that can take years to recover from.

Re:why use scrum in the first place

[Matthew Weigel]

...if [test-driven development] is cut from Scrum, the project is doomed to fail...

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.

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.

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:why use scrum in the first place

[gmrath]

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.

Re:why use scrum in the first place

[daVinci1980]

It could, or it could not.

The question is whether it will save you at least the overhead, where the overhead is a scrum master + 6.25% of the total project. Let's call that 10% total overhead.

If SCRUM doesn't save you 10%, it wasn't worth it--you should've used something else or nothing at all.

Re:why use scrum in the first place

[shutdown -p now]

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.

Re:why use scrum in the first place

[Dahamma]

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:why use scrum in the first place

[Hognoxious]

That's the thing - you can have total and utter chaos but just claim it's agile. Anyone who has concerns "doesn't get it" or is "old fashioned". I'm not saying everything agile is bad, but sometimes there's a whiff of a cult around it.

Re:why use scrum in the first place

[Abcd1234]

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:why use scrum in the first place

[Keynan]

The problem with scrum (and agile in general) is the misconception. Too many people both users and critics don't bother to follow it properly. It's seen as cowboy coding when in fact done properly both scrum and agile are very disciplined methodologies.

More specific to scrum though is that things like "good documentation and good test cases/proofs" were taken out of scrum because it was hard to sell in Scrums infancy and are now only associated with XP. Which is why your always told to do both XP & Scrum

In all fairness though GP is write about the SM certification program. It is just a pirimid scam

Re:why use scrum in the first place

[ScrewMaster]

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.

Kinda like social workers.

Re:why use scrum in the first place

[ScrewMaster]

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

Personally, I find that it works best if you only use Wrigley's Spearmint Scrum.

Re:why use scrum in the first place

[ScrewMaster]

Not that any of those programs are necessarily bad, per sey

Stick to English, fucktard.

Listen to Mr. Perfect. You tend to your own knitting.

Re:why use scrum in the first place

[Jewbird]

If you're not doing calisthenics and singing company songs, you're not doing it right.

Re:why use scrum in the first place

[GunFodder]

That sounds like a project manager to me - an experienced professional with leadership experience that doesn't participate in the day-to-day work of the development team. The best sprints I have participated in have been facilitated by project managers.

Re:why use scrum in the first place

[Matthew Weigel]

So then what's the product owner? How many different titles and concurrent positions need to be held by facilitators at once?

Re:why use scrum in the first place

[angel'o'sphere]

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

Scrum does not even have the idea that you write your test first ^^

The main problem about this thread is: the original author / poster had questions. ALL AWNSERS down to yours, especially all that got modded up, show that their authors don't know what Scrum is. Nevertheless half are bashing it and most important: no one is giving usefull awnsers to the guy who asked

angel'o'sphere

Re:why use scrum in the first place

[angel'o'sphere]

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?

This makes no sense.

If a project fails, everyone involved in the project has his part in the cause for failure. It is not the "project of the ScrumMaster" so it is not his project.

The ScrumMaster is not a replacement for a Project Manager, a Lead Developer, a Chief Engineer or a Manager or the Developers or the Customer or the Architect or Contractors ....

The ScrumMasters responsibility is to support the Organization to implement Scrum, thats all.

The ScrumMaster is not responsible for Test First or Test Driven Development, he is not responsible to implement XP, he is not responsible if the back ups of the configuration management system gets lost (or for the introduction of a configuration management system).

The ScrumMaster is not responsible for introducing nightly builds, for crafting a build system that does nightly builds, for continuous integration etc.

The ScrumMaster is definitely not responsible if a project is over time or over budget (as you suggested in a different post earlier), he is however responsible to clearly show that this is the case very early in the development.

To awnser the questions of the original asker:
a) it might be more appropriated if the ScrumMaster is not from your organization
b) if your best man does not the job he can best anymore ... then you either need a replacement for his old job or somehow make him aware of it
c) water fall model or not, that has again nothing to do with Scrum! The process how you in fact develop software is not touched at all by Scrum! Scrum only wants you to have a clear idea what your next iteration will deliver! For that you have the sprint and the sprint backlog. But I don't want to explain Scrum here ....

I assume your organization makes several mistakes at once:

• Starting a new project
• Starting a new "Approach" (Scrum in this case)
• Starting a new Development Process (Scrum is not really a Development Process, it is an Organizational Process) like Test First or what ever
• Probably using new tools / architectures / frameworks

Haha, I said mistakes ... every part in it self is probably a right thing, but doing to many of them simultaneously is a mistake!

It is always very hard to change everything at once. You should keep everything as is during the first 3 or 4 iterations. Only focus on Scrum during the start, don't change anything else of what your software development team is doing during normal old school development! Let them develop just as they do since years!

If you don't do that, then your first Scrum leaded development iterations wont reflect the effect of Scrum, but they will reflect all the other introduced changes someone (probably the ScrumMaster! And if so he indeed failed!) introduced concurrently with Scrum.

Your questions:
But I would like to put the questions to Slashdotters as to whether they have seen these same transitional difficulties, ...
Yes, I could say dozens of times ....

what the results have been at their respective companies, ...
In fact lot of companies don't have the culture for Scrum or XP on one side because of a common lack of ability to work in teams as "friends".
As stated above, introducing Scrum or XP often is the last attempt to introduce some "structure" into development after all other attempts have failed. That mea

Re:why use scrum in the first place

[angel'o'sphere]

The product owner is the customer! Or more precisely: it is the person on the side of the customer who is responsible for defining what the product should be, what the features of the product should be.

angel'o'sphere

Re:why use scrum in the first place

[Matthew Weigel]

The ScrumMasters responsibility is to support the Organization to implement Scrum, thats all.

Right, of course. They are, as scrummasters say, involved in the project. They aren't fully committed the way the developers are, the ones who could lose their jobs if the project goes south.

And that's where the snake oil alarms go off; the scrummaster is someone that, according to scrum, is committed to the project in a visceral way. It's just not true, and it's dishonest right around the part where the scrum evangelist's job is on the line.

As for my own situation... I'm barely affected by scrum at all; supposedly we do it, but I can get my job done without caring what process is being used. I notice that we have more meetings now than when I wasn't in an organization doing scrum, and that interrupts my programming time; but overall it doesn't have much noticeable effect of any kind.

Scrum doesn't slow our project down, it doesn't accelerate it; it has zero effect. And that's the most damning thing - scrum doesn't matter. If it doesn't matter, why bother buying books, going through training, hiring more people... why spend all that money?

Re:why use scrum in the first place

[Fulcrum of Evil]

Well, if you do it half assed the first time, it's reasonable to conclude that you probably didn't understand the implications of removing parts of the process. What's wrong with trying scrum on a small project first before trying to switch it around? You wouldn't ease into driving a stick shift by leaving clutch usage to the second week, would you?

Re:why use scrum in the first place

[Dystopian Rebel]

understanding 120% all the interactions between those parts

I have written a thesis about this problem

*Do not* have the math reviewed by an English major!

Hurl

[Anonymous Coward]

Goddamn wankfest of a post.

Re:Hurl

[S-4'N3]

Agreed. This thread is nothing but an opportunity for developers to whine about the 'poor working conditions' of their jobs. Of course, that isn't going to stop me from reading it.

Re:Hurl

[jdgeorge]

Gah! "Insightful", not "Informative"!

I agree, anyway. the poster is obviously because his organization's development environment is changing, but is stating that the part that offends him is that "highly paid developers" are acting as Scrum masters.

The "question" to Slashdot can be paraphrased as "don't you agree that my whining is justified?" Suck it up and write some darn code!

Re:Hurl

[sycodon]

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

Re:Hurl

[Anonymous Coward]

People who do their job aren't valued by management.

The ones who are valued are those who can do nothing themselves - they are so clueless that they need everyone else's help to get a task completed.

This double-whammy makes them shine in the eyes of management - (a) they are on the manger's level (b) they are motivators - their cluelessness coupled with the good intentions of those around them (sorry, *their* motivational skills) means that they get - things - done.

Re:Hurl

[Connie_Lingus]

very good...my thoughts exactly.

thxs for the LOL.

Re:Hurl

[ceoyoyo]

Excellent. You're hired. You're going to have to learn rugby though.

Re:Hurl

[Ihmhi]

Yeah, I thought that too at first... I imagined Bill Gates in rugby shorts.

Excuse me while I wash out my mind's eye with bleach.

Re:Hurl

[Fulcrum of Evil]

I'd take a pay cut if it meant playing rugby with BG. Of course, he'd be on the other team.

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.

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.

Re:Wrong all wrong

[Jurily]

instead of forcing them to play silly mind games.

That's why I like Joel's approach.

Re:Wrong all wrong

[buchner.johannes]

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:Wrong all wrong

[Anonymous Cowherd]

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:Wrong all wrong

[erroneus]

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:Wrong all wrong

[mellon]

That's a great attitude for them to have if you want to be an employee who's stuck doing the same thing your whole career. Some people are very comfortable with that. The problem is that it tends to work poorly both for the employer and for the employee: the employer has a project that will be difficult to recover if the programmer gets hit by a truck, and the programmer stagnates, so that when, as inevitably happens, the job goes away despite being "stable," he or she is unable to easily land a new job.

My personal experience of this is that A-level programmers are great, and valuable, and worth having around, but they are not the only kind of programmer that is useful. A detail-oriented programmer who's not a real hotshot coder can be just as helpful. Programmers who go off and do what you asked them to, but need to be re-cued every day, can get a lot of work done, and can produce a quality product, as long as there is at least one good architect on the project who's willing to work with a team.

So in a team where you have a bunch of hotshots, scrum may not be the best idea. But in a team where you have a lot of careful plodders and a good architect, scrum is actually a very good idea.

Re:Wrong all wrong

[omb]

Absolutely correct, and in addition, the difference between best and average is __MUCH__ wider than in any other activity I know, except possibly Pure mathematics, and can be a factor of 50+ x.

Most methodologies attract only PHBs and MBAs.

Re:Wrong all wrong

[lastchance_000]

Not to mention that improved code quality means less time spent fixing things in the future, either because bugs were avoided, or because the code is easier to maintain.

Re:Wrong all wrong

[sycodon]

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

[Anonymous Coward]

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 will be changing the requirements during development.

Or

Bob produced this estimate. But he is on vacation for two weeks, so you will have to implement it. He didn't write up any implementation guidelines or anything, but I am sure you will be able to implement what he had in mind, and I am holding you to the deadline we set for him.

Or

This problem seems pretty simple from the high-level view. Therefore, I think your estimate is too big. I think we can beat it if we code aggressively. So do this, but make sure that coding aggressively doesn't introduce any new bugs. If it does, I will expect you to fix those on your own time.

These are some problems agile is designed to solve. In my opinion, the reason so many people do agile incorrectly is not because agile itself is fundamentally misguided, but because it requires a higher level of abstract thought and critical thinking than most people are capable of. People think they understand it, but they don't, so they do it wrong, and it makes things worse, so they give up on agile. I know it makes me sound like an erudite elitist. I make no apologies. Agile is not for the feint-of-mind.

Re:Wrong all wrong

[eulernet]

Not to mention that improved code quality means less time spent fixing things in the future, either because bugs were avoided, or because the code is easier to maintain.

In theory, yes.
But in practice, no.

We started with a lot of legacy code, and parts of this code are refactored from time to time.
However, the base code had no unit test at all, and it's impossible to write tests afterwards.

Anyway, we have now a lot of functional tests, so we are able to find issues immediately.
The only downside is that these automated tests take 4 hours.

Re:Wrong all wrong

[sitarah]

I have never seen Scrum done correctly anywhere either. It's usually half-assed in a way that completely misses the point. The people that espouse it seem a touch arrogant, too -- my favorite was an article from the late Dr Dobbs magazine that said "If your Scrum/Agile approach failed, it was just because you were doing it wrong." What? Your software development process fits everything perfectly, all the time? Yeah, kill it with fire.

These processes seem to be made for the lowest common denominator; lazy or inept coders who need a lot of hand-holding. The only good side is that this gives startups quite the leg up -- they are less likely to hire the lazy, inept people, can get rid of them easier, and can code without the overhead of stand-up meetings, scrummasters, and sprints. As long as corporations are bogged down with useless meetings and an army of crappy coders, there's an opening to steal a little bit of their lunch.

Re:Wrong all wrong

[DragonWriter]

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.

I think its more that Agile, Scrum, and Ruby are all things that a few people were incredibly successful with, and that a bunch of other people decided to use them as magical talismans without bothering to learn anything about them, producing epic fails.

Agile, in particular, I've seen frequently used as a buzzword and claim and excuse by firms that are, in fact, doing nothing that even vaguely resembles any Agile methodology.

Re:Wrong all wrong

[DragonWriter]

Instead, let's recognise the truth: development is hard, and the best programmers are orders of magnitude better than the worst.

Only with a good process (some of which can be generalized, and some of which has to be specific to the task). With a bad enough development methodology, the best programmers can be just as bad as the worst at producing value.

Re:Wrong all wrong

[Crimsonjade]

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

Strange, I thought the goal was to break things to small, manageable tasks. If any simple task requires days to code, regardless of the level of code quality, then your tasks are too large. I follow Cockburn's approach to development: the use case breaks the problem down into very small chunks that I can then implement. In regards to project timelines and code quality: Using shortcuts and hacks may get the initial part of the project moving along, but it will come to bite you later on when there are additional requirements and bugs.

Re:Wrong all wrong

[pclminion]

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

I suppose it depends on your product, but I've never considered the velocity to be where the value of the method lies. Instead it is the order of magnitude increase in code quality that appeals to me. I've seen the process work miracles in circumstances where there was a tight deadline and a requirement for high quality. But in our case, slipping the deadline is preferable to releasing incompletely tested code.

Your natural velocity (rate of backlog difficulty execution per team member) depends mostly on the team itself, not the little idiosyncracies of your process. If your process is getting in the way it should be changed, but assuming the process is at fault is a lot like assuming you've found a compiler bug -- it could happen, but it's usually something else.

Re:Wrong all wrong

[Crimsonjade]

The gp is talking about code quality and you are countering his argument with an anecdote on testing? Code quality means people are not doing things that make the code impossible/very difficult to maintain. Things like keeping business logic separate from the view logic.

In regards to your post: Why can't you run the entire test suite each evening if it takes that long? If you are developing some portion of the code, then run a subset of tests that directly relate to that code before you commit. Doesn't seem like a real problem.

Re:Wrong all wrong

[Dastardly]

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

Agile and Scrum don't work with the above. One of the main principles is a stable development team. If you take short term hires try to assemble them into a Scrum team, then blow that team up and start over again you are screwed. (Scrum buzzords follow) You then have to rediscover velocity every time, you have to rediscover planning poker, and you never accumulate the experience and team trust that allows one to just rely on people to know what needs to be done and to brig problems to the attention of the group and leadership when needed.

It does reduce the overhead of middle management roles in particular Project Managers who are constantly scrambling around preparing schedules that end up not fitting reality, presentation about how everything is moving according to the fake schedule, and finally shortly before code delivery telling management why the due date will not be met, and giving the next fake delivery date.

Re:Wrong all wrong

[generica1]

instead of forcing them to play silly mind games.

That's why I like Joel's approach.

Thanks for posting that link. Much better to read Joel's tips than this retarded "article".

Re:Wrong all wrong

[eulernet]

Yes, it's one of the goals.

Of course, when a task is too large, we break it in smaller tasks.
However, we don't count in days of work, because it's always wrong.
Instead, we rate every task with a difficulty score, a la Fibonacci (1,2,3,5,8,13,etc...)
We found that it's impossible to finish a 13 in 3 weeks, so now, all the tasks are below 13.
But even a 8 could require weeks of work.
As I posted in another thread, it's because we use a large legacy based code, with no unit tests.
Also, our code is a mix of VB.NET, XSL, Javascript, etc...
A small task could require to change a lot of files.

Adding Agility in an existing project takes a lot of efforts.
And starting a project with agile methodology requires that you have an experienced team knowing how to work with it (otherwise you'll encounter all kinds of problems).
Since it's my first project (with more than one year of using strict Agile), I doubt our current agile process is efficient.

It may also be due our architect, who concentrates too much on quality instead of progressing (did you ever rewrite code 3 times, even though the first one worked ?).

I guess you should take whatever works with your team, instead of trying to force the theoretical methods.
I have read about Lean Software (where you put the minimal effort to get the maximal result, and identify bottlenecks), and it seems more suited than our current agile process.

Re:Wrong all wrong

[Timothy Brownawell]

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.

Software is not yet a bunch of Lego bricks you can snap together, but I think it's definitely moving in that direction. Some of it's there already, like *nix shellutils.

Re:Wrong all wrong

[AigariusDebian]

You fail at understanding then - you are trying out a jet plane, but decide to take of its wings, elerons and the landing gear and then you complain about having problems. You can not pick and choose parts of Scrum - they are interdependent in many soft ways.

Like pair programming is essential for Scrum - it is essential for writing good test before the code, live crosschecking of the code, live design validation (the coder is so deep in the code, that he often forgets the larger picture and he doesn't have empty brain capacity to think about alternative solutions), cross-motivation, cross-training of people (if I have little knowledge of SQL and someone else in the team is a god and we two write some SQL-heavy part together with me coding and him sayingme what to write and why, then I can be confident to modify that part of the code later on even without that person present).

Also in Agile you only write as much code as needed to pass the tests. If you need more later - you refactor depending on the tests to show you that the refactored code works.

You need to implement all the parts of a well developed and tested Agile methodology to really get it going. Picking parts might give you partial benefits, but might also fail spectacularly.

Re:Wrong all wrong

[eulernet]

Like pair programming is essential for Scrum - it is essential for writing good test before the code, live crosschecking of the code

snip

No, I understand the whole method.

Basically, you are telling me that it works fine if you are in an ideal environment, which never happens in reality.

Of course, if I don't think that I'm able to code something, I ask for help, but I don't see why the Scrumm process is so much complicated.

Basically, what you are saying is that if you have a good team that wants to play the Agile game, everything will be fine.
Frankly, when you have a team that really wants to finish a product (I mean: very motivated), you don't have to use all the Scrumm machinery.

But I agree that there are some good tricks in Agile, and if I work in a non agile team, I'll probably push to include some of the agile processes.

At my job, there is a guy that reads every book about agility, but this doesn't change the fact that we are f**king slow because of HIM.

In theory, agile methodology will make our work so enjoyable that every coder will be happy to work. Doesn't that sound like the communist utopia for you ?

Frankly, it all depends on the people that take the decisions.
If you have a dickhead in your team, you are doomed.

I think agile methods will continue to evolve and become simpler.

What prevents agile methodology to definitely fail now is that people interested in this method are people who are willing to change.
Once agility will be common, we'll have psychorigid people applying this method, and all the problems I've explained in my posts here will surface.

Re:Wrong all wrong

[curmudgeon kate]

How about retrospectives? I have a suspicion your team either isn't doing them, or they also go in the "doesn't work" column for you.

Re:Wrong all wrong

[daVinci1980]

There are companies that do this. I'm fortunate enough to work for one.

Re:Wrong all wrong

[eulernet]

We are also doing retrospectives.

Some things work fine, some don't.

We also have a low velocity because we work on prototypes, which are not counted in it.

For us, a task noted 1 means that it's easy to do.
It may require several days to finish, but it's counted as 1 point in the iteration (we have 3 weeks iterations, and did some successful tests with 2 weeks iterations).

Our prototypes are not meant to be finished, so they don't have a note, and thus, at the end of the iteration, we have a nice score of 0 for them.

Re:Wrong all wrong

[wrook]

It is true that the best programmers are at least an order of magnitude better than the worst. I've had programmers on my team who couldn't write more than 100 lines of code in a year (and you'd have to throw away those 100 lines). I've had programmers on my team that are so beligerant and incompetant that their net contribution is negative (they steal time from others). Clearly we want to avoid those people.

But a team of the best people does not make the best team. The best team is composed of a few veterans with good communication skills, a few superstars, a few dependable work horses and a few rookies. The best team isn't assembled, it is developed over time. The individuals on the team are trained individually to exceed what they can do now. And the team itself is developed to improve its chemistry.

There are many methods that helpful. There are more that are unhelpful. You are correct to say that any given set of methods, indeed any methodology that chooses those methods doesn't create success. The team creates success. But to imply that creating a successful team is composed strictly of picking talented personnel is simply wrong.

Helping individuals improve their skills, helping them pick or modify methods to work better with each other, moving people in and out of the team based on their chemistry with others rather than just their skill level -- this will create successful teams.

In sports this role is called a coach, and it's different from a manager. We need coaches -- good coaches that are specifically trained to build successful teams. The original complaint talks about making senior developers Scrum masters. I agree that this is a good way to fail.

Re:Wrong all wrong

[Hognoxious]

Some software is like Lego. The problem is that people are change resistant, and every business thinks its accumulated pile of tiny ideosyncracies are the fruit of pure genius. This bit's a bit different to what we're used to ... can't you just just file it down a little?

Before you know it, you're carving your own bricks. You've solved the make/buy dilemma by doing both.

Re:Wrong all wrong

[ITgrrrl]

I see no direct mention of test driven development here. This speeds up development ultimately by reducing errors. BTW - I've seen paired programming work best as an 'apprenticeship' for newly hatched academic programmers or an experienced one learning a new language or framework from another who's already adept.

Re:Wrong all wrong

[Fulcrum of Evil]

In our company we're doing an agile project. Only problem is:

• In addition to the project work, you have bugs to fix, usually with assigned releases
• every two weeks, we pick a new pair of people to deal with the shit random work that distracts the hell out of us (used to be worse - spread the shit around and bother anyone you can find whenever something bad happened. Spent over half our time on this crap)
• I'm the lead on the project, so when I'm also the shit worker, I get two jobs, because people still ask for guidance and i have design docs that need done.

I really do wonder if it's supposed to work this way.

Re:Wrong all wrong

[eulernet]

• every two weeks, we pick a new pair of people to deal with the shit random work that distracts the hell out of us (used to be worse - spread the shit around and bother anyone you can find whenever something bad happened. Spent over half our time on this crap)
• I'm the lead on the project, so when I'm also the shit worker, I get two jobs, because people still ask for guidance and i have design docs that need done.

Bugs to fix are unavoidable.
We use a table where we place post-its.
Every post-it is a task, and a task is either a bug or a new feature.

When you have some random work, it would be better to have one people assigned to creating a task.
Place the tasks by order of priority from the top to the bottom on your table.

What has been successful is to use the standup meeting to include people that are not working directly on the project, so that they realize what we are doing and so they could ask for help.
Everybody speaks in less than one minute, and we are able to solve problems before they become too big (we have 10 people, so a meeting takes from 10 to 15 minutes, before going to lunch).

However, it seems that you have several roles, since you cannot both code and write docs.
In theory, Agile should remove the use of writing documentations, because the tests represent the user stories.
At my job, we have a lot of heavy functional tests describing real-life scenarios.
Maybe you don't have such tests...

For the documentation, we have dedicated people, who decide which functionalities are to be added in the product.
So may be you should stop working on the project, and instead spend your time on planning the new functionalities (planning means asking for card notes, and prioritizing new functionalities).

"Restrictive agile"?

[williamhb]

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-hiring tends to produce disenchantment as people feel that the organisation is not rewarding ability and effort (by promoting internally) but is putting a glass ceiling above them ("we're hiring from outside because you do not have experience of the next job up the tree").

Just IMHO though

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!

Re:WTF does this mean???

[Mathiasdm]

Here you go :-)

And yes, you are absolutely right. I couldn't entirely understand the article either.

Re:WTF does this mean???

[tacarat]

Not to be confused with SCUMM.

Re:WTF does this mean???

[slaker]

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:WTF does this mean???

[Junior J. Junior III]

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:WTF does this mean???

[stephanruby]

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:WTF does this mean???

[Vintermann]

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 developers as ... let's just call them schedule handlers.)

Re:WTF does this mean???

[Anonymous Coward]

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.

Re:WTF does this mean???

[ArsenneLupin]

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!

Re:WTF does this mean???

[marxz]

ditto on this... a random smattering of words combos only half of which would be counted as valid by my spellchecker. Also I would have thought a scrum was the last thing you needed in a work environment.. ... I mean I could live with the title "Loosehead prop" I could see my boss being happy with being called a "tighthead prop" but I can't see anyone in my current environment putting their hand up to have "hooker" as their job title.

Re:WTF does this mean???

[nickyandthefuture]

It's a post made by an idiot, full of buzzwords and fury, signifying nothing.

Re:WTF does this mean???

[ChienAndalu]

I think this article made me understand wikipedia deletionists .

Re:WTF does this mean???

[Culture20]

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:WTF does this mean???

[Obyron]

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

Re:WTF does this mean???

[Hurricane78]

Protip: Never *ever* link a "here" or similar word! Ever! :)

Re:WTF does this mean???

[Fox_1]

My first thought on reading the article was : "What a f*cking Idiot"
Seriously make my eyes bleed some other day.

Re:WTF does this mean???

[Dastardly]

That has been my experience as well, and I am by no means an expert on Agile or Scrum. I agree probably the biggest thing is the retrospective every iteration, if you don't look back at what works and what does not and are willing to change it wont work.

I also agree Scrum Master is a misnomer. I find their #1 purpose is to keep the Scrum meeting on task and short. Even removing impediments might not be their job, although making sure that some one is working on removing the impediment would be appropriate.

Re:WTF does this mean???

[Radovici]

Re: "velocity"... unnecessary but thought-provoking; misused or incomplete but interesting.

Re:WTF does this mean???

[Darinbob]

If there is any value to "Agile", whatever that is, it is completely trashed by the inept marketing and buried in a corporate landfill. I hope these advocates talk this way in interviews, so that smart people can leave before they're over. I get nervous just hearing people use words like "methodology", much less the more mystical varieties.

Re:WTF does this mean???

[cbraescu1]

RTFA

Re:WTF does this mean???

[SpaceMika]

Thank you. Thank you, thank you, thank you.

I'm already cross-eyed from spending the last week pushing to finish a big project and keep being vaguely bemused by basic human interaction, then this came up and I was completely lost. The rant was both necessary and entertaining. So: thank you.

Re:WTF does this mean???

[Hognoxious]

RPG speak is the new car analogy. Remember, you read it here first.

Re:WTF does this mean???

[Hognoxious]

If someone tried to work a flanker you might get blindsided.

Re:WTF does this mean???

[Vintermann]

We don't play rugby here either. And what's a ruck?

Re:WTF does this mean???

[natehoy]

RPG? Now you're talking my language! :)

And, yes, I've programmed in RPG using a couple of Agile development methodologies, including Scrum. .. oh, wait, different RPG.. ;)

Try before you buy?

[El_Muerte_TDS]

I wish I could try this scrum in a safe environment, I need some sort of ScrumVM.

You're missing the problem

[91degrees]

A scrum master is not a manager. He's only mean to organise a handful of meetings and deal with impediments. These should not take any significant time.

Re:You're missing the problem

[FroMan]

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, though any of the team can mention to take it offline after the standup. Similarly with the planning, review, and retrospective meetings he'll usually be the first to remind everyone of the purpose of the meeting, but anyone on the team can do that.

In my view a scrummaster is only needed to get a scrum team started up to keep things on track instead of letting everything degrade into chaos. After an scrum team is up and running and into a good groove any member of the team can help provide scrummaster-ish direction.

Re:You're missing the problem

[Delkster]

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 meetings instead of being to the point, but it's part of the scrum master's responsibilities to take care that it doesn't happen.

Re:You're missing the problem

[Kristoph]

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.

Re:You're missing the problem

[91degrees]

If he's the Scrum master then that's what he should do. I certainly will. Except all he need to do is say that they need to talk about it after the standup.

Since in this case they're fairly senior, that's not a problem. Even if they are, the difference in rank is small. An intern is not going to be in the same scrum as senior management.

Yes, use experts as scrum masters

[192939495969798999]

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 allowing work to stretch past 'daily scrums' would be better.

Re:Yes, use experts as scrum masters

[cyber-vandal]

Well done, you've just managed to be even more confusing than the original article.

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.

Re:Yes, use experts as scrum masters

[rendermaniac]

The film industry has an adminstrative position called Line Producer. They deal with managing team schedules, the project budget, making sure resources are available for the team, booking / chairing meetings, and dealing with paperwork, clients and upper management. This sounds like an equivalent position but without the (less professional sounding in my opinion) buzzword compliant "Scrum Master" moniker. The actual task of getting the project done falls to a Supervisor (ie a project manager) who deals with technical and creative decisions, assigning tasks to the team, and critiquing work in progress. A female Line Producer often work very well when dealing with a mainly male team. This could be to do with fewer ego clashes and women generally being more organised (again my personal opinion).

DTFT! (Define That Fucking Term!)

[Anonymous Coward]

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 the management guy handle HR and BS from the higher ups, and let the uber-coder handle developing the junior coders and explaining shit to the management guy. Just pay them the same.

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.

Re:Velociraptors

[teg]

"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, you could see it as the rate at which EV increases. You can find an interesting paper about it here.

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:Velociraptors

[Delkster]

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 stuff into your sprint backlog; so, if you can't or don't want to change that, don't use scrum.

If management insists on doing "scrum" but actually acts contrary to it, the management doesn't appear to understand what they're doing. Again, that'd probably cause icky problems, scrum or not.

I'm not really a scrum believer but have seen a few scrum projects, some of them better done, some of them worse, none of them really done properly as scrum, so I know how much it can suck if it isn't done right. I agree that the whole thing is somewhat loaded with buzzwords. But the better the organization and the team has actually adhered to the methods, the better it has worked.

Re:Velociraptors

[vjmurphy]

"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!

Re:Velociraptors

[Hal_Porter]

I say we execute the people spouting buzzwords and go back to coding.

Re:Velociraptors

[sgrfsh]

"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?

Velocity is dependent on acceleration in a particular direction, *and* on the size of the 'body'. The guys at his company obviously need to eat more cheeseburgers.

Re:Velociraptors

[thePowerOfGrayskull]

...joblist...burn-down chart...sprint...scrummaster...

Egads! He's doing it too! Is this "scrum" contagious?! Excuse me, I must go wash my hands now.

Re:Velociraptors

[Anonymous Coward]

in that case, I know now what the article says:

"My boss wants me to take responsibility. Tell him I don't have to."

Re:Velociraptors

[booyabazooka]

"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?

Let me google that for you.

Re:Velociraptors

[Runaway1956]

Cute. I liked that. A mod should give you points. :^) But, as you may have notice, I'm not one for buzzwords. I could point you to a dictionary, and suggest the word "productivity". "Velocity" properly belongs to several discussions, including projectiles, vehicles, athletics, and astrophysics. In the environment under discussion here, "velocity" is a terribly contrived buzzword.

Re:Velociraptors

[Matthew Weigel]

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.

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.

You actually have to do it more or less properly for it to work.

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:Velociraptors

[CaptKilljoy]

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.

True. However, when those conditions are met, the effectiveness of scrum is nothing short of absolutely astounding.

Re:Velociraptors

[StrawberryFrog]

. 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. If your sprints are already as short as they can go (1 week) and management still cannot keep priorities stable over that length of time, and cannot be taught to, then they are dickheads, and you should find new management to work for. Scrum cannot solve that problem, but it might make you face it a lot sooner.

"Our mis-implementation of Agile includes.."

[IainMH]

"Our mis-implementation of Agile includes.." ..is a pretty good idea for a ThinkGeek t-shirt.

Re:"Our mis-implementation of Agile includes.."

[Zontar The Mindless]

"... Lotus Notes and a machine gun. It is the finest available."

Sorry, I just couldn't help myself.

Re:"Our mis-implementation of Agile includes.."

[martin-boundary]

TZING! Nooobody expects a ThinkGeek T-shirt!

Re:"Our mis-implementation of Agile includes.."

[shutdown -p now]

"Our mis-implementation of Agile includes.." ..is a pretty good idea for a ThinkGeek t-shirt.

I prefer "Our Agile is the only True Agile".

scrum, isn't that a rugby term?

[kamakazi]

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:scrum, isn't that a rugby term?

[the ReviveR]

I just read the post and realized how sad it is that I understood that completely.

...and yes the name of the scrum development model comes from rugby.

Re:scrum, isn't that a rugby term?

[Paul Jakma]

Yep, and bite each other's ears, punch each other's noses, etc..

(Also, I hope whoever modded you troll gets punished in m2).

Re:scrum, isn't that a rugby term?

[LoztInSpace]

Oh FFS. They kick, bite & punch the other team not each other.

Yikes

[ShakaUVM]

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

[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

Re:Yikes

[themightythor]

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

I respectfully have to disagree with you. My vote is with "Extreme Programming". Here's an idea: let's market it like we market Mountain fucking Dew...it's extreme.

Re:Yikes

[mokus000]

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:Yikes

[mevets]

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.

Re:Yikes

[Darinbob]

Yes, hiding behind lingo without understanding it seems to be the essence of many software engineering styles. Using these silly words just has me imagining these people reading a magic tome full of arcane rituals. They don't know what they're doing, but they think if they follow the recipes exactly that the results will be as promised. The reason stupid words get used is because people are trying to copy what someone else did exactly, without actually understanding what they did.

"Says the chicken needs a pinch of cardamon, anyone know what that is? A spice you say? Ok, let's dump in some cinnamon, that sounds similar. Bob, are you done getting the oil out of that snake yet?"

!rugby

[IRoll11!s]

funniest tag on a post ever

Re:!rugby

[oji-sama]

making sense doesn't prevent it from being funny ^.^

View from the Dark Side

[Phloebas]

I do projects assurance work for a small development company. We have some very well-paid, highly skilled and extremely experienced developers, who occasionally are made Team Leads. This means they have to do project governance. We use PRINCE2, which is far less-suited to software development, and there is a definite problem going on here.

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 of young first- or second-year analysts, all of whom embrace our governance, and generally perform the project administration side of things far better than their more-experienced colleagues.

On the other other hand, I have noticed that the younger consultants lack the project experience to plan creatively and come up with ways to make the process work for them. They would if they could, while the older ones can but couldn't be asked. I fear that over time the negative attitude towards governance that lingers from the older generation will infect the new guys.

Our company recruits annually, and is always running a number of internal projects. What I advocate is that the new consultants spend a while running small internal initiatives during part of their time, and then spend their second year as the administrators on client projects, before being able to "earn" not having to worry so much about all the extra overhead that comes with that sort of thing. It might also help with retaining experienced staff.

Re:View from the Dark Side

[Anonymous Coward]

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

Re:View from the Dark Side

[Phloebas]

I get that kind of response a lot at work (although they're less mean). I am a fairly junior member of staff, but I (to use more management jargon) "serve a strategic function", and so you could say I'm senior management's rat on the development floor. That is, I make sure the developers aren't wasting the clients' (and our) money.

There is a lot to be said for letting developers run wild. But when clients want to see a plan and a contract, and we want to make sure we haven't agreed to deliver a telepathic user interface in 6 months, someone has to do some paperwork.

Nobody likes it, but anyone who has been at my company for a while realizes that it is a necessary evil. I do my best to make it as little hassle as possible, but at the end of the day someone has to do it and we feel that it saves money for us and adds value in the long run.

Clearly a targetted post:

[BluePojo]

If you work on an agile dev team, this post uses every day language. (yeah, velocity is not an unusual word when referring to backlog burndown rate :D) If you're just an enthusiast or work in IT, this post is crazy off the wall nuts.

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:Clearly a targetted post:

[BluePojo]

Additionally, why is ScrumMaster one word...?

Re:Clearly a targetted post:

[emj]

CamelCase is cool, it's an ExtremeProgramming thingy..

Re:Clearly a targetted post:

[Dachannien]

Bingo, sir.

Re:Clearly a targetted post:

[halivar]

We use Scrum Lord, because it's funnier.

Re:Clearly a targetted post:

[DragonWriter]

If you work on an agile dev team, this post uses every day language. (yeah, velocity is not an unusual word when referring to backlog burndown rate :D)

Isn't "velocity" in that context (and, for that matter, the particular sense of "backlog" and "burndown" you are using), Scrum-specific jargon rather than general Agile jargon?

Re:Clearly a targetted post:

[radtea]

impact your velocity

I assume by "impact" you mean "reduce". But really, why use a more concrete term when a more abstract one is available? It will impress the ignorant by making your writing marginally harder to read without actually becoming incoherent.

That's the fundamental purpose of all the specialized terminology around commercialized software development methods: to give people a false sense of superiority based on their mastery of the terminology. The ideal language is sufficiently evocative that ignorant people can get a sense of what it means but aren't able to speak it fluently themselves, which puts them at a psychological disadvantage.

Humans are hierarchical social primates, and men especially want innately and desperately to climb the hierarchy because that's how our male ancestors scored the most high-value mates. The methods market in software development does nothing but provide an excuse to create novel hierarchies for us to climb. None of the methods that various companies sell actually increase the speed of development (laughably called "velocity" because you really need a signed quantity if you use one of these methods as you'll be going backwards half the time). None of them increase the robustness or maintainability of the finished product.

This is not to say that methods and process aren't important, but that as soon as a method is commercialized and sold as a product you can be sure that the primary draw is not the method's utility but its social hierarchy value.

Side note: "methodology" is or ought to be the study of methods. "Method" is the term we ought to use for a method of developing software. But of course to use the language that way would identify me as an outsider who is no where near the top of the hierarchy...

Re:Clearly a targetted post:

[RedBear]

[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 industry where other people apparently use these terms without being a member of the cast of SNL.

Talk about insanity. There is no possible way that any group of people using this kind of nonsense language could create reliable software. Good LORD, people. Get a GRIP and get back to proper software design and coding. And take an English class.

To parent: If your organization is successfully producing quality software at a decent clip it is only because you have good coders and a workable organizational structure that adapts to long-term needs, like changing the project lead every couple of months and keeping task lists short and manageable. You don't make decent code merely by using this monkey language of nonsense words to describe your process. We have a perfectly good set of millions of words in the English language, many of which are applicable to describing any form of process methodology you care to use. There is no need for the waving of hands and making up of new words out of thin air. Leave that to the flim-flam artists you are in grave danger of becoming confused with.

Re:Clearly a targetted post:

[Abcd1234]

Honestly, I gotta tell ya, all this jargon sounds like the software development equivalent of Scientology... then again, I suppose it wouldn't be unfair to compare Agile followers to religious true-believers.

Re:Clearly a targetted post:

[StrawberryFrog]

This article/post contains the most ridiculous joke-like conglomeration of pointlessly obscure buzzword phrases that I have ever seen in my ENTIRE LIFE

Either you don't work in software development, or you're just ignorant.

Embrace the modern religion!

[JeffHome]

>> A scrum master is not a manager. He's only mean to organise a handful of meetings and deal with impediments. These should not take any significant time.

.

The Scrum Master does indeed manage impediments to the projects. They act as a "shit umbrella" - protecting the team from all external influences that are deemed detrimental to actually doing the job. They "keep a finger on the pulse" of the team - identifying problems (sometimes between individuals, sometimes with individuals, sometimes with external 3rd parties interfering). They are there to allow the team to develop the software they are employed to do... in a pleasant environment (that doesn't include phones ringing all the time, doesn't include constant multi-tasking, and doesn't include managers walking up and asking dumb questions every 2 minutes).

.

I disagree with a previous poster that the "top people" should be Scrum Masters. Whilst the role must have someone with a strong personality and understanding of the business relationships between the project and the rest of the organisation (in a large corporate at least), they do not need to have any "hands-on" technical ability (or involvement). For similar reasons, an intern is probably not a good solution as Scrum Master either. So-called "soft" skills are more important here.

.

The Scrum Master role is as facilitator - and to help "keep the team honest" with respect to Agile principles and process (regardless of what flavour your organisation has chosen to attempt).

.

I've been working in Agile teams now for 4+ years - seen good and bad implementation... had lots of success - and some failures (don't we all). Agile tends to work with enthusiastic, smart, intelligent and "bright" people. It doesn't do so well if the people are dumb, unfocussed or demotivated. The Scrum Master role includes identifying these people and either working with them to "lift their game" - or works with HR to get them out of the team.

.

I would object strongly if the Scrum Master role was not a full time position, and if they were wanting to act as some kind of technical team lead. Let developers do the development... let people who understand the technology stack make those recommendations... but don't confuse the roles :)

Re:Embrace the modern religion!

[braeldiil]

Every process works well with smart, motivated people. No process works well with dumb, unmotivated people. That's not news. The particular process doesn't matter; neither does the task*. From ditch-digging to nuclear engineering, from slave labor to the latest programming paradigm, it's always the same - the smart, motivated people outperform the stupid and lazy. The trick is to figure out the process that works best for your particular team. And there's no one right answer to that question - each team has to take the available ideas and figure out a process on their own. *The army has studied this pretty closely over the years. IIRC, they estimated a 30% increase in productivity at any task by adding 1 90%+ ASVADS scorer to a team. That's at any task, from tank repair to foxhole digging to missile defense. The increase in productivity was reasonably consistant across the entire gamut of Army jobs.

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

Re:Agile

[ClosedSource]

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

Where do you work? I'd like to work at a place where every manager is inhibited by actions that would upset their team.

Re:Agile

[DragonWriter]

In my opinion, Agile is a great tool for managers, not developers.

Development methodologies, in general, are largely about how to manage projects so that the the right thing gets built for the customer. This is true of agile, sure, but its true about most methodologies.

Re:Agile

[wurp]

Oh yeah, and YAGNI (You ain't gonna need it) is important, too. Don't implement stuff until and unless you actually need it for functionality that impacts an end user.

Re:Agile

[zerocool^]

The worst thing is the doublespeak even in the naming convention. Agile development isn't.

I could write a book on how not to do scrum. But honestly, it'd be 50 pages, with the first page consisting of "Don't use scrum" in 42 point font, centered, the second page saying "If you have good developers, you produce good code.", and then 48 pages that are blank, except for "Notes" written at the top.

Re:Agile

[coldtone]

TDD enables you to refactor mercilessly

While I believe TDD is a great technique for getting code with 100% Statement coverage, I do not feel it allows you to refactor code mercilessly. In order to refactor code you need to know its history, who wrote it and why, what does it do in the scope of the application. This takes time that some developers, (Certainly developers new to an existing project) don't want to spend.

The only scenario where you can refeactor mercilessly is when you have 100% Path coverage, Not statement coverage (100% Statement coverage is trivial and all code should have that.) If you don't have 100% Path coverage on your application (And I think outside of medical and aviation you won't.) you can't refactor mercilessly. You must be cautious and always question the added value of a code refactor.

What the hell?

[Godji]

What the fuck is a ScrumMaster? What the fuck is this person asking? Seriously, how did this get in my RSS reader?

Re:What the hell?

[Rockoon]

What the fuck is a ScrumMaster? What the fuck is this person asking? Seriously, how did this get in my RSS reader?

A ScrumMaster is a person that broadcasts RSS clips in such a way as to raise awareness for the stupidity of RSS feeds.

Re:What the hell?

[CaroKann]

A ScrumMaster is like a BrewMaster, except that instead of having mastered the making of brew, you have mastered the making of scrum.

Re:What the hell?

[Darinbob]

Is that like a side fermented brew?

Re:What the hell?

[StrawberryFrog]

What the fuck is a ScrumMaster?

Here you go: ScrumMaster

Does no one just develop anymore?

[germ!nation]

We use scrums and things at work purely so no 1 developer is lumped with a task called "build this e-learning course" and then waste a few days trying to figure out where to start and generally sink. We implement it poorly and it works great for us.

But honestly, does no one just like write code and get on with things anymore? The overlap of academic programming theory and just everyday programming roles in business (facilitated by t'internet) goes way too far, to the point where I know developers who spend so much time on their patterns, lose coupling and complaining about how things arent "properly" agile that they end up doing most of a day cocking around and then have to do 3 hours overtime just to do their days work.

People need to just breath in a lung-full of stfu and go back to just working and getting things done.

Harmful to my sanity

[dgr73]

Why is it that every few years some dildo comes along and takes ages old best practices, gives them snazzy "marketable" names and calls it a great new method. Then everyone has to go to school to "learn" this new method of doing things, because your a-hole of a manager is so completely enthralled by the marketing buzz that he doesn't listen to you when you tell him that "I know this shit already".

If it was up to me, I'd shove each and every method creator downrange of a shooting gallery just to test how Agile they were.

What the Fuck is This Shit?

[Bob Cat - NYMPHS]

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

[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:Long standing agile developer

[characterZer0]

they're doing it wrong, and all bets are off

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:Long standing agile developer

[Ash Vince]

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 because someone has a job title of developement manager does not mean they always have to take upper managements point of view.

In short, a good manager can go against his own management above him in order to get the team through blockers. They will probably not do it in front of junior staff though as this undermines confidence in upper management. Management might appear to be a united front, but that is just an appearance to those who are at the bottom of the ladder.

Re:Long standing agile developer

[DragonWriter]

You seem to be saying that "ScrumMasters" should be all of the following:
1) Not managers,
2) People with a project management background,
3) People whose primary skill is organizing people,
4) People with sufficient authority within an organization to get through barriers posed by people in management.

This seems somewhat incoherent.

Re:Long standing agile developer

[intranation]

By "not managers", I meant not the managers of the people involved in the agile team. I clarified this by also saying "conflict of interest".

As for the authority piece, it's well known that agile teams need to have top-down buy in from the organisation (to avoid unsavoury situations such as marketing performing "drive by" requests on developers), so "authority...to get through barriers" is a moot point when it comes to looking after the team's interests, as in theory there's a mandate to do things in an agile way.

Overhead

[Anonymous Coward]

What is your scrum master up to?

I thought their over head is only meant to be 10-20%. With our team they arranging meetings, keep a bit of order, and report and handle obstacles but that is about it. Plenty of time to carry on programing.

We experimented at first with managers as scrum masters but there were problems with conflict of interests. Now someone in the team does it.

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:When you cut through all the gibberish

[codehoser]

You've either missed the point or you're intentionally avoiding it.

The point is _not_ to simply "get the work done". If you're trying to make a buck, you need to get the work done better and quicker than any of your competitors. And they may have deeper pockets, more hardware, more developers, etc. The point of Scrum is to help managers and developers work as effectively as possible toward a common goal by, in part, removing all the crap that stands in the way.

Try to think this through just a little bit. Your advise to a company failing (but trying really hard) to be competitive is apparently "get on with your job". Alternatively, I suppose the employer should fire all of the developers and try again with a fresh batch.

The fact that your post was modded "insightful", I think is an indication that people would really like it to be true that software development is brain-dead simple. It's not. Sometimes even "talented" developers can benefit by learning techniques that have proven effective in the past.

Scrum?

[Porchroof]

Maybe I could understand the question if you told me what "scrum" means.

Re: Scrum?

[petes_PoV]

It's a term in Rugby Football (like american football, but without all the protection, padding etc. i.e. for _real_ men). The term is used when 8 of the players from each side, in a 3 - 4 - 1 formation, bend down in a roughly circular pattern. The two at the front sides from each team support the "hooker" who' job it is to get the ball backwards (hooking it with his foot) to his own team.

Meanwhile all the other members of his side of the scrum, try surreptitiously to beat up the other team - under cover of the "scrum", without the referee noticing. It's a very physical, bruising way of achieving possession, but an art form to get right.

On agile programming, it's roughly the same - except there's no ball and no referee - and there aren't really teams - everyone's looking out for themselves.

Re:DTFT! (Define That Fucking Term!)

[CarpetShark]

Seriously, somebody add some wiki-links

This is not a wiki.

ScrumMaster? Isn't that an official WankWord?

[Otis_INF]

ref: http://steve-yegge.blogspot.com/2007/09/ten-tips-for-slightly-less-awful-resume.html

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 that you eat 1001 bags of blue M&Ms during the making, all they care about is if the software does what they need it to do. So you should go write that software, how is up to you, but if that 'how' process is actually taking more time and energy than the software itself, you should perhaps abandone that process you called 'agile' and go back to Common Sense Software Engineering principles, like defining what functionality should be implemented and actually DO that.

Stacked slang

[erroneus]

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?

Re:Stacked slang

[Fr33thot]

How many software developers have a background in any sport let alone Rugby?

Re:DTFT! (Define That Fucking Term!)

[iamflimflam1]

Seriously, you code for a living and have never heard of scrum? Do you not keep up with the latest fashion in development? What will you do when you if you have to go for another job and the interviewer asks you about the latest development methodology that is doing the rounds?

Buzzword Bingo

[Attila Dimedici]

Dagnabit, all I needed was "will implement in the cloud" for Bingo.

Re:Buzzword Bingo

[soccerisgod]

Funny, around here we call it "bullshit bingo" :)

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.

For those who AREN'T DEVELOPERS!!!!

[turtle2k]

SCRUM = Short Conscise Repeatable Uniform Meeting It is designed so everyone on the team can say what they accomplished yesterday, what they plan on accomplishing today and what their current blocks are. It s meant to last only 15 minutes for a small team (dont have large team scrums... it wastes people times) and is an extremely handy tool for working with a small team daily. ScrumMaster is the person who simply facilitates the meeting and enforces the meeting rules. I have seen alot of negative comments towards the original poster... I happen to agree with him. Most companies get it wrong. Why? Methodologies are only as good as the people who implement them. No we do not need highly paid developers leading a scrum meeting... Lets face it, most developers have big egos and believe they out of the rest of the world have been enlightened. They see it as a display of their power to run a scrum meeting that probably isn't even a real one just to prove to themselves that their intelligence actually means something to someone. Find another way to feel good. People have work to do. Ok, to all the posters above that said "wank" or gibberish, etc. You simply shouldn't have posted to a thread you know nothing about... Scrum Master is not a word. Its 2. See thats part of the problem... some dev branded it as a compound word. Its 2 words I promise... Now everyone wants to be one.. :D

Re:For those who AREN'T DEVELOPERS!!!!

[bitemykarma]

When I started programming computers in the 1970's there were fad books then too, which all the managers where reading. The idea of getting more code out of the cheapest people has always been the goal.
Managers! I suggest this one: Manual of Computer Programming for Astrologers

Re:The alternatives are worse

[Delkster]

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

I thought it was common knowledge

[Dunbal]

Everyone knows that engineers make lousy rugby players...

If you misread it as ScumMaster...

[John Hasler]

...it all makes perfect sense.

The answer is obvious...

[meburke]

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 .

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:The answer is obvious...

[StrawberryFrog]

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 important item. Not only does this deal with change, it allows new requirements to be uncovered in an orderly way rather than causing a conceptual train wreck ("but the functional requirements are done"), it allows value to be taken from the existing software as soon as possible, and design flaws (e.g. "system does everything we want, but doesn't scale past 100 users") to be uncovered and corrected much earlier.

Re:The answer is obvious...

[yt8znu35]

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.

This is great advice for someone who will never work for a company. Here is what happens in the real world. In my company the Director of Engineering has mandated Agile and has had the usual lot of Agile gurus come in--no doubt at great expense to the company--to tell us that we are doing a great job with our implementation, thus making her bosses happy. But the reality is that Agile has been a dismal failure for us. Scrum teams here redefine doneness criteria on the fly and regularly fudge the numbers to up their velocity. Middle managers, fearing for their jobs, will not let any information filter up to senior management indicating that we are having severe problems with Agile. We have an "Obstacle" post-it board in a common area for airing concerns or problems with our Agile implementation that is supposed to be regularly viewed by the director. In reality any post-its stuck to the Obstacle Board have been promptly removed by the middle managers before they can be seen by the director. It is pretty well understood within my particular scrum team NOT to post anything on the Obstacle Board. These days the Obstacle Board simply stays blank. So having no obstacle post-its and no negative communication about how Agile processes are working for us reaching the director level means that, per the director, everything is running smoothly. So everyone plays along, just trying not to get fired for not be pumped up enough about Agile at my company.

Re:The answer is obvious...

[meburke]

Yeah. Agile/SCRUM is not always the best way to coordinate development. What works works, what doesn't work doesn't work, and you can do what doesn't work over and over again and it still won't work.

I've seen Agile/SCRUM work real well in a couple of situations, but I've seen it fail in situations where people adopted the template but didn't understand what makes it work. Gold-plating a pile of shit doesn't make it not-shit. SCRUM works when it works because it overcomes some problems in the normal monolithic project management process for teams that have to develop in a hurry. Not adhering to the working process just reinstates the original problems, along with a couple of problems that didn't exist before.

Re:The answer is obvious...

[PostyMcPostwhore]

Agreed. I know of more people just gaming the system to please managers than deriving any real benefit from Agile.

Shiny objects approach

[kanwisch]

There was a leader in my organization at one point who liked "shiny object" names. He liked to use terms that were getting some press in whatever way seemed useful but they never mated up to the real meaning of the term. Scrum is one that is abused and is so far from the three (or four, depending) question, 15 minute, stand-up meeting it's sad. So no, you're not alone.

question...

[buddyglass]

...harmful to our velocity...

Did it impact your speed or direction?

Re:question...

[Daddy-Oh]

Are we talking the European, or African Swallow?

Re:question...

[CptNerd]

You can either know where you are or how fast you're going, but not both.

Re:question...

[jamesfalloon]

What a great metric to measure code by, I wish I could say that I once wrote one million lines of code in a day, in the deleted direction.

Agile, Scrum and fashion sense

[cluge]

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 enlightened as to what they were thinking at that moment in time. These folks point to agile manifesto and scream "Working software over comprehensive documentation". Sorry - sometimes you have to write documentation.

Writing good code involves some planning, some thinking, and with teams LOTS of GOOD communication. It's a creative process as much as it is a engineering or scientific one. If you have a strong management team, good people, and dedication you will quite probably produce good code. It doesn't matter if your a scrum master, agile devotee, or a guy that still starts out with a flow chart. Agile is not the be all end all of coding, and even properly implemented won't make a project successful.

-cluge

I can think of somebody who'd be worse

[NotSoHeavyD3]

I don't mean to be yet another person ripping on Scrum. However the worst person I can think of is a manager who thinks "Scrum Master" is what they call "Project Manager" in scrum. (As in he'd assign people to tasks, expect you to report to him, block the stand up to ask questions on your status. Oh, and he was in charge of writing down what the tasks were and updating them so at the start of the scrum you couldn't even figure out what you were supposed to be working on. Oh, and he didn't actually get rid of roadblocks.) Just personal experience but the SM can be a major choke point if it's done badly. (Our current SM just gets the hell out of the way which is an improvement.)

scrummaster managers is worse

[heironymous]

It could be worse than losing your best coders. Our scrummasters are the managers of the scrum team. Yes, that's right. The scrummaster's direct reports are on the same team. So... candor pretty much goes out the window.

One specific consequence that I didn't see coming... Upper management recently messed with the sprint and pulled people off. Yes, I know we're not supposed to let them do that, but the big bosses didn't seem to agree. Naturally, we only completed about half our stories. So in the demo, the scrummaster manager reported that we completed all our stories so that it wouldn't look bad. He just deleted the incomplete ones from our list.

In other words, upper management didn't learn that their behavior was bad, so I'm sure it will be repeated.

Another problem, Scrum can be like a babies

[NotSoHeavyD3]

You know how babies if they can't see something they don't know it exists? Scrum is like that. Features and fixes that can't be seen are often treated as if they don't exist while the methodolgy goes nuts over things you can see. (Like fixing threading issues which might be hard to notice on the outside world because they only cause bad things occasionally but are glaring and need to be fixed when you look at the code. Why yes, I ran into that and I had to tread carefully to get the thing accepted since that baby mentallity showed up.)

Re:Another problem, Scrum can be like a babies

[Grishnakh]

You know how babies if they can't see something they don't know it exists?

FYI, that's called "object permanence" in psychology. The baby gets excited by seeing and playing with a ball, but when the ball rolls behind a chair, it suddenly ceases to exist in the baby's mind. Very strange. My cats have no trouble with this concept.

Re:Another problem, Scrum can be like a babies

[AigariusDebian]

Cat intelligence can approach that of a 5 year old.

Re:What a festival of ignorance Slashdot has becom

[heironymous]

AC, you actually seem to consider keeping your head in the sand a virtue. Would you want an auto mechanic that stopped learning ten years ago? Or a doctor? There's a big difference between fifteen years of experience and one year of experience fifteen times in a row.

By the way, there's absolutely no consensus in our field that what you call the best common sense methodology is a good way to go. You are preferring contract negotiation over customer collaboration. In fact, that's the exact opposite of what many talented thinkers in our field espouse.

http://agilemanifesto.org/

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.

Re:It's like AD&D

[dcollins]

Sometimes, it's not just about fun: http://deltasdnd.blogspot.com/2009/05/its-not-just-about-fun.html

interns and scrum masters

[Gary W. Longsine]

You were so close, but then you got wound up in a slave/master metaphor. So many people think that what everyone else on the team is doing is easy, and not important. Frankly this guy's management, by making a good developer a scrum master, probably has a clue. The fact that the team isn't working may well be a failure of management -- to fire people who are not productive. My guess is, however, that day is coming. This is probably a case of giving a disfunctional team enough rope to hang itself. I'd get an intern all right, but he or she wouldn't be scrum master. Which person on that team would I fire first... hrm...

Droopy

[Petro026]

I always hear "agile, when implement correctly, makes software development a pleasure." Two things about that statement 1) Poppycock. It's never easy 2) No one fully implements an agile development process and if they did it would turn any large scale development process something akin to a three ring circus.

poster already has his answer

[Haszak]

People are his problem, not process. You can take any methodology or process and twist it to your own ends. Along the very same lines, I'm not a big fan of the metrics surrounding process. Like all statistics, it can support whatever story you want to tell and can't replace the insight of someone who knows what's really going on.

The core problem is that coordinating people is positioned as "moving up", so you get people in those positions that aren't very good at it. Programming is a very different skill than coordinating people. To me, managing just another skill set and the manager should be treated like just another team member. And of course, the other core problem is that most people aren't very mature. :-)

I see a lot of negative comments here about Agile, and I think it's because those saying it just want to be heads-down coders. Or worse, they don't want to tell anyone what they're doing in order to keep control over it. What Agile does well is to get the business people involved in the project in a way they can understand. Instead of a poorly written requirements document, it's an interconnected web of sticky notes. They can SEE the complexity. If a project is late, it's no surprise because they've seen the entire journey.

The Mythical Man Month anyone?

[Temujin_12]

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.

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.

Re:The Mythical Man Month anyone?

[petes_PoV]

You can't get people to believe a £20 book, when a £1000 course tells them otherwise.

It's a sad fact about consultancy and training courses, that the higher the price the more they are believed. They aren't necessarily better - or wrose. However by dint of paying more, you have to go along with the advice given, no matter how outlandish, faddish or nonsensical - otherwise the money has been wasted. Since this is _real_ money, rather than the "funny money" used for project accounting and valuing employees' time, it actually counts for something and has real, live value. Far better for a manager to adopt the conclusions from a piece of consultancy and waste thousands (millions?) on a failed project, than to be seen ignoring that high-priced advice and still having a failed project. (Which, if he/she had to go "outside" for advice or skills is likely, as he/she can't be a very good P.M. in that case).

You're right however. TMMM lists pretty much all of the problems of (and gives solutions to) most software development projects. What this tells us is that the basic issues and therefore the underlying difficulties haven't changed much since <slides over to bookshelf to get publication date > ... 1975 which tells you all yo need to know about all the different methodologies since then,

Re:The Mythical Man Month anyone?

[ADRA]

I went to BCIT, which is a 2 year trade/technology school, and we had large numbers of group projects throughout the courses. There are pluses and minuses to the technique, which really comes down to work distribution and reward.

- Some team members naturally did less (sometimes nothing) for projects while getting lifted by the rest of the group
- Some team members offset their poor abilities in X and applied them to Y instead, making up for their inadequacies
- Some team members would just stop communicating. They may have gotten the work done, but outside classes they were like ghosts

The good things were that it taught us small group teamwork very well. We knew that there are people you can depend on, and those that can't. Since grading was simply based on the net outcome of the group's work, some people who had no business programming got free rides (for group projects at least), but it taught us a good lesson about dealing with dead weight. Some of the lazy sort managed to get by to graduate, but many more flunked out along the way. That was one of the most important non-technical skills I learned when getting a real job.

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

A Natural for Project Managers

[curmudgeon99]

That is a mistake. This is a natural function for the project manager. They should run these meetings.

Similar problem, different religion

[JumpDrive]

I'm not quite sure of all the reasons that these type of changes fail and I'm not familiar with scrum, but it sounds similar to other changes I have encountered in business processes.

Take Quality and ISO: just about everywhere I have seen this, there has been an epic failure of some type
Usually because people can't accept a transition or change. Why? Usually because people take it, that if this works better, then I am a failure, because my past ways were wrong. So they look for ways to make it fail. In this instance, one of the easiest ways to make it fail is to follow it literally to the letter and not bend it to the business. Or a better way of saying it is: Instead of taking the best parts of these processes and applying them to the business current business process, just ad-hoc change everything.
Example: From Quality and ISO Management Reviews: I have seen this transition in 3 different environments.
1. Every report within management and to management had to be changed or was mandated to be changed sometimes a little, but usually a lot. Result: Information that was critical or that needed to be passed along wasn't, just the new numbers. Reports became a complete waste of time and meetings which were a 60% waste of time, became a 90% waste of time. (epic fail: failure blamed on Quality Management and implementation of ISO)
2. Just change the titles of everything and continue on.(epic fail: failure blamed on Quality Management and implementation of ISO)
3. Look at what is currently being done. Consolidate information that is needed to meet business goals. Define business goals objectively. If the TPC reports aren't doing any good, get rid of them. Usually, the hardest part here is that management has a real hard time defining the business goals objectively. (some improvement)

I was going to go into SPC, which is a subset of Quality, but the mistakes in it's usage are about the same and happen for about the same reason.

So, the question I would ask is roughly the same you ask. Does it make sense that the best coders are scrummasters in your business process/environment? I think what you are going to find are answers which are not black and white. And what you should be looking for here in the answers are the answers to the questions, When is it a good idea for the best coders to be scrummasters and when is it not? Which, will probably evolve into, what makes a good scrummaster? Which evolves to, who within this group of people would make the best scrummaster?

Re:DTFT! (Define That Fucking Term!)

[LizardKing]

I'd point out the successful projects on my CV, and then point out that they were all accomplished using common sense - not some bullshit laden methodology of the week. My "methodogy" if you can call it that? KISS.

Here is your problem...

[Sububer]

Scrum is a project management methodology. The role of Scrum Master is a lightweight project management role.

Would you make your best developer your project manager? Hopefully not, unless that person was even more valuable to the company as a project manager.

Choose your Scrum Master using the same criteria as you would a project manager, and leave your best developers developing if that is where they are most valuable to the company.

This just in..

[OneSmartFellow]

..Agile is a crock of shit, news at 11:00.

nothing to do with scrum

[Uzik2]

Managers that try to code are nothing new and not a scrum only problem. If they have the desire to manage then they're not hard core coders and you're better off moving them to management and making space for dedicated professionals. If they're not your manager then you can show your velocity graph to management. If they ignore it then it's their problem. So if you're really into this management stuff you're not a hard core coder either. Why don't you suggest yourself for management and show them your great ideas.

Re:nothing to do with scrum

[Coeurderoy]

Cool so only people that are not so good in doing what the group is doing (coding) should have an opportunity to manage (and the pay raise it implies)..
that is very "agile" indeed...

can I show a speeding ticket instead of a velocity graph ?

Re:nothing to do with scrum

[Uzik2]

* If they're interested in management then perhaps they should be doing management instead of coding. Sounds like they'll be happier and you'll get better code if you get someone who loves it.
* Why do you care if they get a pay raise? The money doesn't come from your pocket. That's jealousy, not a rational reason.
* Who cares if it holds to some arbitrary principles someone set out? They're not perfect and certainly not inviolate.

Re:nothing to do with scrum

[Coeurderoy]

Some people are actually good in management, but being bad in coding is not a prerequisite, nor guaranties to be good in management.

Of course the money comes or would come from my pocket, first of all because I was regularly paying the salaries of the teams. And as a "consumer" I'm paying for the products that are built using IT (more or less everything at some level), so if IT is expensively done, I (we all) pay.
Well "agile" programmers have a strong tendency to present themselves as "perfect and inviolate", of course the irritation is only temporary, sooner or latter reality will check back in...

Re:nothing to do with scrum

[Uzik2]

>Some people are actually good in management, but being bad in coding is not a prerequisite

If they like management better, and that's what interests them, then they should do that instead. They'll do a better job and enjoy it more.

>I was regularly paying the salaries of the teams.

If you were paying the salaries you could decide who got raises and who didn't. You portrayed yourself as a coworker jealous of someone else's raise. Your comments don't make sense. If you do pay the salaries then don't give out raises.

> And as a "consumer" I'm paying for the products that are built using IT

Nonsense. If I don't buy anything from company X then I don't pay any of their salaries unless they're a legal monopoly and I'm forced to pay for them through taxes. Even then my contribution is so miniscule as to be immaterial. I probably waste more money on sodas I didn't finish.

You're emotionally invested and you're making up rationalizations for why you should have this attitude after the fact.

A question

[thePowerOfGrayskull]

How come we only ever hear about agile failures?

Scrum ... isn't this how OSS works?

[Lemming Mark]

I had a friend tell me how great and productive scrum development worked. His description, though, sounded basically like the model that many OSS projects evolve towards: instead of monolithically specifying the product, you do things in a set of short-term development sprints focused on finishing off selected features. Sounds very much like the operation of all the OSS projects (Linux being a particularly strong example) which do short, deadline-based releases and include whatever features are done.

To me this seems more like a formal version of what many programmers are naturally inclined to do, as opposed to imposing a structure of what they "should" do, as in waterfall for instance. Is this a good thing? I don't know.

Re:Scrum ... isn't this how OSS works?

[ADRA]

OSS projects don't generally plan to have feature X, Y, and Z added and working within N weeks/months. OSS usually works by having John, Laura, and Paul submitting some random fix that they decided to spend time on, and if the fixes are sufficient enough for production use, those patches make it into the next release. Having fixed schedules doesn't make OSS == Agile.

I'm not really much of an agile proponent, but without a predetermined goal for what the next release is going to have, then getting the contributors to work feverishly on specific parts of the code that really need improvement is hard. Really large projects like fedora have something like https://fedoraproject.org/wiki/Releases/12/FeatureList which they chip away at through releases, but I don't believe that many small projects I've seen have such targeted collaboration goals.

Re:Scrum ... isn't this how OSS works?

[Lemming Mark]

OK, so the distinction is that scrum has agreed goals (from an outside source) that the team will work on getting done in time for the deadline? Whereas in OSS generally the developers decide the goals themselves. Makes sense. There's quite a similarity but the OSS stuff relatively undirected I guess!

Re:Scrum ... isn't this how OSS works?

[ADRA]

you got it =)

Re:Scrum ... isn't this how OSS works?

[Lemming Mark]

Actually, I now remember the other thing which I should resembled the "release early, release often" aspects of OSS - IIRC part of the point of scrum is a continual re-evaluation of what features are ready, what needs to be done next, etc. Except that, again, in OSS this is distributed.

I find it pretty interesting the way software development in companies increasingly seems to resemble the processes that have semi-naturally evolved in distributed open source projects.

Soo close

[ClosedSource]

Ah, you were doing so well and then you started talking about the uber programmer silver bullet. That's Old-Timey religion, but it's still religion.

But that's crazy talk

[NotSoHeavyD3]

[sarcasm on] I mean next thing you tell us is that we should break up long blocks of code into separate functions instead of writing 1 function that's between 1 and 2 thousand lines long.(Or that sections of repeated code should be replaced with a well named function.) Oh, and that we should give variables sensible names, not stuff like naming a stack "q". [sarcasm off]

Re:Russell, is that you?

[JustShootMe]

Hi Dave!!! Hee hee hee.

Re:DTFT! (Define That Fucking Term!)

[Anonymous Coward]

Here it is

Builds Shit That Works methodology

[codepunk]

I generally stick to the "Builds Shit That Works Methodology". Pretty much the same methodology that is used to
develop the linux kernel.

In reality what you find is one or two guys that actually build stuff and a half dozen cannot build shits running around claiming they know how (definition: Scrum Master).

Re:Oh, for fckn, sake...

[codepunk]

You are 100% correct, it is what I call the 90/10 rule. 90% of of the world talks shit and the other 10% can actually do shit. I don't care what shop
you walk into there are one or two developers actually capable of writing good code and getting things done, the rest are just along for
the ride.

rather the pastor than the commander

[vadmot]

I believe that the scrum master should be rather the pastor than the commander. The engineering talent simply is not relevant here. First this person should be able to convince the people (the managers and the team) to observe the scrum principles like the pastor do. Naturally this person should understand the scrum principles.

The scrum works. The IBM PC computer was created in 1980 actually by the scrum method with small self organizing team (12 persons) who operated on their own in a converted warehouse in remote Boca Raton, Florida with only quarterly corporate reviews.

Microsoft included agile method as one of the templates in their Team Foundation Server. Scott Ambler is now the Practice Leader Agile Development at IBM Corporation in the IBM Methods group. And finally Google implemented Scrum in Adwords. You may find the references in my site (the personal blog part) if you wish.

And yes the main problem is to convince the managers and the team that scrum is the trade off between the innovation freedom and the product delivery according to the schedule. Actually the problem is in the education and ambitions.

Not all managers are as wise as Ronald Reagan who used to said "Surround yourself with the best people you can find, delegate authority, and don't interfere as long as the policy you've decided upon is being carried out".

If there is no the strict schedule (like in most Google projects, or Open Source) all you need is the good people. However, if you have the schedule and deadline, you need the scrum.

Agile is much more then Scrum

[AgileMike]

Hey Guys I've been working on a software company that uses Agile Methodologies for software development for more than 8 years now. And let me tell you something about Agile and Scrum, for those that didn't get the full grasp of the concepts: Agile is a software development methodology that focus on iterations to rapidly getting working software, over process, tools and extensively comprehensive documentation, and also focus on the end users feedback during the software development iterations of the working software, to respond much faster, and within budget, to changes. This is a very short description of the Agile Manifesto that you can find on the web. The benefits of the Agile Methodology is not for manager to keep track of the coders productivity and control team or individual KPIs, but to focus on what it's important: to get working software that responds to the market/business or end users real needs. So instead of having a full and comprehensive 200 pages requirement's document at the beginning of the project, and take 1y and a half to deliver the first running version, you get a smaller and lighter version of the overall requirements, and present smaller working demos of the software every 2 weeks or 3 weeks, giving the change of the end users and the business itself provide their feedback, allowing to change the application in the next iterations, and with new requirements that usually didn't match the 200 page requirements document of the beginning of the project afterall. Regarding Scrum, Agile Software Development Methodologies is much more than just a 10 to 15 minutes scrum of the ongoing work. Scrum should be a very short status meeting to address how to overcome technical difficulties from the current iteration, and not just present a "how the project is going" report to managers. The Scrum Master is not necessarily a manager, but usually, due to it's experience, can also be a team leader. But it's main role in a Scrum is to drive the scrum, and focuses it to what's really important for that iteration to guarantee that all developers are aligned an on scheduled for the working (demo) software version. Usually, in the scrum, the Scrum Master shouldn't care if the developer has been coding fast or not, but he needs to provide immediate decisions or action items to address any presented problem. And even though this is definitely all about programming, adopting Agile Methodologies must be wide spread throughout at least the team using the methodology, but in the end, for the entire company R&D. In this blog there's also more information on the basic steps that a company should take to adopt the Agile Methodology, a concrete approach for Enterprise Rich Web Applications Using Agile Web Methodologies. In the end, the team or company, doesn't necessary needs to adopt all sets or rules and guidelines of the Agile Methodology. Like the methodology it self, it can be an iterative and ongoing process. Cheers

user a PM as SCRUM master, not a developer

[darkeye]

in our organization we simply employ a project manager as a SCRUM master, not a developer. this makes it easy for him to perform what a SCRUM master does, which is in fact a project management role. developers are happy, as the SCRUM part of the day really takes 10 minutes of their time, and then they go back to work (or to lunch) right after the SCRUM meeting.

Re:Oh, for fckn, sake...

[j741]

No process will improve on a (welcomed) shout across the room and reply coming back in 5 seconds.

That's great if your coding something small and used on only one system (like a console game), but if your product needs to work on a very wire range of variable systems, and your development team consists of more people than can sit in a single room, or is spread out over more than one physical building, this method simply does not work and some structured process becomes necessary.

What?

[Palshife]

Our scrums take less time than it took to read this article. Chances are you're doing it wrong.

Re:What a load of bullsh!t

[pclminion]

Pigs and chickens?? Are you f*cking kidding me?? Does any other engineering profession come up with crap like this? Do civil engineers sit around deciding who the ScrumMaster is going to be when they're gonna build a bridge.

It's facetious. Most people don't use those terms on a daily basis. The distinction between pigs and chickens is basically between who defines the priorities and who executes the workload. Also, chickens can't talk in the daily meetings. What this actually means is that the managers don't get to yell at you during the daily standup. Who the hell would say THAT's a bad thing?

Re:Oh, for fckn, sake...

[node159]

And this only works for small teams you will notice. Scale the team up for a big project, add some junior people and the whole pony show falls apart, fast.

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

Re:Scrum master = Project manager!!!!!

[frosty_tsm]

Mod parent up!

The team I work on does scrum and our scrum master is effectively a project manager. The interaction with other teams in the company; making decisions on priorities; holding people accountable... these are things you can't leave to an intern who will be steamrolled by seasoned engineers. At the same time, the skill set is different from engineering, so don't waste the best and brightest engineer in a role that doesn't necessarily match their skill set.

Re:Scrum master = Project manager!!!!!

[publiclurker]

Exactly. One of the main purpose of the scrum master is to see that any roadblocks interfering with the groups tasks get resolved. Ad any place where I've worked, that is also one of the main jobs of the project manager.

Re:Scrum master = Project manager!!!!!

[Zenin]

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:Scrum master = Project manager!!!!!

[JrOldPhart]

So you are saying that a scrum master is supplementary role like grammar-nazi. Little if any added value.

Seems that Continuous improvement would dictate the elimination of that role.

Re:Scrum master = Project manager!!!!!

[plover]

Exactly. One of the main purpose of the scrum master is to see that any roadblocks interfering with the groups tasks get resolved. Ad any place where I've worked, that is also one of the main jobs of the project manager.

As opposed to where I work, where putting up roadblocks to tasks seems to be the job of all of the project managers...

Re:Scrum master = Project manager!!!!!

[Jack9]

Experience will show you that doesn't work. In fact, that's what the summary is talking about. People who don't understand Agile try to "adapt" it when it's not just the same waterfall process with different names.

Re:Scrum master = Project manager!!!!!

[publiclurker]

Sounds like you have managed to combine project managers and product managers. I dealt with that once. Definitely a bad combination.

Re:Scrum master = Project manager!!!!!

[Uniquitous]

Yeah, I got caught in this trap. Spent a year and a half attending meetings, wrangling the schedule, doing requirements... and then when the time comes that the team needed me to wade back into the code with them, surprise! I was completely unfamiliar with the codebase and unable to do much but "ramp up", which is useless in a crunch. I got the hell out of there and to this day make it clear: I'm a coder. I write code. Things have gone smoothly ever since!

Re:Scrum master = Project manager!!!!!

[Keynan]

Scrum master = Project manager!!!!!

NO

Scrum master = Team Lead

Product Owner = Project Manager

Re:Scrum master = Project manager!!!!!

[angel'o'sphere]

The ScrumMaster is not the project manager! He might assist the project manager, but he usually does not do that himself. The ScrumMaster helps introducing Scrum or managing the Scrum part of the project, nothing else. But: the project manager can be the ScrumMaster.

angel'o'sphere

Re:DTFT! (Define That Fucking Term!)

[jgrahn]

I'd point out the successful projects on my CV, and then point out that they were all accomplished using common sense - not some bullshit laden methodology of the week. My "methodogy" if you can call it that? KISS.

Scrum isn't all that bullshit-laden. I haven't used it, but during a presentation I was at, I remember going "oh, this makes sense" or "this is already what I'm trying to do". And I'm not exactly known for loving new methodologies and buzzwords ...

Of course, people will still fuck it up -- some by being overly cynical, others by trying to bend it so that their role is whatever it always was, customers who really still want the same detailed pseudo-control that they always used to have ...

Agile = Self managing teams

[spectro]

SCRUM like other Agile methodologies is about self managing teams, that means the "team lead" or "manager" positions are no longer needed. The team makes all decisions concerning the project they deliver. This is the key point and the hardest for everybody to understand. People don't like having to let go of their power.

The scrummaster is just a facilitator of the process and it is highly recommended for him to go through scrummaster certification training. A properly trained scrummaster can lead several SCRUM teams. Hire a experienced scrummaster and send your senior developers back to what they do the best.

SCRUM is so simple most people complicate it.

Google Tech Talk about Scrum from Ken Schwaber

[file_reaper]

Here's the Google Techtalk, for those like me who have no idea of what Scrum is...

Scrum et al on Youtube

http://www.youtube.com/watch?v=IyNPeTn8fpo

Cheers,

Spot on, but entirely missed the point

[Envy Life]

You are spot on, yet conveniently overlook the fact that most developers are not the "best" and all these methodologies are there to get the other, say, 90% of the IT workforce productive.

The original poster's complaint is the removal of that top 10% talent from what they do best into an administrative job that can be performed by anyone off the street who can follow a 10-point checklist every day (which is why Scrum is popular yet ironically never implemented correctly). It's a management blunder of the worst kind.

Please Mod this up

[HalWasRight]

Best reply I've seen yet. Someone please mod this up!

Re:Please Mod this up

[wurp]

Thanks!

If you can name your development process ...

[BitZtream]

you are doing it wrong.

No one way is 'the right way' and this retarded idea that you follow someone elses method and tout how you use the 'XXX' process is a outstanding sign that you actually don't know what you are doing and are just following someone elses example trying to shoe horn it into your situation because you can't manage the development process yourself.

It's More Than Coding - Start At the Beginning

[LDorman]

The issue with adopting agile / scrum is that it's a lot more complex than just giving a few people some new roles, reading a book, and then magic happens.

You have to start with management who is completely committed to the switchover. A few have responded that their management 'used' the process in their experience. This obviously doesn't work.

There have also been several who have said the problem is that everyone around them is stupid or that management just needs to go get a few cowboys and get rid of everyone else. These are naive soles making this statement. The cowboys and the ones who are otherwise full of themselves are one of the biggest problems in forming a successful and productive development team. Management has to be ready to let some people go when switching over to agile/scrum. There are simply people who don't know how to play with others in the sandbox and they don't meet the requirements for what is trying to be achieved. The script-kiddies who are scoffing at even the discussion of agile/scrum and the various terms can be removed from the conversation immediately.

More effort needs to be put in up front on truly educating everyone on agile/scrum and determining what a particular shop's implementation will look like at the onset. Get someone in-house which really knows this stuff to help answer questions and to mentor. Invest the time up front to do some team building and to identify those people who are entrenching in an effort to protect their fiefdoms.

Finally, everyone has to be open to change. A particular setup that works in one shop may not work as well in the next shop. The entire setup itself must be agile and must be constantly refactored - agile/scrum is about much more than just the code.

Now... to talk about the question that was posed: Is it a bastardization of scrum and an otherwise poor decision to use your senior developers as scrum masters? There is no set answer to this because of all of the dynamics mentioned above. I would personally be suspect of a situation where the senior developers were just randomly made the scrum masters because the are the senior developers.

Scrum master is an important role which needs qualified people filling it. If your senior developers are truly qualified and that is the role they wish to play in the team, then the should not be forbidden from doing so. However, in many cases the uber-coders do not have the skills to be scrum masters. You can have a brilliant teacher who can't explain quantum mechanics (and doesn't need to) and you can have a brilliant scientist (who understands quantum mechanics) who can't teach. They can both serve spectacularly in the proper context and both will fail utterly in the wrong context.

It sounds like your company needs to invest in having a qualified and experience agile / scrum expert come in to assess the situation and consult on the appropriate changes. If management resists the changes then the problem has been identified and there probably isn't much that is going to succeed until that problem has been overcome. Otherwise, if there are some individuals in the way then those individuals need to be given the pep-talk of they can either work in the new environment and where it is going or they are free to explore the market for a place they are more comfortable with.

New Methodology

[Organic Brain Damage]

At my company, we've invented and successfully implemented a new software development methodology. We call it Acelvolution. We only hire pre-pubescent humans in programming roles. We have a cadre of experienced testers. We carefully test and log all the software defects.

Once per quarter, we run a report on the defect base. We sort the developers in a list by number of defects per widget, descending, then we murder the top 10%. The bottom 10%, or the ones that produce the fewest defects per widget, are given sexual maturity hormones and encouraged to reproduce. The rest of them are given hormone treatments to retard sexual maturity and encouraged to work harder making fewer mistakes. Our standard software developer employment contract gives the company right of first refusal hiring our developers offspring. After only 17 generations, we are proud to report that our software defect rate per widget has declined by 34%.

Acelvolution. You're going to hear a lot about this new methodology in the next 5 years.

What.

[Cooldrew]

Am I the only one that didn't understand a damn thing in that post? Are you playing rugby in your office?

flamebait?

[Gary W. Longsine]

Like the entire discussion isn't flamebait. Moderator, I challenge you to enter into a discussion with me regarding the management of software development teams, and Agile methodologies. Obviously you are not aware that the first practice of nearly every agile methodology is assembling a competent team. Agile methods specifically reject the notion that you can take random people and assemble a team to develop software efficiency. The person who submitted the original discussion topic doesn't show many signs of being an appropriate member of an agile team. I'd fire him, first.

Re:flamebait?

[Hognoxious]

Obviously you are not aware that the first practice of nearly every agile methodology is assembling a competent team.

But then the methodology is irrelevant. I could be a pretty competent football manager and a tactical genius if I was put in charge of Real Madrid or Manchester United.

All methodologies are there to try and get something almost usable out of mediocre developers which, statistically, the majority are. Which is why they continue to be popular - because, statistically, it's the mediocre ones most projects are staffed with.

It's Taylor and Ford reapplied.

7 steps to every problem

[johncandale]

I hate people who think there are 7 steps to every problem and the like. There are too many variables in too many combination's in a project for these things to work. Budget, timeline, skill lvls, peoples lives and personalities Either the guidelines are too simple or they are so long and complex as to become useless for it's intent, like union laws, or such.

Scrum - weak leaders

[nicholdraper]

You obviously have weak leaders in your company. Take charge, insist that they make you scrum master, raise your pay and fire the dead weight. If they don't do what you say, use every available means of persuasion, coercion, threats and violence to get what you want. Whatever you do, don't post whinny "my manager doesn't do what I want" on slashdot. Be a man.

Re:Oh, for fckn, sake...

[shutdown -p now]

For larger projects, you scale it up by subdividing it in parts, and having separate teams working on them. Pretty much how it has always been done in virtually every area, not just software development.

Re:Oh, for fckn, sake...

[shutdown -p now]

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.

Well said, sir.

Now, can you please write a book about this "revolutionary new method"? You'll have to come up with some new catchy buzzword for that; I wish you could just call it "sane software development", but I'm afraid that won't sell, and we really, really need this to become the next silver bullet of the day to get actual work done.

My experience

[mpfife]

I have worked in groups and looked at a few companies that do Scrum and agile development. My experience has been this:

1. If a job constantly touts they are a house that focuses on agile development - this doesn't necessarily mean they do or don't focus on agile development. What I found it usually means is they are probably going to work your *ss off and they're going to expect long hours from you every week to meet your task lists. Beware, and ask lots of questions about how many hours the average person works and how long they stay with the company.
2. Until you get really good at estimating your project times AND the ability to accept/deny your tasks, you'll likely be overcommitted for sprint work. This is the number one problem I've seen in most of the agile/scrumm groups I've seen. Sure you can push a little harder for some sprints, but make sure you can get 'easy' sprints too. Life isn't all about work.

As for the original poster - I would say what other have said. The scrumm master should be a good project manager. It's ultimately a more management position than a developer position. Lead devs might not be good at this because they like being devs, and this role is about managine people, productivity, and output. That said, it shouldn't be an intern either. They lack the necessary experience of working on projects and the foils that come up. The project manager needs to have the strength and wisdom to push back on new requirements during the middle of development. They need to be able to go to bat for their team to protect them from unreasonable external requests, while at the same time pushing internally to see those that are floundering and those that need a boot in the rear. This requires tact and experience with people. So maybe it shouldn't be an engineer at all. :)

Re:DTFT! (Define That Fucking Term!)

[1729]

Seriously, you code for a living and have never heard of scrum? Do you not keep up with the latest fashion in development?

I can't speak for the OP, but I'm far too busy getting real work done.

What will you do when you if you have to go for another job and the interviewer asks you about the latest development methodology that is doing the rounds?

I'll try to keep a straight face while I tack on $20k to my minimum salary requirement.

Tech Gurus are bad at Scrum Mastering

[Handyman]

We've been doing Scrum for a while now at my company, and one of the conclusions we've reached is that you should never make the tech gurus the scrum masters. And that conclusion is totally independent from who you *do* want to make scrum masters, just don't pick the technical guru. The reason? Tech gurus tend to be the technical core of the team, everbody asks them deep technical questions all day long, they also have the responsibility of building the most complex technical features that nobody else can really do, which means that they spend their days entrenched in the core technical stuff of the project *which is exactly the opposite of where the scrum master should be*. The scrum master should, ideally:

1. Be able to keep some distance, what we call a "helicopter view". (Note how being entrenched in technical details doesn't fit well here?)

2. Consider the progress of items and tell people when they have unrealistic estimates of whether their items are likely to be "done" at the end of the Sprint, according to the Definition of Done that was agreed on with the Product Owner. (Again, something that requires not being entrenched in the details of technical stuff.)

3. Be able to talk to management about items on a functional level, and be able to think along with them about prioritization. (This is again something that requires more of a functional view on things.)

4. Understand enough about the technical parts to be part of the team -- the scrum master should only need half a word from his team members to understand why something is a problem. You don't want a scrum master who is to be "massaged" by team members in order to get something done, like you would have to do with a PHB.

Point 1-3 disqualifies techies, point 4 disqualifies professional project manages. Ideally, you would find somebody on the team who is not a tech guru, but also not a tech dummy; and you would find somebody who takes an interest in procedural and functional issues.

Just to state the obvious: the most important thing about Agile is that you do retrospectives: you have to think about what works and what doesn't, and fix up your process. We've been continually fixing up our process over the past couple of years, and there's *always* things that still need improvement. If the poster has to go here in order to discuss this, his team doesn't have this very basic and über important part of Agile down.

I am a dev turned scrum master

[Qbertino]

We're pretty much in a simular situation. We chose scrum because we need *some* sort of methodology because our company is growing fast (currently +100 people per year, we're at 300 now). Scrum isn't that ideal for large companies, but since we develop software which changes requirements along the way - games - it's not the worst either. As a seasoned dev it bothers me that I have to do scrum housekeeping part-time and can't spend that time devloping. However I *do* develop and I find that someone has to do the scrum master job, it might as well be the experienced guy on our team. I sit in the same office as our team lead and we've got the seperation of roles pretty well established. My job boils down to going around and keeping up awarenes of our release cycles and project progress tracking and the occasional tooling and process optimisation. I also play a key role when assembling backlogs for the team (including me and the teamlead) and have taken on the grunt work of building loadtests for our app.

It's all about management, and while it sucks to be a manager if you've been a dev for the longest part of your life, it's something that needs to be done and it's better if I can project my experience to the team if I have a key role.

As far as I can see scrum evolving at our place, it's basically a tool to gradually force awareness and responsebilty on to the devs. They learn to predict their time needed and our product owners (teamlead and gamedesigner, both are also part of the team) learn to hone their featuritis and bad prioritising.

I found certain rules to be paramount for implementing a process - of whatever type that may be:

1) The process is for you and your peers. It's not you for the process.

2) If there's no improvement for the people involved, the process is worthless.

3) Personal interaction and communication come first. Tools come very last, if at all. (We use a TWiki for all our Scrum stuff. It has be building the burndowns with calc, but it had us hop into scrum with a zero-fuss approach). I might start looking into Agilo/Trac, but I'm sure as hell not bending over and lubing up for some tool that doesn't fit our variant of the process. ... There's some advantage in being a scrum master and having a say in such things as tooling.

4) Know why you are doing scrum and what you want to achieve with it. If you don't have a target it's pointless in a strange self serving way and will implode after a few weeks. Or it will stay and become a drag, which is even worse.

5) Be aware of the partly pointlessness of an agile process in a large corporation and judge the process accordingly. Don't over or undervalue it.

6) Bend the process, tooling and proceedures whenever required. Use the sprint intervals, backlog assembly meetings and sprint reviews to do so.

7) If you are a scrum master, be prepared to kick the ass of your teamlead or product owners if they step out of line or leave the predefined track of rules required for the team to deliver per-sprint predictable results.

8) You may think that you are the superdev, but as they say the first step to a nervous breakdown is overesstimating your importance. Management is a sacrifice, you step back to have the others do the fun stuff. Therefore you get to manage and learn the metaprocess and see how the really big software projects come to life. Moving from dev to scrum master isn't an end all and it does improve your social skills. And you can still start an open source project on the side, if you miss coding.

In my first job...

[GWBasic]

In my first job out of college I made sure that the code built cleanly, and beat people over the head to keep their unit tests running well. I refused to accept any unit tests that had undocumented dependencies; although I was perfectly happy with a short paragraph or two in a README.

The more senior developers had better things to do then worry about running builds and keeping the unit tests clean.

No love for Agile and scrum on slashdot?

[StrawberryFrog]

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:No love for Agile and scrum on slashdot?

[Edgewize]

New ideas? Please.

The right way to manage a large problem is to periodically examine your processes, figure out the flaws and bottlenecks, and fix them. This is as old as time itself. Agile and Scrum just slap new buzzwords on old ideas, and their proponents act as if they have invented a cure for cancer.

If your business was failing under its old methodology, changing to "agile methods" is not going to help, except maybe as a catalyst to get your dinosaurs to quit in frustration over the meaningless jingo. The problem is that your business was unable to self-identify its flaws and correct them.

Nobody fails because they haven't heard of agile methods. Nobody fails because they honestly believe that a single "waterfall" cycle is the correct way to run a large project.

People and projects fail because they get locked into a specific process without any effort to identify and correct flaws in that process. Scrum is just one more process that you can be blindly locked into.

Re:No love for Agile and scrum on slashdot?

[StrawberryFrog]

The right way to manage a large problem is to periodically examine your processes, figure out the flaws and bottlenecks, and fix them.

While I agree with that, there's a lot of merit in packaging up some common sense and nest practice (that few people in fact do, sense not being all that common). It gives developers an excuse to do the right thing. It also gives them a buzzword to offer up to management.

Nobody fails because they honestly believe that a single "waterfall" cycle is the correct way to run a large project.

I disagree. If you honestly believe that a single "waterfall" cycle is the correct way to run a large project, then you will fail. The last time I saw it happen up close was late 1990s, but it's most likely happening somewhere right now.

Washing the hog

[FatherDale]

My boss sat me down at my first terminal in 1977, so I've been in the IT business for more than three decades. In that time, I have seen mass quantities of jargon-laden, content-free paragraphs. Now I've seen several more. There must be a market for that.

This is why I hate one of the Agile Dogmas

[NotSoHeavyD3]

The one that says working code is more important than extensive documentation. I know what that says but I know how developers will interpret it, "Don't worry about docs." There's the problem, the last thing you want to do is encourage a developer to do is skimp on the documentation since that's their natural tendency anyways. I've never met a developer where I thought "Wow, he or she documents too much." (To be fair some devs are decent about docs) It's maddening when you have to come back to the code for some updates and nobody knows what it's supposed to do since nobody bothered to write it down. (Let alone extend it.)

In my humble opinion...

[jarich]

Many, many "Agile" teams are really just using the buzzword... saw it in a magazine (or on Slashdot!), and thought it sounded good. They pick the one practice they like, ignore all the rest, then blame "Agile" when it fails. (It's really "frAgile", not Agile, but that's another post).

In the OP's question, he wondered whether promoting great developers into a non-technical role was a good idea. It's the same age-old question about developers becoming managers. And the answer is? Almost always a horrible idea. Hire the skills. Find someone who wants to learn it. Don't do automatic promotions. In other words, THINK!

No pro sports player would try to play their sport without a coach, but developers try to pick up new techniques all the time by ourselves. Sometimes it works... sometimes, you need an expert to help you figure it out as quickly as possible. Team-wide (and company wide!) process changes are the times you always need a coach. Bring in an expert and solve these problems before you run into them.

Re:In my humble opinion...

[Fulcrum of Evil]

Not to put too fine a point on it, but pro sports players usually make a lot of money and do the same thing year after year. As a developer, I make decent money, but i do different things each year, and I don't compete with some other team (not directly, anyway). If you bumped me up to $350k and paired me with 3-4 other people, we could totally justify a coach to push us and try new things. Of course, it's easier to work really hard when there's an off season that you can use for fishing or whatever.

Re:Oh, for fckn, sake...

[Stiletto]

I love how that was modded insightful.

You might be seeing "good code" being written, but that doesn't mean you are seeing a good product being produced. If "good code" (whatever that means) was all it took to produce a successful product, you wouldn't see so many disastrous failed products out there.

Saying "Good software products = good code" is like saying "Good cars = strong metal". It's totally over-simplified.

If you want to create a successful software product, instead of whatever 10,000 line toy your 4 man team put together by shouting across the room, you probably ought to consider one or more of:

  * requirements
  * a functional specification
  * a design document
  * a plan that includes a schedule with milestones
  * documented use cases
  * end user documentation
  * system-level class-level and method documentation
  * configuration management
  * scheduled code reviews
  * unit testing
  * integration testing
  * a formal quality assurance procedure
  * a deployment plan

oh, and "good code" might help, I guess. I'm of the mind that with the right amount of management, organization, process, design, and documentation, actual "programming" is just glorified data entry.

The Wheel is turning

[chicago_scott]

Shut up and code :-)

Yup...which is why SCRUM

[meburke]

..and Agile development are not always the best choices for development. My solution is really a cure for a situation where Agile?SCRUM has already failed.

Re:Oh, for fckn, sake...

[KZigurs]

"I'm of the mind that with the right amount of management, organization, process, design, and documentation, actual "programming" is just glorified data entry."
And perhaps you are wrong. Although if you do feel that programming can be reduced to glorified data entry, well, sometimes development is a bit more than just mucking around with the api calls in your preferred java IDE... Couple of points follows.

Good managers are much harder to come by than good developers. If you feel otherwise, I would be happy to see reasonable arguments - as far as I am concerned I have met/seen/worked with only three or, maybe, four competent technical managers versus at least ten to fifteen competent developers (sometimes you do not appreciate it until later, so, less precise here ;)). Strangely enough there is some overlap between two sets. And here is the catch - bad developers are way easier to spot than bad managers - there actually is something measurable and no (often used) buffer to fall back to.

I do not dispute any of the things you listed, not by a long shot, just the form. In example - any company that focuses on documentation or formal QA - with all due respect, as far as I am concerned, is an excellent indicator of company that believes that there are tasks that can be delegated to 'junior' developers for cost reasons. Or the great big outsorcing to a team that might be part of the company or might not, but somehow are supposed to have an idea of everything that happens. Oh, and let us add a framework or two for that too. Similar to functional specifications, scheduled code reviews or design.

Software development is a game of context. Large context and it isn't going to become any smaller regardless of what you do. Unless you can reasonably well predict the effect of your innocent change in that pl/sql procedure feeding cgi handled C frontend pretending to be an RPC bound UI abstraction, all you are doing is taking stabs in the dark - no level of abstraction, interfaces or glue layers will help if the underlying assumption about using base 16 for all color values or cents stored as integers rounded to nearest 1/1000th turns out not to match whatever conversion/calculations/assumptions are done en-route. Scope-wise context while developing software is at least as large as actual business decisions, with the only difference being that when working with software most of the variables can at least be predicted. Financial impact by both can be pretty similar as some might have noticed. Oh, and you know what - good developers are perfectly capable to factor in business context in their work too. In fact, perhaps, it could be argued, that when developer/team actually is informed why any particular deadline has to be met or any particular feature is a must-have instead of being an ugly hack shoved in the last minute, better results follow. Perhaps worse code, since yes, for this deadline this particular hack could be allowed, but better results for sure.

I have nothing against anything you listed, all are absolute basics. And I couldn't imagine to work without proper, hot, intense and pouring jiras all over my inbox QA anymore, althou it should be noted that in my experience not always what managers think can be called a QA has anything to do with quality or assurance, quite often it is just an arbitrary signoff with no contribution whatsoever justifying some manager somwhere. Same for design documentation - a quick scratch on a napkin can, and often will be miles more valuable than your 500 page reiteration of buzzwords and copy-pasta of latest hot frameworks API - someone actually bothered to discuss what to do and how to proceed while only thing around was a napkin. Your plan with schedule and milestones is worthless - show me a single plan that actually matched reality, with the exception of those where you ended up with nice and comfortable 4-8 hour tasks and on every developers status meeting everyone was happily nodding that this is _exactly_ what they are working on 30.25% of

Re:Oh, for fckn, sake...

[KZigurs]

You introduce junior ('cheap') people, and yes, you do screw up. There is nothing less insulting for a good developer than to see management covering up shit for a bad hire.

Re:Oh, for fckn, sake...

[KZigurs]

You missed the point. I do not advocate against process, I advocate against 'Process (signed off by board, three dev-leads and four external consultants)'. Anyone worth 2p will set up a process as soon as they touch anything. Even you have a process to take a piss - you unzip first, pull out second, do your stuff and then kinda clean up. In software development you often need to get 3 signatures and documented trail in your e-mail just to unzip :) And god forbid you even imagine thinking about letting it go without board approval!

methodology

[Gary W. Longsine]

"But then the methodology is irrelevant. I could be a pretty competent football manager and a tactical genius if I was put in charge of Real Madrid or Manchester United."

No, you could be lucky. A good manager and a good team can still screw it up. Methodology cannot turn a team of "mediocre" developers into a great development team.