Second module of agile/scrum course. Agile philosophy and Scrum basics

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