11/05/2009 SCRUM. Agile en Scrum. onder de loop. Workshop 13 mei 2009 Kris Phillipaerts & Peter Janssens SCRUM BASICS. Scrum Process.

Transcription

1 Agile en Scrum onder de loop SCRUM Workshop 13 mei 2009 Kris Phillipaerts & Peter Janssens 1 2 SCRUM BASICS Scrum Process 3 4 Scrum Process 5 6 1

2 ROLLEN: Varkens en kiekens Product Owner Vertegenwoordigt klant bij team Beheert product backlog Bepaalt release plan Maar: Respecteert schattingen Respecteert sprint planning 7 8 Team Empowered team Cross-functional team Self organizing Maar: Respecteert team rules Respecteert prioritisering van PO Respecteert Scrum regels Scrum Master Evangelist Werkt impediments weg Bewaakt Scrum proces Motivator en servant leader Maar: Respecteert team beslissingen 9 10 Klant Verantwoordelijkheden Functionele sturing Prioritisering Acceptatie Testing + feedback Maar: Hangt van klant tot klant af Aanpasbaar aan noden van klant Artefacts & Ceremonies Product Backlog Backlog, Estimation meetings, Velocity, Burndown chart Sprint Planning, Sprint Backlog, Taskboard, Burndown chart, Daily standup (daily Scrum), Review (demo), Retrospective Project Kickoff

3 Product Backlog Product Backlog Elke user story is - Gemakkelijk te verstaan - Waardevol voor de klant/gebruiker Estimation Meetings Relatieve inschatting = vergelijkend Eenheden Points Ideal Man Hours Velocity Velocity = aantal punten per sprint Begin: inschatting optimisch scenario? conservatief scenario? Opvolging sprint na sprint wordt een waarneming (empirisch) Velocity Project Burndown chart OPGELET Velocity is een middel om vooruit te denken obv empirische vaststellingen Velocity IS GEEN DOEL Na elke sprint noteren we het aantal punten die nog moeten gerealiseerd worden 3

4 11/05/2009 Project Burndown chart Project Burndown chart Scope uitbreiding 19 Scope uitbreiding bij Fixed Time 20 Project Burndown chart Burndown chart Target deadline vervroegd 21 Beter: optimistisch & conservatief scenario 22 Sprint Planning Sprint Backlog

5 11/05/2009 Taskboard Sprint Burndown Dagelijks noteren we het aantal taken die nog moeten gerealiseerd worden Daily Scrum / Stand up 27 Talking stick 28 Impediments list 29 Sprint Review / Demo 30 5

6 Sprint Retrospective Project kickoff Staffing (rolverdeling) Scrum proces uitleggen Team rules afspreken Definition of done bepalen Plaatsing van Agile Scrum Toolbox Filosofie Prince2 Waterfall Rollen Courage PMBOK AGILE Lean Scrum extreme Programming DSDM Ad Hoc Iteratief RUP Practices Artefacten Ceremonies Openness Focus Respect Commitment Scrum fundament Scrum impact

7 SCRUM HISTORIEK PRAKTISCHE SCRUM DEPENDENCIES 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review 1993 Jef Sutherland: first Scrum at Easel 1995 Ken Schwaber: First white paper on Scrum 1996 Kent Beck: XP 2001 Agile Manifesto 2003 Lean Software Development < Mary & Tom Poppendieck 2008 Team organisatie samen werken, fysieke locatie, kanban whiteboards, team Management zelf organiserende teams, ondersteuning, pull info ipv push Technisch versioning, CI, auto testen, build & deploy process, TDD Klanten input (prioriteiten) & output (demo s & pilots) Warnings Warnings Scrum is meer dan enkel het gebruik van een set tools No silver bullet Niet voor elk project contracteisen en klantrelatie Time & Material versus Fixed Price AGENDA Alternatieven The Agile Manifesto DOEL? Scrum Backlog & Program management Embedded engineering Scrum + Prince DOEL? DOEL? Wat willen wij bereiken? Onderscheid doel <> middelen project struktuur plan documentatie software communicatie mensen werk procedures efficientie functies tools architectuur

