Real world Agile practices and estimates

Question

In a perfect world, we tell the client we follow an agile methodology where we allow the scope to increase/decrease as the requirements change and we bill per hour for each iteration.

In reality, estimates need to be delivered before the project starts, and there is always pressure to hit that estimate number while being flexible with scope changes.

I'm wondering what sort of real-word agile practices people have applied to the de-facto waterfall based billing/estimating that we sometimes get stuck in. Can you "break-in" a client to agile mid project, after you have acquired trust, or are there any other techniques to transition a client to agile.

*side note: in my "real world" situation I run a recently founded development company that does not have the luxury of forcing clients to use our method and process. Many times we have to bend our backs to use theirs, but I see it as a burden all businesses face when starting. I'm wondering how best to deal with it.

Answer 1

In the real world, we tell the client we follow an agile methodology.

We don't "force" the client. The client can ask for any methodology they want. We're still going to do things in an Agile manner. In the worst case a client demands a lot of design up front. We're patient about explaining that we still create a backlog and they still have to prioritize the backlog. We're also patient about breaking the team into pieces so we have multiple overlapping sprints so that the client "feels" like we're doing a lot of design up front. Actually, we're building code for the first release while designing the second release. Everyone's happy.

We do not allow the scope to increase/decrease as the requirements change.

We adjust the order, timing and priority of the deliverables as the requirements change.

Estimates need to be delivered before the project starts, and there is always pressure to hit that estimate number while being flexible with the priorities and order of deliveries.

Scope changes are inevitable. Everyone knows they happen, and the accountants like to see a "Change Order" that documents the scope changes.

A scope change is rare and different from the common, ordinary re-order, re-prioritizing and re-thinking the backlog.

You don't have to change the budget or the schedule if you constantly rethink the priorities and the value being delivered.

In many cases, the original plan was trash, and after a little bit of development work, better plans surface which can be cheaper and more effective than the original plan.

Agile doesn't mean random scope changes.

Agile means thinking the priorities through collaboratively to create as much value as quickly as possible.

Answer 2

I think the best agile practices are those that you develop naturally. Putting in place a particular methodology is good but I believe that you are fitting yourself into what worked well for someone else (and they documented it). Read up on scrum etc but what you'll find over time is that patterns will emerge with particular clients and if you keep on your toes you'll develop a natural rythym to them. You're in a service industry so you have to respond to what your clients want and they all want something different.

Always let your clients know that estimates are only estimates and are susceptible to different levels of accuracy depending on how much they are inclined to change their minds :)

Answer 3

the scope, deadline, and cost of each iteration is fixed

in between iterations, everything is negotiable