2009. Agile en Scrum. onder de loop. Workshop 13 mei 2009 Kris Phillipaerts & Peter Janssens SCRUM

11/05/2009

Agile en Scrum onder de loop

Workshop 13 mei 2009 Kris Phillipaerts & Peter Janssens

1

SCRUM

2

1

11/05/2009

SCRUM BASICS

3

Scrum Process

4

2

11/05/2009

Scrum Process

5

6

3

11/05/2009

ROLLEN: Varkens en kiekens

7

Product Owner •Vertegenwoordigt klant bij team •Beheert product backlog •Bepaalt release plan Maar: • Respecteert schattingen • Respecteert sprint planning

8

4

11/05/2009

Team •Empowered team •Cross-functional team •Self organizing Maar: •Respecteert “team rules” •Respecteert prioritisering van PO •Respecteert Scrum regels

9

Scrum Master • Evangelist • Werkt impediments weg • Bewaakt Scrum proces • Motivator en servant leader Maar: • Respecteert team beslissingen

10

5

11/05/2009

Klant Verantwoordelijkheden • Functionele sturing • Prioritisering • Acceptatie • Testing + feedback Maar: • Hangt van klant tot klant af • Aanpasbaar aan noden van klant 11

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 12

6

11/05/2009

Product Backlog

13

Product Backlog

Elke user story is - Gemakkelijk te verstaan - Waardevol voor de klant/gebruiker 14

7

11/05/2009

Estimation Meetings Relatieve inschatting = vergelijkend Eenheden • Points • Ideal Man Hours

15

Velocity Velocity = aantal punten per sprint Begin: inschatting • optimisch scenario? • conservatief scenario? Opvolging sprint na sprint • wordt een waarneming (empirisch)

16

8

11/05/2009

Velocity OPGELET Velocity is een middel om vooruit te denken obv empirische vaststellingen Velocity IS GEEN DOEL

17

Project Burndown chart

Na elke sprint noteren we het aantal punten die nog moeten gerealiseerd worden 18

9

11/05/2009


15

16

Scope uitbreiding 19


Scope uitbreiding bij Fixed Time 20

10

11/05/2009


Target deadline vervroegd 21

Burndown chart

Beter: optimistisch & conservatief scenario 22

11

11/05/2009

Sprint Planning

23

Sprint Backlog

... 24

12

11/05/2009

Taskboard

25

Sprint Burndown

Dagelijks noteren we het aantal taken die nog moeten gerealiseerd worden 26

13

11/05/2009

Daily Scrum / Stand up

27

Talking stick

28

14

11/05/2009

Impediments list

29

Sprint Review / Demo

30

15

11/05/2009

Sprint Retrospective

31

Project kickoff •Staffing (rolverdeling) •Scrum proces uitleggen •Team rules afspreken •Definition of done bepalen

32

16

11/05/2009

Plaatsing van Agile

Prince2

Waterfall

PMBOK RUP Scrum

AGILE

Lean

DSDM

eXtreme Programming

Ad Hoc Iteratief

33

Scrum Toolbox Rollen

Filosofie Courage

Artefacten

Ceremonies

Openness

Focus

Practices

Respect

Commitment

34

17

11/05/2009

Scrum fundament

35

Scrum impact

36

18

11/05/2009

SCRUM HISTORIEK 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review

1993 Jef Sutherland:

2003 Lean Software Development < Mary & Tom Poppendieck

first Scrum at Easel

2008

1995 Ken Schwaber: First white paper on Scrum

1996 Kent Beck: XP 2001 Agile Manifesto

37

PRAKTISCHE SCRUM DEPENDENCIES

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)

38

19

11/05/2009

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 39

AGENDA

Alternatieven

Backlog & Program management Embedded engineering

The Agile Manifesto

Scrum + Prince2

DOEL ? Scrum 40

20

11/05/2009

DOEL ? • Wat willen wij bereiken? • Onderscheid doel <> middelen

