I’m facing this approach every day. We were able to convince one client to use more agile methods, but it’s still very far from pure agile you’d like to see. The rest is very reluctant and to some level I can understand that.

The problem with inviting agile methods is that decision-makers rarely have a chance to see how things are going. There are two reasons:

1. Decision-makers are far from the place where projects are happening and they’re not aware of all details of project management (including methodologies).

2. Even if they’re close enough they don’t want to risk checking whether some novelty is good or not. They prefer what they know.

I’m not going to try to convince you agile is bad, because it isn’t. I like agile methods and use them whenever they suit fine. That doesn’t mean however I treat as “one size fits all” type of answer.

By the way: I’ve tried to leave a comment on your blog but every time I get 404 error.

I’m not finding that to be true–at least no after they see how things are going.

I don’t say you aren’t allowed to apply agile in big organizations. My point is they usually don’t want agile. They don’t help you with agile. They don’t support your team with their feedback.

Of course, no one forbids you to use scrum in the project, but you have to deal with old-school product owner who doesn’t play the game on your terms.

Because of customer not participating in the process you won’t end up with better product or functions which cover business needs in a better way. Then it’s all about how your team works on software. Whichever method you’re using I’d advise you to stick with it (as far as it’s reasonable).

I saw your comment on Johanna Rothman’s blog and followed it here and to Steve McConnell’s blog. I’ve left a longer reply on my blog, but I thought I should leave a notice here since there didn’t seem to be a way to leave a trackback.

The short answer is that I’m surprised by your implication that, because big companies need predictability, Agile is inappropriate. I spend a lot of time helping big companies achieve more predictability by using Agile techniques. Of course, they can choose to give up the predicted date to add scope, but they don’t have to. They just get a choice to do what’s best for their business.

P.S. I can’t seem to do the same on Steve McConnell’s blog. Even after the nuisance of creating a “login” for a blog, I seen no means of leaving a comment. Perhaps he only supports Internet Explorer? If you can leave comments there, perhaps you could mention my response.

First thing, we use some of agile methods in a couple of projects. Agile works great whenever you work with customer who is engaged in the process. Our testbed for agile is a project where we have internal client so we can drive work whenever sponsors want. That’s great but I can’t say what exactly we’ll be working on in two weeks from now or what’s the plan for next two months.

You can’t call me a convert but I’m not a blind naysayer either.

The most important principle lying behind agile is client active participation in the process. Whenever your client is eager to work with you on the product most likely agile methods will work well. On the other hand when you have a client who has different proirities you probably won’t get good results because of lack of feedback.

My answer to agile evangelist is usually the same: go, make some big project for big, highly formalized company agile way.

I work everyday with mobile operators and they just won’t buy it. They need detailed singen agreement specifying what will be done and, when possible, how it will be done. And that’s even before beginning of the project.

Agile just wouldn’t work in that kind of environment.

It’s all about specific goals and priorities a client have. I fully agree with points Steve McConnell gave and I recommend you to read the whole article if you haven’t done it yet.

I am a convert also. Test it out and you’ll see.

As for your response to Bruce; your partnership model is an adversarial one. It doesn’t have to be that way. If your clienta dn you have an ongoing relationship this agile model is a solid path to beter outcomes for both parties.

I think we differ on definition of predictability. If I wanted to create a cool website of my company I would gladly choose an agile company. There would be some core fetures I must have and a bunch of “wanna-haves.” We’d limit budget and timeframe and would search the result which suits me the best.

On the other hand if I was a director in a mobile operator and I was choosing the system I would squeeze vendor to get the longest possible list of features. Then I would squeeze the vendor to get all those features working (hey, I paid for them). And then, when all above is done I would think how to manage all ideas which came up during implementation. On that position you don’t spend your own money and you must care about all politics in the company. You can’t change the scope just because “you don’t need the function any more” because someone will come and ask where the hell is that damn feature we paid for.

And now between those two models there are hundreds of others, more or less flexible.

And predictability is not about getting the best solution but about knowing on the very begging what will be delivered.

One thing more. There are more methodoliges than waterfall and agile. And I defend here any of them.

I actually think that an agile project can give you more predictability than a traditional waterfall approach and will typically lead to functionality that is more to the point.

With agile the first step is to decide how much you have to spend and by when it has to be completed. These two variables can be fixed even before the project started.

Now there are always unknowns that pop up in projects. “Oh, is that what you meant when you said…” or “No, we do not need that function any more”

In waterfall the team tries to oust all of these unknown by doing very detailed requirements analyses. The problem is of course that misunderstandings will still occur and that the longer the project runs for the more the customer will change their mind.

One of the big goals of the agile approach is to discovered these unknowns earlier rather than later by showing the user what you are building as early and as often as possible. The customer is involved in prioritising the ongoing development, thus getting the best value for money and focused achievement of their changing vision.