Coconut Headphones: Why Agile Has Failed

This recent meme about agile is so dumb that I feel like I shouldn't say anything at all, but here goes anyway. I'll keep this as short as possible...

Agile works fine for teams that embrace it. It's going to work totally different from team to team. The real point is to find the process that works best for your team to deliver software that meets the customer requirements and budget. Agile for a team of 1 or 3 is not the same as agile for a team of 10 or 100.

Agile tends to fail in two places and they are both communication related. First, developers give terrible estimates because of pride. They don't think through the problem, they don't consider complexity, and they want to look awesome so they ALWAYS over promise and under deliver. That makes them look bad and destroys confidence in the project because it's dishonest.

Second, managers will take estimates and turn them into deadlines because that is kind of their job and they are doing the best they can with the bad information that developers give them (see bad estimates above). A good PM needs to really push their team for real esteems. Poor estimates lead to poor communication because when things go badly, nobody wants to send up the signal flare for help or tell the boss that the project is not going to hit the deadline. This is often compounded when the client decides to firedrill a feature or bug fix mid sprint, and the manager doesn't push back and say that it is going to push everything else back.

The best estimates are the ones that are the most honest, not the shortest.

Between the bad estimates and the poor communication that comes out of it, there are plenty of times that "Agile" goes wrong, but it's not agile's fault. It's your fault. It's your team's fault. It doesn't work if you aren't willing to continuously tweak and reevaluate the process until it fits your situation. That means doing retrospectives and making improvements based on them.

Continuous improvement makes agile work. A stagnant process is doomed to failure as requirements and resources change over time.

The problem with agile was never engineering, it was non-engineerial management bs.

Once again, this is about mismanagement rather than Agile or software development.

Besides the objections concerning throwing out the baby with the bathwater when it comes to Agile, I also object to the notion that non-technical managers cannot manage a software project.

True, 90% of all non-technical managers do not have the knowledge necessary to manage software development, but very little of that actually includes hard technical knowledge. As a tech manager with 25+ years of development experience, most of my work involves management skills, not technical skills. The technical insight needed can be taught to any smart non-technical manager.

Also, managing a software project is not about being "in charge" and micromanaging, but mostly about serving, protecting and coaching a team. People in the "no management" camp mistake management for hierarchy. Being the manager is a team role, just like being a back-end developer, and interaction designer etcetera.

None of this is about Agile or management, it's about two sides, old school hierarchical "programmers-are-codemonkeys" management and tunnel vision "we-don't-need-no-stinking-suits" developers, trying very hard not to understand each other.

And using Agile as a stick to beat each other with.

If Agile is dead, it's because it's been brutally murdered by two factions unwilling to face their own shortcomings.

We have a similar support load, but have been able to avoid that problem. I attribute this to two things: - We have a highly skilled support team that can handle pretty much everything except actually writing bug fixes - Every iteration we pull the whole team back to swarm on feature development together. They may get pulled into different historical features for support, but new development is always done as a team.

Support is still very costly for us, because the distraction of working on old features slows down new development. To combat that we're putting a lot of effort into fixing the root causes of our support issues and training our support team to handle more and more technical problems.

I second this. My team is about 18 months into our transition to agile, and it is a tough road. This book has been an excellent resource.

The one gap is that it mostly focuses on greenfield projects. It does a good job of highlighting the parts where legacy systems will make agile more difficult, and I understand that spending more time on that would have made the book harder to understand. But we've had to do a lot of learning on our own to try to fill in those gaps for ourselves. With that said, this book does the best job of addressing legacy projects of any that I've read.

If anyone has any recommendations for resources on using agile in legacy systems, I'd love to hear them.