41

DOEL ?

werkende oplossingen project struktuur

plan

documentatie

kwaliteit software communicatie mensen werk procedures efficientie functies

werkende oplossingen tools

architectuur

42

21

11/05/2009

DOEL ?

Wat willen wij bereiken ?

project struktuur

werkende oplossingen

plan

documentatie

kwaliteit software communicatie mensen werk procedures


efficientie functies

tools

architectuur

43

DOEL ?



Welke middelen hebben wij ? mensen

software

project struktuur

functies tools architectuur documentatie communicatie

plan

werk procedures

kwaliteit

efficientie 44

22

11/05/2009

DOEL ?

mensen

software

project struktuur

functies tools architectuur documentatie communicatie

plan

werk procedures

kwaliteit

Welke middelen hebben wij ?

werkende oplossingen kwaliteit efficientie


45

DOEL ?

Welke middelen hebben wij ? mensen software project struktuur functies tools architectuur documentatie communicatie

plan

werk procedures

efficientie

werkende oplossingen kwaliteit

kwaliteit


46

23

11/05/2009

THE AGILE MANIFESTO • Context • Principes

47

CONTEXT


48

24

11/05/2009


CONTEXT

Kunnen omgaan met Complexiteit

49


CONTEXT ?

Kunnen omgaan met Voortschrijdend inzicht Gevraagd

Bij nader inzicht

50

25

11/05/2009

CONTEXT


Kunnen omgaan met Snelle veranderingen

51

CONTEXT


Kunnen omgaan met Mensen

52

26

11/05/2009

CONTEXT


Kunnen omgaan met Creativiteit

53

CONTEXT


Kunnen omgaan met Duurzaamheid - kwaliteit

54

27

11/05/2009


CONTEXT

Scope

Kwalliteit

Tijd

Kost

70 % result in extra budget due to change request over initial contract

55

CONTEXT

Is “op tijd” een voorwaarde voor success? •Tijd is geen objectief in de definitie van een project bij PMBOK of Prince2 •Tijd kan een (belangrijk) objectief zijn in een business case 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.

PMBOK (PMI) Project: a temporary endeavor undertaken to create a unique product or service

56

28

11/05/2009

CONTEXT


CONTEXT


57

Chaos

58

29

11/05/2009

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

That is, while there is value in the items on the right, we value the items on the more

59

Agile Manifesto


Individuals and interactions over processes and tools

60

30

11/05/2009

Agile Manifesto


Working software over comprehensive documentation

61

Agile Manifesto


Customer collaboration over contract negotiation

62

31

11/05/2009


Agile Manifesto

Responding to change over following a plan

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

AGILE ALTERNATIEVEN • • • • •

(algemeen: iteratief development) Lean Software Development Kanban software development DSDM Extreme Programming (XP)

64

32

11/05/2009


ITERATIEF DEVELOPMENT

BACKLOG

WIP (WORK IN PROGRESS)

WORKING SOFTWARE

65

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?

BACKLOG

66

(versus economy of Scale)

Bug = stop productie

Red alert = Elk team lid kan productie stoppen

33

11/05/2009

KANBAN SOFTWARE DEVELOPMENT


DSDM


67

68

34

11/05/2009

EXTREME PROGRAMMING


EXTREME PROGRAMMING


69

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 Open Workspace Bonus

70

35

11/05/2009

XP Practices


Planning Game • Release Planning developers + customers exploration > commitment > steering/adjustment

• Iteration Planning developers only exploration > commitment > steering/adjustment

71

XP Practices


Functional Testing • No new development until acceptable for the customer • Prevent regressions and communicate important historical information • Automation 72

36

11/05/2009

XP Practices


Test Driven Development ~ unit tests use short development iterations based on pre-written test cases that define desired improvements. 73

XP Practices


Refactor Mercilessly Don’t leave duplicate or uncommunicative code around

74

37

11/05/2009

XP Practices