8 DOEL? DOEL? Wat willen wij bereiken? project struktuur plan documentatie software communicatie mensen Wat willen wij bereiken? Welke middelen hebben wij? mensen software project struktuur functies tools architectuur documentatie communicatie plan werk procedures werk procedures efficientie functies tools architectuur efficientie DOEL? Wat willen wij bereiken? Welke middelen hebben wij? mensen software project struktuur functies tools architectuur documentatie communicatie plan werk procedures efficientie DOEL? Wat willen wij bereiken? Welke middelen hebben wij? mensen software project struktuur functies tools architectuur documentatie communicatie plan werk procedures efficientie CONTEXT Context Principes THE AGILE MANIFESTO

9 11/05/2009 CONTEXT CONTEXT? Kunnen omgaan met Kunnen omgaan met Complexiteit Voortschrijdend inzicht Gevraagd Bij nader inzicht CONTEXT CONTEXT Kunnen omgaan met Kunnen omgaan met Snelle veranderingen Mensen CONTEXT CONTEXT Kunnen omgaan met Kunnen omgaan met Creativiteit 53 Duurzaamheid

10 11/05/2009 CONTEXT CONTEXT Is op tijd een voorwaarde voor success? Scope Tijd is geen objectief in de definitie van een project bij PMBOK of Prince2 Kwalliteit Tijd kan een (belangrijk) objectief zijn in een business case Kost Tijd Prince2 Project: a (temporary) management environment that is created for the purpose of delivering one or more business products according to a specified Business Case. 70 % result in extra budget due to change request over initial contract 55 PMBOK (PMI) Project: a temporary endeavor undertaken to create a unique product or service 56 CONTEXT CONTEXT Chaos Agile Manifesto Individuals and interactions over processes and tools Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a predefined plan 59 That is, while there is value in the items on the right, we value the items on the more 60 10

11 11/05/2009 Agile Manifesto Agile Manifesto Working software Customer collaboration over comprehensive documentation over contract negotiation Agile Manifesto Responding to change over following a plan AGILE ALTERNATIEVEN (algemeen: iteratief development) Lean Software Development Kanban software development DSDM Extreme Programming (XP) If the map does not agree with the terrain, trust the terrain (first rule from the handbook map reading ) 63 No battle plan ever survives contact with the enemy. < Field Marshall Helmuth Carl Bernard von Moltke ITERATIEF DEVELOPMENT 64 LEAN SOFTWARE DEVELOPMENT WIP (WORK IN PROGRESS) WORKING SOFTWARE Zo weinig mogelijk voorbereiding Zo weinig mogelijk tegelijk Zo veel mogelijk In gebruik Beslis zo laat mogelijk definitief Economy of flow Fail Fast leercurve Wat is nu de hoogste business prio? Wat is nu de grootste bottleneck? 65 WIP (WORK IN PROGRESS) WORKING SOFTWARE 66 (versus economy of Scale) Bug = stop productie Red alert = Elk team lid kan productie stoppen 11

12 KANBAN SOFTWARE DEVELOPMENT DSDM EXTREME PROGRAMMING 70 EXTREME PROGRAMMING Practises 1. Planning Game 2. Functional Testing 3. Test Driven Development & Unit tests 4. Refactor Mercilessly 5. Code & design simply 6. System metaphor 7. Collective Code Ownership 8. Coding Standards 9. Continuous Integration 10.On-site Customer 11.Sustainable Pace 12.Pair Programming Bonus Open Workspace Planning Game Functional Testing Release Planning developers + customers exploration > commitment > steering/adjustment Iteration Planning developers only exploration > commitment > steering/adjustment No new development until acceptable for the customer Prevent regressions and communicate important historical information Automation

