agile contracting - killing bureaucracy
Post on 10-May-2015
2.719 Views
Preview:
DESCRIPTION
TRANSCRIPT
Agile ContractingLL.M. Juha Ilola
Agile Saturday X / Agile Estonia15 Feb 2014
Saturday, February 15, 14
© Copyright Reaktor 2014
legal guy @ Reaktor
previously @ major law firm, Sulake
doing legal IT stuff since 2001
Saturday, February 15, 14
© Copyright Reaktor 2014
Agenda
Killing Bureaucracy
Waterfall Contracts
Agile Contracts
Saturday, February 15, 14
© Copyright Reaktor 2014
Killing Bureaucracy
Photo Credit: http://www.flickr.com/photos/x_jamesmorris/
Saturday, February 15, 14
© Copyright Reaktor 2014
people really do hate bureaucracy.
Saturday, February 15, 14
© Copyright Reaktor 2014
bureaucracy=
“excessively complicated administrative procedure”.
Source: Oxford Pocket Dictionary via Google
Saturday, February 15, 14
© Copyright Reaktor 2014
lawyers, procurement, other bureaucrats
excessive, unnecessary administrative complexity.
Saturday, February 15, 14
© Copyright Reaktor 2014
administrative complexity
- increased initial transaction costs- increased cost of change
- increased non-value-adding work(e.g., unnecessary features, excessive documentation)
Saturday, February 15, 14
© Copyright Reaktor 2014
bureaucracy=
not only waste by itself, but also a catalyst for waste in
the system.
Saturday, February 15, 14
© Copyright Reaktor 2014
to eliminate waste, you need to kill bureaucracy.
Saturday, February 15, 14
© Copyright Reaktor 2014
unfortunately, laws prevent you from killing bureaucrats
like me.
Saturday, February 15, 14
© Copyright Reaktor 2014
two examples of legal ways to kill bureaucracy
Saturday, February 15, 14
© Copyright Reaktor 2014
1foot-in-the-door approach:
start small; immediately deliver exceptional results;
kill bureaucracy via internal pressure from the biz guys.
Saturday, February 15, 14
© Copyright Reaktor 2014
2kill-the-silos approach:
make bureaucrats understand agile / the way
value-adding work is actually done.
Saturday, February 15, 14
© Copyright Reaktor 2014
from waterfall to agile contract
Saturday, February 15, 14
© Copyright Reaktor 2014
a zero-sum game approach to collaborative contracts
creates non-optimal contracts, bureaucracy and
waste.
Saturday, February 15, 14
© Copyright Reaktor 2014
a collaborative contract should be optimized for
successful outcome, not for the (imaginary) interests of
one party.
Saturday, February 15, 14
© Copyright Reaktor 2014
a beautiful contract provides the the simplest possible solution
for its purpose.
Saturday, February 15, 14
© Copyright Reaktor 2014
Waterfall Contracts
Saturday, February 15, 14
© Copyright Reaktor 2014
waterfall contract
=
fixed price + fixed scope
Saturday, February 15, 14
© Copyright Reaktor 2014
“the Supplier will deliver to the Customer the
software described in Annex 1 for EUR [price] by
[deadline].”
Saturday, February 15, 14
© Copyright Reaktor 2014
assumptions in the contract dictate what will be done, not the real
(discovered) needs.
Saturday, February 15, 14
© Copyright Reaktor 2014
Fixed price encourages the
Supplier to put in minimum effort for
the agreed price.
Saturday, February 15, 14
© Copyright Reaktor 2014
Change Managementthe Supplier will agree to
change only if there is enough money on the
table.
contract is renegotiated throughout the project
(Change Orders).
Saturday, February 15, 14
© Copyright Reaktor 2014
the contract gives the customer illusion of control, but in fact
the Supplier operates as a black box and
has no incentives for transparency.
Saturday, February 15, 14
© Copyright Reaktor 2014
if one of the most common causes for IT failures is budget overflow, is price in
“fixed price contracts” really fixed?
Saturday, February 15, 14
© Copyright Reaktor 2014
Agile Contracts
Saturday, February 15, 14
© Copyright Reaktor 2014
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.
Saturday, February 15, 14
© Copyright Reaktor 2014
Empiric
Specified
Saturday, February 15, 14
© Copyright Reaktor 2014
Backlog
Specified in detail
Recognized, required functionalities
Release 1
Fuzzy ideas
Priority
Saturday, February 15, 14
© Copyright Reaktor 2014
the object of an agile contract should be the performance of service
(as opposed to delivery of specified results).
Saturday, February 15, 14
© Copyright Reaktor 2014
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.
Saturday, February 15, 14
© Copyright Reaktor 2014
contents of the services (i.e. backlog)
are agreed in accordance with the
agile method.
no separate change management is
necessary.
Saturday, February 15, 14
© Copyright Reaktor 2014
charged on time & material basis on the
basis of realized hours / days.
set max budget?
payment not tied to approval of results.
Saturday, February 15, 14
© Copyright Reaktor 2014
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.
Saturday, February 15, 14
© Copyright Reaktor 2014
indefinite term contract with
2 - 4 weeks’ notice period.
customer’s exit made possible by
assignment of all rights or unlimited license to results.
Saturday, February 15, 14
© Copyright Reaktor 2014
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.
Saturday, February 15, 14
© Copyright Reaktor 2014
Thanks!
Saturday, February 15, 14
top related