Agile Contracts
0 likes237 views
This document provides guidance on building agile contracts. It emphasizes focusing on problems rather than past practices, designing contracts that encourage cooperation between parties, and prioritizing early learning through an experimental process. The document recommends front-loading contracts with information, minimizing costs of learning so rational decisions can be made, and using a four-step cycle of discover, conceptualize, execute, and assess to continuously learn and adapt contracts over time based on new information that emerges. The overall aim is for contracts to reflect the intention of cooperation and accountability while encouraging adaptation and learning throughout the project lifecycle.
Agile Contracts
- 1. How to build an agile contract some steps to get you thinking in the right way • Martin Kearns • 25th Apr 2016
- 2. What problem do you want to focus on
- 3. Incremental change will not be enough as we enter this new era of agile and scrum in the corporate world.
- 4. Complete Exercise ASAP What does vendor management / your business want from a contractual engagement? What is preven:ng them and you from achieving their goal? • • • • • • • • • •
- 5. It is hard or maybe even impossible to extract, codify and transfer past knowledge in a way that makes sense outside it’s original seCng The only way to gain such knowledge is via an incremental process of learning by pracEce Projects have to discover their own way Place less emphasis on best pracEce
- 6. You can never direct a living system, you can only disturb it Maturana + Varela “ The Tree of Knowledge: The Biological Roots of Human Understanding 1992” A system will only be disturbed by informaEon based on what is going on inside the organisaEon
- 7. We really need to shake this place up! Order (Date, Cost, Time) is be[er than deep complexity regardless of informaEon lost It’s MarEn Time NOT !!!!!!!!!!!!!!! Our minds incline toward the instant and the obvious (Habit) under a false pretense that it will help in our own survival
- 8. Be wary of well-‐walked paths Once we know something, that knowledge makes it nearly impossible to remember not knowing. We become a prisoner to our tacit experience. Agile contracts are less about designing to get it right first Eme and more on learning and responding to new informaEon as it emerges within the lifecycle of a project / engagement
- 9. Name the enemy Meaning of so<ware So`ware means a right, including a licence, to use so`ware. Expenditure on so`ware includes expenditure you incur on acquiring or developing so`ware or in having another person develop so`ware principally for you to use to perform the funcEons for which you acquired or developed the so`ware. Expenditure in relaEon to so`ware projects is capitalised and depreciated from the :me you use the so<ware or install it ready for use. You can’t capitalise a fic::ous Business Case and/or a Business Requirements Document and/or the effort you place into wri:ng a crap contract. ….. End of story h[ps://www.ato.gov.au/Forms/Guide-‐to-‐ depreciaEon-‐2001/?page=24
- 10. Construct co-‐opera:on into the contract The more important thing is that the contract represents the intenEon, expected behaviours and accountability to the approach. The trick is to encourage co-‐ operaEon, by making sure there is the right pressure to encourage parEes to reciprocate.
- 11. Principle 1. Exploit early informaEon by front-‐loading the process The pebbles of past failures grows heavier the longer you keep carrying them on your shoulders
- 12. Design in the price-‐point for learning Time Minimise the cost of learning so that emoEons can be controlled and raEonal decision making is the norm Value / $ cost Pay to learn The ability to iterate is an economical decision. Where feedback is seen to shape an outcome through a) Re-‐enforcing b) AdapEng c) Serendipity d) Failing e) PivoEng Iterate Acquisition of knowledge Prioritize on early value Re-purpose Funding learning demonstrable value Incremental Min. viable project
- 13. An Experimental – Learning Cycle STEP 4 – Assess Carefully assess the tangible evidence of the sprint and determine whether to Pivot / Fail / Persevere / Pause Develop understanding of cause and effect STEP 1 -‐ Discover Run workshops where focus is on refining concepts through idenEfying new informaEon / causaEon Observe risk profile STEP 2 -‐ Conceptualise Build the hypothesis on what knowledge is required to assess confidence and the desire to proceed Prepare test environment STEP 3 -‐ Execute Use sprints to prove / disprove project assumpEons and the cohesiveness of the team Work purposefully Learning by Experimenta:on Via a cross-‐func:onal team
- 14. Step 1 – Designing your process of discovery STEP 1 -‐ Discover Run workshops where focus is on refining concepts through idenEfying new InformaEon / causaEon Observe risk profile Discovery requires a willingness to risk, or admit, not knowing when we confront directly the full weight our confusion or dilemma we are facing.
- 15. We need to broaden our perspecEve Early sprints encompass project experimentaEon, where understanding what works and does not work are of equal importance for learning.
- 16. Principle 2: The definiEon of done is a strategic decision Roles / Functions Infrastructure Continuous Integration Dev P.C. Continuous Delivery Predictive Analytics Iterative Development Digital Enabled SME in team no automation TDD/Build server We must engineer the removal of interfaces between funcEonal groups in order to speed up the process of team learning.
- 17. TesEng the landscape © SQS So`ware Quality Systems Ireland | Title of the PresentaEon | February 2013 | Business Shared Services IT Shared Understanding Incremental Value Demonstrable Value Empirical Evidence By working to a shared “definiEon of done” we have the ability to test the beliefs around collecEve responsibility, culture and required behaviors to achieve success. Learning increases linked cause and effect without the normal organisation factors that obscure our ability to commit to an outcome. Done
- 18. Outline a definiEon of done for your scenario Roles / Functions Infrastructure
- 19. Step 2 – Engineer rapid feedback to shape ideas by re-‐ inforcing, modifying or complemenEng exisEng knowledge Retaining cogniEve diversity is a required capability within teams to allow differenEaEon, permiCng the emergence of new thinking and new realisaEons of what is possible. STEP 2 -‐ Conceptualise Build the hypothesis on what knowledge is required to assess confidence and the desire to proceed. Prepare test environment.
- 20. Principle 3: Create a hypothesis to generate variables of interest
- 21. Steer the direcEon to what and where you wish to learn Regardless of what backlog items are delivered the culture and capability of the team will be demonstrated. Experimentation Degree of intervention Activity Description High Some Low Exploration Observation A focus on interface and technical functionality to assess feasibility of the intended solution exceeds behavioral concerns. Regardless on what backlog items are delivered the culture and capability of the team will be demonstrated.
- 23. Set your hypothesis NOW! No I won’t bring back that other slide. The learning objecEve is for you to create the focused language required to get the desired behavior and purpose across to others.
- 25. Step 3 – Test intent against the behaviours and velocity achieved via MVP Sprints Provide the rapid feedback necessary to shape behavior, process and soluEons by reinforcing, modifying or complemenEng exisEng knowledge. STEP 3 -‐ Execute Use sprints to prove / disprove project assumpEons and the cohesiveness of the team. Work Purposefully.
- 26. Process and roles limit the impact that technology advancement can provide through excessive organisaEon interfaces (gates) and normalised behaviors (roles) Principle 4: Enable the viability and resilience of systems to become purposeful
- 27. The intent of M.V.P. informaEon is to off-‐balance norms between two parEes and open itself to new and more meaningful conversaEon “Stretch to fit “
- 29. By moving away from command and control to one of “autonomy to outcome” you create a self-‐ determinisEc system. The gap between raEonal and behavioral viewpoints can spell the difference between project success and failure. Focus on the individual integrity
- 30. OrganisaEonal norm can impede adapEon & arEculate principles as a form of control Compliance Externalisa:on Internalisa:on Conformance to principle Explicit Prac:ces Educa:on Collec:vely responsible Self determined Behavioral norm Create an agreed set of fundamental truths around a project that are the foundaEons for system belief, individual intuiEon and decision making.
- 31. Values Principles Practices Methods • New information will be identified and valued when change is seen as a necessity for preservation and/or creativity • Maintain a higher sense of purpose within the team • People must be empowered to make their own decision as to “How” they can achieve a goal • A team must consist of all the skills needed to achieve the “Definition of Done” • Team takes collective responsibility for their processes and outcomes My Scrum Principles
- 32. Define some control/common principles for the engagement you have defined You have guessed it, I am not going to share the previous slide -‐ work on your own language. Try to see how you can explicitly state the expected behavior of two parEes into a common/shared understanding of how value is created.
- 33. STEP 4 – Assess Carefully assess the tangible evidence of the sprint and determine whether to Pivot / Fail / Persevere / Pause Develop understanding of cause and effect Provide the rapid feedback necessary to shape behavior, process and soluEons by reinforcing, modifying or complemenEng exisEng Knowledge. Step 4 – test intent against the behaviours and velocity achieved via MVP sprints
- 34. The iteraEon allows for any system variable to be created, disrupted, corrected & destroyed by creaEng pa[erns at scale that make contract levers tangible and used. Principle 5: You must prepare and sustain the required energy to observe and measure To see patterns, we need to step back from the problem and gain perspective System fractals are created as individuals exercise both freedom and responsibility towards some simple rules.
- 35. Create guiding values to outcome What we don’t want in a contract: People use their shared sense of idenEty to maximise their unique contribuEon to project success. Your responsible for How I will decide to punish -‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐ Deliverables Output Input We focus on achieving a shared outcome CollecEve Responsibility
- 36. IteraEons help small differences amplify into powerful and unpredicted system variables in non-‐linear systems that no model or methodology could achieve -‐ the system feeds back onto itself through the learning cycle. Don‘t ever forget what an iteraEon is for
- 37. Some simple but powerful stories Assessing the levels of maturity being achieve with the backlog over Eme and a commitment to a fixed deliverable. Visualizing the movements within a product backlog with velocity and a predicted trajectory of progress / compleEon.
- 38. Making contract deviaEons visible !
- 39. Produce some visualisaEons of a known problem Feel free to reuse some of what you have learnt today. However, if you want to really impress me, come up with some new ideas on how you can influence your systems through new forms of measurement and visualisaEon.
- 40. Individual raEonality leads to a worse outcome for both than what is possible Project variation Change request Over spend Leads to Best price Recover Unhappy customers Prisoners Dilemma – players cannot get out of the dilemma by taking turns exploiEng one another. The struggle to establish one’s reputaEon can be a major feature of intense conflicts.
- 41. Shared Experience Hands On ConstrucEve Feedback Transparency Shared Success Stories Strong Metric Legal Contract Co-‐created AdapEng to Change Embedded Team Evidence Based CollaboraEve Framework CollecEve Responsibility Partnership In any partnership, we recognise that we all have know-‐how, skills and insights to offer, and we all have the opportunity to learn and grow from one another. This is why we know that we will be co-‐creaEng with you the approaches that work for the ATO Enlarge the shadow of the future via Partnering When the probability to work with one another is high, co-‐ operaEon based on reciprocity is high bringing stability to future delivery.
- 42. An effecEve strategy must be able to take into account the history of iteraEon / interacEon to far MVP Discount parameter MMF W Enable multiple exit clauses With the opportunity for future sprints / interacEons co-‐operaEon can emerge from a system. Mutual co-‐operaEon depends on their being a good chance of a conEnuing relaEonship, as measured my the size of w. Co-‐operaEon can be accelerated by making interacEons more frequent and the ability to recognise defecEon more readily.
- 45. Dialogue Real dialogue is where two or more parEes become willing to suspend their certainty in each others presence. David Bohm My hope is that I have opened a door through which you can walk into a greater understanding how contracts can be framed.