Agile Failure Patterns in Organizations

https://age-of-product.com/agile-failure-patterns-in-organizations/

by swolpers • 11 years ago

58 82 11 years ago

kraftman4• 11 years ago

Does anyone else find this hard to read? Small grey type on a white background makes it look more like terms and conditions than an article.

kelvin0• 11 years ago

Dude, at least pretend to comment on the content and as a side note, comment on the form. How would you feel if someone commented that way on a matter you wrote about concerning an issue you consider important?

jboons• 11 years ago

The way in which you communicate your important issue is probably equally important.

kraftman4• 11 years ago

I'd appreciate the feedback and I'd try and make it more comfortable to read.

dean• 11 years ago

Have you never come across a site that looked so shitty, that you just left, thinking there could be nothing valuable there? This site is like that. And having to click through the popup, after first scanning it for the extremely non-obvious link, well that just makes the site sleazy. These things lend credibility or take it away.

zoner• 11 years ago

Yes, one of the sites I have to use an user css.

Otherwise painfully high number of failure points are true in the place I'm working, so a good article to show the management on the next scrum meeting (some point in the next two months) :)

kraftman4• 11 years ago

Probably a dumb question but how do you apply your own css? With a browser plugin?

m0nty2• 11 years ago

I clicked out as soon as that blue rectangle completely obscured my view of the page, which I was already struggling to read anyway (not just because of the contrast - it was a very listy article). Why do so many publishers think a popup is acceptable just because it's now called an interstitial, not a popup?

squeaky-clean• 11 years ago

One my phone I thought it was tough to read. Now that I've opened it on my PC, it's practically impossible to read.

demian3• 11 years ago

"Culture of Failure"

Good luck selling that to upper management.

On the contrary, quick iterations are about reducing the risk of building the wrong thing. Of course in the normal "blaming" corporate culture this won't work, because departments are always competing over budget and deliverables that are not "perfect" will be used as ammunition against the department where the product came from.

mathgeek2• 11 years ago

I usually prefer to call it "culture of learning to get back up again after falling."

demian3• 11 years ago

Just "Culture of Learning" sounds great.

swolpers3• 11 years ago

Good one; I amended the original text.

techterrier2• 11 years ago

On the other hand those types do love them a bit of darwinian language. Call it 'Aggressive pursuit of fitness" or something.

demian3• 11 years ago

Not really into using darwinian language, but I like the focus on fitness.

It may work better for customer-facing products ("Market Fit" is a thing), but It may be harder to sell it for internal products ("Functional Fit"?)

noarchy5• 11 years ago

More of the "No True Scotsman" apologia for why Agile fails so often. I especially liked this gem:

Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones.

I can't say I'd feel bad if a failed, Agile approach was not in my comfort zone.

DanielBMarkham2• 11 years ago

As somebody who uses this argument, and somebody who cares about reasoned debate, I must disagree.

Agile is not a standard. There is no class, there are no tests, and there is no governing body to determine whether you are agile or not.

As such, it's just a marketing term around best practices in iterative and incremental development. Along with XP and the latest hotness in CI/CD/DevOps/etc, it's where you go to see how the cool kids are doing it.

Since it's "cool stuff that works most of the time in hi-tech teams", the real question here is this: are you trying new stuff? If so, are you trying stuff that seems to work for a lot of people?

If you are not, then, by definition, you are not "doing agile" (or however you want to phrase it). If you are, good for you! You still might suck, but at least you'll suck in different and interesting ways.

So in this case the writer is correct. The "No True Scotsman" label does not apply. There are no Scotsmen to begin with.

ADD: And of course the flip-side to my argument is also true. Don't get me started with the folks who think that simply because you're doing various Agile practices you should automatically be succeeding -- or the folks that think "if we were only doing Scrum the right way". I've had a lot of headaches there.

Tools exist to get work done. If the work is not getting done, use a different tool. "Agile" is simply the sign over the place in the hardware store we go to get certain kinds of tools. We understand and apply tools expertly, but we do not do work by spending all of our time and energy being focused on tools. Instead, good tools allow us to focus our time and energy on the problem.

noarchy5• 11 years ago

Of course it is a marketing term. There are enough people billing themselves out as Agile "coaches", or Scrum "consultants", that the marketing seems to be working. But if they aren't Scotsmen, they've done some great marketing to make people think that they are. So if you or your organization failed, it is because the wrong people were implementing it and/or you did it wrong.

incepted2• 11 years ago

