Focus Scrum Organization of a Scrum development work

Focus: Scrum Organization of a Scrum development work See Ken Schwaber at Google, September 2006 One hour video recording of one of the originators of Scrum Karlstads University Computer Science Software Engineering, DVGC 05

Scrum characteristics • • Transparancy – exposesproblems early Strict prioritization Empirical & adaptive – Short feedback loop – Continuous improvement – Frequent & regular delivery of working software – Plans are needed, but they are always wrong – Yesterday’s weather Cross-functional self-organizing team Pull scheduling – team chooses how much work to commit to Timeboxing Face-to-face communication Simple tools Karlstads University Computer Science 2 Software Engineering, DVGC 05

Scrum process Karlstads University Computer Science 3 Software Engineering, DVGC 05

History Karlstads University Computer Science 4 Software Engineering, DVGC 05

Slack Karlstads University Computer Science 5 Software Engineering, DVGC 05

Life wisdom • 3 things we wish were true – The customer knows what he/she wants – The developers know how to build it – Nothing will change along the way • 3 things we have to live with – The customer discovers what he/she wants – The developers discover how to build it – Many things change along the way Karlstads University Computer Science 6 Software Engineering, DVGC 05

Monolithic vs Incremental Karlstads University Computer Science 7 Software Engineering, DVGC 05

Push vs Pull Karlstads University Computer Science 8 Software Engineering, DVGC 05

Agile vs Waterfall Karlstads University Computer Science 9 Software Engineering, DVGC 05

Does it work? Karlstads University Computer Science 10 Software Engineering, DVGC 05

Relation between Scrum and XP Karlstads University Computer Science 11 Software Engineering, DVGC 05

Feedback cycles Karlstads University Computer Science 12 Software Engineering, DVGC 05

A Scrum sprint Some details Karlstads University Computer Science Software Engineering, DVGC 05

A Scrum Sprint Pre-project Disciplines Initial requirements Sprints Requirements Analysis Mo. SCo. W / Pareto, solve top 20% requirements first Design Implementation Test Sprints Karlstads University Computer Science [Pareto], [Mo. SCo. W] #1 14 #2 #3 #4 Software Engineering, DVGC 05

Iterative Development – One Iteration • Each iteration is a mini project involving all disciplines – Normally not in sequence * [until finished] Requirements Analysis capture in Requirements Model verify requirements in Analysis Model : Class Test Architecture and Design Implementation Karlstads University Computer Science specify requirements in realise requirements in implement requirements in 15 : Actor Test Model Architecture Model Design Model Code Software Engineering, DVGC 05

The Sprint Flow • Sprint planning meeting, eight hours Time box – Team and Product Owner update and prioritize Product Backlog 4 h – The team plans for and starts the sprint 4 h • Place tasks in the Sprint Backlog, the sprint has started • Team runs sprint – Team holds Daily Scrum • Synchronizes team members • What is done, what is planned, what impediments stop me – Team updates Sprint Backlog 28 d 15’ • Team holds Sprint review meeting – Demonstrate sprint results to anyone interested 4 h • Scrum Master holds Sprint retrospective meeting with Team – Team revises and improves development process 3 h Karlstads University Computer Science 16 Software Engineering, DVGC 05

The Scrum Process Overview Planning meeting Vision: Anticipated ROI, Releases, Milestones. Initial requirements Karlstads University Computer Science [Scrum 07] 17 Software Engineering, DVGC 05

What does Done mean? • Deliverable to the customer – Ready to be used in a product – QA, documentation, refactored, meets good engineering practice standards • What if I am unable to finish all this during this sprint? • Some options – Increase effort, work harder, longer, smarter – Cut quality, skip design, testing, intergation, documentation – Cut features • What are the consequences of each? – Which one is least / most desireable Karlstads University Computer Science 18 Software Engineering, DVGC 05

Consequences of Rushing or Cutting Quality • Rushing: Working overtime, cutting breaks, adding people – Leads to burn out – Error rate increases • More crap produced in shorter time • Cutting quality – Harder to reuse and develop further • Increased technical dept due to lack of refactoring – Reduces velocity – Makes it harder to meet new goals – Increases need to rush or cut quality in subsequent sprints • Only sustainable option – Cut features, postpone to lates sprints and/or releases – Informed decisions with the PO involved Karlstads University Computer Science [Kniberg 08] 19 Software Engineering, DVGC 05