13 Refactor Mercilessly Don t leave duplicate or uncommunicative code around Test Driven Development ~ unit tests use short development iterations based on pre-written test cases that define desired improvements Code and design simply System metaphor Objective take a "simple is best" approach to software design. Practical After every new piece of code: 'is there a simpler way to introduce the same functionality? > Refactoring Derive class, method, variables, and basic responsibilities around one or a small set of cooperating metaphors. Don t just go off inventing names on your own Collective Code Ownership everyone is responsible for all the code this, in turn, means that everybody is allowed to change any part of the code Develop Coding Standards developing is a team game Examples choose same style of class & variable names format code the same way if you run across some code that could be improved, you have to stop and improve it

14 Continuous Integration The development team should always be working on the latest version of the software Often combined with a regular (automated) build process & automated testing. On-site Customer the one who really uses the system. not the one who pays the bill. should be on hand at all times and available for questions. You can't just take your understanding of requirements and design and implement with them for a month Sustainable Pace Every day starts at start time ends at end time Pair Programming is a software development technique in which two programmers work together at one work station. > Driver + Observer/navigator need for regular overtime is a clear signal that something else is wrong with the project. better awareness, better refactoring, simpler code Pair Programming Open Workspace Bonus How much time do we spend on pure coding? How do you share code ownership? How do you prevent design hocus-pocus? Who is questioning your idea-fixes? What about Monday-morning code? Who is so smart he can stop learning? 15% cost increase 40% less time required (Time To Market) 60% quality increase (Cost of Quality) Yelling Teams 1 room for all Tables in center with computers & dual screens A project board

15 Backlog & Program Management Backlog = prioritised list of requirements A user story should be I ndependent N egotiable V aluable to users or customers E stimatable S mall T estable Agile Estimating And Planning By Mike Cohn Backlog Management challenges How to avoid Dependencies? How to minimize backlog management (minimize work) Make sure that Flow = progress How to manage time boxed projects with evolving user stories? Analysis challenges Iterative or incremental? 89 When stopping Analysis to give space to evolving insights? Balance between Design Upfront & clear user stories & reliable estimations Focus on Business Analysis (=demand) <> Functional analysis (=solution) 90 15

16 Documents Info Data / Operations Data / Operations 11/05/2009 Project Vision/Strategy Prioritise: based on Business Urgency or Logical workflow? Business Value determined by ROI or by development efficiency? There is no silver bullet 91 How to apply end-to-end thinking in a cyclic development? 92. Technique: User Role Modelling 1. Brainstorm an initial set of user roles 2. Organize the initial set 3. Consolidate roles 4. Refine the roles Agile Striptease A pattern/guideline for creating & elaborating user stories 93 Role Who Job Seeker Scott First Timer Laura Layoff Victim Kindra Geographic Searcher Allan Monitor Ashish Job Poster Mario, Savannah Resume Reader Delaney, Savannah 94 Represent your business case visually Identify the critical outputs People Inputs Outputs Solution As a solution (not software, process,...) For people Outputs People Tips - Set focus: identify your output first, before searching means or tackling bottleneck (set focus, delegate responsibility to realise > Leadership) - Stong focus allows less analysis less elaboration - Idenfy the 1 most critical output. Several outputs? Identify the flow and take the last critical one Examples - Payments - data: addresses, people, companies - consider: critical report on operations or data 16

17 Data / Operations Data / Operations Data / Operations Data / Operations 11/05/2009 Split your roads from in>out into different cases Case A Case B Case C Case D Identify your typical simplest case Case A Solution Solution 97 Examples - Different kinds of customers - Different kinds of contracts - Different kinds of employees -... Outputs Good to know - These cases will, amongst others, be a start for user stories 98 Good to know & Tips - rationale: Simple case first: Make it work priority next: improve & complete - to do: Sort the other cases in order of business priority (frequency & importance) Examples - a simple request - a typical customer - a typical contract Strip, strip, strip, strip and strip again (even when you think you can t strip any more) Case A Case A+ Case A++ Case A+++ Case A Case A+ Case A++ Case A+++ Solution Solution Good to know & Tips - Every stripped complexity becomes a new user story Good to know & Tips - Every stripped complexity becomes a new user story 99 Examples - strip exceptions, validations & acceptance (assume yes & make no a separate input case) - simplify & select a single region, language, type of customers: split the case 100 Examples - strip exceptions, validations & acceptance (assume yes & make no a separate input case) - simplify & select a single region, language, type of customers: split the case Simple typical case + naked shortest roads (cases) = basic framework + list of stripped complexities = Initial backlog Benefits - Realise basic framework extremely fast - Cases can easily be sorted by priority (frequency & importance) - Enables/allows progressing insights