there is no governing body to determine whether you are agile or not

Tell that to agile advocates who are always quick to point out that when a project using Agile fails, it's never Agile's fault, it's always because the team didn't apply Agile correctly.

It's the text book definition of "No True Scotsman".

deanCommie2• 11 years ago

Presuming that the approach in this situation is a failed one.

I've encountered extreme resistance from devs who have already made their mind about Agile ("just let me write some fucking code") and fought against the leanest of agile principles ("Hey, how about we try to only plan for 2-3 weeks ahead, aim to have something demoable, and then have a retrospective to see what we could do differently next time around?" "Pass.")

Fact is, too many developers think their job is to write code. It's not. It's to solve a customer problem. And if that problem can be solved with code, great. But since 99% of the time the customer doesn't know what their problem is, doesn't know how to explain it, or will change their mind once they see it, that is why agile principles were declared - to help developers deal with this challenge.

VLM3• 11 years ago

that is why agile principles were declared - to help developers deal with this challenge.

I've noticed that in practice everyone benefits from agile except the devs... The managers have new and extremely elaborate play acting to perform, dominance to new authority to vigorously enforce, and extensive new paperwork and reports and whiteboards to shuffle. The snake oil salesmen obviously love selling snake oil. The marketing and HR folk have a new feature nobody can deny they use because nobody knows what it is, its like being "customer focused" or "empowered", it means nothing and sounds nice therefore everyone does it. Customer svc has a great excuse, well, sure you have a bug, but now we have agile so surely there will never be any bugs in the future. The customers are told things will get better because of Agile and when things invariably get better for whatever reason, it was because of the wise application of agile and their wisdom in selecting an agile supplier. But what do the actual devs get out of it? Nothing, really.

Everything that happens around a plastic christmas tree is really cool and fuzzy and happy and the best thing to ever happen and the nicest time of the year and watch us drinking cups of eggnog while you stand there as a plastic christmas tree. And that's nice ... for everyone around the christmas tree. But with some empathy for the point of view of the plastic christmas tree itself, all the foolishness related to christmas, is kinda irrelevant to itself in it's tree-i-ness. The plastic christmas tree is having a lot of things done to it and around it but it is not affected in any way.

exelius4• 11 years ago

I absolutely disagree.

There is no "True Scotsman" argument against Agile, IMO because there is no such thing as "true Agile". The best description I've heard of Agile is that it is the bare minimum amount of project management you can do on a project and still be successful. Beyond that, it's all about what works for each team. The entire f-ing point of Agile is that it's a generic framework you can adapt to many different business contexts.

But there are still common reasons Agile methodologies fail. I don't know how many of these are really failures of "Agile" or just common mistakes that new teams in general make. But it doesn't really matter, because the two situations are often inextricable from each other.

noarchy5• 11 years ago

There is no "True Scotsman" argument against Agile, IMO because there is no such thing as "true Agile".

If Agile is so nebulous as a concept that it can't be defined (only vaguely described, at best), then perhaps it cannot fail. But it also cannot succeed, as it apparently doesn't exist.

There may be teams for whom these management methodologies work, and good for them. I am genuinely curious about how much the success or failure of these methods have been studied.

err4nt2• 11 years ago

There's a difference between what an ideology is at its core, and how it is practiced by humans.

In theory, christianity is a simple religion that strongly values charity, sacrifice for others, and selflessness. Yet when you look at people practicing christianity you see practices that go against these values. How can that be?

Agile sounds great on paper, the tough part is actually acting in a way that's truly agile, without acting in an 'agile way'.

Glide2• 11 years ago

I concur wholeheartedly.

I've had people claim that they do agile. No retrospectives or any kind of feedback loop in their processes. No modification of work tracking either. All of that customization was from the top. Basically breaking several core tenets right there... But I digress.

We really need to accept that delivering is difficult to do. Creating new teams is a _hard_ thing to do. Delivering a project on time when the team wasn't formed at the beginning and had no input into the timeline is difficult. No matter what methodology you use there are things that can kill the project.

lojack2• 11 years ago

Agile processes are either bent or ignored whenever it seems appropriate. There is a lack of process discipline.

This one I don't understand. Isn't it sort of the antithesis of the first core principle of the Agile manifesto? Shouldn't it be a _good_ thing that the processes are bent or ignored when appropriate.

err4nt2• 11 years ago

Whenever I meet people hiring for tech in Toronto They say things like: 'We practice XP, We apply agile to agile!", I hear "We have no idea what we're doing, and no idea how we're going about it but we will change it whether it's working or not and expect you to jump through a lot of hoops in addition to getting your work done"

