Q: What would be the right approach or main reasons when convincing a client to switch from the classic Waterfall to Agile? What would be his main benefits (business wise)?
Some of the first folks said:
the client needs to feel the pain of waterfall first, or they won't have a compelling reason to make the shiftor something like it. This bothers me greatly.
My response:
Doing waterfall first can help, but do we really want to say that Agile can only be sold when the pain of waterfall has been felt?Your thoughts?
I'd start with these two points...
1- you can cancel the project at the end of any iteration if you are not happy and still have delivered business value. With waterfall this typically only happens at the very end.
2- You can change the scope as you learn and see your product grow and there are options for still delivering business value at dates before the end of the project.
It's the data early and often that seems a good selling point. You start sooner, start producing real data sooner, and have more options.
ReplyDeleteBut I'm generally called in when the decision to change has already been made. I don't know how it's sold.
Tim
I would add a combination of 1 and 2:
ReplyDeleteThe client can decide to finish(not cancel) the project earlier, when he has enough business value and don´t want to spend more money on features that are not so relevant for the business.
The thing I find sells most users/stakeholders/customers is visibility. Even if the requirements aren't likely to change that much and even if the project has a well-defined and funded purpose that makes it unlikely to be cancelled, the fact that USCs can SEE the progress of system development against the high-level plan is a major advantage over waterfall.
ReplyDelete