Trust based contract model
for public sector
ANTTI VIRTANEN
+358 44 507 0050
antti.virtanen@solita.fi
Agenda
› Agile contract is and isn’t
› Public sector’s special properties
› Big agile: National Land Survey of Finland
› S...
Who am I?
› I work for Solita.
› We build software based solutions. Big and small. Web, BI, DW,
integrations. Data analyti...
Agile project
needs a
Agile contract
Picture: FAKEGRIMLOCK, under Creative Commons license
What kind of project is agile?
› Budget – scope – schedule
› You can’t be agile and have these fixed
› Change management
›...
What are you afraid of?
› What is the paramount concern?
› Budget, Schedule, Scope?
› Make it clear upfront why this is so...
The contract of fear
› Centered about sanctions
› Big sanctions on missing a preset goal
› Lot of difficult lawyer text
› ...
Trust is power
Trust based relationship
› Trust - “belief that someone or something is
reliable, good, honest, effective, etc.”
› Merriam...
Trust is simple
› Replaces the lawyer text with people
› Interestingly, agile is about people
› Simple is not easy
› Trust...
Trust doesn’t take away accountability
Picture: FAKEGRIMLOCK, under Creative Commons license
A trust based contract
› The vendor can take the risk
› A contract gives customer an easy way out
› Belief: “If the work i...
Public sector is afraid?
Picture: FAKEGRIMLOCK, under Creative Commons license
The laws
› We have a law about buying in Finland
(Hankintalaki)
› But it doesn’t say much about the contract model
› Neuvo...
Agile may look dangerous
› Fixed contracts might feel safe
› But they are not.
› In the best case you get what you ordered...
Public source is a new phenomena
› Why not make the result public and grant a liberal
license?
› Tax payers (us, the peopl...
Big Agile: Case NLS
(Maanmittauslaitos)
Case NLS, the Kirre project
› Three-year, multi million project
› Very visible (only if it doesn’t work)
› No fixed budget...
Case NLS, the contract model
› Two month trial period.
› A client can cancel the whole contract with their discretion.
› T...
Case NLS, the process model
› Client in Pasila, vendor in Tampere 180km away
› Hour based contract
› Transparency absolute...
Case NLS, how did it go?
› Original schedule was to go live in the end of
2012.
› Rescheduled to march 2013.
› Deemed too ...
Small agile: Case OPH
(Finnish National Board of
Education)
Case OPH, the Aitu project
› One team, approximately six months
› Not a high risk visible project
› Some of the requiremen...
Our current process model
› No sprints
› but weekly meeting and demo
› Dropped the estimates
› Past performance is quite a...
Maximum transparency
› The source code is 100% public (https://github.com/Opetushallitus/aitu)
› No vendor lock-in
› Quali...
The contract model
› Hour based contract
› The client has ultimate power over what will happen
› End date set
› Optional m...
OPH, How did it go?
› Pretty well
› Client is happy with the results
› We are happy to do our best
› Not perfectly
› Targe...
How to
make it
work
The secret: why does it work?
› Trust involves risk
› Most people are trustworthy. (Especially in Finland?)
› Being truste...
Do or do not; there is no try.
Picture: FAKEGRIMLOCK, under Creative Commons license
Practical issues
› Transparency is necessary
› About everything. Goals, progress, risks. Profits too.
› Both parties must ...
Responsibilities, a suggestion
› Backlog priorization (client)
› Setting the roadmap for the future
› Validating tests (cl...
Conclusions
Play it again, Sam?
› Public source code means accountability
› I won’t sign awful source code with my own name.
› Anyone ...
Some references to other people’s work
› Solinor contract model is extremely trust based:
› http://solinor.com/wp-content/...
QUESTIONS?
Thank you..
Upcoming SlideShare
Loading in …5
×

Turkuagile agile contractmodel_13052014

351 views

Published on

A

Published in: Software, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
351
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Turkuagile agile contractmodel_13052014

  1. 1. Trust based contract model for public sector ANTTI VIRTANEN +358 44 507 0050 antti.virtanen@solita.fi
  2. 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. 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. 4. Agile project needs a Agile contract Picture: FAKEGRIMLOCK, under Creative Commons license
  5. 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. 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. 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. 8. Trust is power
  9. 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. 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. 11. Trust doesn’t take away accountability Picture: FAKEGRIMLOCK, under Creative Commons license
  12. 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. 13. Public sector is afraid? Picture: FAKEGRIMLOCK, under Creative Commons license
  14. 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. 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. 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. 17. Big Agile: Case NLS (Maanmittauslaitos)
  18. 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. 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. 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. 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. 22. Small agile: Case OPH (Finnish National Board of Education)
  23. 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. 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. 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. 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. 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. 28. How to make it work
  29. 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. 30. Do or do not; there is no try. Picture: FAKEGRIMLOCK, under Creative Commons license
  31. 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. 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. 33. Conclusions
  34. 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. 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. 36. QUESTIONS? Thank you..

×