Agile intro module 1
- 1. Agile Introduction Module 1 - General introduction
- 2. Agile according to Dilbert 2
- 3. Sprint 1 Backlog TO-DO DOING DONE What is Agile? Scrum XP Kanban 3
- 4. User Story As a trainee I want to understand Agile principles To be able to apply Agile in various situations 4
- 5. Agile Manifesto MoreAgile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. by Geert Bossuyt Through this work we have come to value: Individuals and interactions over processes and tools Teamwork & responsibility over Individuals and Interaction WorkingDeliver Value over Working software documentation software over comprehensive Partnership elaboration over Customer collaboration Customer collaboration over contract negotiation Embrace change over Respond to Change Responding to change over Agile Manifesto,plan While we value the following a we state that MoreAgile is more Agile. That is, while there is value in the items on the right, we value the items on the left more. 5
- 6. 12 principles Our highest priority is to satisfy the customer Working software is the primary 1 measure of progress. 7 through early and continuous delivery of valuable software. Agile processes promote sustainable Welcome changing requirements, even late in development. The sponsors, developers, 2 and users should be able to maintain a 8 development. Agile processes harness change for the customer's competitive advantage. constant pace indefinitely. Continuous attention to technical Deliver working software frequently, from a 3 excellence and good design enhances 9 couple of weeks to a couple of months, with a agility. preference to the shorter timescale. Simplicity--the art of maximizing the Business people and developers must work 4 amount of work not done--is essential. 10 together daily throughout the project. The best architectures, requirements, Build projects around motivated individuals. 5 and designs emerge from self-organizing teams. 11 Give them the environment and support they need, and trust them to get the job done. At regular intervals, the team reflects The most efficient and effective method of on how to become more effective, then 6 tunes and adjusts its behavior 12 conveying information to and within a development team is face-to-face conversation. accordingly. 6
- 7. Agile - protest movement • Against: • waterfall development • micro management • disdain for craftsmanship of developers 7
- 8. Principles no Rules • YAGNI - you ain’t gonna need it • BDUF - big design up front • BPUF - big planning up front • Simplicity - the art of maximizing the amount of work NOT done • Fail fast • IKIWISI 8
- 9. Other planning principles Scope Time Cost FIXED Agile ESTIMATE Traditional Time Cost Scope 9
- 10. Scrum in a Nutshell 10
- 11. Kanban in a Nutshell • Visualise workflow • Limit WIP • Measure lead time 11
- 12. XP in a Nutshell 12
- 13. Comparing methods prescriptive: more rules to follow adaptive: less rules to follow 13
- 14. Sprint 1 Backlog TO-DO DOING DONE What is Agile? Scrum XP Kanban 14
- 15. User Story As a trainee I want to know what Scrum is and XP Because I might start applying it 15
- 16. Scrum • PROJECT MANAGEMENT approach • So, same goals as Prince2 • But, a completely different approach! 16
- 17. The big picture Image available at www.mountaingoatsoftware.com/scrum
- 18. Three pillars • Transparency • Inspection • Adaptation 18
- 19. Scrum framework Roles • Product owner • ScrumMaster Events • Team • (Release planning) • Sprint planning meeting • Daily scrum meeting • Sprint review meeting • Sprint retrospective Artifacts • Product backlog • Sprint backlog • (Burndown charts) • Definition of Done 19
- 20. Scrum framework Roles • Product owner • ScrumMaster Events • Team • (Release planning) • Sprint planning meeting • Daily scrum meeting Sprint review meeting • Sprint retrospective Artifacts • Product backlog • Sprint backlog • (Burndown charts) • Definition of Done 20
- 21. Product owner • Define the features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Accept or reject work results Mountain Goat Software, LLC
- 22. The ScrumMaster • Represents management to the project • Responsible for enacting Scrum values and practices • Removes impediments • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences Mountain Goat Software, LLC
- 23. The Super Scrum Master 23
- 24. The team • PO, SM, Development Team • Typically 3-9 people (excl. PO/SM) • Cross-functional: • Programmers, testers, user experience designers, etc. • Members should be full-time • May be exceptions (e.g., database administrator) • Teams are self-organizing • Ideally, no titles but rarely a possibility • Membership should change only between sprint Mountain Goat Software, LLC
- 25. Roles in Scrum Product Owner Team Scrum Master Responsible for VALUE Responsible for Responsible to remove the team delivers QUALITY of delivery Impediments Responsible for HOW Responsible for HOW Responsible for WHAT (Content) (Scrum process) Owner of Owner of Facilitates Sprint Planning Product Backlog Sprint Backlog Meeting One person, no Optimal size 6 ± 3 Servant leader committee Is, or represents, the Cross-functional, self- Introduces Scrum in customer organising Project and Organisation 25
- 26. Scrum framework Roles • Product owner • ScrumMaster Events • Team • (Release planning) • Sprint planning meeting • Daily scrum meeting • Sprint review meeting • Sprint retrospective Artifacts • Product backlog • Sprint backlog • (Burndown charts) • Definition of Done 26
- 27. Release Planning Product Vision 1 2 3 4 5 6 7 8 User User User User Story Story Story User stories are the Story Epic Agile way of documenting User User User User Story Story Story requirements. Epic Story As a <user role> Epic Epic User User User User User Story Story Story I want <something> Story Story So I can achieve <value> User User User User User User Story Story Story Story Story Story 27
- 28. Team Sprint planning meeting capacity Sprint prioritization Product • Analyze and evaluate product Sprint backlog backlog goal • Select sprint goal Business conditions Sprint planning • Decide how to achieve sprint goal (design) Current Sprint product • Create sprint backlog (tasks) from product backlog items (user backlog stories / features) Technology • Estimate sprint backlog in hours 28
- 29. Sprint planning • Team selects items from the product backlog they can commit to completing • Sprint backlog is created • Tasks are identified and each is estimated (1-16 hours) • Collaboratively, not done alone by the ScrumMaster • High-level design is considered As a vacation Code the middle tier (8 hours) planner, I want to Code the user interface (4) Write test fixtures (4) see photos of the Code the foo class (6) hotels. Update performance tests (4) 29
- 30. The daily scrum • Parameters • Daily • 15-minutes • Stand-up • Not for problem solving • Whole world is invited • Only team members, ScrumMaster, product owner, can talk • Helps avoid other meetings 30
- 31. Everyone answers 3 questions 1 What did you do yesterday? 2 What will you do today? 3 Is anything in your way? • These are not status for the ScrumMaster • They are commitments in front of peers 31
- 32. The sprint review • Team presents what it accomplished during the sprint • Typically or underlying architecture of new features takes the form of a demo • Informal • 2-hour prep time rule • No slides • Whole team participates • Invite the world 32
- 33. Sprint retrospective • Periodically take a look at what is and is not working • Typically 15–30 minutes • Done after every sprint • Whole team participates • ScrumMaster • Product owner • Team • Possibly customers and others 33
- 34. Start / Stop / Continue • Whole team gathers and discusses what they’d like to: Start doing Stop doing This is just one of many ways to Continue doing do a sprint retrospective. 34
- 35. Scrum framework Roles • Product owner • ScrumMaster • Team Ceremonies • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts • Definition of Done 35
- 36. Product backlog •The features, functions, requirements, enhancements and fixes •A list of all desired work on the project •Ideally expressedusers or customers of has value to the such that each item the product • Ordered by the product owner This is the• Re-ordered at the start of each sprint product backlog 36
- 37. A sample product backlog Backlog item Estimate Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a 3 reservation. As a hotel employee, I can run RevPAR reports 8 (revenue-per-available-room) Improve exception handling 8 ... 30 Or use T-Shirt ... sizes (S/M/L) 50 37
- 38. The sprint goal • A short statement of what the work will be focused on during the sprint Life Sciences Support features necessary for Database Application population genetics studies. Make the application run on SQL Server in addition to Oracle. Financial services Support more technical indicators than company ABC with real-time, streaming data. 38
- 39. The Sprint Backlog Definition • subset of product backlog • selected for this sprint • plan for delivering the increment and realising the sprint goal 39
- 40. Managing the sprint backlog • Individuals sign up for work of their own choosing • Work is never assigned • Any team member can add, delete or change the sprint backlog • Work for the sprint emerges 40
- 41. Definition of Done From a presentation by Ken Schwaber: 1. I can readily understand the software and where and how things happen; 2. When I change or add to part of the software, there are no unintended or poorly designed dependencies; 3. I can read the code without lookin for tricks or poorly defined and • labeled variables or is een taak (een stuk code) af? Wanneer data; 4. I don’t need the person(s) who wrote the code to explain it to me; 5. There are a full set of (automated) tests to check that the function works as expected; 6. When I change something and add to the test, I can check that the entire change and product continuous to work; 7. How thing work and hang together is transparent, and 8. Standard, well-known design principles have been adhered to. 41
- 42. Definition of Done • Ten behoeve van de test wordt een voorstel voor een testaanpak opgeleverd. • Een oplevering moet volledig zijn getest (door middel van een functionele en een regressietest) en de testresultaten moeten zijn beschreven / bevindingen zijn geregistreerd in een testrapport. • Issues worden geregistreerd zoals beschreven in bijlage 1. Een oplevering mag per ernstcategorie niet meer dan het aantal bij de betreffende categorie vermeldde maximum toegestane open bevindingen bevatten. • 80% van alle pagina’s moet binnen 2 seconden volledig zichtbaar zijn, de overige pagina’s moeten binnen 5 seconden zichtbaar zijn. • Rapporten en overzichten welke dagelijks kunnen worden opgevraagd door teamleiders moeten binnen 15 seconden in beeld verschijnen, voor de overige rapporten is geen performance eis gesteld. • Er moeten meerdere mensen tegelijk kunnen raadplegen en muteren. • Coding guidelines van Microsoft worden gehanteerd. • Per oplevering wordt een installatiehandleiding met release notes meegeleverd waarin o.a. het datamodel en de samenhang van de technische modules staan vermeld. Daarnaast wordt een set met User Stories die in de betreffende oplevering zitten meegeleverd. • Elke oplevering moet op zowel de acceptatie- als productieomgeving geïnstalleerd kunnen worden, wat betekent dat iedere oplevering na de eerste oplevering een upgrade moet zijn in plaats van een full install. Deze moet voldoen aan de eisen van de beheerorganisatie van <klant>. • Helpteksten dienen in de applicatie te staan om zodoende een gebruikershandleiding overbodig te maken, maar het is niet vereist dat deze ook middels een beheerscherm in de applicatie beheerd kunnen worden. • Voor elke oplevering wordt er een architectuurcontrole uitgevoerd waaruit blijkt dat men zich gehouden aan de voorgeschreven architectuur. • Voor elke oplevering wordt een installatie-test uitgevoerd waaruit blijkt dat de software succesvol installeerbaar op de infrastructuur zoals in gebruik bij <klant> 42
- 43. Definition of Done • Tested & bugfree • Refactoring • Deployed to test server, • Code reviewed when so PO can test needed • All user actions • Remember to check • All supported browsers the Style_guideline • IE7/8 • Maintain wiki page • Chrome • Maintain ERD document • Firefox • Versions of components • Safari on Mac • License overview • Comments in code • Check the constraints 43
- 44. Responsibilities Team PO Scrum Master
- 45. Scrum • Lightweight • Simple to understand • Extremely difficult to master 45
- 46. Sprint 1 Backlog TO-DO DOING DONE What is Agile? Scrum XP Kanban 46
- 47. XP - eXtreme Programming • DEVELOPMENT approach 47
- 48. XP Practices 48
- 49. Sprint 1 Backlog TO-DO DOING DONE What is Agile? Scrum XP Kanban 49
- 50. On day in Kanban land 50
- 51. On day in Kanban land 51
- 52. On day in Kanban land 52
- 53. On day in Kanban land 53
- 54. On day in Kanban land 54
- 55. On day in Kanban land 55
- 56. On day in Kanban land 56
- 57. On day in Kanban land 57
- 58. On day in Kanban land 58
- 59. On day in Kanban land 59
- 60. On day in Kanban land 60
- 61. On day in Kanban land 61
- 62. Sprint 1 Backlog TO-DO DOING DONE What is Agile? Scrum XP Kanban 62
- 63. Sprint 2 Backlog TO-DO DOING DONE XP Game Context 63
- 64. Sprint 2 Backlog TO-DO DOING DONE XP Game Context 64
- 65. 65
- 66. The Rhineland Way Anglo-american Rhineland Boss has authority Expert has authority Individualism Solidarity Unlimited growth Human limits Soll as starting point Ist as starting point Heroes Teamplay Rule driven Principle-driven Specialists Craftsmanship Measuring = knowing Measuring is knowing Quarterly reports Long term 66
- 67. Cynefin Complex Un-order Hidden Order C&E coherent in retrospect C&E discoverable Act Sense Sense Categorise Respond Respond Chaotic Un-order Visible Order No perceivable C&E C&E obvious 67
- 68. Complex Un-order Hidden Order C&E coherent in retrospect C&E discoverable Worst Good Practice Practice Novel Best Practice Practice Chaotic Un-order Visible Order No perceivable C&E C&E obvious 68
- 69. 69
- 70. Intervention types Complex Empirically Knowable The domain of many possibilities The domain of Pattern Management the probable PERSPECTIVE FILTERS Analytical/Reductionist COMPLEX ADAPTIVE SYSTEMS SCENARIO PLANNING SYSTEMS THINKING Chaos Empirically Known The domain of the The domain of inconceivable the actual Stability focused intervention Legitimate best practice ENACTMENT TOOLS STANDARD PROCEDURES CRISIS MANAGEMENT PROCESS RE-ENGINEERING 70
- 71. House of commons Position: current Position: we definitely need Anglo-american management tostyle is the The Rhineland change to best for our Cynefin observers Way companies An nelan ders Observe the debate: glo-a Rhi were the solutions me ric (interventions) in line with ans the 4 Cynefin domains? 71
- 72. Sprint 2 Backlog TO-DO DOING DONE XP Game Context 72
- 73. Credits • Several slides have been taken from the Redistributable Scrum Introduction - Scrum Alliance 73