My Agile Contracts speech given at Agile Estonia in February 2014, where I encouraged people to kill bureaucracy and to call doges doges, not cats.

1. Agile Contracting
LL.M. Juha Ilola
Agile Saturday X / Agile Estonia
15 Feb 2014
Saturday, February 15, 14

2. legal guy @ Reaktor
previously @ major law firm, Sulake
doing legal IT stuff since 2001
© Copyright Reaktor 2014
Saturday, February 15, 14

3. Agenda
Killing Bureaucracy
Waterfall Contracts
Agile Contracts
© Copyright Reaktor 2014
Saturday, February 15, 14

4. Photo Credit: http://www.flickr.com/photos/x_jamesmorris/
Killing Bureaucracy
© Copyright Reaktor 2014
Saturday, February 15, 14

5. people really do hate
bureaucracy.
© Copyright Reaktor 2014
Saturday, February 15, 14

6. bureaucracy
=
“excessively complicated
administrative procedure”.
Source: Oxford Pocket Dictionary via Google
© Copyright Reaktor 2014
Saturday, February 15, 14

7. lawyers, procurement, other
bureaucrats
excessive, unnecessary
administrative complexity.
© Copyright Reaktor 2014
Saturday, February 15, 14

8. administrative complexity
- increased initial transaction costs
- increased cost of change
- increased non-value-adding work
(e.g., unnecessary features, excessive documentation)
© Copyright Reaktor 2014
Saturday, February 15, 14

9. bureaucracy
=
not only waste by itself, but
also a catalyst for waste in
the system.
© Copyright Reaktor 2014
Saturday, February 15, 14

10. to eliminate waste, you need
to kill bureaucracy.
© Copyright Reaktor 2014
Saturday, February 15, 14

11. unfortunately, laws prevent
you from killing bureaucrats
like me.
© Copyright Reaktor 2014
Saturday, February 15, 14

12. two examples of legal ways
to kill bureaucracy
© Copyright Reaktor 2014
Saturday, February 15, 14

13. 1
foot-in-the-door approach:
start small; immediately
deliver exceptional results;
kill bureaucracy via internal
pressure from the biz guys.
© Copyright Reaktor 2014
Saturday, February 15, 14

14. 2
kill-the-silos approach:
make bureaucrats
understand agile / the way
value-adding work is actually
done.
© Copyright Reaktor 2014
Saturday, February 15, 14

15. from waterfall to agile contract
© Copyright Reaktor 2014
Saturday, February 15, 14

16. a zero-sum game approach
to collaborative contracts
creates non-optimal
contracts, bureaucracy and
waste.
© Copyright Reaktor 2014
Saturday, February 15, 14

17. a collaborative contract
should be optimized for
successful outcome, not for
the (imaginary) interests of
one party.
© Copyright Reaktor 2014
Saturday, February 15, 14

18. a beautiful contract provides the
the simplest possible solution
for its purpose.
© Copyright Reaktor 2014
Saturday, February 15, 14

19. Waterfall Contracts
© Copyright Reaktor 2014
Saturday, February 15, 14

20. waterfall contract
=
fixed price + fixed scope
© Copyright Reaktor 2014
Saturday, February 15, 14

21. “the Supplier will deliver
to the Customer the
software described in
Annex 1 for EUR [price] by
[deadline].”
© Copyright Reaktor 2014
Saturday, February 15, 14

22. assumptions in
the contract dictate what
will be done, not the real
(discovered) needs.
© Copyright Reaktor 2014
Saturday, February 15, 14

23. Fixed price
encourages the
Supplier to put in
minimum effort for
the agreed price.
© Copyright Reaktor 2014
Saturday, February 15, 14

24. Change Management
the Supplier will agree to
change only if there is
enough money on the
table.
contract is renegotiated
throughout the project
(Change Orders).
© Copyright Reaktor 2014
Saturday, February 15, 14

25. the contract gives the
customer illusion of
control, but in fact
the Supplier operates
as a black box and
has no incentives for
transparency.
© Copyright Reaktor 2014
Saturday, February 15, 14

26. if one of the most common causes for IT
failures is budget overflow, is price in
“fixed price contracts” really fixed?
© Copyright Reaktor 2014
Saturday, February 15, 14

27. Agile Contracts
© Copyright Reaktor 2014
Saturday, February 15, 14

28. risks of a software project are best
addressed by using agile methods.
not with contract.
agile contract should make it possible
to capitalize on the ability of agile
methods to provide the customer with
best value for a given budget.
© Copyright Reaktor 2014
Saturday, February 15, 14

29. Specified
Empiric
© Copyright Reaktor 2014
Saturday, February 15, 14

30. Backlog
Specified in detail
Priority
Recognized, required
functionalities
Fuzzy ideas
Release 1
© Copyright Reaktor 2014
Saturday, February 15, 14

31. the object of an agile
contract should be the
performance of service
(as opposed to delivery of
specified results).
© Copyright Reaktor 2014
Saturday, February 15, 14

32. team members subject
to approval of the
customer.
the customer has the
right require the
change of a team
member at any time,
for any reason.
© Copyright Reaktor 2014
Saturday, February 15, 14

33. contents of the
services (i.e. backlog)
are agreed in
accordance with the
agile method.
no separate change
management is
necessary.
© Copyright Reaktor 2014
Saturday, February 15, 14

34. charged on time &
material basis on the
basis of realized
hours / days.
set max budget?
payment not tied to
approval of results.
© Copyright Reaktor 2014
Saturday, February 15, 14

35. Reaktor’s satisfaction
guarantee:
if the customer feels that
Reaktor has not performed
with satisfactory level, they
may notify Reaktor and
receive automatic discount
- no questions asked.
© Copyright Reaktor 2014
Saturday, February 15, 14

36. indefinite term
contract with
2 - 4 weeks’ notice
period.
customer’s exit made
possible by
assignment of all
rights or unlimited
license to results.
© Copyright Reaktor 2014
Saturday, February 15, 14

37. doge is doge even if you call it cat.
Regardless of what you call it, it is not
agile if you do it with waterfall contract.
© Copyright Reaktor 2014
Saturday, February 15, 14

38. Thanks!
© Copyright Reaktor 2014
Saturday, February 15, 14