1 / 26

Agile contracting games The rules of the game

Agile contracting games The rules of the game. v2.1 – December 2011. Introduction Who are we. Gert van de Krol. Dick van der Sar. Introduction Workshop. Introduction Session structure. Baseline Statements. Agree. Disagree. No opinion.

ros
Download Presentation

Agile contracting games The rules of the game

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agile contracting gamesThe rules of the game v2.1 – December 2011

  2. IntroductionWho are we Gert van de Krol Dick van der Sar

  3. IntroductionWorkshop

  4. IntroductionSession structure

  5. BaselineStatements Agree Disagree No opinion • A project has a joint and shared objective, a game has an individualgoal; • Rules may change during the game; • Everyone must know the contract; • Agile projects do not need a contract; • With Agile the workplace is detachedfrom management. B F B F B F B F B F

  6. IT ContractAgile Manifesto The ‘Agile manifesto’ Customer collaboration over contract negotiation. • What does this statement mean? • No contract (negotiations)? • Only contracts focused on collaboration with users?

  7. IT ContractXP Bill of Rights Developer Bill of Rights • You have the right to know what is needed with clear declarations of priority. • You have the right to produce quality work at all times. • You have the right to ask for and receive help from peers, superiors, and customers. • You have the right to make and update your own estimates. • You have the right to accept responsibilities instead of having them assigned to you. Customer Bill of Rights • You have the right to an overall plan, to know what can be accomplished when and at what cost. • You have the right to get the greatest possible value out of every programming week. • You have the right to see progress in a running system proven to work by passing repeatable tests that you specify. • You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs. • You have the right to be informed of schedule changes in time to choose how to reduce the scope to restore the original date. You can cancel the project at any time and be left with a useful working system reflecting the investment to date.

  8. IT ContractDefinition General: • A contract is an agreement between two or more parties which can be legallyenforced. • Contract implies an offer and an acceptance of that offer. • Offer: delivering a product or service. • Acceptance: rewarding the successful delivery. IT: • What kind of offerings? • When is the delivery successful? • How does a contract ensure the success?

  9. IT ContractOfferings: sourcing levels • Commitment / Time & material Agreement (posting). • Project Agreement. • Framework Agreement. • Service Level Agreement (SLA)

  10. Game 1Playing the game • Number of players: 2 + observers. • Available time: 2 min 30 Goal: to win! Assumptions: • Each participant knows how to play cards. • The players can interact and discuss Material: • Two stacks of cards

  11. Game 1Evaluation • Observations: • The rules of play. • The goal of the game • Translation into IT: • The analogy with contracting.

  12. Rules of playExample

  13. Rules of play Structure • Context • number of persons • duration of the game • ages of participants • Goal of the game • Materials • Roles • Preparation • Rounds • steps • situations • examples • exceptions • Game end • Scoring

  14. Rules of playStructure in the example Rounds & Examples Game end Context, Persons & Age Scoring Materials & Roles Goal Preparation Rounds & Examples

  15. Game 2Changing the rules • Available time: 5 min • Roles: n players + 1 rule manager + 1 observer. • Preparation: • each player gets 5 cards. • stack of cards face down with one card facing up at the side • Rounds: • Player1 plays a card. • If rule is applicable the rule manager explains the rule. • The rule is executed • Player2 plays a card. • etc. • Game end and score: • The first player who has played all his or her cards wins. Goal: to win a game of ‘Jacks’ (pesten)! Assumptions: • Each participant knows how to play cards. • The players can interact and discuss. • The rules have been described and handed over to the rule manager. Material: • Stack of cards. • Rule paper.

  16. Game 2Evaluation • Observations: • the rules of play. • roles. • Translation into IT: • the analogy with contracting.

  17. Agile contractingPRINCE2 and RUP

  18. Agile contractingRUP-lifecycle

  19. Agile contractingPRINCE2 and RUP

  20. Game 3Cooperation • Available time: 10 min • Roles: 4 players (builders, saboteurs) + 1 observer. The color of the highest card determines the role: • Red: saboteur. • Black: builder. (when both colors have the highest card : builder). • Preparation: • each player gets 4 cards in hand. • one card facing up (start card), thee (end) cards facing down. • pile of cardsfacing down • Game end : • time is up or • all cards of the deck have been picked. Goal: Create a road of 5 cards width. Score • builders win when a road is created. • saboteurs win when no road is created. Assumptions: • The players may not interact and discuss there roles. • A saboteur must act carefully. Material: • Stack of cards. • Rule paper.

  21. Game 3Evaluation • Observations: • the rules of play. • roles. • Translation into IT: • the analogy with contracting / project execution. • the performance of the individual players. • dividing the profit.

  22. Agile contractingDefinition of Success • Hiring and co-sourcing: • No difference between linear (waterfall) and Agile projects. • Execution and Service: • Linear (waterfall): success is the well defined completion of a stage in the project based on input from the previous step. • Agile (RUP, SCRUM, ..): Agile is about the teamperformance vs. contract is about the performance of a supplier as a part of the team. Can an execution or service level offer be combined with an Agile method?

  23. Agile contractingProject lifecycle Project lifecycle Prioriterise & budget Business case Proposal Initiatie Proposal Preparation Proposal Execution Handover Accep- tance Imple- mentation After care Discharge Evaluation voor project Initiatie- fase Volgende uitvoeringsfase(n) Laatste uitvoeringsfase Functioneal design TD Develop- ment Test Test Requirements Linear method Iterative method Inception Elaboration Construction Transition E1 E2 C1 C2 C3 C4 T1 T1

  24. SummaryThe Agile IT Contract • Make the contract for each project member readableand available. • Handle the contract as a projectdeliverable. • Adjust the contract according to the phase and retrospective/evaluation of the project. • Add the contract to the CMDB / version management. • Use the structure for rules of games for contracts. • Goal of the game • Roles • Preparation • Rounds • Game end • Scoring • Decide in advance, how team reward is divided among team members (suppliers) when the team successfully delivers.

  25. BaselineStatements Agree Disagree No opinion • A project has a joint and shared objective, a game has an individualgoal; • Rules may change during the game; • Everyone must know the contract; • Agile projects do not need a contract; • With Agile the workplace is detachedfrom management. B F B F B F B F B F

  26. Discussion

More Related