I've seen offices with Gold stars for employees and these huge whiteboards filled with different milestones and benchmarks for projects. It looks great, but the difference is the work isn't getting finished. I feel like agile can create a smoke screen (if you're not careful) where you're too busy seeing how successfully you're on track with agile and miss the opportunities or failures that are happening in the real world to your product, instead of inside your process. You can be in great shape as far as agile goes, and still be losing customers because your work comes months too late.

To me, process should never be more important than product. I come from a graphic design background where process is very important to ensuring consistent results, but you can never fetishize the design process over the results it produces or else you end up with mediocre, commoditized design that is indistinguishable from the worst stuff coming out.

You couldn't pay me enough to deal with agile in the workplace, I feel like you'd have to toss an extra 50k on the top nd I doubt anybody would pay me an extra 50k just to deal with it, so I'll continue working with non-agile folks who manage to get stuff done, like professionals! Opportunity doesn't wait for standups, timeboxing (telling people when they are allowed to talk or not), and micromanagement.

jacques_chester2• 11 years ago

I feel like you're rejecting a strawman, rather than basing it on an honest "suspension of disbelief" experience at a well-regarded agile shop.

I joined Pivotal Labs a skeptic. Now I'm a proselyte.

dragonwriter4• 11 years ago

The Manifesto if vague enough that you can pull anything out of it, is not really a set of concrete standards. Generally, I think it's not good to break processes when individuals feel it is appropriate, because you then have no common reliable basis for expectations. It's good to have processes that are followed consistently but which are owned by the team and which the team together is free to modify and define exceptions to -- and where everyone is free to call a halt to have the team consider the need to address a process issue in the context of a current work item. At least that's my view, is also seems a fairly common approach in the Lean literature, which seems to be based on the same values as Agile, by be stronger on on concrete, high-level framework methodology. The Agile literature seems to jump from the Manifesto to lots of low-level processes and practices without as much attention to high-level approaches which really make concrete how to effectively empower people in teams, and manage the choice and adaptation of low-level processes in a way which really reflects the Manifesto's values.

lojack2• 11 years ago

My take on this (which may not necessarily conflict with your view) is that process exists to serve individuals and interactions. For example, the standup meeting is a common practice used to facilitate interaction amongst team members, and to bring forward issues an individual may be experiencing. However, there are teams out there that communicate really well outside of standups. Individuals bring up roadblocks early on. For these teams, standups are redundant... but they are core to most agile processes. In this case it makes sense to ignore that part of the process -- it just gets in the way.

In my opinion, process should _always_ be bent and ignored when appropriate. This doesn't mean that you shouldn't be disciplined, or that you should ignore process. Additionally, I think that questioning the process should be encouraged. To which, the author also says:

Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones.

To me, there's a fine line between rejecting something because it pushes you out of your comfort zone and rejecting something because it gets in the way of doing work. The fact that the author doesn't bring up the possibility that there are many valid reasons for rejecting methodology leads me to believe that he may himself be lumping anyone who disagrees with him into this category, which can be very dangerous. One shouldn't ignore the process just because you don't feel like it, but you also shouldn't blindly follow the process just because someone says that's the only way to stay disciplined.

swolpers3• 11 years ago

Let me explain this text with an example:

A team is working in Scrum mode – all systems GO, everything looks fine – when a deadline is approaching.

To meet this deadline at all costs, management decides to gather a task force including member from various other teams, thus overriding the Scrum process.

r0naa• 11 years ago

Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones.

I love how this equates critical thinking and complacency.

See? I can do it too.

incepted2• 11 years ago

Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones

Or maybe they have identified Agile for what it is: a snake oil methodology that's completely unproven, which sometimes works, sometimes doesn't and, regardless of the outcome is never blamed if the project fails.

Bit like a religion.

_dark_matter_• 11 years ago

they have identified Agile for what it is: a snake oil methodology that's completely unproven

Is this a common line of thought? I recently started working for a company that follows Agile and I thought it was generally accepted as the "next step" so to speak in software development. I didn't know that there was any resentment for it. Care to elaborate? Do others feel this way as well?

techterrier2• 11 years ago

It's certainly preferable to team of analysts spending 6 months writing specs, then engineers spending 12 months writing code, then 2 years spent testing and fixing things only to find out that while that's all been happening the internets been invented and the original product has no purpose.

Glide2• 11 years ago

It's important to remember the historical context for Agile. Agile grew up and started where there was Waterfall. From that viewpoint of Agile != Waterfall, it is a step forward.

There will always be resentment towards agile. There are too many botched attempts at making a methodology work from well-meaning but inept individuals that have effected lives and workplaces.

What's insane is the marketing around Agile and more specifically Scrum.

scarmig2• 11 years ago

Agile would be good if it existed as described and was a stable organizational mode.

In reality, every "Agile" place I've worked for really uses Agile-for-name-value-only, which amounts to daily half-hour long status reports on what you did yesterday and project deadlines that come from on high that have to be ratified pro forma by the engineering team.

Yes, I know that's not true Agile. Just like the USSR wasn't true socialism! Agile can never fail, it can only be failed.

m0nty2• 11 years ago

Where I work it seems to be a bit of a cargo cult, rather than an ethos of actively solving problems. We do standup meetings because sit-down ones wouldn't work. We use post-it notes on whiteboards because just writing on the whiteboard wouldn't work. We have sprints because just doing the job wouldn't work. All the trappings of agile, none of the results.

I'm not hostile to agile per se - it clearly does work. But not where I am, it's just another fad which will eventually be replaced by some other magic methodology.

pkaye• 11 years ago

In your experience, what kind of methodology do you think works?

ThomaszKrueger• 11 years ago

M'fcking programming. Never failed me.

joesmo3• 11 years ago

This is likely the number one reason for rejecting agile: it has already failed. I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do. What's worse, the process degrades into 30-60 minute "stand-ups" or "scrums" or whatever, eating into a good chunk of the day for absolutely negative gain (as it's mostly people talking about shit that's irrelevant to 90% of the team and wasting everyone's time because the "process" says they should). I've also seen it degrade into another reason for management to enforce deadlines in all places, including places that only employ deadlines when development is really behind schedule (as is all software development I've ever seen in the business world).

