5 Things That Will Make Your Agile Development Project FAIL

Far too many Agile development projects fail. It is hard to even accurately measure the number of failures because so many software development projects end up “complete” and shipped, even though:

  • They took far too long to build
  • The quality of what we built was poor
  • What was built was not what the customer wanted
  • The cost to develop was more than it should have been

Over the years, I’ve worked on many different Agile teams and have consulted for and trained many teams on Agile development. In this time, I have found 5 common problems, that if not resolved, are very likely to cause a project to be a failure.

1. Not having a product owner

Of all the things that can cause an Agile software project to fail, not having a person that is ultimately the decision maker for the product being developed is the quickest way to ensure its demise.

It doesn’t matter if you are following Scrum, doing your own Kanban style project or something else; if you want your project to succeed, you need someone who can set its direction and make decisions about the product being developed.

Think about remodeling a kitchen. If you hired a bunch of contractors to come in and do the various jobs, like: plumbing; carpentry; flooring; etc, but you don’t have someone deciding what the actual finished kitchen should look like, you are going to get a random mess.

Agile development remodel

A few skilled contractors will probably be smart enough to find the right person to ask about what should be done, but it takes more than just making arbitrary decisions about where the cabinets should go to design a kitchen. You need someone to actually come up with a real design and vision and be able to modify that vision appropriately as the project progresses and problems inevitably occur.

It seems pretty nuts to spend a huge amount of money remodeling your kitchen, but not want to invest any time or effort in either designing the finished product or hiring someone to do it.

Yet, day in and day out, I see this exact behavior in software projects. I see companies investing huge amounts of cash in Agile development, but not appointing anyone to be the true owner of what is being built and to set the vision for it.

2. Not iterating

One of the key values that Agile development brings to the software development world is iteration.

What is iteration though?

You may think it means breaking your project into 2 week sprints or iterations.  While doing this can facilitate iterative development, it doesn’t mean you are actually iterating.

Confused? Let me explain.

The key to iterating is to develop a product a little bit at time. It would be accurate to describe the process of iterating on a product as evolution of a product.

Whether you believe in macroevolution or not, microevolution, or adaptation is a proven concept.  The idea behind evolution is that things change gradually over time. Those small changes add up to result in a big change.

Imagine how silly it would be if evolution worked the way most “Agile” software is built.

Imagine, if you will, a fish that swims in the ocean and has some little fish babies that are born with fully functional legs. Then, those legged fish babies grow up and have fish babies that have wings.

Agile development evolved fish

Probably the legs and wings wouldn’t do that fish much good, nor would they be designed properly, because instead of adapting and changing over time, they just suddenly appeared.

Features should not be built in a single sprint or iteration. It is as silly as legs showing up on a fish in a single generation.

Instead, features should be evolved and grow over time. A feature shouldn’t be pushed into a single sprint or iteration and then be done. A feature should start out small and develop and evolve over time as feedback is received and customers or the product owner tries it out.

Far too many times, I see Agile development projects mistake having iterations with actually iterating the development of the product.

Don’t try to ship a completed feature at once, let it evolve over time.

3. Not breaking things down small enough

I am a big proponent of breaking things down into small, easily digestible pieces.

The main reason why this is so important is because it prevents procrastination. Procrastination usually occurs when either we dread some large task that will be difficult or we don’t know what to do next.

If you can break a big project up into small parts, it will seem easier to accomplish and will have clear steps of progression.

I often see software projects where the person creating the backlogs or work items is not considering the work enough before giving it to the team.

I coined a term for these kinds of backlogs: fatlogs. Fatlogs are backlogs that are not broken down small enough and often are very vague in what needs to be accomplished.

Fatlogs are notoriously difficult to estimate and waste time when trying to explain and understand them. It is critical that fatlogs be broken down into smaller actionable backlogs before being given to an Agile development team or a large amount of time will be wasted.

Many times, I have found that the creator of the fatlog could have easily broken down the work it represents into several smaller backlogs that would be easier to explain and understand, even without knowing much about software development.

I often recommend to Agile development teams that they outright reject fatlogs and send them back up the chain.

“If you can’t take enough time to clearly state what you want, it must not be that important.”

This doesn’t excuse development teams either. Development teams should break down any backlogs they get into small tasks as well.

4. Not setting done criteria

What is the first thing a waiter asks you when you order a steak?

That’s right, they ask you how you would like it done.

If the chef doesn’t know what the done criteria is for your steak, the chef will have to decide what he or she thinks the done criteria is.

Agile development done steak

You may get back a well-done steak, or a rare steak, or something in between, depending on the personal preferences of the person cooking your meat.

This isn’t a good way to cook steaks and it isn’t a good way to cook software either.

In many software projects I often encounter lots of steaks being cooked but no one defining when they are done. The backlogs most often end up being “done” when time runs out.

It is very important to have explicit unambiguous done criteria for any backlogs being worked on by an Agile development team.

