utilizing agile in your contracting process

Reaktor Mannerheimintie 2 00100, Helsinki Finland

tel: +358 9 4152 0200 www.reaktor.com [email protected]

©2016 Reaktor All rights reserved

Utilizing Agile in Your Contracting Process General Counsel Juha Ilola

IACCM EMEA Conference / 10 May 2016, Rome

REAKTOR MAY 2016 REAKTOR MAY 2016

About Reaktor • Creative technology company on mission

to build exceptional digital services

• Offices in NYC, Helsinki and Tokyo

• Headcount 360, turnover 43 MEUR

• Customers include HBO, Finnair, Nasdaq, Panasonic, Michael Kors, Kone, Supercell

•  Also one of the most active Nordic early stage investors through its investment arm Reaktor Ventures


My Focus •  I come from sell side, but presentation

focus is buy side •  Typical contract is continuous

professional service contract with 0 - 2 weeks’ notice period and 500K - 5 MEUR annual value

•  Reaktor’s focus industries are finance, retail, media, telecommunications, in-flight services and the public sector

•  Reaktor has flat organization consisting of small, self-organizing teams


1. Why agile?

2. What is agile?

3. How to contract in more agile manner?

4. Key takeaways

My Agenda

REAKTOR MAY 2016

1. Why agile?

Agile methods were conceived in the software industry to

tackle constant project delays and failures.

REAKTOR MAY 2016

Back in 1994, success rate in software projects was abysmal

16%

with 31% of projects failing and 53% becoming challenged.

REAKTOR MAY 2016

SOURCE: STANDISH GROUP INTERNATIONAL: CHAOS REPORT 1994

By 2015, success rate with agile methods has climbed to

39%

with 9% projects failing and 52% becoming challenged.

REAKTOR MAY 2016

SOURCE: STANDISH GROUP INTERNATIONAL: CHAOS REPORT 2015

REAKTOR MAY 2016

Technologies

Cus

tom

er n

eeds

Known Uncertain

Cle

ar

Uncl

ear

SOURCE: STRATEGIC MANAGEMENT AND ORGANIZATIONAL DYNAMICS BY RALPH STACEY

REAKTOR MAY 2016

I’m not in software business. Why should I

care?

REAKTOR MAY 2016

Software is eating the world. Disruptive new players shake every industry. Those who cannot adapt face

extinction.

REAKTOR MAY 2016

REAKTOR MAY 2016

2. What is agile?

REAKTOR MAY 2016

Typically when someone explains agile, you may hear and see something

like this.

Scrum

REAKTOR MAY 2016

Scrum

Kanban

REAKTOR MAY 2016

Scrum

Kanban

Extreme Programming REAKTOR MAY 2016

Scrum

Kanban

Extreme Programming

Process

REAKTOR MAY 2016

Scrum

Kanban

Extreme Programming

Events

SprintPlanning

DailyScrum

Sprint Review

Process

REAKTOR MAY 2016

Scrum

Kanban

Extreme Programming ProductBacklog Sprint

Backlog

Artifacts

Events

SprintPlanning

DailyScrum

Sprint Review

Process

REAKTOR MAY 2016

Scrum

Kanban

Extreme Programming Team

ProductOwner

ScrumMaster

Roles ProductBacklog Sprint

Backlog

Artifacts

Events

SprintPlanning

DailyScrum

Sprint Review

Process

REAKTOR MAY 2016

Although that stuff is important, let’s put it aside for the remainder of this

presentation.

REAKTOR MAY 2016

Being agile means being able to change course, and then changing

course when appropriate.

REAKTOR MAY 2016

Changing course includes the ability to easily start, and to end,

something when appropriate. The ability to try.

REAKTOR MAY 2016

REAKTOR MAY 2016

When operating in the complex problem domain you

need to be able to change course; and to start, end and

try things. You need to be agile.

REAKTOR MAY 2016

REAKTOR MAY 2016

3. How to contract in more agile manner?

“we have come to value… customer collaboration over

contract negotiation” The Agile Manifesto

REAKTOR MAY 2016

Risks in a software projects are most effectively managed with

proper ways of working, i.e. agile methodologies.

Not with a contract.

REAKTOR MAY 2016

A “great deal” passing all risk to other party mitigates your

down-side risk, but may hinder or even remove chances of succeeding.

REAKTOR MAY 2016

DON’T

prepare detailed, up-front specifications of deliverables as in reality deliverables are bound to

evolve during the project when your real needs are discovered.

REAKTOR MAY 2016

DO

find the best talent for the project. Keep possible contractual

requirements on a high level only so that implementation details

can benefit from emerging knowledge.

REAKTOR MAY 2016

DON’T

impose strict change management process in the

contract where “business owner to engineer” or “engineer to

engineer” change management is sufficient.

REAKTOR MAY 2016

REAKTOR MAY 2016

DO

give your business / project owner and the supplier’s professionals the power

to agree on changes to the scope within specified budget.

DON’T

use liquidated damages for delay or excessive warranties as they force

the supplier to deliver on the outdated requirements set out in the contract

and to fight changes.

REAKTOR MAY 2016

REAKTOR MAY 2016

DO

aim for collaborative issue resolution, e.g. by downscaling scope in case of apparent delay. If sanctions

are necessary, aim for “smaller percentages” without need to

evidence breach (e.g., trial period, satisfaction guarantee).

DON’T

enter into long fixed-term contracts with limited exit rights, or

(excessive) early termination penalties.

REAKTOR MAY 2016

REAKTOR MAY 2016

DO

aim for contracts that can be freely terminated when they no longer

benefit both parties. Split big contracts into small contracts. Test

new suppliers with PoC’s / small contracts before bigger awards.

DON’T

contractually force non-optimal ways of working onto people

performing the work.

REAKTOR MAY 2016

DO

let the people performing the work define and improve the ways or

working.

DON’T

set-up or agree to vendor lock-ins (via limited licenses or

otherwise).

REAKTOR MAY 2016

DO

ensure that you can actually end the business relationship

when it is no longer in your interest. In software world,

ensure that you have the IPR or unlimited license after expiry.

DON’T

increase your transaction costs by drafting unnessarily complex

contracts.

REAKTOR MAY 2016

DO

strive to draft simple, beautiful contracts, that provide the

simplest solution to the problem at hand. Simple contracts are easy to negotiate, perform and change.

DON’T

limit your thinking of agile to context of one contract only.

REAKTOR MAY 2016

DO

aim for an agile portfolio of contracts that can be quickly adapted

to change - e.g., by concluding and ending contracts, re-awarding

contracts between suppliers, scaling scopes up and down on the basis of

focus area shifts.

REAKTOR MAY 2016

4. Key takeaways

1.  Agility is crucial in complex domain.

2. To be agile is to be able to change course - and to start, end and try.

3. Contract terms should not limit agility in name of risk management if and where risks are best managed otherwise.

Thank you. Twitter @juha_ilola

utilizing agile in your contracting process

Business