Agile Failure Patterns in Organizations | Hacker News Reader

Agile Failure Patterns in Organizations

age-of-product.com

58 pointsswolpers83 comments

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.

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.

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.

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.

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.

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.

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

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

Just "Culture of Learning" sounds great.

Already used outside of the development world, so I suppose it would be par for the course on confusion.

Good one; I amended the original text.

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

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

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

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.

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.

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.

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.

I am not ruling out that the overhead of Agile maybe too expensive for some sort of tasks/jobs.

But in before-mentioned cases, accepting more responsibility wasn't considered appropriate by the individuals: Why would you want to do more work under the risk of being blamed?

Command & control structures have a great advantage: Blame goes up…

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.

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.

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.

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

Agile can be defined, but at its core, Agile is a set of best practices that by definition can be ignored. It's a collection of optional components that can produce a functional process when cobbled together in the right way. But figuring out what works for a team is often a lot of trial and error, so a skilled "Agile practitioner" can help you look at what has worked for you, what hasn't, and suggest things to try.

And you're right; when defined this way, Agile cannot fail. Agile isn't a magic bullet for your development team - at its core, Agile is a method by which dev teams can more or less self-organize around a set of generally agreed-upon processes. But it's up to each Agile team to develop those processes themselves.

I have yet to see an Agile team fail because their Agile process failed. I have seen Agile teams fail because the team was too inexperienced to provide their own direction. I have seen Agile teams fail because the dev lead wanted to play dictator. I've seen Agile teams fail because their business counterparts kept changing the requirements and demanding impossible things of the dev team.

I've never seen an Agile team fail because they couldn't figure out how to assign user stories or because they had no concept of release management. Sure, those things might be a disaster, but usually (after enough times going through some painful manual process) some developer steps up and says "Hey, I think I know a better way we can do this..." And those problems almost never endanger releases because Agile teams are by their very nature empowered to solve problems. Sure, the solution may have been inefficient and non-repeatable, but it worked.

>Agile can be defined

I tend to find that if you line up 4 developers and ask them what agile is you'll get a minimum of 5 definitions.

Exactly my point, and why there is no such thing as "true Agile" or a true Scotsman argument to be made.

And yes, I agree that the term Agile is largely meaningless at this point. Partly because nobody knows what it means, and partly because it's so ubiquitous there's no point calling it out on its own anymore.

I love your point. Cut right through the bull.

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.

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

The analogy between Christianity and Agile is actually quite apt in a fairly significant way: both were fairly explicitly founded in reaction against an excess focus on formalized, one-size-fits-all process over consideration of individuals in context, and both are realized in a wide variety of nominal implementation, many -- and perhaps the majority in each case -- of which have come back to an excessive focus on formalized, one-size-fits-all process over consideration of individuals in context.

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.

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

Right off the bat, I can see you've worked at some toxic work environments because you see managers as impediments to work because what their MO is to play act, exert authority, and get off on paperwork.

On a good team, a manager is worth their weight in goal, and will work tirelessly to remove road blocks from devs.

The agile manifesto was written by developers for developers. But these developers were builders who liked building and solving customer problems. Not people like you who seem to think everyone in the company is useless and just gets in the way of devs who do the only real work. If that is really the only experience you know, I urge you to work hard to find a better job.

Any philosophy or process is only as good as the people attempting to practice it.

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.

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

Those "agile advocates" are just trying to sell their own services to improve your "agile functioning". Shame on you for falling for it. Agile is so widespread at this point that "doing Agile wrong" isn't a reason teams fail.

Most Agile teams fail for reasons outside the development process. Ineffective leadership, lack of experience, poor product focus, etc. These teams would have failed with a waterfall model too; it would have just taken longer to realize it.

>Those "agile advocates" are just trying to sell their own services to improve your "agile functioning". Shame on you for falling for it. Agile is so widespread at this point that "doing Agile wrong" isn't a reason teams fail.

To be fair, it isn't often the individual developer who "falls" for it. These management methodologies are imposed on them, and the developer has to learn to roll with it. You may not be in a position to determine whether or not a project manager was sent off for "Scrum master certification".

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.

Here's an apt quote from HN a few years back regarding tools.

https://news.ycombinator.com/item?id=2380679

The excerpt from that post that I find most appropriate is, "Bad tools typically take longer to work with, and typically teach bad habits to get around their deficiencies." That's how many of us feel about Agile.

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

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.

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

I agree. So I'll add that none of those places had any values aligned with agile at all, despite spending time, money, and effort on agile. Maybe that's because values don't come from processes and trying to implement a process to instill values into people is patently absurd.

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

Here's a new methodology I invented (that's about as useful as agile): perfection. Do everything perfectly. However, no one has managed to implement this amazing new methodology in a way that works yet. It's so simple. So many have tried and failed. Surely it's not the perfection methodology that's at fault because that's perfect. It must be the idiots trying to implement it, who haven't actually implemented perfection, that are failing to implement perfection. If only they could implement perfection, they'd see how perfect perfection is! But I don't see perfection anywhere! WTF?

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.

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

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.

