What are some situations where Agile is inappropriate?

Question

I have been hearing and reading about Agile for years. I own a book or two on it and I like the idea.

I am finally in a position where I could roll something like this out where I work, but I have serious concerns about whether it's the way to go for us:

• Isn't there a minimum size for this? Big design up front must be more efficient for a three or four week project... Right?
• Our customers usually require fixed prices. They need to know what they're dealing with, except in special cases where we are up against an obvious black hole and even then people are more comfortable with a cap. So how can you provide a quote if you're going with a process that is tolerant of ongoing requirement changes?
• I understand that Agile may provide better odds of success in more complex projects, but won't it drive up costs to the customer? And of course there is the cost of failure to consider - perhaps we are back at the minimum size question here.
• How in the world would you explain this counter-intuitive approach to customers? Non-technicial stakeholders might not have the experience to wrap their heads around anything beyond Waterfall.
• Even for internal projects, there are budgets. What am I missing?
• It seems like there is some backlash against Agile lately. Is something else going to start gaining traction soon?

Note: We are a 5 dev shop with projects ranging from a day or two all the way up to several months. I don't believe that there is one methodology to rule them all, but it would be great to find something flexible enough that we can adapt it to all of our projects.

Thanks a lot!

Brian MacKay

Answer 1

It depends on who you ask and whether they believe in agile or not...

As for this:

I would like to find one methodology to rule them all.

Are all your clients the same? You've already said the durations vary wildly... Why would you suppose that all manner of differing projects would be suited to one single methodology?

Answer 2

Search for what make Agile practice fail... If you got 1-2 minors points go for it, you will find way to go over them. Else, you looking for a failure. And once you failed, you won't have another opportunity to try it. Even if it's not the Agile practice that failed...

Answer 3

I don't think one methodology can rule them all. I am sorry. I am a firm believer in finding the right model for the right project. For example how would you feel if your were into surgery and you knew the machine which was keeping you alive was developed in a rapid iterative cycle with little design upfront.

But anyways on to your question. I am a big believer in agile approaches, of keeping your iterations short, focusing on what the user wants, and not building the battleship but only building exactly what you need. I would say 95% of all projects could use agile approaches, and if they can't it's usually a cultural issue, not a project issue.

Now as far as BDUF (Big Design up Front), we had great success with a 20 person team on a 4 month project, we took the project broke it down into 3 four week cycles, at the start of each cycle we all meet in a room, and said ok here's what we need to build, here's how we will build it, and we took a stab at what our interfaces would look like, what data we needed etc...But it was only a stab, we then went back to our desks, and whoever owned the various pieces flushed out the details.

Essentially we did enough BDUF upfront to jumpstart the team (And ensure we covered all the business requirements). We used to call these sessions Developer Days and it was a good way to jumpstart the team. If you have the cash take the team off site you can stuff them in a conference room at a hotel feed them lots of junk and watch the juices flow.

Answer 4

Start with internal projects to get some experience with how your agile process works and how you can best estimate how long things are going to take. When you feel that you're ready to take on a real customer, pick one that you have a lot of trust with and pick a reasonably small project to start with. The key here is that you want to build confidence. Explain what you're doing and why -- you want to provide better software to them that better reflects their priorities sooner -- and show them how you have been successful on your internal projects. Deliver on your promises -- since I believe in agile methods, I don't think this will be too hard to do.

Once you've succeeded (and wow-ed the customer), they will ask you to use the method on their other projects. Once you have one happy customer you can start to expand to others, using your first customer as a reference. Pretty soon you'll find that the practices you're using work so well that they creep into your "waterfall" processes as well. Eventually, you'll have drunk enough of the kool-aid to be like the rest of us agilists. :-)

Oh. And yes, there are projects that aren't particularly amenable to agile methods. Things like life critical systems, nuclear power plant control, highly regulated industries can all require more up-front design and process than agile allows. Most of us don't ever work on these projects.

Answer 5

If you can't get buyin from the stakeholders; if your organization requires some other methodology and developers are evaluated by technique rather than success; if there isn't enough time or money; then it's not appropriate.

The question would be, what other methodology would do better under those circumstances.

Answer 6

the simple solution has 2 steps:

1. don't estimate costs and schedules for projects, estimate costs and schedules for features
2. measure and record enough information to calculate your velocity and estimation errors

start small and in-house if possible to get some base numbers. If you still want to do 'big up-front design', do it for individual features. This will help your initial estimates be more accurate, and also what granularity of 'feature' you are comfortable with.

Note: this will only work if the customer is committed to do their part, namely, to be highly available to the developers (to answer questions, write stories and test descriptions, et al), and to not change their mind during an iteration

good luck with your transition, and let us know how it goes!

Answer 7

By far the biggest contraindication I've seen is a values mismatch. Extreme Programming relies on respect, communication, feedback, courage, and simplicity. In an organization that behaves based on incompatible values, applying XP will cause friction and won't result in any lasting change (IME).

Answer 8

Scott Ambler is one good authority for an answer on this. His article does a good job of highlighting some of the pitfalls of fixed-price, but it's definitely possible. Alistair Cockburn agrees it's possible also, but points out that some of the benefits you get from agile are lost in fixed-price contracts.

One basic problem with "big design up-front" (BDUF) is the time spent designing functionality that is rarely, if ever, used. If you need to have a finished product in a month or less, the problem must be really well-defined beforehand.

As for the cost of failure, that's a very legitimate concern. One benefit of Agile is that any failures happen earlier and at far less cost than they would in a project following the waterfall methodology. Being able to learn from those failures and get a good product at the end isn't an outcome that the waterfall methodology can deliver. The federal government has a fair number of high-profile failures of software projects that followed the waterfall methodology and BDUF. I've blogged about the FBI's Virtual Case File project failure.