This means that the product owner should be defining some level of acceptance testing. It doesn’t matter if the tests are manual tests or fully automated tests (BATs), what matters is that some criteria is defined by which the team can evaluate whether they have achieved their goal or not.

Lacking this criteria is like a parent responding with “enough” when their child asks “how many more peas do I have to eat?”

Not having done criteria is demotivating and results in the finger pointing game of why the correct thing was not built.

I have found that if you tell someone exactly what is expected of them and what criteria they will be judged by, you get much better results than just throwing them in the ring, slapping them on the back, and saying “do a good job.”

5. Not letting the team be a team

Teams are strange organisms, especially Agile teams.

There are many dynamics that affect how teams act and interact. There are many ways to foster a healthy team and many ways to create unhealthy teams.

A healthy motivated team has synergy, a unhealthy gaunt team can be less effective than all of its members are on their own.

The key to having a healthy motivated team, is letting them be mostly autonomous. Regardless of your political persuasion, you would probably agree that when a country invades another country and sets up an unelected government to oversee the people, there are going to be problems.

The same thing happens in Agile development.

I’m not saying teams shouldn’t have accountability. But if you want to run a software project in an Agile way, you have to let teams self organize and self manage to some degree.

When big brother is always watching and interfering, team dynamics become very different. Naturally, teams usually develop their own cadence, leadership and roles (this is called norms.) However, when outside forces directly interfere with how the team does things, and they don’t have the power to decide their own fate, team members begin to realize that they need to look out for themselves.

Additional agile development resources

I’ve found it to be pretty difficult to find good resources on these topics, but here are a few books I’ve found useful that address some of the issues I described above.

What do you think? Have I missed any of the major Agile project killers? Any useful tips for dealing with them?

Let me know in the comments below.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."

  • pauldangerkile

    If iterations are done on complete layers, then changes will cascade through them, and the project may fall victim to many paper cuts. Each iteration needs to function top-to-bottom. That also lets your customer test each iteration, top to bottom, which builds trust.

    For Java:

    1) Have a “Build Master” build and test the code every day.

    2) Put the tested-good code for that day in a central location.

    3) Each developer’s development environment has their dev directory at the beginning of their CLASSPATH, and the tested-good code’s central location later in their CLASSPATH.

    4) Each developer’s dev environment only has the classes that they have locked-during-checkout in it. All other classes are found in the central location, but their checked-out classes will override those, because they are earlier in the CLASSPATH.

    That ensures that everyone has the daily approved-good-code, and completely eliminates having to rebuild the project throughout the day. You only compile the one class that you are editing, and not the entire project, but your class (within your dev environment) will run in the correct context, as if you built the entire project.

    • http://twitter.com/ppetrovdotnet pip010

      1) this is not “Build Master” but CI , continuous integration

      2) what do you mean? do you imply moving code out of 1 single central source control? all the NOT tested should go there too, what the point of CI otherwise :)) ?

      3) too much juggling

      4) lock and checkout ? you lost me completely

      “That ensures that everyone has the daily approved-good-code”

      have CI with test and you have it implicitly true

      “completely eliminates having to rebuild the project throughout the day.” how the heck do i test? good that i compile only part of the project, but what if I need change elsewhere?

    • danrue

      Nightly builds are an excellent best practice. Most teams don’t do this.

  • oakdalesoft

    Most IT projects fail. Period.

    Mostly because key people don’t have the talent required to make them succeed but also because internal politics was put before delivery.

    After 20 years of delivering projects I have found these two points are all that matter. Agile or even the next big talent replacement methodology cannot save you from mediocrity.

    • http://twitter.com/ppetrovdotnet pip010

      in fact SCRUM brings a common-denominator and facilitates mediocrity as far tech goes!

    • jsonmez

      I do believe the internal politics and even weak talent can be overcome if you have a few key technical leaders with good people skills that can break down tasks and get the team working together right, but I am an optimist. :)

  • http://twitter.com/ppetrovdotnet pip010

    What you describe is SCRUM and SCRUM is NOT AGILE!

    • jsonmez

      I agree with you, but most people think of Scrum when they think of Agile.
      See my link about Kanbanand, to see how I think software should be developed.

      • http://twitter.com/ppetrovdotnet pip010

        “I agree with you, but most people think of Scrum when they think of Agile.” it is prevalent. Why is so?

        I can see it is tempting to try to handle soft-development as car-manufacturing,but really, how wrong and far from the truth that is :(

        The agile manifesto is good enough for me.

        I will look into Kanbanand, but what I’m really looking for is to get out of the office work :(

        it is too much stress and frustration for me combined.

  • danrue

    Excellent article! I think you hit the biggest points, for sure. I’ve seen all of those mistakes made. You’re spot on.

  • Pingback: Scrumhint | 5 Things That Will Make Your Agile Development Project FAIL - Scrumhint()