Contracts are shaping the way we work. Even more so if you are working as a contractor. Surprise?! Is this why we are spending more and more time on them? Fixing them, trying to make them cover all aspects of the work, all possibilities of opportunistic behavior and so on.

I believe we are, in fact, forcing or leading parties of contracts with steady hands into a supposedly pre-determined behavior. And without even thinking of it, we are limiting our own abilities.

I mean, sometimes you do need some form of ‘protection’. Something to cover your behind. At least, that is what I see and hear a lot. People believing they need something to fall back upon. ‘When all else fails’.  To me, the time invested in coming up with a potential contract is what matters. This is what gets you thinking of what you want, how you want to achieve it and what it might be worth to you. Let that be a starting point and guidance. Don’t let it constrain you.

Tell me how

Some of the best software development efforts I’ve been involved in has been characterized by the lack of contracts. Or contained very little detail on working conditions. While this requires a lot of trust it really enables creative, competitive and collaborative solutions. Which is why you entered a contract or hooked up in the first place. The best working conditions are win-win. While many claim to be in a win-win relation, very few are. It is more often compromises. Or even win-lose, or lose-lose.

Some of you might come up with situations where contracts are more or less obligatory and you could be right. This is probably between two different organizations though.


Contracts within an organization usually doesn’t exist but I’ve heard of stories where they do. Imagine a situation where IT-departments have to submit offers to quotations from another part of the same organization … for every single project they want to start. Isn’t that just ridiculous. If there isn’t enough trust in an organization to do work without quotations, tenders and such, it is severely dysfunctional. Still, this happens, even as we speak. Probably more than we would like to think.

I have even been in situations where there are conflicting contracts. Think contracts between three different parties. ‘Software maintenance’ <-> ‘Customer’ <-> ‘Software development’. Where are the incentives for this to work. Maintenance has an SLA (Service Level Agreement) to adhere to. They do not want any ‘crap’ from software development. Software development wants to get things ‘out of  their hands’ as quickly as possible. Does that sound like good conditions for collaboration.

Have you ever been in a situation like that?

There are already several other forms of barriers you have to work against. You don’t need another hindrance to effective communication and collaboration. My guess is you could probably drop well over 80% of all contracts/content of a contract and still get by very well.

Contracts dictate behavior

Why all this ranting about contracts then. Well, contracts and their content is the driving force behind [a lot of] software projects. They in turn drive the ‘requirements’ which in turn shape the result of the effort. I believe there is a tremendous amount of waste involved in this phase of projects. I say phase because it usually is. If you have an agile view on how things should be done, and you are having a hard time getting there, it might be because you have two ‘phases’ surrounding your agile software development. The requirements phase before the project and then the delivery phase at the end.

What I’m saying is. No matter how ‘agile’ your software development is, look at the whole picture. Is the software part really as wasteful as anything else. Was it even as wasteful as, lets say the ‘prospecting’ phase, before you made it more effective?

Collaboration over negotiation

As a finish I would like to turn to the Agile manifesto and remind you all of the third value:

‘Customer collaboration over contract negotiation’.

Let that be a reminder for all of you who are in a contract situation. And that might very well include all of us. Is the contract limiting you in any way. Keep looking, because you might find things there that give you hints on why things work the way they do. Or don’t work the way you want them to.

Contracts and requirements often define they way we work, when they really should do so as little as possible. They are supposed to make it easy to stop working together. Not prolong a separation or support dysfunctional behavior.


About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

One response »

  1. […] Part three – Contract and Initial requirements   […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s