Comments on: Freedom of Agile Contracts http://blog.brodzinski.com/2010/02/agile-contract-freedom.html Dealing with software projects in real life Thu, 09 Sep 2010 12:05:20 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Pawel Brodzinski http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4544 Pawel Brodzinski Sat, 27 Feb 2010 13:21:51 +0000 http://blog.brodzinski.com/?p=1657#comment-4544 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. 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.

]]> By: Pawel Lipinski http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4493 Pawel Lipinski Fri, 26 Feb 2010 13:33:11 +0000 http://blog.brodzinski.com/?p=1657#comment-4493 Pawel 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
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.

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4449 Pawel Brodzinski Thu, 25 Feb 2010 08:55:25 +0000 http://blog.brodzinski.com/?p=1657#comment-4449 Pawel, 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,

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)?

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4447 Pawel Brodzinski Thu, 25 Feb 2010 08:42:25 +0000 http://blog.brodzinski.com/?p=1657#comment-4447 Laurent, "<i>You can’t have full agility and complete predictability at the same time.</i>" 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. Laurent,

“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.

]]> By: Pawel Lipinski http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4445 Pawel Lipinski Thu, 25 Feb 2010 08:07:28 +0000 http://blog.brodzinski.com/?p=1657#comment-4445 Hi 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 :-) Cheers Hi
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 :-)
Cheers

]]> By: Laurent Parenteau http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4425 Laurent Parenteau Wed, 24 Feb 2010 20:38:42 +0000 http://blog.brodzinski.com/?p=1657#comment-4425 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. 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.

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4422 Pawel Brodzinski Wed, 24 Feb 2010 20:06:10 +0000 http://blog.brodzinski.com/?p=1657#comment-4422 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 <b>need</b> 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>I need to know what I get in 30 weeks</i>" 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. 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.

]]> By: Laurent Parenteau http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4420 Laurent Parenteau Wed, 24 Feb 2010 19:54:24 +0000 http://blog.brodzinski.com/?p=1657#comment-4420 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... 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…

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4419 Pawel Brodzinski Wed, 24 Feb 2010 19:35:50 +0000 http://blog.brodzinski.com/?p=1657#comment-4419 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. 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.

]]> By: Laurent Parenteau http://blog.brodzinski.com/2010/02/agile-contract-freedom.html#comment-4418 Laurent Parenteau Wed, 24 Feb 2010 19:19:09 +0000 http://blog.brodzinski.com/?p=1657#comment-4418 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. 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.

]]>