≡ Menu
Pawel Brodzinski on Software Project Management

Freedom of Agile Contracts


A discussion about convincing clients to agile is old already. I believe clients don’t care if you’re agile but to get most of your own agile adoption you usually need to change your client’s approach and that’s exactly where difficulties begin.

Agile is not a key selling-point; often it even makes selling a project harder. But you still want your client to accept the way you’re going to run the project. Why? That’s simple: at the very least you want to avoid BDUF and in the best case you need strong and frequent client’s involvement in the development process. And when we are at it – usually you want an agreement which reflect this kind of cooperation too. An agreement which uses more time and material basis than fixed fee for fixed work approach.

So yes, you need to convince your client to agile. How? Now, that’s a good question. There are a lot of answers, some good, some not-so-good, but I want to focus on one specific which is completely flawed. It goes like that:

“You, as a client, have a freedom to terminate this contract after each iteration, so if the whole thing doesn’t work for you it won’t cost you much.”

Sounds nice. But when I think about projects bigger than very small I hardly imagine a situation when I can see some features in their final versions during early iterations. I mean I can get some GUI doing things which I requested but it will be a mockup. On the other hand I can get the whole feature or two but they will be useless alone. Either way I can’t really say whether you do a good job or just a good show off. So I read it like that:

“You, as a client, have a freedom to terminate this contract after each iteration, but we’ll be halfway through until you’ll be able to say if you’re happy with the cooperation.”

It is still cheaper than it could have been, isn’t it? Well, it isn’t. I’ve already invested some money and, even more important, time. If I change a vendor now I’m losing twice and I have to start over. Odds are I’m already at the point where it’s easier to finish and fix instead of trash the project and start over. Thus I see it more like:

“You, as a client, have freedom to terminate this contract after each iteration, but when you know you want to do that most likely it won’t be cost-effective anyway.”

But I have a choice at least. Not that I would have much use of it but still, it’s my call. Sort of actually. This kind of rules is usually symmetrical. What does it mean? It means in most contracts both sides will have equal right to break it in specific situation. If I, as a vendor, can end cooperation in any given moment, so does my vendor. And we get to the point where:

“We, as a vendor, have freedom to terminate this contract after each iteration, i.e. when we hate your guts or we get a better deal somewhere else, and then you, as a client, are left out in the cold.”

You know what? I screw this kind of freedom. It looks nice on paper but I, as a client, have very limited use of it. At the same time I lose the stick I could use against a vendor which is a new risk for my project. Maybe the risk probability isn’t very high, but its potential impact is devastating. And yes, I’ve seen more cases of vendor abandoning the client than the other way around. And yes, it was a surprise to me at first. And yes, then I got used to it because it isn’t very uncommon.

OK, I admit there are projects which don’t look like that – you can either quickly verify quality of work or you have a comfort to trash the project and start over again even a day before its launch. On the other hand these projects don’t happen very often.

Freedom of agile contracts is overrated. When I wear my client hat I prefer to plan for longer relationship and fix it if it doesn’t work well. Breaking the relation is always hard and costly for client. A couple of iterations worth a month of vendor’s time means much more in terms of client’s preparation to kick the project off and usually a big slip in general plan. For a vendor it’s all easier.

You better don’t try use freedom as an argument to convince clients to agile contracts. At a first glimpse it may look appealing but if you give it more thought it is not.

Do you use freedom as an argument in discussions with your customers? How do they react?

in: project management, software business