Sprint Planning Meeting • Product Owner selects top priority features from Product Backlog – Candidates for next sprint – Feature = something useful for product owner – Closer to top more detailed stories, more scenarios • Team estimates features from top until sprint velocity reached – Story Points, Sprint velocity = number of story points done in earlier sprints • Only complete features count • Feature estimates kept constant throughout product development – Planning Poker • Only rough, relative estimates (story points) for whole features • Product Owner writes acceptance tests – For selected features – Supported by team members Karlstads University Computer Science [Backlog item practice], [Planning 20 Poker] Software Engineering, DVGC 05

Sprint Starts • Team builds initial Sprint Backlog – Breaks down features to tasks • Add database tables or fields • Write data access routines • Increase domain model functionality • Add user interface • Etc etc – Makes initial task estimates by hours • Do not map directly to Product Backlog scale – Build sprint backlog • Workshop tools – Off you go • The sprint has already started, time is ticking Karlstads University Computer Science 21 Software Engineering, DVGC 05

Work During Sprint, for One Task at a Time • Select an acceptance test corresponding to the user story – Prepared by PO – Set test property on local workstation only • Analysis and design – For the short term items • No AP (Analysis Paralysis) • No DBUF (Big Design Up Front) – Normally standing in groups in front of a whiteboard • Incrementally and iteratively develop features in tiny steps – Document example in NUnit, implement, refactor – Apply all design skills and software engineering practices during refactoring – Until Done with that task and eventually that user story Karlstads University Computer Science 22 Software Engineering, DVGC 05

Daily Stand Up Meeting • Purpose – Team member inform each other of their progress and need for assistance – Three items: • Achieved yesterday, goal for today, impediments • Common pitfalls – discuss what kind of problems they cause – Team members report to the project manager – Team members embellish their progress – Team members report ”done” before Done – Team members do not offer to help each other • Time boxed to 15 minutes – Expanded discussions are postponed to additional meetings Karlstads University Computer Science 23 Software Engineering, DVGC 05

Scrum Demonstration • With Product Owner and any interested party – You have to deliver a piece of business functionality every sprint • Last day of every sprint – End of sprint time box – Time and date fixed in advance at regular pace – Unconditional • Demonstrates that was promised actually works – No excuse – Problems should have been raised and solved earlier – Include ”How to demonstrate” in Product Backlog • Next up – Team and Scrum Master: Retrospective meeting – Product Owner: Plan priorities for next sprint Karlstads University Computer Science 24 Software Engineering, DVGC 05

Scrum Retrospective Meeting • Team and Scrum Master • The single most important activity for continuous improvement – Återblicken, blog Tobias Fors, Citerus (in Swedish) • Assess what has worked and what has not during last sprint – Make list of what needs to improve – Suggest changes • Select at most one item to change during the coming sprint – Discuss how to implement the change • Next up – Team, Scrum Master, Product Owner: Planning meeting for the next sprint Karlstads University Computer Science 25 Software Engineering, DVGC 05

Practices • • • Pair programming – TODO: en bild om parprogrammering Stand up meetings TDD Incremental design Continuous integration Collective code ownership Informativ workspace Coding standard Sustainable pace Karlstads University Computer Science 26 Software Engineering, DVGC 05

Tools • • • Visual Studio – Coding and connecting NUnit – TDD Fit. Nesse – Integration testing Sub. Version – Version control Cruise Control – Automation MSBuild – Putting it all together Karlstads University Computer Science 27 Software Engineering, DVGC 05

Group business • • • There will be three groups – 5 -6 people We want your groups to work as well as possible together – Good composition – Good teamwork – Good guidance Different skills – user thinking/requirements – analys/design – coding – testing Which of the above four is your strongest, according to yourself? – All skills will be needed – Has no bearing to course grade Also think about if you want to speak English in your group or not Karlstads University Computer Science 28 Software Engineering, DVGC 05

More group business • • Group yourself in the four corners of the room according to your strong point English or not Karlstads University Computer Science 29 Software Engineering, DVGC 05