18 Benefits Benefits - Stories have few dependencies - Stories are valuable for the business (output oriented) & testable - Stories can be kept small - Time consuming complexity at end sorted by priority - If project stops - (many) High priorities are realised - Drop off: (few) low priorities Fitnesse Benefits - Encourages end-to-end vision - Scope: requirements become dimensional => not in our out tests are expressed as tables of input data and expected output data executable requirements Fitnesse Risk Prevention Any user can - Understand - Give input Uses tables (Ms Excel) Implicit risk prevention High priorities are realised first High risks (or spikes) should be prioritised high High group learning curve => lower individual dependencies

19 Risk Prevention Implicit risk prevention Risk Prevention Implicit risk prevention Fail fast & early detection through daily visual management short feedback loop end-to-end strategy Reliable information Progress = progress Velocity = velocity Risk Prevention Implicit risk prevention Scrum will not prevent all risks for you Have a risk assessment at the start of your projects Agile Program Management Onion: levels of detail Agile Program Management Agile Program Management Cone of Uncertainty RoadMap backlog (see RoadMap.xls) Relative estimations Estimate min & max realisation time Monitor real progress & update forecasts

20 Agile Program Management Success Factors Keep Projects Small set max size work with sub projects Embedded Engineering... Conclusies Agile Open, France 115 Do not over analyse (Re-)estimate regularly in short exercises Be aware of level of progressive insight Awareness is more important than exact estimates If needed, use correction factors for types of uncertainty 116 Prince2 Bedrijfs- of Programmamanagement aankondiging projectstart goedgekeurde PID voortgangsinformatie projectafsluiting Scrum + Prince2? Prince2 1 min overview Implementation types Process mapping Role mapping Warning: mind set SP OP Opstarten v/e Project Projectvoorstel Sturen v/e Project (Stuurgroep) PID IP Initiëren v/e Project autorisatie Projectmandaat Initiatiefaseplan Projectplan oplevering, Projecteindrapport autorisatie MP Managen Productoplevering autorisatie rapporten, advies BF Beheersen v/e Fase rapporten, producten Teamplan Faseplan, Fase-eindrapport MF Managen Faseovergangen volgende Faseplan, Afwijkingsplan AP Afsluiten v/e Project PL Opstellen v/e Plan Implementation Types Implementation Types Typical Prince2 Stabilisers Steering committee Project initiation don't use Prince2 at all Use Scrum but still use some of the "stabilisers" from Prince2 such as Risk Log, Issue Log, Highlight Reports Scrum is only used for the delivery of a work package (i.e. a Prince2 work package). Using Scrum internally but to outside organisations you are providing a Prince2 facade or interface Risk Management Using the stabilisers still comes at a cost though and these should be included as Sprint Backlog items to illustrate to the Product Owner how much effort they are costing known as an "incremental death march", i.e. all your really doing is breaking up the different phases of the project into "increments", including an increment for design You are using Scrum internally Reporting (dangerous) Program management 119 Source:

21 (sub)process Mapping Role Mapping Analysis: See P2code Area/Activities Scrum / Agile X-Ref Project Startup & Initiation SU1 Appoint Executive and PM N/A SU1 Produce Project Mandate Define Project Vision SU1 PM Job Description N/A SU2 Design PM Team Assemble Team SU3 Appoint PM Team Assemble Team SU4 Create Risk/Issue Log & Initial Risks & Issues 'Sprint 0' planning SU4 Create Outline Business Case 'Sprint 0' planning SU4 Capture Customer Quality Expectations 'Sprint 0' planning: Prepare Initial Product Backlog SU4 Capture Project Tolerances & Acceptance Criteria 'Sprint 0' planning SU4 Capture & Prioritise Initial Customer Requirements 'Sprint 0' planning: Prepare Initial Product Backlog SU5 Capture Customer best practices, standards & constraints 'Sprint 0' planning CP1 Identify operational needs 'Sprint 0' planning CP1 Identify maintenance needs 'Sprint 0' planning IP1 Establish Configuration Management Plan 'Sprint 0' planning IP1 Establish Change Control approach Scrum Rollout IP1 Establish QA approach for testing 'Sprint 0' planning IP1 Establish QA approach for delivery 'Sprint 0' planning IP1 Establish Quality Log 'Sprint 0' planning IP2 Plan overall Project 'Sprint 0' planning IP3 Refine Business Case & Risks Sprint planning IP4 Set up Project Controls 'Sprint 0' planning IP4 Prepare Communications Plan N/A IP5 Setting up Lessons Learned Log 'Sprint 0' planning IP6 Assemble Project Initiation Document / Pack 'Sprint 0' planning Project Direction DP2 Authorising Project Sprint 0 Review & Retrospectives DP3 Authorising a Stage or Exception Plan Sprint Planning DP4 Giving Ad Hoc Direction Day to Day Sprint Management / Cancelling a Sprint DP5 Confirming Project Closure Release Sprint Review & Retrospectives Stage Control CS1 Authorising Work Package Sprint Planning Meeting CS2 Assessing (Work Package) Progress Day to Day Sprint Management CS3 Capturing Project Issues Daily Scrums CS4 Examining Project Issues Day to Day Sprint Management CS5 Reviewing Stage Status Day to Day Sprint Management SCRUM Product Owner Executive Project Manager Senior User Scrum Master Project Manager Team Team manager Team members PRINCE2 Executive Product owner Project Manager Product Owner Scrum Master Senior User Product Owner Team manager & members Team Warning: Mind Set AGENDA SCRUM Adaptive Iterative & incremental Start delivering value immediately & guarantee learning curve PRINCE2 Planning Phased, sequential Big Design Upfront: pro & contra! Don t start scrum with a Prince2 impediment!! Don t be afraid to complete Scrum with Prince2 stabilisers! Alternatieven The Agile Manifesto DOEL? Scrum Program management YOU? Embedded engineering Scrum + Prince REFERENTIES Scrum in five minutes Scrum Alliance Scrum and XP from the Trenches Scrum articles directory Agile Alliance's Scrum library InfoQ.com / Agile Agilo for Scrum The New New Product Development Game Jeff Sutherland, Agile development: lessons learned from the first Scrum, How can we help you? 125 Agile Project Management with Scrum By Ken Schwaber User Stories Applied By Mike Cohn Agile Estimating And Planning By Mike Cohn

22 SERVICES CHANGE MANAGEMENT 1- Assessment Assessment 2- Charter Is Scrum the optimal management for you? Transition Map Identify roles & responsibilities Competences & skills gap analysis Implementation Strategy Impact on the organisation 3- Scrum Quickstart Set Up Guidance Day to day team coaching Executives people mentoring Ad Interim insourcing Training Scrum Master Product Owner Team Members 4- Iteratieve verbeteringen Optimization Team scaling Team audits & optimization assistance Advanced Training Managerial, eg effective retrospectives Backgrounds, eg lean development Interpersonal, eg assertivity Technical Implementation Implement Development Process Superior Techniques e.g. Mocking techniques 1- Assessment 2- Charter 3- Scrum Quickstart 4- Iteratieve verbeteringen ilean You liked this session? and you want more? -> Subscribe to (or search for ilearn on Google groups) for Agile & Scrum related free events & trainings