And what are the advantages? Little Joe over there in the corner can feel brave enough to speak up about his problem once a day? Seriously? Is this a process for the socially inept? Is that what we're trying to solve here? Disrupting the coding flow? Allowing the manager to be even more lazy in his contact with the team by limiting it to a few minutes a day (closer to 30 than 5)? Having it replace those couple of hours you could have spent designing your app with a few months of 16 hour bug-tracking right before release? Oh, please ... I think it's time to acknowledge the process doesn't work, that anyone can come up with hundreds of points showing why it doesn't, and that it's time to ditch this resource-wasting process altogether.

gregmac2• 11 years ago

I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do.
I think it's time to acknowledge the process doesn't work

Sure, if you don't actually do it, it doesn't work.

For example, you could say: "I've worked at over a dozen places claiming to be linux shops, but they don't have linux installed anywhere. I think it's time to acknowledge linux doesn't work."

Does this mean that agile itself is bad? No, it can and does work. It's just much harder to do correctly than it seems (eg: it takes more than reading a book, putting a Kanban board up, and having a daily "standup" meeting).

dragonwriter4• 11 years ago

I've worked at over a dozen places claiming to do agile and have found exactly zero that actually do.

Agile is, if it is anything, a set of values for selecting what you do, not a set of things you do. And a weakness in the Agile literature is that there is a lot that talks about things you could do (and a lot of it conflicts), but there is a lot less about how you make the values of the Agile manifesto concrete in selecting and adapting what you do (while its not specifically "Agile", there's a lot written on this that is applicable in an Agile context in the Lean methods literature -- Lean and Agile are directed at largely similar values, but Lean has stronger roots in process engineering and seems to have more focus on understanding why things work and how you know that they work.)

dragonwriter4• 11 years ago

Agile isn't a methodology, so it can't be a snake oil methodology. However, it's also not a set of quantifiable, unambiguously decidable metrics for evaluating a set of methodological choices, either, so a lot of different methodologies, some of them snake-oil, get sold as Agile (and some which aren't snake-oil get sold in a way which obscures the actual indications for use, which turns then into effectively snake-oil even when they have, underneath, something fundamentally sound.)

baconner• 11 years ago

I can appreciate where your comment probably comes from - it's absolutely been oversold at many organizations and there's an industry of scrum trainers and the like that oversell it. Against the standard of perfection no methodology works and none ever will I think. Software development is messy and complicated and difficult to put in a box.

Still agile doesn't claim to be a silver bullet. It's a loose collection of ideas about how to adapt to change and communicate better during development. Its just about strategies to contain the mess. Thats it.

