eLABa KISP darbo grupių mokymai Supažindinimas su Agile projektų valdymu
•Download as PPTX, PDF•
1 like•65 views
supažindinimas su Agile projektų valdymu.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to eLABa KISP darbo grupių mokymai Supažindinimas su Agile projektų valdymu
Similar to eLABa KISP darbo grupių mokymai Supažindinimas su Agile projektų valdymu (16)
eLABa KISP darbo grupių mokymai Supažindinimas su Agile projektų valdymu
- 1. Susipažinimas su projektų valdymu eLABa KISP darbo grupių mokymai Vilnius 2018-12-14 Leonard Vorobej leonardas@gmail.com +370 68319110 1 Smart IT
- 2. - TOC (nuo amato prie verslo) - Certified Scrum Master (CSM) - Certified Product Owner (CSPO) - IC Agile certified Professional (ICP) - Agile Diena 2013 (200+) - Agile Turas Vilniuje/LT 2013+ (400+) - Agile pusryčiai 2014+ (50+) - Asociacijos Agile Lietuva valdyba Smart IT Leonard Vorobej leonardas@gmail.com +370 68319110 www.agileturas.lt www.agile.lt www.agilediena.lt valstybe.agile.lt 2
- 3. Turinys 3 Vaidas Adomauskas Blog: http://scrum.agile.lt Twitter: @adomauskas www.slideshare.net/vaidasa www.linkedin.com/in/vaidas
- 6. Konferencijos • www.agilediena.lt • www.pmdays.eu • www.agileturas.lt • Kaunas • Master Classes • Vilnius 6
- 7. Agile terminų ir medžiagos vertimai •Agile terminai: http://www.agile.lt/straipsnis/agile-lietuviskai-42 •Agile manifestas ir principai: http://agilemanifesto.org/iso/lt/ •Scrum gidas: https://www.scrum.org/Portals/0/Documents/Scrum% 20Guides/2013/Scrum-Guide-LTU.pdf#zoom=100 7
- 8. Bendravimas su valstybiniu sektoriumi • Valstybinės informacinės sistemos gyvavimo ciklo valdymo metodika • http://www3.lrs.lt/pls/inter3/dokpaieska.showdoc_l?p_id= 466380 http://valstybe.agile.lt Agile pusryčiai valstybiniam sektoriui Nuo 2013m. 8
- 10. Kas jus? • Kas girdėjote apie Agile (Scrum, Kanban, DSDM...)? • Kas bandėte/bandote naudoti? • Kas rimtai naudojate? • Kas: • Programuotojas • Testuotojas • Analitikas • Architektas • Projektų vadovas • Vadovas • kita.. 10
- 11. Kas yra projektas? • PMI • A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. • And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. • APM • A project is a unique, transient endeavour, undertaken to achieve planned objectives, which could be defined in terms of outputs, outcomes or benefits. http://www.pmi.org/About-Us/About-Us-What-is-Project-Management.aspx https://www.apm.org.uk/WhatIsPM 11
- 12. Kur yra projektas? Software development House building Car manufacturing 12
- 16. Reikalavimai > dizainas > programavimas 16
- 18. Tradiciniai projektai – kaip šaudymas iš patrankos Prielaidos: • Klientas žino ko nori • Programuotojai žino kaip sukurti • Niekas pakeliui nepasikeis 18
- 20. Nuoseklusis (krioklinis) projektas • Reikalavimai (SRS) • “Surašykit VISKĄ ką galite sugalvoti. Bet koks reikalavimų keitimas ateityje jums kainuos LABAI daug” • Dokumentacija (artifacts) • “Apsisaugosim kai ieškos kaltų” 20
- 21. Mes kuriame nereikalingą funkcionalumą Didžiausia galimybė padidinti programinės įrangos kūrimo produktyvumą yra rašyti mažiau kodo!* This graph courtesy of Mary Poppendieck *Mary Poppiendieck, “It’s Not About Working Software”, Agileee 2010 conference 21
- 22. Galbūt tai darome sėkmingai? 22
- 24. Comparing Software Development Paradigms: 2018 http://www.ambysoft.com/surveys/success2018.html
- 25. Comparing Delivery Paradigms -3.0 -1.0 1.0 3.0 5.0 7.0 Time/Schedule ROI Stakeholder Value Product Quality Lean Agile Iterative Ad-hoc Traditional Copyright 2014 Scott W. Ambler www.ambysoft.com/surveys/ http://www.ambysoft.com/downloads/surveys/Success2013.pptx
- 26. Agile www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. February 11-13, 2001 Snowbird ski resort, Utah Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 26
- 27. Judrumo (Agile) manifestas ...mes vertiname: Žmones ir jų bendravimą labiau nei procesą ir įrankius http://agilemanifesto.org/ 27
- 28. Judrumo (Agile) manifestas ...mes vertiname: Veikiančią programinę įrangą labiau nei išsamią dokumentaciją http://agilemanifesto.org/ 28
- 29. Judrumo (Agile) manifestas ...mes vertiname: Bendradarbiavimą su klientu labiau nei derybas dėl kontraktų http://agilemanifesto.org/ 29
- 30. Judrumo (Agile) manifestas ...mes vertiname: Reagavimą į pokyčius labiau nei plano sekimą http://agilemanifesto.org/ 30
- 32. Iteracija 1 • Pilnai pabaigtas (done) • paleidžiamas (shipable) • produkto prieaugis (increment) 32
- 33. Iteracija 2 33
- 34. Iteracijos 3 - … 34
- 35. Agile yra procesas kurti nuolat priaugantį produktą! 35
- 36. Judrūs projektai – kaip valdoma raketa Prielaidos: • Klientas atras ko nori • Programuotojai atras kaip sukurti • Pokyčių tikrai bus 36
- 37. Judrus projektas P P V SP V P V P V 37
- 38. Judraus projekto planas • Sistema kuriama funkcijomis / moduliais (dydis): – Funkcija 1 (20) – Funkcija 2 (40) – Funkcija 3 (20) – Funkcija 4 (40) – Funkcija 5 (20) – Funkcija 6 (40) • Viso (180) • Anksti matosi ar teisingai įvertinome: – Funkcija 1 (20) – baigėm po 30 – Funkcija 2 (40) – Funkcija 3 (20) – Funkcija 4 (40) – Funkcija 5 (20) – Funkcija 6 (40) • Viso (180) - ar tikrai 180? • Funkcijų prioritetus galima keisti jei pasikeitė svarbumas: – Funkcija 1 (20) – Funkcija 2 (40) – Funkcija 5 (20) – svarbesnė – Funkcija 3 (20) – Funkcija 4 (40) – Funkcija 6 (40) • Viso (180) • Funkcijas galima keisti (tokio pat dydžio funkcija: – Funkcija 1 (20) – Funkcija 2 (40) – Funkcija 3 (20) – Funkcija 7 (40) – nauja – Funkcija 5 (20) – Funkcija 6 (40) • Viso (180) 38
- 39. 4% with no estimate!!! 39 Woody Zuill - https://speakerdeck.com/agilelatvia/no-estimates-lets-explore-the-possibilities-by-woody-zuill
- 40. 40
- 43. Multitasking‘o žala • Multitasking is associated with harm to our brains; • Multitasking increases chronic stress; • Multitasking increases depression and social anxiety; • Multitasking makes you less productive and less efficient; • Multitasking Makes You a Poor Judge of Your Own Abilities • Multitasking reduces focus and concentration; • Multitasking could make you dumber; 43
- 44. Multitasking‘o žaidimas • Pirma lentelė: • Užpildykite stulpelius vertikaliai ( 1…10, I…X, A…C) • Užsirašykite pabaigos laiką • Pradedam! • Antra lentelė: • Užpildykite stulpelius iš kairės į dešinę (1, I, A, 2, II, B, 3…) • Užsirašykite pabaigos laiką • Pradedam! • Komentarai? 44
- 45. 3 nepriklausomi projektai Multitasking‘as: P1 P2 P3P1 P2 P3 P1 P2P3 Projekto 1 laikas (7 dienos) Teoriškai: Project 1 Project 3Project 2 (3 dienos) Realybė: Project 1 Project 3Project 2 (2 dienos) Visi projektai (6 dienos) 45
- 46. Apibrėžtas bei empirinis procesai 46
- 47. Kur yra projektas? Software development House building Car manufacturing 47
- 51. Viktorija Trubačiūtė http://www.slideshare.net/AgileLietuva/vieno-pilotinio-projekto-istorija, Lietuvos Agile Diena 2011 Stabili komanda 51
- 52. Sub-optimization vs. Optimize the Whole 52
- 54. Potentially shippable product increment Tarp-funkcinė komanda 54 Product owner
- 55. Pietų?
- 56. Agile metodai 56
- 58. Scrum 58
- 59. Ekstremalus programavimas (XP) • 12 praktikų • The Planning Game • Small releases • Metaphor • Simple design • Continues Testing • Refactoring • Pair programming • Collective code ownership • Continuous integration • 40 hour week • On-site customer • Coding standards 59
- 60. Sprint Planning meeting Daily Scrum Sprint Review Sprint backlog Product backlog TDD Pair programming Refactoring Simple design Coding standard Sustainable Pace Metaphor Continuous Integration Collective ownership Whole team Planning game Small releases Customer tests Burndown chart Product owner Team ScrumMaster Scrum XP 60
- 61. Kanban • Vizualizuok darbo procesą • Limituok pradėtą darbą (WIP – work in progress) • Matuok ir optimizuok tėkmę 61
- 62. Kiti Agile metodai • Feature Driven Development (FDD) • Agile Modeling • Crystal • Agile Unified Process (AUP) • Dynamic Systems Development Method (DSDM) • … 62
- 63. • Mažinti šiukšles (Muda) • Gaminti kokybiškai • Gaminti greitai • Vertinti žmones • Optimizuoti sistemą • Nuolat tobulinama (Kaizen) Lean 63 Realybė: Project 1 Project 3Project 2 (2 dienos) Visi projektai (6 dienos) “Organizations that are truly lean have a strong competitive advantage because they respond very rapidly and in a highly disciplined manner to market demand, rather than try to predict the future.” – Mary Poppendieck Mary & Tom Poppendieck
- 64. Kas čia blogai? Nei viena iš šių problemų yra sukelta įrankio!!! Blogai naudojasi įrankiu Naudoja blogą įrankį 64
- 65. Agile 65 Chaos No planning (no predictability) No documentation Small teams Process Product Backlog : just in time and just enough Just in time and minimal enough Microsoft, IBM, Amazon, Swedbank Myths Reality
- 67. Kas toliau? • Teorija • Statistika • Scrum • Žaidimas • Praktika • Doclogix • Locatory • Swedbank 67
- 69. Scrum • Scrum yra sistema (framework) kurti sudėtingiems produktams; • Scrum neaprašo konkrečių metodų ar technikų • Scrum nėra „sidarbinrė kulka“ (silver bullet) ar panacėja • Scrum yra įrankis, kuris išryškina ką reikia tobulinti, kuriant kokybišką ir greitai atsiperkančią PĮ 69
- 70. Scrum komanda (1) • Moralas: vištoas negali sakyti kiaulėms KAIP daryti darbą • Kiaulės: Scrum komanda • Vištos: visi kiti (vadovai, dep. Vadovai, klientai ir t.t.) 70
- 71. Scrum rolės • Scrum meistas (SM, Scrum mster) • Produkto šeimininkas (PO, Product owner) • Komanda (team, cross functional team, CFT) 71
- 72. Scrum procesas • Paleidimo planavimas • Produkto užduočių sąrašas • Sprintai • Sprinto planavimas • Kasdienis Scrum • Sprinto deginimo kreivė • Sprinto peržiūra • Sprint retrospektyva 72
- 73. Pabaigta (Done) • Visiškai „pabaigtas“ prieaugis (increment) turi atliktą: • Analizę • Dizainą • Perrašymą (refactoring) • Kodo rašymą • Dokumentaciją • Testavimą • Paleidimą • Demonstravimą 73
- 74. Klausimai? 74
- 75. Taip, bet...
- 76. Fosbury Flop – istorija apie šuoį į aukštį • Tradicinis šuolis į aukštį iki 1968 • 1968 Meksiko olimpiada – Dick Fosbury (aukso medalis) • Nuo 1972 tik 2 medaliai buvo laimėti nenaudojant „Fosbury Flop“ • Keistis sunku... http://en.wikipedia.org/wiki/Dick_Fosbury 76
- 77. Bet... • Mes naudojame Scrum, bet... • Turime unikalias aplinkybes • Taigi turėjome pakeisti Scrum, kad jis veiktų čia „Agile development is like teenage sex. Everyone says they‘re doing it, but only 10% are. And those who are – ARE DOING IT WRONG.“ – The Hacker Chick Blog „If you‘re not having fun, you‘re not doing it right!“ – Joseph Pelrine, CST and Social Complexity Scientist „Prieš du metus atėjęs vadovauti (pabandyti) informacinių sistemų kūrimui, iš esmės pakeitė visą programavimo kultūrą.“ - Paulius Nomgaudas (VGTU) http://valstybe.agile.lt/agile-pusryciai-2015/ 77
- 78. Klausimai? 78
- 79. Praktika • Doclogix patirits • Locatory patirtis • Swedbank patirits
- 80. Patirtis „DocLogix“ yra pripažinta geriausia dokumentų ir procesų valdymo sistema Europoje. Ji yra lengvai adaptuojama, išplečiama ir konfigūruojama. „DocLogix“ skirta informacijos apdorojimui, valdymui, saugojimui ir patogiai prieigai. Išskirtinis dokumentų valdymo sprendimas vartotojams leidžia kurti, modifikuoti automatizuotus organizacijos procesus (darbų sekas) be jokių programavimo žinių. 80www.doclogix.lt
- 81. Aplinka • Alna įmonių grupės dukterinė kompanija • Biuras: Vilnius • Dydis: ~50 darbuotojų (~30 produkto vystymui, palaikymui) • Rinka: Baltijos šalys, Rytai (buvusios NVS), Europa, Amerika • Vartotojai: 350 verslo įmonių bei daug valstybinių institucijų, 70 000 vartotojų, 13 šalių • Įmonė kuria produktą nuo 1997 m. 81
- 82. Esama Agile situacija • 3 komandos (produkto vystytojai, diegėjai, palaikymas) • 1 komanda bando Scrum • Palaikymas kuriasi nuo 0 • Likę dirba pagal tradicinį projektų valdymą • Herojų kultas • Atskiros „talpyklos“ pagal roles (silos) 82
- 83. Agile kelionė • Retrospektyvų nauda • Eksperimentavimas • Įmonės produkto vystymo komandų restruktūrizacija • Projektų valdymas įmonės mastu 83
- 84. Patirtis • Locatory.com is an aviation IT company primarily acting as an aircraft parts locator. It offers the most innovative tools for aircraft parts procurement and exploration via a broad aviation marketplace it manages. • Locatory.com is a part of Avia Solutions Group, integrating MRO services & supply chain, pilot & crew training, aviation staff leasing, ground handling & aircraft fuelling, aircraft management, business charter, as well as airport management service providers. 84 www.locatory.com
- 85. Aplinka • Avia solution group dukterinė įmonė • Biuras: Vilnius • Dydis: ~35 darbuotojų (~6 MP produkto vystymui, 10 MRO produkto vystymui) • Rinka: Visas pasaulis, 50%+ klientų JAV • Vartotojai: 800+ aviacijos kompanijų • Kiekis: 6 mln. detalių katalogas 85
- 86. Esama situacija • 1 komanda (4 programuotojai, testuotojas, Projektų vadovas) • 5 vidiniai užsakovai (produktas, palaikymas, pardavimai, marketingas, administracija), 3 išoriniai užsakovai • Dirbama pagal brangiausiai apmokamo asmens įmonėje prioritetus • 15 projektų/produktų (pagrindinis produktas yra Marketplace, 5 metai programavimo) 86
- 87. Agile kelionė • Žmogus viskas viename (PM, SM, PO, analitikas, vadovas) • „paleistas“ Scrum • Prioritetizavimas įmonės lygmenyje • Darbų vertinimas tiek iš techninės pusės, tiek iš biznio vertės; • Darbų aiškumas; • Išoriniai užsakovai sudarė užduoių sąrašą, pradėtas darbų prioritetziavimas 87
- 88. Patirtis • Bankas! • Biuras: SE, LT, LV, EE • Dydis: 12 tūkst. Darbuotojų, ~2500 LT (~600 iš jų IT) • Rinka: Baltijos valstybės, Švedija • Vartotojai: 7,3 mln. privačių ir apie 552 tūkst. verslo klientų 88
- 89. Esama situacija • Organizacija juda link bendro Scrum proceso per visą organizaciją • Produkto savaninkas Turinio valdymo sistemai • Visa komanda Estijoje • Vadovas šalia 89
- 90. Agile kelionė • Reorganizacija per visą banką, Agile per visus lygius • IT sujungiama su „Biznio“ žmonėmis ir palaikymu • Naujos galimybės • SWAP 3.0 • Scrum meistras Open banking komandoje • Didelė organizacija, daug nežinomųjų • Mažais žingsneliais pirmyn! • Kolegų mokymas, procesų sutvarkymas, darbas su komanda 90
- 91. Pertrauka? 9 1
- 92. Žaidimas! 92
- 93. Žaidimo taisyklės 93 1 didelė ir šauni komanda! Kiekvienas objektas turi turėti „oro laiką“ Kiekvienas objektas turi būti paliestas bent viena kartą kiekvieno komandos nario Objektas negali būti perduotas šalia stovinčiam kolegai Kiekvienas objektas turi gižti pas tą patį asmenį, kuris šį objektą įtraukė į sistemą Bus 5 iteracijos
- 94. Retrospektyva 94
- 95. Ačiū 95 Leonard Vorobej leonardas@gmail.com +370 68319110 Smart IT http://www.noop.nl/2011/ 04/the-feedback-door.html
Editor's Notes
- * Pabrėžti valstybe.agile.lt!
- Asociacijos Agile Lietuva pristatymas; Susitarkime kas yra projektas?; Sukursime vaikų saugaus eismo mokymo programą; Aptarsime kas yra Agile; Susipažinsime su Agile Manifestu; Suprasime kas yra Scrum, Kanban, Lean ir kiti „keiksmažodižiai“; Kodėl naudoti ir kodėl veikia Agile?;
- Asociacija “Agile Lietuva” yra aktyvių Agile projektų valdymo metodų ir techninių praktikų naudotojų Lietuvoje bendruomenė. Tikslas Dalinantis patirtimi tobulinti Agile projektų valdymo metodų ir techninių praktikų naudojimą savo kompanijose. Tikslinė grupė Mes diskutuojame apie Agile metodų naudojimo praktinius aspektus, todėl mūsų tikslinė grupė yra vadovai, projektų vadovai, Scrum meistrai (Scrum Masters), produktų šeimininkai (Product Owners), komandų lyderiai ir kiti atsakingi už procesų tobulinimą įmonėse.
- 50+
- Project management Institute Association of project management - Laikinos pastangos
- Complicated problems can be hard to solve, but they are addressable with rules and recipes, like the algorithms that place ads on your Twitter feed. They also can be resolved with systems and processes, like the hierarchical structure that most companies use to command and control employees. Everything is complex, and everything can be simplified. The very chair you sit on consists of atoms spinning around randomly, and which only give you the illusion of stability because their spinning cancels out overall. The ground under your feet is spinning at over 1600 km per hour, and hurtling round the sun at 30 km per second. But again, it feels stable because you’re moving right along with it. Your simplest relationships are sustained by an intricate web of verbal and nonverbal signalling in every interaction, all of which you process to determine how to respond to each other and how to generate desired responses. But everything can also be simplified. You simply sit on the chair. You walk like the earth isn’t moving. You categorise your relationships—parent, child, colleague, friend, best friend—each name a code for how you’re handle each one.
- SRS – software requirement specification
- The levels of success were defined as follows: Successful. A project is considered successful if a solution has been delivered and it met its success criteria within a range acceptable to your organization. Challenged. A project is considered challenged if a solution was delivered but the team did not fully meet all of the project's success criteria within acceptable ranges (e.g. the quality was fine, the project was pretty much on time, but ROI was too low). Failed. The project team did not deliver a solution. The paradigms were defined as follows: Ad-hoc. On an ad-hoc software development project the team does not follow a defined process. Iterative. On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP. NOTE: We will ask about Agile projects, which are defined as iterative projects that are performed in a highly collaborative and lightweight manner, later. Agile. On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is Scrum, XP, and Disciplined Agile Delivery (DAD). Traditional. On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes. Lean. Lean is a label applied to a customer value-focused mindset/philosophy. A lean process continuously strives to optimize value to the end customer, while minimizing waste which may be measured in terms of time, quality, and cost. Ultimately the Lean journey is the development of a learning organization. Examples of Lean methods/processes include Kanban and Scrumban. Success rates were calculated using the following strategy: A weighted average for each of level of success was calculated. A selection of 91-100% was considered to be 95%, 81-90% as 85% and so on. A selection of 0 was considered as 0. Answers of Don’t Know were now counted. A normalized value was calculated. The weighted averages didn’t always add up to 100%. For example, the weighted averages may have been 60% 30% and 20% for a total of 110%. To normalize the values we divided by the total, to report 60/110, 30/110, and 20/110.
- The following questions were asked for each factor: Product Quality. When it comes to the quality of the system delivered, what is your experience regarding the effectiveness of [paradigm] software development teams? Stakeholder Value. When it comes to ability to deliver a solution which meets the actual needs of it's stakeholders, what is your experience regarding the effectiveness of [paradigm] software development teams? ROI. When it comes to effective use of return on investment (ROI), what is your experience regarding the effectiveness of [paradigm] software development teams? Time/Schedule. When it comes to time/schedule, what is your experience regarding the effectiveness of [paradigm] software development teams? When respondents indicated that they had experience with a given paradigm, for each of the potential success factors there were given the following options: Not applicable (not counted for scoring) Very effective (Score = 10) Effective (Score = 5) Neutral (Score = 0) Ineffective (Score = -5) Very ineffective (Score = -10) To calculate the overall rating for each factor was calculated as a weighted average using the score values listed above.
- - Oranžiniai buvo Lietuvoje Agile Tour LT konferencijose pranešėjais;
- Definition of Done
- http://www.online-stopwatch.com/large-stopwatch/
- Kur yra projektai? Kur gamyba? O startup‘ai anarchijoje ;)
- Kur yra projektai? Kur gamyba? O startup‘ai anarchijoje ;)
- How long will they work together? Usually… less than a 1 month Usually… analysts at the beginning, testers will join in the end How many projects will they work on? Usually… 2 or more What activities will we take to build a team? Usually… beers!
- Silos – talpykla;
- Kur yra projektai? Kur gamyba? O startup‘ai anarchijoje ;)
- Kanban (かんばん(看板)?) (literally signboard or billboard in Japanese) is a scheduling system for lean and just-in-time (JIT) production.[2] Kanban is a system to control the logistical chain from a production point of view, and is an inventory control system. Kanban was developed by Taiichi Ohno, an industrial engineer at Toyota, as a system to improve and maintain a high level of production. Kanban is one method to achieve JIT.[3]
- In a nutshell, Lean says to relentlessly eliminate anything that isn’t adding value and only work on what we absolutely need to be doing at this moment in time. Eliminating waste means eliminating useless meetings, tasks and documentation. But it also means eliminating time spent building what “we know” we’ll need in the future (things are constantly changing so we often end up not needing them – or if we do, we have to rework them because conditions and our understanding has changed by then). It also means eliminating inefficient ways of working – like multitasking (!) – so we can deliver fast. Lean also puts a very strong emphasis on what it calls “the system” – that is, the way that the team operates as a whole. We always need to be looking at our work from a top level to ensure we’re optimizing for the whole. For example, many managers want to “optimize” individual developers by ensuring they’re always at 100% – but most of the time, this is actually counter-productive. Let’s not have people coding something that isn’t needed (or fully defined yet) just for the sake of coding, because that actually creates more work for us in the future (see: Why You Should Let Your Developers Surf). Along those lines, Lean says to respect that the people doing the work are the ones that best know how to do it. Give them what they need to be effective and then trust them to do it. Software development is about learning, so structure the work to ensure we’re continuously learning. And because of that, defer decisions until the last responsible moment (because we’ll know more by then). Finally, develop in a way that builds quality into our product, because there’s no way to continuously deliver fast if we have to keep going back to clean up our messes. “Organizations that are truly lean have a strong competitive advantage because they respond very rapidly and in a highly disciplined manner to market demand, rather than try to predict the future.” – Mary Poppendieck
- Never blame the tool!
- SM rolė: Saugo; Prižiūri; Skaičiuoja; Lyderis; Jautrus; Padeda PO, Team‘ui; Fasiliuoja meeting‘us PO rolė: Prioritetizuoja; Bendradarbiauja su užsakovu ir kitais; Derina su kitom komandom darbų planą, dependency‘ies; Priima darbus; Visada prieinamas; Komanda narių rolė: Įgyvendina; Visos reikalingos kompetencijos; Kuria tai ko reikia;
- -
- What happened? Which iterations felt the best? How did you make decisions? Who had all the ideas? When something went wrong what did you do? How would things have been different if you had appointed a leader? Would things have been better with one up front 10 minute planning session instead of five 2 minute planning sessions throughout? Why did dropped balls cost 2 points? Did you work harder or faster to improve your score? What happened after I told you about the scores achieved by the best teams? How does all this apply to you? Key findings At the conclusion of the exercise, debrief for five to ten minutes. There are a number of interesting points that are worth talking about. Firstly, it’s worth mentioning the Deming Cycle. Secondly, it’s worth pointing out that every system has a natural velocity. And finally, it’s worth discussing “flow” and the necessary criteria for it. Here’s Boris’ full documentation of the game. Self-organisation works. You don’t need a leader to tell you what to do, rather you should feel empowered to decide how best to do a task. If everyone feels empowered and cares about the process, the ideas are likely to be even generated throughout the team. If leaders are appointed or imposed, teams can revert to looking to them for all the thinking. Leaders can become bottlenecks if individuals don’t feel empowered. A long up front planning session doesn’t give you the opportunity to learn by doing and replan.