Code and design simply 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 75

XP Practices


System metaphor • 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.

76

38

11/05/2009

XP Practices


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 •if you run across some code that could be improved, you have to stop and improve it 77

XP Practices


Develop Coding Standards developing is a team game

Examples • choose same style of class & variable names • format code the same way

78

39

11/05/2009


XP Practices

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. 79


XP Practices

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.

80

40

11/05/2009

XP Practices


Sustainable Pace Every day • starts at start time • ends at end time • need for regular overtime is a clear signal that something else is wrong with the project. • better awareness, better refactoring, simpler code

81

XP Practices


Pair Programming is a software development technique in which two programmers work together at one work station. > Driver + Observer/navigator

82

41

11/05/2009


XP Practices

Pair Programming 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

83

XP Practices

Open Workspace

werkende oplossingen kwaliteit Bonus

• 1 room for all • Tables in center with computers & dual screens • A project board

84

42

11/05/2009

Backlog & Program Management

85

BACKLOG


Backlog = prioritised list of requirements

86

43

11/05/2009

BACKLOG


A user story should be • I ndependent • N egotiable • V aluable to users or customers

Agile Estimating And Planning By Mike Cohn

• E stimatable • S mall • T estable 87

BACKLOG


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?

88

44

11/05/2009

BACKLOG


Analysis challenges • 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) 89

BACKLOG


Iterative or incremental?

90

45

11/05/2009


BACKLOG

Project Vision/Strategy • Prioritise: based on Business Urgency or Logical workflow? • Business Value – determined by ROI or by development efficiency? • How to apply end-to-end thinking in a cyclic development? 91

BACKLOG


There is no silver bullet

92

46

11/05/2009

.


BACKLOG

Technique: User Role Modelling 1. Brainstorm an initial set of user roles 2. Organize the initial set 3. Consolidate roles 4. Refine the roles Role Job Seeker First Timer Layoff Victim Geographic Searcher Monitor Job Poster Resume Reader

Who Scott Laura Kindra Allan Ashish Mario, Savannah Delaney, Savannah

93

BACKLOG


Agile Striptease A pattern/guideline for creating & elaborating user stories

94

47

11/05/2009


BACKLOG

Represent your business case visually People Inputs

Documents

Info

Solution

As a solution (not “software”, “process”, ...) For people

Data / Operations

Outputs People

95


BACKLOG

Identify the critical outputs Data / Operations

Outputs

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

96

48

11/05/2009


BACKLOG

Split your roads from in>out into different “cases” Case A

Case B

Case C

Case D

Solution

Data / Operations

Outputs

Examples - Different kinds of customers - Different kinds of contracts - Different kinds of employees - ... Good to know - These cases will, amongst others, be a start for user stories 97


BACKLOG

Identify your typical simplest case Case A

Solution

Data / Operations

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 98

49

11/05/2009


BACKLOG

Strip, strip, strip, strip Case A

Case A+

Case A++

Case A+++

Solution

Data / Operations

Good to know & Tips - Every stripped complexity becomes a new user story 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

99


BACKLOG

…and strip again (even when you think you can’t strip any more) Case A

Case A+

Case A++

Case A+++

Solution

Data / Operations

Good to know & Tips - Every stripped complexity becomes a new user story 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

50

11/05/2009

BACKLOG


Simple typical case + naked shortest roads (cases) = basic framework + list of stripped complexities = Initial backlog

101

BACKLOG


Benefits - Realise basic framework extremely fast - Cases can easily be sorted by priority (frequency & importance) - Enables/allows progressing insights

102

51

11/05/2009

BACKLOG


Benefits - Stories have few dependencies - Stories are valuable for the business (output oriented) & testable - Stories can be kept small

103

BACKLOG


Benefits - Time consuming complexity at end sorted by priority - If project stops - (many) High priorities are realised - Drop off: (few) low priorities

104

52

11/05/2009

BACKLOG


