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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

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

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

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

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

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

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

[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

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

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

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.

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.

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

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?

Buzzword Bingo

[Attila Dimedici]

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

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.

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.

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.

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.

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

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.

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

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.

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

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

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,

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.

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.

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?