On my teams I've seen great benefits from some things like sprint reviews but it has not magically produced high quality code or made customers love every product. We didn't try to saddle it with that expectation though. For me its enough that it's less painful than gigantic specs that are never quite correct but more visble than everyone just winging it and it gives us some checkpoints to tweak the process regularly to improve the way we work. That's an improvement imo.

If you treat it as a religion then yes it's going to be a big disappointment. The same is true for any methodology.

UK-AL• 11 years ago

I think trying to do a big bang deployment of scrum in a slow organisation bureaucratic organisation is probably a bad idea.

Probably best idea is something using kanban. Map the existing process using kanban. Find bottle necks, and fix the process. Start changing bits to it. Start using TDD, maybe user stories, maybe add "sprint" planning meetings.

You might not be implementing "true agile", but its better than complete disaster trying to enforce everything suddenly.

Also this comment he stated in the comments makes me uncomfortable.

"being uncomfortable committing to an outcome that’s time-boxed"

" sticking to a 5-to-9 mentality "

You shouldn't really being "commiting" to a time box. Its a guess, not a commitment. You use velocity to get better at the guess. If you miss, oh well lets get better at it next time by adjusting the story points in a sprint.

He makes sound like he expecting people to work overtime to meet a commitment. This is not recommended in scrum. You should have a normal work time mentality and work requirements should fit into normal hours. If you miss the "guess", you should adjust the next sprint to not include as much. If you work overtime to meet the commitment, you re-enforce the idea that it is ok to commit a overloaded amount of work to a sprint. Bad. Bad. Bad. That can be abused.

jahaja2• 11 years ago

Why would one adopt a methodology with so many pitfalls?

noxToken• 11 years ago

Other methodologies have their pitfalls as well, but agile is the methodology that many are adopting from the get-go or changing to. As such, it's head is on the chopping block. Developers are scrutinizing it to evaluate the trade-offs. You'll see people celebrating agile as if its the messiah to save all projects, and you'll see others decrying it as smoke and mirrors.

I think it's important that people are openly (not overly) critical of trends. It can help people make more informed decisions. The problem then lies with others trying to wade through vocal idiots masquerading as experts and legitimate information hidden in the cruft.

jahaja2• 11 years ago

Yupp, it's indeed the thing of the day. Reading that list I just wondered if using no apparent methodology would be any worse. I have a hard time rationalizing the almost theological adherence to software development methodologies in general.

canthonytucci• 11 years ago

I see a lot of people using "agile" and Scrum™ interchangeably. Am I just a deluded fool, or is the agile manifesto completely ignored in practice? People talk about "agile methodology" and I wonder "doesn't the manifesto explicitly reject all 'methodologies'?". I thought that was the point. The manifesto is pretty short already but more or less I understand it as " do what makes sense to you". It's open to interpretation, but that's the whole reason for its existence. If companies think there's a magic book or a system to rigidly define "what makes sense" for all teams on all projects, and that such a system can/should be purchased if only the idiots working for them would just follow the rules, they're doomed anyway.

pcurve• 11 years ago

I agree 100%. I work in a big corporate environment. The problem with Agile is, it doesn't seem to work in a big corporate environment that loves the followings:

1. Ability to plug and play bodies (PM, Dev, BA, offshore/outsource)

2. Having those bodies held accountable individually

3. Predictable process over progress or quality.

4. Layers of management.

VLM3• 11 years ago

With the minor correction that #1 also applies to divisions (east coast office vs west coast office) and cross shift (3rd shift ops has the same written procedures and instincts or whatever as 2nd or 1st shift ops).

Programming is a young profession. On the other hand, design and engineering and automation are old, and the giants got that way by following pcurve's list, more or less, not by inventing or implementing Agile. Therefore the higher people go in management and therefore the more abstracted they get get from the front line, the more likely they are to completely uninterested in Agile, as that's just not how big companies are run, even if it works for a ten person startup. So there's going to be a push from the top to call it whatever you want but when you interface with the exec suite you'll talk in terms of micromanaged waterfall because that's how we build jet engines here, or mining machines, or run a worldwide communications system, or whatever.

gregmac2• 11 years ago

I think you're bang-on. The trouble is approaching it as if it is some prescriptive methodology, where you can implement the processes and magically you're "agile". It doesn't help that several books, blogs and consultants try to convince you this is the case.

The reality is that agile is a philosophy, and there are some processes (like Scrum describes) that happen work well with it: but if you don't embrace the philosophy, the processes won't do anything.