What methodologies you use will be determined as much by the fit with your team as the type of software you're building, and your customers. tvanfosson is quite right about the projects that aren't suited to agile methods. I agree with Kent Beck on the values mismatch idea. Some organizations aren't ready for Agile from a cultural perspective, regardless of its merits and success elsewhere.

Answer 9

Let me answer your concerns point-by-point:

Isn't there a minimum size for this? Big design up front must be more efficient for a three or four week project... Right?

I'm not sure what makes you think that drawing rectangles on paper must be faster than refactoring code.

Anyway, even if it was, the question of whether BDUF pays back would be much more a function of how much learning you expect during the project than of project size. The more you can expect to learn something about the design, the requirements, etc. while implementing the system, the more your up front design becomes wasted.

I have yet to encounter a project where I didn't learn significant things while implementing the system.

Our customers usually require fixed prices. They need to know what they're dealing with, except in special cases where we are up against an obvious black hole and even then people are more comfortable with a cap. So how can you provide a quote if you're going with a process that is tolerant of ongoing requirement changes?

Only accept requirement changes that don't change total effort. That is, when new requirements come in, drop less important ones. Let the customer decide so that he can get the most bang for the buck.

You won't get all benefits of Agile this way, but it's as good as fixed price can get, as far as I can tell.

I understand that Agile may provide better odds of success in more complex projects, but won't it drive up costs to the customer?

Are you suggesting that projects run the Agile way are more costly than traditional projects? There are actually companies out there that experienced the opposite, up to a cost reduction by 50%.

And of course there is the cost of failure to consider - perhaps we are back at the minimum size question here.

Cost of failure goes down with an Agile project, because of the early feedback. You can notice failure - and therefore decide to cancel the project - much earlier.

How in the world would you explain this counter-intuitive approach to customers? Non-technicial stakeholders might not have the experience to wrap their heads around anything beyond Waterfall.

Why does Agile Software Development pay?

Even for internal projects, there are budgets. What am I missing?

I don't know. Agile works fine with budgets - implement the highest priority features until the budget is used up. You have the most valuable system that could have been implemented for that money.

It seems like there is some backlash against Agile lately. Is something else going to start gaining traction soon?

There has been backlash against it from the very beginning. And as it's becoming more popular (and it is!), it's just natural that you also see more backlash.

Lean Software Development is gaining a lot of traction. It's not in competition to Agile development, but rather complementary, though. The communities actually are quite overlapping.

Regarding the "one methodology to rule them all" - take a look at Alistair Cockburn's "Crystal" family of Agile processes. He argues (quite competently) that every project needs it's own process, and that even one project's process needs to change over the course of the project. And he provides a lightweight framework for developing your process.

As does Scrum, as I think about it. Scrum actually doesn't tell you very much about how to run your project, but much more about how to find out what's working and how to enable the team to adapt to those findings.

Answer 10

I would suggest against Agile when developing a new air traffic control system.

Answer 11

I would not necessarily use agile for a project where all is known up front. Agile works well when change is highly likely. In the event that change is not likley, one can use the predictive or waterfall process to manage such a project.

Responses to your particular questions follow: Isn't there a minimum size for this? From a practical perspective, Agile is size independent. Having said that, the bigger a project the more likely change will occur. If a project is small enaough then all is knowable and change is unlikely.

Big design up front must be more efficient for a three or four week project... Right? Simple and evolutionarily design driven by TDD is always more effective. You should have just enough architecture done up front to know where the main pieces fall. Don't use architecture to guess at what you are going to do, only capture what is knowable. Let simple and evolutionary design enable you to evolve your detailed design as you build the application.

Our customers usually require fixed prices. They need to know what they're dealing with, except in special cases where we are up against an obvious black hole and even then people are more comfortable with a cap. So how can you provide a quote if you're going with a process that is tolerant of ongoing requirement changes? Some education is required initially. You would establish a product backlog, ask the product owner to prioritize it and then do an initial estimate of the work. This does required that the product owner establish a cut line on the backlog for the fixed bid. Then you size the team and duration to meet the estimate. The contract then states you will use the fixed capacity of the team for the time box established. This will keep the product owner focused on the timebox and budget when making priority calls on the backlog.

I understand that Agile may provide better odds of success in more complex projects, but won't it drive up costs to the customer? A successful project is always cheaper than a failed one.

How in the world would you explain this counter-intuitive approach to customers? Non-technicial stakeholders might not have the experience to wrap their heads around anything beyond Waterfall. Education (i.e., agile boot camp) and visiting successful agile teams will help tremendously. Then get the team going. The work will keept them busy and the results will sell them.

Even for internal projects, there are budgets. What am I missing? It seems like there is some backlash against Agile lately. Is something else going to start gaining traction soon? The only backlash I am aware of is agile projects that don't use engineering practices effectively (i.e., SCRUM only). A team using SCRUM and XP effectivley will do very well at delivery and sustainable pace.

Answer 12

Imho:

Agile or not, you should design what is known before implementing--before "just trying stuff". Recursively break things down into manageable tasks, then design what is known, be it nitty-gritty details or just broad concepts. Things like UI and every-day business requirements are almost never set in stone prior to development, whereas aircraft simulation features might be.

One way to try to "sell" agile to customers is grant them two options: 1. Waterfall, where there is no cancelling as long as we (the devs) meet our end of the agreement. 2. Agile, where you get weekly updates on status, hands-on demos as they become available, and the right to discontinue service every 2 weeks (in case you don't like our work).