When Agile goes wrong [closed]

Question

I'm writing an Agile course for some of the new guys we are on-boarding recently, and I want to add a cautionary tale so they understand that Agile is not meant for all projects.

My problem is that, because of the nature of the projects I work in with Agile has worked pretty well so far, I can't honestly point out what can go wrong and why when you use it in the wrong kind of project.

What are things to look out for when an Agile project goes wrong?

Answer 1

The biggest failure with "Agile" teams is a result of what is called Cargo Culting. Essentially, teams want the effects of successful agile teams so they mimic the visibile actions

• Daily standups (that run for an hour or so)
• Breaking work into sprints
• User stories (that are usually little more than a sentence but an estimate is expected)

Those are the three that you'll see consistently "applied" in these environments but very little committment to actually being agile. In fact you'll hear management say we're "doing agile." (Run away at those two words it's a bad sign.)

You'll also hear a lot about technical debt but their definition of technical debt is "do it quick and dirty and maybe we'll get around to making it better later." (Translation: we are going to make it sound like we're concerned with maintainability but in reality we will keep the same boiler room mentality because that's what's worked for us in the past).

Other key phrases: "I know these stories aren't fully defined but we're doing agile so we can fix them as we go."

"We're doing agile development so you should be able to accomodate what I need within the sprint as I identify it."

"We're not able to lock down our committed stories at the beginning of the sprint because needs keep changing mid-sprint."

The key indicator on whether an Agile project will be successful is if the project lead (scrum master or whatever role) has had experience or formal training on leading an agile project. Too often I've seen people read about Agile in a book or take a two day course on being a scrum master and think they've got the chops to successfully implement it. Sorry it ain't happening captain.

Answer 2

People that didn't understand what agile is (was?) all about and apply it to:

• clients that are unavailable for comment until the deadline
  ...and threat legal action afterwards;

• managers that keep developers away from the client, (probably because they're slightly underpaid, and could jump ships, going to work for said client) and play a game of the "broken telephone" in a desperate (often successful, though) attempt at looking busy and useful,

  See also: mushroom management, aka "kept obscure, fed manure" and pointy-haired bosses. :)

• teams that are too big to go anywhere;

• companies that are keeping on their payroll once-renowned system architecture designers that are desperately diverting attention from the fact they completely lost sight of the actual coding craft, by overdesigning magnificent, unpractical, hard-to-realize, UML sagrada familias.

Answer 3

Agile is not suitable for fixed-term or fixed-price contracts. Once you've signed up for such a beast, you have to deliver. Agile is very good at continuing development for ever, as customers change their minds and 'clarify' their requirements. That does not help you on the day the money runs out, but still have to finish the work.

Agile is very good for the post-project phase when you are doing incremental updates and bug fixes however.

The other aspect where Agile fails is not a fault of Agile, its a fault of people who insist on all the old stuff like full-on project documentation, up-front designs, and poor lines of communication. (The half-arsed agile manifesto).

Answer 4

Here are a few questions that may be useful to look for an answer in terms of finding an example where an attempt at Agile can go poorly:

• Is Agile the new micromanagement?
• The Agile process: how and what should be documented?
• Right mix of planning and programming on a new project

Have you ever heard of "pseudo Agile"? Here are a couple of blog entries about it:

• From Pseudo-Agile to Waterfall – The path of a small and new software company
• Pseudo Agile!

There is something to be said for companies that may take their own view of what is Agile and butcher it into something else.

Answer 5

I worked on a highly successful Agile team, as well as a few that attempted Agile, but couldn't get it to work.

The successful one had the following elements:

• Truly "Agile" requirements. There were user stories, and we coded off of them.
• Available product owner. If a user story I was coding from was incomplete, I could easily go to the product owner, ask him what should be there, add it, and the complete the code.
• Commitment to the process and a realization that it was a learning curve.
• Focused team.
• Managers who knew and understood the Agile way of doing things who were committed to making it work.

The successful team did Agile, and did it really well. I would think that if you don't have any of those points above, you could fail quite easily. The first and second things go hand in hand, and if you don't have that, then Agile won't work.

The team I was on that didn't do Agile well had a few elements too:

• Lack of committment from management. The management didn't believe in the philosophy, and were hesitant to commit as a result.
• Requirements documented in other places than user stories. See above about management commitment. Also, we had highly paid requirements analysts and big expensive requirements tools that someone needed to justify the use of.

Answer 6

I will add to the great answers already posted that, by my experience, agile and specifically Scrum will only work if management AND team are willing to put lot of visibility of what's going on.

This means that in public companies (governments for example), it will be very difficult to make it work properly.

Answer 7

I do not know this from personal experience, but hypothetically, there are many circumstances when agile is not the best option.

• Projects whose product is life or property critical - For example, you do not want to use agile to develop the software that runs your pacemaker. Why? Because you have near-zero tolerance for errors. Consider a classic example of programming error within medicine in regards to the Therac 25. Granted, it wasn't built with agile, but the point is this: Developing life or property critical is no place to say, "we'll clean that up on the next sprint" or "we don't need great, just good enough."

• Projects with too many junior developers - Agile expects a certain amount of autonomy within the participating group. If there isn't enough experience on the team, then that autonomy can work against you.

• Projects that require a higher degree of control or planning than what is traditionally offered with Agile.

I'm assuming either someone else will jump in and help out with better examples, or downvote this bit of tripe I've written ;-).

Just remember that when the only tool you have is a hammer, every problem looks like a nail. Not all projects are nails.

Answer 8

Agile in my opinion is all about the culture of the team that is practicing. If the culture sucks, the team members do not get along, and people are not collaborating to meet sprint committments then the culture or team is deficient.

I wouldn't necessarily say however that Waterfall will necessarily work in such an environment, it is not a black and white situation, very little is truly black and white.

A good Agile team is communal. They have a tribal spirit of community where all members are working towards the same goals. The team succeeds or fails together. They work together on solving problems. A team member will stop what he is doing with his tasks to help a struggling team member out. Everything is sink or swim.

When this is not the case then it quickly becomes apparent what is wrong. If the team members are sitting down, typing on their laptops or texting, or zoning out during the daily standup then you don't have a good Agile team. If your project managers are enforcing all the Scrum procedures, definitions and terminologies but everybody is just keeping cadence and paying lip service, then this is just a rather blatant farce of what Agile truly is, and this in many ways leads to team dysfunction, inefficiency, missed deadlines and failed projects.

Failing Agile is in many ways worse off than a moderately successful Waterfall team and probably have lower project success rates.