This sounds a bit hand-wavey, but it has parallels to software itself: if you fix bugs without understanding their cause, you're doomed to keep "fixing" the same bugs over and over (since you're just fixing the symptoms). Likewise, if someone makes a feature request "I need a button here", and you just put a button where they ask without first asking "why?" and understanding the need, you end up building the wrong things and wasting everyone's time and money.

Personally, I'd say the most important things about implementing an agile process that seem to me to be the cause of many people's problems with agile are:

* Implement retrospectives, with the power granted to the team to change the process in whatever way makes sense

* Stop building systems or components, and start thinking about everything as user stories

Retrospectives are where you define YOUR agile process. When we started at my company, I think we did some fairly significant changes to our process at every retro for the few months, and often when someone new joins the team, process changes start coming up at retros again.

Building User stories is what really breaks out agile from waterfall. You still have to define the system to some degree (to have a sane architecture), but you don't have to actually build it. "As an administrator, I need to be able to create a new user" can be fully implemented before any code to edit or delete the user is written. Like most things, this is of course not black and white: if you don't define the system as a whole enough, you'll rewrite every feature over and over, or have an un-maintainable mess.

However, do it properly, and you get working (if incomplete, from a market perspective) software faster. The real benefit comes from doing the most risky things first, getting user feedback, and failing fast. You don't want to find out that the data model you built can't support the insertion speed you need and needs to be changed after you've already started to build the reporting UI.

slavik81• 11 years ago

I absolutely agree. Whenever this topic comes up for discussion in programmer circles, I see comments along the lines of 'Agile is pointless. It doesn't matter whether you use Agile process or not. Good people can make just about any system work.' But, that's part what the agile manifesto says!

Perhaps it should be quoted more:

  We are uncovering better ways of developing
  software by doing it and helping others do it.
  Through this work we have come to value:

  Individuals and interactions over processes and tools
  Working software over comprehensive documentation
  Customer collaboration over contract negotiation
  Responding to change over following a plan

  That is, while there is value in the items on
  the right, we value the items on the left more.

Zigurd• 11 years ago

Agile doesn't abjure methodology, and most working Agile teams use scrum-style meetings and kanban-style task tracking. But the first line of the Agile Manifesto says:

Individuals and interactions over processes and tools

Which implies a few things, not least the default excuse for failed Agile-managed projects: "You did not have the right people." Well, duh. With the rightest people you can transcend any methodology. Conversely, piling on the process won't save your ass if you have the wrong people.

You have to have good people using good tools, and the wisdom to know if that's good enough.

VLM3• 11 years ago

Some common pathological beliefs I've seen, some logical fallacies, some worse:

The rationalization drive implies failure needs an excuse. Sometimes Agile is the least strongly defended possible victim. Therefore Agile is bad.

Agile is complicated. The simplest components to explain are also the most trivial. Something that's only trivial is invariably foolish. Therefore Agile is bad.

"Most people" are experimenting with Agile. Half of managers / devs are below median by definition. Its a very realistic prediction that half the time, Agile will result in below median performance. Therefore Agile is bad.

Every other silver bullet for the past 50+ years has been a scam. Agile is a silver bullet. No one can explain why this silver bullet is any more likely to be real than the last couple dozen fads. Therefore Agile is bad.

Agile only seems to scale to a narrow range of team size. Things that don't scale up, or down, are stereotypically seen as bad by programmers, no matter if the stereotype is applicable or not to the situation under discussion (that's why its called a stereotype or bias). Therefore Agile is bad.

Sometimes Agile is implemented as a sub-scheme where the overarching style remains micromanagement or seagull management or simple chaos. If the cake is a lie, a thin layer of Agile flavored frosting isn't going to make the overall dish taste good. Coverups are inherently bad. Therefore Agile is bad.

Agile is impossible to define and really popular. Grok that. At least some of the bottom half of the median will simply use the word as a checkbox without ever implementing it. Essentially managers who "have no idea whats going on" will sometimes describe themselves as Agile as false advertising. Therefore Agile is bad.

Related to most of the above, the odds of finding a shop actually successfully implementing true Agile are low. Therefore statistically if an employer says they're agile that's a sign for applicants to avoid them. And that means the best people will successfully avoid agile, with all kinds of secondary effects. Therefore Agile is bad.

s73v3r• 11 years ago

Wait, why would people think that Agile is a substitute for hiring senior people?

Agile Failure Patterns in Organizations

Related Stories