Updated - Agile Based Contracts

Normal contracts are difficult enough to agree. Do we have a consultancy agreement, master service agreement, master service and support agreement, statement of works, amendments, changes, appendices etc etc. What is the appetite to risk, rewards, and payments, what if things go wrong? Agile based contracts take this to a new level.?How do we make suppliers, contract managers responsible accountable when by its very nature we need to change deliverables on a regular basis? Agile is one of those words that is like marmite, love it, hate it but few people really understand what all the fuss is about. Internally to the team it is a buzz word and even a fad. Quite often it is confused with lack of planning, JFDI or it something the development team do. This is simply put the wrong end of the stick. The word agile, can mean nimble, spritely, supple, alert or even swift. Great I hear you say but what has that got to do with me in my firm. One of the key aims of the contract is to stop firms needing to go to court, it clarifies the expectations, obligations and delivery approaches, whilst minimising risk with flexibility to change or pivot direction.

Let’s have a 101 session Agile should infect all layers of a business, it is really about breaking down big steps to little steps with the ability to change direction if you need to fast. It starts off with an idea often borne out of a customer(s) pain points and thinking about how we can put solution together that can resolve these issues. If the firm is good they can do some market research and often assessed against some basic criteria, called the “IT Industry”

???????????????Will customers buy it?

???????????????Can we support it?

???????????????Can we build it?

???????????????Can our customers use it?

Now we are in the IT industry, we often need help to delivery IT. One of the hardest things to do is to write an Agile contract without named deliverables. By definition the deliverables change to fast, so where do you start and how do you write one. For example using the SAFE framework there are Sprints (2 weeks in length) and Program Increment Event, which can change scope and prioritisations (5 or 6 sprints in length). In a traditional contract that could potentially mean a change control every 2 weeks, for every team. 10 teams could lead to lots of changes. Hence not a good idea, especially if a decision is needed to proceed and that decision/change team may meet once a week or two. We need to work smarter, as resources can not sit around waiting for decisions to be made.?Worse still how can we clarify that the teams are working at proper pace and giving due consideration to all relevant factors (GDPR/NIS2, Security, Definitions of Done, Definitions of Ready, Continuous Integration/Continuous Development (CI/CD) etc etc).

Using the SAFE Framework, in principle we can go to SAFE and download a copy of a contract and hand it out to a supplier who will happily sign it. There is a nice article, please see the link https://www.scaledagileframework.com/agile-contracts/ unfortunately it is not even a starting point. If you thought it would be a quick process, given many firms review processes, we are where we are approach,?give yourself 6 months – 1 year to create the documentation and to get the standards up to be required level to be able to use it. A new MSA will take 2-3 months to agree with a supplier.

So in principle much of the contract is based on processes / cadence outside of the contract that is then referred to within the contract. In reality no one cares about the contract unless something goes dreadfully wrong then every word is stewed over. Agile manifesto says Customer Collaboration over Contract Negotiation, however lawyers will tell you that is great until you need to go to court. Typical arguments that contracts need to cover

·????????The Customer approved the work with the response you’re the experts

·????????Transition to live that is your process, you never told us

·????????Maintenance don’t mention security hotfixes and only N-1

·????????The requirements did not cover data lifecycles

·????????Normalisation of business complexity points is for the organisation to address

?

Every issue listed above will need work outside of the contract to facilitate a successful product. One of the key learning points is that architects and developers are not lawyers, and hence the organisational assets that are developed will change and that writing standards needs to ensure that SMART approaches for requirements are documented. Continuous service improvement means information that is not online will be out of date and thinking about how to deal with this is required from sentences like such and such standards will be modified from time to time by a named role to please see the link for latest version. Some of these standards that will need to be documented include

·????????Acceptance criteria

·????????Testing methodologies and frameworks

·????????Definitions of done

·????????Definitions of ready

·????????Standardised job roles

·????????GDPR + any other external compliance

·????????Story Points, Business complexity points

This is before you start with the traditional areas of contract management

·????????Payment

·????????Project Tools, Supplier's warranties, Customer's warranties,

·????????Limitation of liability,?Insurance, Force Majeure, Confidentiality

·????????Data protection , Security of network and information systems

·????????Anti-bribery

·????????Termination, Conflict, Severance

·????????Governing law

·????????Dispute resolution procedure

·????????Scope

·????????Location of Service

·????????Supplier rates

·????????Billing summary

·????????Project duration

·????????Support Key Performance Indicators (KPI), Service Window, Supplier Service Window

·????????Contract Changes

·????????Fees, Invoicing

·????????Processing, Personal Data and Data Subjects

·????????Supplier's network and information systems security

·????????Expenses, Public, local and company calendar, Holidays

·????????Etc etc ….

Just a word to the wise, be careful about ensuring that Buy, Make or reuse is considered before a team is engaged.?There is a whole world of pain for organisations that go down the agile route for product development rather than considering if it is cheaper to buy a product and configure. This will be the subject of a different article.

In summary whatever time you believe an Agile Contract will take, double it and add some more, as the internal standards for the organisation will almost certainly need a major overhaul. Writing an Agile Based Contract is a completely different way of viewing contracts to achieve an element of standardisation.

Jason Douglas has been a Supplier Manager / Programme Manager and Enterprise Architect for Konica Minolta who has developed and implemented the Agile processes for Outsourcing Supplier Management.