A

1. Trust based contract model
for public sector
ANTTI VIRTANEN
+358 44 507 0050
antti.virtanen@solita.fi

2. Agenda
› Agile contract is and isn’t
› Public sector’s special properties
› Big agile: National Land Survey of Finland
› Small agile: Finnish National Board of Education
› How to make it work
› Conclusions

3. Who am I?
› I work for Solita.
› We build software based solutions. Big and small. Web, BI, DW,
integrations. Data analytics. Cool things.
› My title is “software architect”
› I work as a Product Owner in my current project.
› I am the project manager too.
› I also implement things. Clojure, SQL, Java, DevOps, whatever.
› Does this sound weird?

4. Agile project
needs a
Agile contract
Picture: FAKEGRIMLOCK, under Creative Commons license

5. What kind of project is agile?
› Budget – scope – schedule
› You can’t be agile and have these fixed
› Change management
› A board meeting 1-4 times / month?
› Not agile (in my book)
› Agile is about managing change and dealing with
(unpleasant) surprises

6. What are you afraid of?
› What is the paramount concern?
› Budget, Schedule, Scope?
› Make it clear upfront why this is so.
› The other two should be flexible.
› Do you trust the vendor
› to do their best?
› to have your best interest in mind?
› to be competent?

7. The contract of fear
› Centered about sanctions
› Big sanctions on missing a preset goal
› Lot of difficult lawyer text
› “Doing the right thing” might become
unreasonable under this contract.
› Creates an illusion of safety.
› This a win-lose contract. Often lose-lose.

8. Trust is power

9. Trust based relationship
› Trust - “belief that someone or something is
reliable, good, honest, effective, etc.”
› Merriam-Webster
› Base the relationship between vendor and client
on trust
› The contract is a statement of mutual understanding
› The relationship is more important than the transaction

10. Trust is simple
› Replaces the lawyer text with people
› Interestingly, agile is about people
› Simple is not easy
› Trust involves risk
› Trusted relationship can’t be one-sided
› How to know who is trustworthy?

11. Trust doesn’t take away accountability
Picture: FAKEGRIMLOCK, under Creative Commons license

12. A trust based contract
› The vendor can take the risk
› A contract gives customer an easy way out
› Belief: “If the work is good, customer will pay”
› The risk: Customer will use the contract as a lever to squeeze
› The customer too takes a risk
› No hard sanctions or heavy change management
› Belief: “We have chosen the right partner”
› The risk: If it doesn’t work out, there is no one to blame

13. Public sector is afraid?
Picture: FAKEGRIMLOCK, under Creative Commons license

14. The laws
› We have a law about buying in Finland
(Hankintalaki)
› But it doesn’t say much about the contract model
› Neuvottelumenettely (negotiation based contracting) is not
utilized
› Often scope, schedule and budget are somewhat
fixed.
› It is important to be transparent about this!

15. Agile may look dangerous
› Fixed contracts might feel safe
› But they are not.
› In the best case you get what you ordered. Not what was needed.
› In the worst case you end up fighting over the contract.
› Contracting agile vendor is risky
› But so is fixed bidding competition

16. Public source is a new phenomena
› Why not make the result public and grant a liberal
license?
› Tax payers (us, the people) pay the bill.
› By definition, public sector has no competition.
› There is real potential
› Public source code may get reused
› This is transparency for the citizens
› Quality is likely better; who would deliver crappy software in public?
› A vendor lock-in is unlikely. At least it is visible.

17. Big Agile: Case NLS
(Maanmittauslaitos)

18. Case NLS, the Kirre project
› Three-year, multi million project
› Very visible (only if it doesn’t work)
› No fixed budget, but a target budget
› Pretty fixed schedule
› Schedule not directly controlled by the client
› Partly fixed scope
› Some of the requirements specified by the law
› Laws leave room for interpretation

19. Case NLS, the contract model
› Two month trial period.
› A client can cancel the whole contract with their discretion.
› Technical, process, delivery etc. abilities evaluated during the
trial.
› Basically an insurance to offer the easy way out. Both parties
took a big risk.
› It worked very well!
› We were transparent and open about our progress and issues.
› The client was open about their thoughts.

