[mbesto]

> “No changes will be effective unless and until memorialized in a written change order signed by both parties.”

Ahhh, in the "Enterprise", we call this a Change Request (we would name and number them CRXXX, for example) and put them in a "register" (Excel doc that got passed around 100x a day). These become so excessive they needed to be managed by a Management Consultant (who charges $250+/hr) who specializes in change management.

> There are three variables to any project: Money, Time, and Scope.

Every project I approached, I would draw the following diagram to the client: http://en.wikipedia.org/wiki/Project_management_triangle and any time one of the corners changed (it always did) I would redraw the triangle and ask the client how they wanted to proceed with ensuring the quality of the project.

As someone who has successfully and unsuccessfully implemented agile in arguably the worst environment possible ("The Enterprise"), my general conclusion is this: if the client doesn't understand agile fully or is already implementing practices that are agile-like, then do not begin the project. Set up workshops, assess their ability to adhere to budget-less (agile) projects, and make a decision then. For smaller clients, I typically ask the client "what's your budget?" and then I work backwards from that. So if a developer is $100/hr, and the client has $5k to spend, I'll say "ok you get a developer for 50 hrs. Most likely we can build this, this and this" If/when the client disagrees ("But I can get 2 people in Malaysia for that price!") you simply tell them to go find someone cheaper on oDesk.

[Joeri]

I'm wondering up to what size you managed to do an agile project for 'The Enterprise'. From what I've seen, as soon as an enterprise contract is big enough to involve a tender, bidding round and separate purchasing department, agile is impossible. Being agile actually works against you, since regular demo's will bring up more opportunities to point out how you aren't sticking to the letter of the contract, flexible scope means adding scope and never reducing it, and grooming as you go along means uncovering big requirements which are sort-of-kind-of in the contract halfway through a big project that's already late. And those are the easy projects compared to government contracts.

I keep wondering how you're supposed to negotiate the typical big enterprise contract so you're allowed to be agile while executing it. I haven't seen it done successfully yet.

[mbesto]

You're not incorrect. But I always like to think there is always a possible ;) The reality is agile is such a strong buzzword in 'The Enterprise' now that you can't even avoid it anymore.

The one that was successful was a $250k project - 3 months. Client insisted fixed price and done "in agile". We estimated the actual work was only 6 weeks, but knew they'd change their minds 100x times (they did). We didn't optimize the timeline properly (as you are insinuating, it's almost impossible to predict), so our margins ended up being quite low.

I do know one company which successfully does agile (within a company that does $100bil in rev). They budget the whole year out for X amount of employees and then do everything in 3 week sprints. They basically "fit in as much development as they can with the resources they have" and disregard the high level 3-year "integration plans" that the management consultants put together.

[analyst74]

The key is to have a strong project sponsor who believes in you, and if done correctly, you can actually make your sponsor look really good as an executive who "gets" technology. Believe it or not, the term Agile is making its way into the dictionary of senior leaderships of traditional organizations.

[pjmlp]

I came to the conclusion it is impossible to do agile in the enterprise, the best one can hope for is when sprints are seen as a kind of "mini-waterfall".

And even then, no one cares about unit tests, tdd, or whatever is the testing flavour of the month, besides the integration tests at delivery dates.