10 comments… add one

  • Laurent Parenteau February 24, 2010, 12:19 pm

    First, thanks for the link to the answers on askaboutprojects.com. It’s a really interesting thread!

    Instead of trying to convince your client to sign that “agile contract”, would it be better to forget agile while crafting the contract?

    I mean, like you already said, clients don’t care about agile, they care about results. So if you think that a specific technique would improve the results / lower cost / reduce time for that particular project, and that technique require something from the clients (you don’t need to put “pair programming” in the contract), than why you don’t simply explain why it’s better, what are the alternative, and let the client decide which way he want to go?

    If you don’t use buzz word, like agile or waterfall or scrum or anything, and instead describe the exact activities you want to do, there should be less influence from external factor/prejudice and only your explanation will be used for the decision.

    At the end of the day, it is the client’s choice, but you may help him make to correct choice if you think about his needs before thinking about how you normally do stuff.

  • Pawel Brodzinski February 24, 2010, 12:35 pm

    I agree that we shouldn’t really talk about this “agile contract.” The only problem is that a contract which resonates well with agile development process is time-and-material-based. This is completely different than what we typically see which is fixed fee. So yes, we can forget about this whole agile thing but you still need to convince client to sign time and material contract, which is equally hard. And we come back to a discussion above.

  • Laurent Parenteau February 24, 2010, 12:54 pm

    Instead of convincing the client to sign a time and material contract, for the whole project, could you to cut the project into smaller parts? Than, you could go fixed price for the smaller parts, one part at a time (ie. you don’t talk about the fixed price terms of the second part until the first part is done). This way, you won’t have to go BDUF, since you only have to plan the first part, which could be a single (or couple of) iteration(s).

    But maybe the client could see this the same way as your example of “we can leave you anytime with an unfinished project”… It would depends on how you chop the projects, if the work done can be reused if the client decide to switch to another vendor…

    Maybe if you explain to your client that if he want fixed price, you’ll have to charge him change orders every time he change his mind, or add something, or remove something, that was not in the original proposal? I don’t think he will feel safer this way, and it may make your iterative proposition more interesting…

  • Pawel Brodzinski February 24, 2010, 1:06 pm

    That’s an interesting idea, I admit. But you face the same issues. Ideally I’d like to be pretty sure the vendor will go all the way to the final deployment, so I wouldn’t like to have a series of smaller contracts for something which makes logically a single project.

    On the other hand you can use a price as a differentiator, but it is taking a risk on your own.

    It is a mindset which is hard to overcome:

    – We’ll deliver you parts of the project every two weeks and you’ll be able to decide what’s next and change things all the time.
    – Cool. But tell me what exactly I get after 30 weeks?
    – Don’t know. It depends on your decisions along the way.
    – Not so cool then. I need to know what I buy.

    That’s a side discussion but this is one of things you need to overcome to sign “iterative” contract. “I need to know what I get in 30 weeks” syndrome.

    My point is that for a client this is more of a problem than a value. Even though it is often cited as one of arguments which should convince clients to go for agile contract.

  • Laurent Parenteau February 24, 2010, 1:38 pm

    We should not forget that agile was though by people developing software, not clients. Some clients may like it, but some may not. If your client absolutely want to know in advance exactly what it will be in 30 weeks, you have to plan for 30 weeks or refuse the project. There’s no magic solution. You can’t have full agility and complete predictability at the same time.

    But, you can have anything in between, balancing the advantages and disadvantages of both. You have to find the middle ground that you and (more importantly) your client are comfortable with.

  • Pawel Lipinski February 25, 2010, 1:07 am

    I think you’re wrong with the assumption that the main reason for stopping a contract is ‘because we have a bad cooperation’ or because the client is not satisfied with the project. Should that be the reason you’d be right. But the main point in being able to stop a contract/project after any iteration is to be able to ship a project at a given (unspecified when signing the agreement) point and be satisfied with whatever there is.
    Since we accept, that the project scope will change during the development, we also need to place in the contract some way to stop the cooperation, for the client to say: ‘I’m happy with what I have, that’s it!’
    That’s why we (at Pragmatists) have a clause, that the customer can stop after any iteration, but with 2-iterations of notice period (with 2-weeks iterations). It’s fair for the customer, since they cay really stop the project at any point, and it’s fair for us since we know with a monthly advance that we need to look for another job :-)

  • Pawel Brodzinski February 25, 2010, 1:42 am


    You can’t have full agility and complete predictability at the same time.

    You nailed it. Now, if you can adjust your process to client’s needs that’s fine, but if you want to adjust client’s process to your needs you should expect an uphill battle.

  • Pawel Brodzinski February 25, 2010, 1:55 am


    Finishing cooperation (in terms of new development) at the end of the project is natural. It doesn’t really matter how you define ‘the end’ – it may be delivery of specified functionality (as in fixed fee contracts) or client being satisfied with what they got (as in your example).

    I’m pretty sure majority of time and material contracts ends because of that – the work is done and there’s no reason to continue contract.

    However the argument I’m discussing here wasn’t about terminating the contract when the job is done but about doing this at any given moment because of any given reason, especially a client being unsatisfied with a vendor performance. And most of the time this isn’t real freedom for a client, because this freedom isn’t real and is limited in many ways.

    By the way, don’t answer if you don’t want, but when you, as a vendor, can terminate the contract? At the end of any iteration as long as you leave a month notice (2-iteration long)?

  • Pawel Lipinski February 26, 2010, 6:33 am

    I perfectly got your point the first time. I just meant that the idea of being able to stop at any iteration doesn’t aim at finishing bad cooperation, but is simply an ‘end of project’ condition.
    Finishing cooperation with a vendor is ALWAYS hard, irregardless of project management method. Client is never free nor is his vendor. That’s why we call cooperation a RELATION – it’s always a dependency. The later in the project – the deeper.

    And I as a vendor can also terminate also at any point, obviously keeping the notice period. But we have a really close cooperation with a lot of trust between me (as the owner of the vendor company) and our customer.

  • Pawel Brodzinski February 27, 2010, 6:21 am

    Yes, in the first place the point is to end cooperation smoothly when the job is done. But it can be used for both you and your client as an escape plan during the project too. But that’s not specific for agile contracts – every deal signed on time and material basis has option.

    The thing I don’t agree with is selling the escape plan as an advantage for customer. It just isn’t one.

    By the way: thing I observe is that average agile company values trust relationship with clients more than typical software house. Unfortunately this doesn’t mean that agile automatically mean ‘can be trusted’ since many companies just use it as yet another trendy buzz word which can buy them a couple of deals more.

Leave a Comment