Coconut Headphones: Why Agile Has Failed (2014)

The best example of this I have seen lately:<p>Big Software Company officially changed over to Agile this year. Now has two-week development sprints. Any customer who calls in with huge, flaming, earth-shattering issues with the software is now told that the earliest their issue can be brought up is whenever the current sprint is over. There&#x27;s absolutely no leeway whatsoever to do any ad-hoc development for customers (frequently Fortune 500 or 100 who are paying millions for their software support.)

In short: <i>«The core problem is that non-technical managers of software projects will always fail, or at best be counter productive, whatever the methodology. Developing software is a deeply technical endeavour.»</i> Technical excellence or at least competence is key and can&#x27;t be replaced with any process. Estimates are not very useful; technical debt is dangerous toxic waste, and any process that does not treat it well is bound to fail.<p>A discussion 2 years ago: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7389940" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7389940</a>

This article hurts. I&#x27;m currently contracting with a large company and they said they were agile. The only agile thing about them is their cultic insistence on two week sprints and retros, other than that, the project rots from within. Case in point: team I work in takes care of all the web front end. One team needed some web work but then management came thundering down to us demanding that we finish another module because someone opened their mouth and over delivered, now it&#x27;s time to save someone&#x27;s hide.<p>Imagine having one team yell at you while management yells at you. Oh, and did I mention that management wanted 100% feature complete on a module that was 30% done? Genius.<p>After reading this, my liver was like &quot;oh sh<i></i> that hurts.&quot;

&quot;Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver.&quot;<p>^ This. This. This. I can&#x27;t say this enough. I understand business is business, but that side of a company needs to be more flexible for development. Hard deadlines only lead to cutting corners and poor, quick design decisions that make everything there after much worse.

This is the area of software development I actively dislike. I&#x27;ve had interview questions about whether at work we practiced agile, or SCRUM or some other crap. I&#x27;d much rather work than relegate time to learning about the trendiest way to ship.<p>When I was in charge of development, it was simple. Ship as soon as it&#x27;s ready as long as it&#x27;s not a Friday, bugfixes go all the way to the top of the pile. I don&#x27;t even know what scrum means. If it&#x27;s dead, I&#x27;m glad I&#x27;ve heard the last of it.

Agile methodologies can work, but it often requires a feature-centric deployment model, not deadline-centric. Having a fixed N-week deployment cycle can&#x27;t simply be applied to all products and expect it to work.<p>I&#x27;ve found that an &quot;Agile&quot; approach can work quite well as long as you apply a healthy does of common sense to it.<p>I think to often people forget that product management frameworks are there to create a common language and set exceptions, not blindly dictate exactly how one should operate.

My experience with agile development in companies: It is largely used to delegate the responsibility for a project and the results away from the management to the developers.<p>They just throw the objectives (made by the management) over the wall to the developers, those have to give an estimation and the managements is free of any further responsibility.<p>So the developers will in practice exploit themselves. This already was profitable in the automotive industry, where instead of the management, the fellow workers pressured the coworkers. The peer-pressure can be even more pressing than any management mechanics.<p>This finally of course is the opposite of agile development as it meant to be -- but that is nothing, that anybody in management would care about. The label &quot;agile&quot; is good enough and even most employees don&#x27;t see how they where betrayed. They think (at least for some time), they where &quot;empowered&quot;, but the real empowerment is, that they are now free to enslave themselves for the boss.

Although I agree that putting non-technical managers in charge of a technical team can be a problem in some cases - I think the article focuses a little too much on that aspect vs what I think may be more problematic -- that, in my experience, focus falls on process dogma (even agile&#x27;s) when there isn&#x27;t enough interaction with the user.<p>From the start of the article:<p>&gt; They identified that the programmer is the central actor in the creation of software, and that the best software grows and evolves organically in contact with its users.<p>I find myself echoing this a lot lately - that contact with users is the key to success in software development.<p>Note that this has to be told to both management <i>AND</i> engineers. I&#x27;ve met lots of engineers in my time that don&#x27;t want contact with users ...that is a problem.

I think the overarching aspect of agile has failed, in part because it requires more implementation than most companies are willing to put up with.<p>I see, in general (and I am a certified scrummaster, FWIW), that companies tend to embrace sprints - usually going for two weeks - and daily standups (which they might do poorly, but at least they try). Everything else - estimation sessions, lessons learned, burndown charts - are up for grabs. Maybe that&#x27;s a failure of the company. Maybe that&#x27;s a failure or Agile, for failing to take into account the normal inertia of companies - I don&#x27;t konw. It is better than waterfall, but it&#x27;s not fully embraced.

&gt; <i>The original agile manifesto was very much about self organizing teams, it would be great if we could get back to that.</i><p>Sorry, not going to catch on. Corporations make money. Where there&#x27;s money, there are power struggles. Where there are power struggles, nobody is going to relinquish power and let people &quot;self-organize&quot;. Sure, there might be exceptions, but the vast masses out there will never follow.

I&#x27;ve found that organizations who strongly embrace agile or other management fads&#x2F;tenets are often recovering from one or more projects that took too long or went over budget... someone got blamed, someone hired a consultant or read an agile book, and the next thing you know the rules of agile are used as weapons in whatever internal political battles predated the change.<p>Or, non-technical management is being criticized for too-slow development and an exasperated engineering&#x2F;product team resorts to agile as a method of radical transparency (you were on board with the sprint plan, we delivered, so stfu, etc.)<p>I&#x27;d say any of these are pretty big warning signs about an organization&#x27;s culture... in particular they likely reveal that the culture doesn&#x27;t appreciate good engineering practice or good product practice.

Good,a while ago it was the contrarian, underground cult, then it was all the rage, then you were not a professional if you didn&#x27;t worship it, then the cracks started to show, now it&#x27;s failed and passé.<p>When should we expect the revival?

This is exactly why John Boyd never wrote any books explaining his thought process - his entire point is to drop fixed and inflexible doctrine in favor of striking at the heart of what makes military operations work, and explicitly serializing your mental models is a quick way to convince people to interpret them as a fixed doctrine.

The problem is that management has to do &quot;something&quot;. When the developers are off designing and coding, what are the managers supposed to do? They have no clue, so they adopt &quot;agile&quot; so that they can appear to be busy collecting data on how well the team is doing.