Benefits - Encourages end-to-end vision - Scope: requirements become dimensional => not “in” our “out”

105

Fitnesse tests are expressed as tables of input data and expected output data

“executable requirements”

106

53

11/05/2009

Fitnesse Any user can - Understand - Give input Uses tables (Ms Excel) www.fitnesse.org

107

Risk Prevention Implicit risk prevention •High priorities are realised first •High risks (or spikes) should be prioritised high •High group learning curve => lower individual dependencies 108

54

11/05/2009

Risk Prevention Implicit risk prevention •Fail fast & early detection through • daily visual management • short feedback loop • end-to-end strategy

109

Risk Prevention Implicit risk prevention •Reliable information Progress = progress Velocity = velocity

110

55

11/05/2009

Risk Prevention Implicit risk prevention •Scrum will not prevent all risks for you •Have a risk assessment at the start of your projects

111

Agile Program Management


Onion: levels of detail

112

56

11/05/2009



Cone of Uncertainty

113



RoadMap backlog (see RoadMap.xls) Relative estimations Estimate min & max realisation time Monitor real progress & update forecasts 114

57

11/05/2009



Success Factors Keep Projects Small • set max size • work with sub projects

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 115

Embedded Engineering • ... • Conclusies Agile Open, France

116

58

11/05/2009

Scrum + Prince2 ? • • • • •

Prince2 1 min overview Implementation types Process mapping Role mapping Warning: mind set

117

Prince2 Bedrijfs- of Programmamanagement aankondiging projectstart

SP

OP Opstarten v/e Project

PID autorisatie

rapporten, advies

IP Initiëren v/e Project

PL

Projectplan

Faseplan, Fase-eindrapport

autorisatie

BF Beheersen v/e Fase autorisatie

Initiatiefaseplan

projectafsluiting

Sturen v/e Project (Stuurgroep) Projectvoorstel

Projectmandaat

voortgangsinformatie

goedgekeurde PID

MF Managen Faseovergangen

oplevering, Projecteindrapport

AP Afsluiten v/e Project

rapporten, producten

MP Managen Productoplevering

volgende Faseplan, Afwijkingsplan

Teamplan

Opstellen v/e Plan

118

59

11/05/2009

Implementation Types

don't use Prince2 at all

119

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

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

Source: http://blog.scottywakefield.net/2008/04/scrum-and-prince2-working-together.html

Implementation Types

Typical Prince2 Stabilisers • Steering committee • Project initiation • Risk Management • Reporting (dangerous) • Program management 120

60

11/05/2009

(sub)Process Mapping Analysis: See http://blog.julianonsoftware.com P2code SU1 SU1 SU1 SU2 SU3 SU4 SU4 SU4 SU4 SU4 SU5 CP1 CP1 IP1 IP1 IP1 IP1 IP1 IP2 IP3 IP4 IP4 IP5 IP6 DP2 DP3 DP4 DP5 CS1 CS2 CS3 CS4 CS5

Area/Activities Project Startup & Initiation Appoint Executive and PM Produce Project Mandate PM Job Description Design PM Team Appoint PM Team Create Risk/Issue Log & Initial Risks & Issues Create Outline Business Case Capture Customer Quality Expectations Capture Project Tolerances & Acceptance Criteria Capture & Prioritise Initial Customer Requirements Capture Customer best practices, standards & constraints Identify operational needs Identify maintenance needs Establish Configuration Management Plan Establish Change Control approach Establish QA approach for testing Establish QA approach for delivery Establish Quality Log Plan overall Project Refine Business Case & Risks Set up Project Controls Prepare Communications Plan Setting up Lessons Learned Log Assemble Project Initiation Document / Pack Project Direction Authorising Project Authorising a Stage or Exception Plan Giving Ad Hoc Direction Confirming Project Closure Stage Control Authorising Work Package Assessing (Work Package) Progress Capturing Project Issues Examining Project Issues Reviewing Stage Status