Do you also reject democracy because all brutal dictatorships call themselves The Democratic Republic of X?

Yes.

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.

Anecdotal, but I've never been witness to a project where requirements changed so drastically it led to failure. I've seen MANY "Agile" projects where effectively no analysis was done however. Which then reliably leads to failure.

EDIT: To add:

If the success metric you're using is: From the client's perspective, do they get what they asked for, when they were promised, for the price they agreed to?

Then I've seen a majority of "Waterfall" like projects succeed. And the ones that don't typically "fail fast" in the analysis phase.

I've never seen an Agile project meet that bar. By the time they're canned they're usually already way over budget and while a team might imagine they've "delivered value" the projects are (IME) canned specifically because it became evident they would most likely be handed over to another vendor and the delivered version scrapped entirely at some point.

I also find it frustratingly comical that projects are routinely compared to assembly line work (Toyota assembly line philosophies) when they have a lot more in common with the design and development phases of car production. Agile in the small perhaps, but overall an incredibly structured process with a lot of planning and analysis. Unless you want a car launch 3 years late that costs 50% more than you promised. Nobody wants an "Agile" car (unless you've already set aside your deposit for a Tesla Model 3 I suppose ;-) ).

If I were a client, there's no way I'd ever give a anything bigger than a low six figure project to an Agile shop. For a process intended to lower risk, I've only seen it do the opposite.

i've seen exactly 0 of this type of projects you describe in corporate multinational environemnt (or any other for that matter). in any non-agile corp i've been, projects are usually a mix, where analysis doesn't finish when dev starts, testing is ongoing with dev, just shifted a bit. and when these projects go fubar, it's usually caused my forces far away from delivery team. rarely, it's really fault of team not delivering, but agian, situation is so complex and uncontrollable, that putting everything and everybody (including all stakeholders) into agile wouldn't probably make a big difference in go/nogo call.

agile approach brings quite a few aspects that developers like and they just feel right (or at least better), but frankly, it's overhyped. just another tool/approach to certain set of situations, in certain conditions

> i've seen exactly 0 of this type of projects you describe in corporate multinational environemnt

I work in Pivotal Labs.

I happen to be working on such a project with one of the world's largest financial firms. Across the hall from me is another team working with that company. Behind me are three teams working for a retail giant, in front two teams working for a large insurer.

In the same office I've seen everything from iphone scroller games, to startup apps, to microservice migrations, to entire product categories, being created this way.

Collectively, Pivotal Labs has helped develop thousands of products for hundreds of clients with a collective business value in the billions.

I invite you to visit any of our offices to see it for yourself. Email me: jchester@pivotal.io and I'll set it up.

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.

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.

This is just not historically accurate at all. There was a wide variety of methodologies before agile came along - Spiral, Cleanroom, OOP, TSP, RAD, RUP, et al. These are not all waterfall - waterfall was never really a prescribed method of development, see [1]. Many of these methodologies have proven track records and some even have fairly strong empirical support.

The resentment isn't resentment - it's people who have actually used something other than Agile listening to this made-up history and the catastrophizing of up-front planning, and seeing it for the nonsense it is. Agile isn't right for many or even most organizations, and it's failure doesn't seem like the problem of a good idea bungled in the wrong hands. Just very inexperienced people suckered in by good marketing into picking an inferior tool.

All that being said there are many good things about agile. It's helped bring a human focus into the industry, and introduced some decent ideas. For a fairly balanced look I'd see [2].

[1]: https://leanpub.com/leprechauns [2]: http://www.amazon.com/Agile-The-Good-Hype-Ugly/dp/3319051547

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

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

M'fcking programming. Never failed me.

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.

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.

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

Why would one adopt a methodology with so many pitfalls?

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.

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.

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.

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?

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.

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

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

I have a bookmarklet, which I've shared here: http://codepen.io/anon/pen/wKpewj (there are lots if you search bookmarklet + {something}). It makes the text 1em, not bold/thin, black on tan.

Something a bit better could preserve headings, bold words etc.

Firefox's Reader Mode sometimes works, although not on this site.

Thanks for sharing this. I'm not sure about Agile but the productivity boost from using this bookmarklet is real.

Very handy, thanks!

Yes, you can use plug-ins like Stylish. It works well for tweaking sites you read regularly, HN say, though personally I find it too much messing around for a site I'm just visiting quickly. I'm more likely to just open the developer tools in whichever browser I'm using and look for rules that set a tiny font-size, a font-weight of 300, a faded color, etc. Often just disabling a couple of those will make a page dramatically easier to read, so I do recommend spending five or ten minutes figuring out how it works in your preferred browser. Even then, I sometimes have to admit defeat. I hate the idea of criticising style rather than substance, but with a site as awful as this one you can spend several minutes trying to make it comfortable to read and still fail.

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?

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.

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

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

Good, but giving feedback in an unrelated forum that the author probably doesn't read is not useful. The page has a "Leave A Comment" box. Give feedback there.

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

Reply on news.ycombinator.com