Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
We are a small company working in web development. I like Agile and I tend to use it within my team. The issue is: usually, clients need to get quoted with a lump sum of their project that will not adapt to their usual needs for changes. If I started charging them by change time, eventually they will think that we are over-charging them and these new requirements or changes aren't worthy to be charged.
How do you deal with your customers regarding charging and agile?
This question has two levels:
Even if you sign fixed scope/price contract with customer you still might be better off using agile/iterative approach. Use it as risk minimizing factor.
Nothing stops you from using e.g Scrum for fixed scope bid:
You can work in iterations
You can deliver increments of working software every Sprint
You can incorporate clients feedback (it might cause change/request, formal scope adjustment)
But what is more important, in the situation you run behind and you have problems with delivering 100% of scope on time/budget (which happens in most of software projects anyway)... you will be better off with agile approach.
You have better negotiation position with your customer:
Most importantly, you will have big part of the scope done and potentially shippable
Customer has probably seen your progress, so there is much more confidence and trust if your ability to eventually deliver, therefore it will be easier to find common ground
Most commonly used contract is Time & Material where customer pays for your team's work.
I've seen interested variation of agile contract that was proposed by Ken Schwaber in one of his books (I think Agile Project Management with Scrum):
After initial Release Planning you agree on the scope and contract value
If all the work is done and under budget you get 10% bonus added (not sure about exact figure)
Customer can decide to stop the work after each Sprint and pay you 20% of remaining budget as a re-compensate for the fact that you need to instantly reassign team to other teams
If you go over budget then customer is paying you much lower rate for the rest of work (you're sharing the risk of going over).
I usually approached your situation initially without even proposing anything else than fixed price contract as it seemed to be lost battle without relationship and trust. To build this relationship? Proving that you're professional and you know what you're doing is the best way :)
Upon contract signing I would inform customer that you'll be using Scrum for this project and invite them to participate. This is crucial, you want them to see for themselves how "their" software is built, you want then to have influence and see they can realize business value faster. If client stakeholders have real need for the software and you will engage them, there is good chance they will get addicted to the approach.
After first project, you can try agile contract described above or move strictly to time & material. It's matter of preference and business circumstances on both client and your company.
Discuss it with them and get their buy-in first.
Agile won't work very well if not everyone involved is on-board. Worst-case, you can still try to use Agile internally while working with external customers in a more Waterfall style.
Do not try to just foist Agile on them. Inform them about the benefits and let them see why it would be a good idea. If they're not buying it, do not just go ahead and start charging them for something that wasn't agreed upon.
TL:DR: Always use agile, change your reporting, not your contracts.
It sounds like the root problem here isn't about using agile nor the kind of contract you use, it's about managing Change Management.
Regardless of if you use agile or traditional development techniques any project over roughly a week is going to see changes. You need to help your client understand the costs of change and how this impacts the contract.
Using agile development means you have metrics that are usually more accurate and reflective of changes. Even if you use classic velocity based burn downs with best case, worst case (a good example can be found in Henrik Kniberg's Product Owner YouTube video) you can show a client, "Okay if you add this scope, we will either ship on X date, or need to drop Y scope to make your date."
To take it to a more advanced and highly data-driven model, I recommend Troy Magennis' forecasting model. You can find this at FocusedObjective.com where he offers the models free. These spreadsheets can model single and multi-feature projects and allow you to give highly accurate, Monte Carlo simulation based, forecasts for your projects. You'll be able to easily sit with a client and go "if we do this, X happens, this and Y happens and this Z happens. What do you want to do?".
Cheers
eventually they will think that we are over-charging them and these new requirements or changes aren't worthy to be charged.
The client should decide on the order of the backlog. If they feel enough value has been achieved then they should be able to cancel the development team at anytime. So if they think it is not worthy anymore you are done, time for the next client.
Recently I wrote about Agile and contracts on Medium, my final pitch was:
Don’t pay for features you do not need, minimize risk by working in short iterations and start monetising after the first most valuable features have been delivered as working software. Why settle for less?
I suggested you use a fixed budget and the client decides what has priority, just don't specify requirements in the contract. Jeff Sutherland wrote an example about a contract win-win for developers and clients in his latest book. (will try to summarize later, time for a meeting now ;-)
For agile to work the clients, product owners, scrum masters and team have to be trained (or should buy the concept) on agile.
I have seen many projects failing scrum sprints as the client's priority and sprint priorities clash and scope of sprints changes.
Agile is not remedy for every project. Evaluate your situation and make Waterfall with fixed priced model work better for you. You can use wireframes, workflow diagrams or sequence diagrams to get the requirements clarified better so as to reduce change requests.
OP
You have two problems:
1) How to handle change requests
Minor tweaks are fine, but at some point you will need to be firm, charge the clients for them and make them aware how the changes will impact the delivery date.
I suggest keeping a change log to track all change requests, and try and ensure that the requirement gathering is done thoroughly before work has begun.
2) Use Kanban, not Scrum for external clients.
Scrum is value and velocity based. The idea behind Scrum is where you only deliver x amount of work based on y velocity. So you prioritise the backlog according to what gives the most value and then omit the rest when you have run out of time.
Many clients do not care about this, and it only works extremely well when you're working in an environment or project that adopts this approach.
Since Kanban is based on cycle time and not velocity it is perfect for delivering work where there are fixed deadlines. It is also agile, since any new requirement goes to the bottom of the backlog where delivery is done in a conveyer belt style way.