Scrum / Agile X-Ref N/A Define Project Vision N/A Assemble Team Assemble Team 'Sprint 0' planning 'Sprint 0' planning 'Sprint 0' planning: Prepare Initial Product Backlog 'Sprint 0' planning 'Sprint 0' planning: Prepare Initial Product Backlog 'Sprint 0' planning 'Sprint 0' planning 'Sprint 0' planning 'Sprint 0' planning Scrum Rollout 'Sprint 0' planning 'Sprint 0' planning 'Sprint 0' planning 'Sprint 0' planning Sprint planning 'Sprint 0' planning N/A 'Sprint 0' planning 'Sprint 0' planning Sprint 0 Review & Retrospectives Sprint Planning Day to Day Sprint Management / Cancelling a Sprint Release Sprint Review & Retrospectives Sprint Planning Meeting Day to Day Sprint Management Daily Scrums Day to Day Sprint Management Day to Day Sprint Management

121

Role Mapping SCRUM

PRINCE2

Product Owner

Executive

Executive Project Manager Senior User

Scrum Master

Product owner

Project Manager Product Owner Scrum Master

Project Manager

Senior User Product Owner

Team Team manager Team members

Team manager & members Team

122

61

11/05/2009

Warning: Mind Set SCRUM

PRINCE2

•Adaptive

• Planning

•Iterative & incremental

•Phased, sequential

•Start delivering value immediately & guarantee learning curve

•Big Design Upfront: pro & contra

! Don’t start scrum with a Prince2 impediment ! ! Don’t be afraid to complete Scrum with Prince2 stabilisers!

123

AGENDA

Alternatieven

Program management Embedded engineering

The Agile Manifesto

Scrum + Prince2

DOEL ? Scrum

YOU?

124

62

11/05/2009

REFERENTIES Scrum in five minutes http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf

Scrum Alliance http://www.scrumalliance.org/

Scrum and XP from the Trenches http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Scrum articles directory http://www.softdevarticles.com/modules/weblinks/viewcat.php?cid=46

Agile Alliance's Scrum library http://www.agilealliance.org/article/articles_by_category/17

InfoQ.com / Agile http://www.infoq.com/Agile

Agilo for Scrum http://www.agile42.com/cms/pages/download/

The New New Product Development Game http://apln-richmond.pbwiki.com/f/New%20New%20Prod%20Devel%20Game.pdf

Jeff Sutherland, Agile development: lessons learned from the first Scrum, 2004 http://jeffsutherland.com/scrum/FirstScrum2004.pdf

Agile Project Management with Scrum 125By Ken Schwaber

User Stories Applied By Mike Cohn

Agile Estimating And Planning By Mike Cohn

How can we help you?

126

63

11/05/2009

SERVICES

1- Assessment

3- Scrum

4- Iteratieve

Quickstart

verbeteringen

Assessment Is Scrum the optimal management for you?

Transition Map

Set Up Guidance

Optimization

Identify roles & responsibilities

Day to day team coaching

Team scaling

Competences & skills gap analysis

Executives people mentoring

Team audits & optimization assistance

Implementation Strategy

Ad Interim insourcing

Impact on the organisation

Training

2- Charter

Advanced Training Managerial, eg effective retrospectives

Scrum Master Product Owner

Backgrounds, eg lean development

Team Members

Interpersonal, eg assertivity

Technical Implementation Implement Development Process

Superior Techniques e.g. Mocking techniques

127

CHANGE MANAGEMENT

1- Assessment

2- Charter

3- Scrum Quickstart

4- Iteratieve verbeteringen

128

64

11/05/2009

iLean

You liked this session? and you want more? -> Subscribe to [email protected] (or search for “iLearn” on Google groups) for Agile & Scrum related free events & trainings

129

130

65

2009. Agile en Scrum. onder de loop. Workshop 13 mei 2009 Kris Phillipaerts & Peter Janssens SCRUM

Recommend Documents