Hacker News new | ask | show | jobs
by tchaffee 2130 days ago
So one data point. Sounds like they didn't differentiate themselves well enough from the fixed bid contract. The great thing about fixed price per sprint is they have to impress you with progress every sprint or they risk losing the job. That's great at motivating them to deliver value to you every sprint. Another way your interests are aligned: you know how many sprints you want to pay for. That motivates you to prioritize the most important features so they are completed before you run out of budget and sprints. What a great way to manage risk.
1 comments

But lack of alignment is known to be an issue with both flat AND time-based fees.

Charging per sprint is only superficially different from charging hourly/per day/per week/biweekly.

Consultants will want the project to last as long as possible. Clients will want it to be over as fast as possible.

You have to impress the client with every sprint? Just like a regular contractor must impress the client with every milestone.

How do you know how many sprints you want to pay for? So you have a budget, just like any regular old project.

You can prioritize features? But why wouldn't you do that without sprints?

What am I missing?

> But lack of alignment is known to be an issue with both flat AND time-based fees.

Agreed. Agile only puts you in a more flexible relationship. It does not fix every alignment issue. For that you need to be more creative with the contract. However it does spread the risk more evenly. And by you as the client taking on more of the risk instead of pretending an estimate or contract erased it, you will do a better job of managing the risk. Every sprint you'll decide what must be built next. Every sprint you get the opportunity to change requirements. Both of those are far better ways of managing risk than fixed price contracts or estimates.

> Charging per sprint is only superficially different from charging hourly/per day/per week/biweekly.

Not if you are delivering a working product at the end of each sprint. And yes, milestones are somewhat similar to sprints. Except as a client you've now locked yourself into what gets built and if requirements change you've got to renegotiate the contract.

> You can prioritize features? But why wouldn't you do that without sprints?

Because your fixed price contract legally "guarantees" all the listed features will be included.

> Clients will want it to be over as fast as possible.

And you can have that if each sprint ends with a working product. Up to you when the product has enough features included that you are happy with it. Or that you are out of budget. And you've managed risk aligned with the consultant instead of getting an unrealistic estimate they won't meet, or having a to head to court with a broken contract.