20. Case NLS, the process model
› Client in Pasila, vendor in Tampere 180km away
› Hour based contract
› Transparency absolutely essential
› No strict “process model” or ceremonies
› Adapted multiple times during the project
› Scrum-style with two week sprints.
› One week when things got serious :-)

21. Case NLS, how did it go?
› Original schedule was to go live in the end of
2012.
› Rescheduled to march 2013.
› Deemed too risky and went live on may 2013. (+ 5 months)
› Budget and scope were in original target
› In the end, everything was ok
› But definitely didn’t go the way it was planned!
› Wouldn’t have worked out well without mutual trust.

22. Small agile: Case OPH
(Finnish National Board of
Education)

23. Case OPH, the Aitu project
› One team, approximately six months
› Not a high risk visible project
› Some of the requirements fixed
› The law again
› Our client is Vocational Adult Education and
Training unit inside the Board of Education.

24. Our current process model
› No sprints
› but weekly meeting and demo
› Dropped the estimates
› Past performance is quite accurate
› Continuous Delivery
› Build promotion from the trunk
› Very flexible. Lean and agile

25. Maximum transparency
› The source code is 100% public (https://github.com/Opetushallitus/aitu)
› No vendor lock-in
› Quality pressure on us
› Kanban flow
› Jira + Git + Jenkins + continuous delivery
› Daily progress visible on demo environment 24/7
› Priorization not tied to sprints, possible at any moment

26. The contract model
› Hour based contract
› The client has ultimate power over what will happen
› End date set
› Optional maintenance phase
› The easy way out
› A big requirements document
› .. which still left room for interpretation

27. OPH, How did it go?
› Pretty well
› Client is happy with the results
› We are happy to do our best
› Not perfectly
› Target budget has been overrun
› We didn’t go live as planned.
› The problems?
› Various reasons. Transparency helps a lot.

28. How to
make it
work

29. The secret: why does it work?
› Trust involves risk
› Most people are trustworthy. (Especially in Finland?)
› Being trusted is empowering
› Being trusted implies being responsible for results
› Trust means freedom and autonomy
› Both of these factors are highly motivating
› Not everyone will want this
› What are they afraid of?

30. Do or do not; there is no try.
Picture: FAKEGRIMLOCK, under Creative Commons license

31. Practical issues
› Transparency is necessary
› About everything. Goals, progress, risks. Profits too.
› Both parties must be open.
› Public source code is a new tool.
› Keep the contract simple
1. Insurance clause: Easy way out
2. Mutual understanding of big issues
› Everything else is waste.
› Hour based agile contracts demand lean flow
› Continuous delivery and short lead times

32. Responsibilities, a suggestion
› Backlog priorization (client)
› Setting the roadmap for the future
› Validating tests (client)
› Are we building the right thing? (Product Owner)
› Verification tests (vendor)
› Everything works as we agreed
› Deployment pipeline (vendor)
› The client should get everything instantly (lean + JIT. Continuous delivery.)
› Building the thing (vendor)
› Change management (both?)

33. Conclusions

34. Play it again, Sam?
› Public source code means accountability
› I won’t sign awful source code with my own name.
› Anyone can see what our tax money is being used for.
› Competition? Bring them on..
› Public source code enables competition.
› The upside of trust based contracts
› No micro management
› No boring and useless meetings
› Everything happens faster (no waste)
› We provided proof that this works
› And it is simple. (Not easy.)

35. Some references to other people’s work
› Solinor contract model is extremely trust based:
› http://solinor.com/wp-content/uploads/Solinor-Ketteran-kehityksen-
sopimus.pdf
› Vincit seems to be talking about the same thing here:
› http://67.prosenttia.fi/2013/08/22/julkiset-hankkeet-osa-1001/
› The book Trusted Advisor is also relevant:
› http://www.amazon.com/The-Trusted-Advisor-David-
Maister/dp/0743207769/ref=dp_ob_title_bk
› Martin Fowler has some good ideas to share:
› http://www.martinfowler.com/articles/newMethodology.html
› Also Reaktor likes simple trust based contracts:
› http://turkuagileday.fi/past/2013/topics/slides/ilola.pdf

36. QUESTIONS?
Thank you..