contracts, copyright, IPR, contractual and business relationship with your client

Software development is a service

lower maintenance, better uptime
****************************************************************
Think Again:
- Software is a service
- Software development is a service
• Contract for complex software development services, not only for lines of code
- Therefore we Sell the service, and not only product

• Designs, Data, acquired Know how, Business Domain Knowledge, Intellectual Property Rights are the consequences of such intellectual service - and who owns them is the question which must be answered crisply and precisely?!
Answer is: it depends, and it is complicated legal and business issue - it depends what type of contract have you signed!
- did you give limited or unlimited licence to your client to use, sell and modify your code?
- do you keep or did you transfer some, all or none of Intellectual Property Rights to your client?
- do you have some royalties which depend on sales success of your software, or is it just one time sell?

• rethink the contract process - Within a rolling contract framework
– Client may cancel contract at any time without payment of the outstanding fees
– Client may add work during contract
– Client must agree priorities for each iteration

• Contract is a framework for work
• Contract to do work – Client is buying capacity to do work
– Open ended time – Discovering what is needed is part of the work
– Duel track discovery & development

• Planning: deciding what to build is part of the work
• Contracts do not state precisely what will be built, only vaguely in marketing terms
• Think Again - Don’t sell product features B, C, D, ….
• Think Again - Do sell a development service and tell to client: We will work with you to solve problem, and unlock various other benefits ( which might be B, C, D, …)


===================================================
Commits: Software development work is done in small chunks.
Increments: I know this may not sound very sexy, but software creation works best when small changes are introduced to working software with production data.
Iterations: Software development work is done in tiny pieces again, again, and again.
Cost: The truth is that when we start an IT project, we often don’t know how much time and effort it will take to complete. Consequently, we don’t know how much it will cost.
Proverbial win-win scenario: Suppliers who can break away from the fixed price, fixed scope, fixed time contracts stand to gain a competitive advantage over the market leaders. Customers stand to benefit from innovative approaches that provide a better outcome.
===================================================
We have used Agile contracts twice now with great success. One was on a local government engagement in which there were three parties bidding. We were the most expensive and won it because of the approach we took (Scrum). The client didn’t know what they didn’t know, so the idea of being able to reduce risk by seeing working software delivered to them every Friday afternoon, shortly followed by another Sprint Planning session to plan the next round of work was something they were more than happy to pay for.
I believe as an industry we have held clients at arms length via traditional fixed price (/scope, /time) contracts and not been entirely honest about the implications of this approach. After all, didn’t the Agile Manifesto talk about customer collaboration over contract negotiation? I realise the commercial reality is sometimes different and challenging but I passionately believe that as professionals we owe it to the industry to grow and mature, after all – isn’t that part of our job and a moral responsibility? How else will it ever change?
We will continue to use agile contracts to our advantage as from the above we have earned the trust and respect of our clients - something that requires a long term view but in my mind is worth the time.
===================================================
While an employer owns intellectual property created by employees in the course of employment, the same rule does NOT apply when engaging a contractor, author or consultant.

In the absence of a contract to the contrary, an author-consultant will own the intellectual property that he creates.

Question for you: In construction projects, do architects usually figure out all of it when they finish the design?
Do they usually have to change design after they start constructing?

The problem with your second point is that the subject matter experts don't know how to design and code and software engineers normally don't understand the business well enough to write the requirements and use cases. The design phase of construction projects is like software development. The architects use iterations with feedback to create 3D models and finally blueprints that are used as a starting point for fixed price bids and actual construction.

Pragmatically, the flavor of the relationship will influence and the shape the contract. When you sit down and sign, both sides have this feeling of excitement and anticipation rather than nervousness and fear.
Agile Manifesto talk about customer collaboration over contract negotiation?