Post on 10-May-2015
description
Agile IntroductionModule 1 - General introduction
Agile according to Dilbert
2
Sprint 1 Backlog
3
TO-DO DOING DONE
What is Agile?
Scrum
XP
Kanban
User Story
4
As a traineeI want to understand Agile principlesTo be able to apply Agile in various situations
Agile Manifesto
5
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
That is, while there is value in the items on the right, we value the items on the left more.
That is, while there is value in the items on the right, we value the items on the left more.
MoreAgile Manifesto
by Geert Bossuyt
Teamwork & responsibility over Individuals and Interaction
Deliver Value over Working software
Partnership elaboration over Customer collaboration
Embrace change over Respond to Change
While we value the Agile Manifesto, we state that MoreAgile is more Agile.
12 principles
6
Working software is the primary measure of progress.
Our highest priority is to satisfy the customerthrough early and continuous delivery of valuable software.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Continuous attention to technical excellence and good design enhances agility.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Simplicity--the art of maximizing the amount of work not done--is essential.
Business people and developers must work together daily throughout the project.
The best architectures, requirements, and designs emerge from self-organizing teams.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
1 7
2 8
3 9
4 10
5 11
6 12
Agile - protest movement
• Against:
• waterfall development
• micro management
• disdain for craftsmanship of developers
7
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
Other planning principles
9
FIX
EDES
TIM
ATE
Scope
Time Cost
Traditional
Scope
Time Cost
Agile
Scrum in a Nutshell
10
Kanban in a Nutshell• Visualise workflow
• Limit WIP
• Measure lead time
11
XP in a Nutshell
12
Comparing methods
13
prescriptive: more rules to followadaptive: less rules to follow
Sprint 1 Backlog
14
TO-DO DOING DONE
What is Agile?
Scrum
XP
Kanban
User Story
15
As a traineeI want to know what Scrum is and XPBecause I might start applying it
Scrum
16
• PROJECT MANAGEMENT approach
• So, same goals as Prince2
• But, a completely different approach!
The big picture
Image available at www.mountaingoatsoftware.com/scrum
Three pillars
• Transparency
• Inspection
• Adaptation
18
Scrum framework•Product owner•ScrumMaster•Team
Roles
•(Release planning)•Sprint planning meeting•Daily scrum meeting•Sprint review meeting•Sprint retrospective
Events
•Product backlog•Sprint backlog•(Burndown charts)•Definition of Done
Artifacts
19
Scrum framework•Product owner•ScrumMaster•Team
Roles
•(Release planning)•Sprint planning meeting•Daily scrum meeting Sprint review meeting
•Sprint retrospective
Events
•Product backlog•Sprint backlog•(Burndown charts)•Definition of Done
Artifacts
20
Mountain Goat Software, LLC
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
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
The Super Scrum Master
23
Mountain Goat Software, LLC
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
Roles in Scrum
25
Product Owner Team Scrum Master
Responsible for VALUE the team delivers
Responsible for QUALITY of delivery
Responsible to remove Impediments
Responsible for WHAT Responsible for HOW (Content)
Responsible for HOW (Scrum process)
Owner of Product Backlog
Owner of Sprint Backlog
Facilitates Sprint Planning Meeting
One person, no committee Optimal size 6 ± 3 Servant leader
Is, or represents, the customer
Cross-functional, self-organising
Introduces Scrum in Project and Organisation
Scrum framework•Product owner•ScrumMaster•Team
Roles
•(Release planning)•Sprint planning meeting•Daily scrum meeting•Sprint review meeting•Sprint retrospective
Events
•Product backlog•Sprint backlog•(Burndown charts)•Definition of Done
Artifacts
26
Release Planning
27
Product Vision
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Epic
User Story
User Story
Epic
User Story
Epic Epic
1 2 3 4 5 6 7 8
User stories are the Agile way of documenting
requirements.As a <user role>
I want <something>So I can achieve <value>
Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint goal (design)
• Create sprint backlog (tasks) from product backlog items (user stories / features)
• Estimate sprint backlog in hours
Sprintgoal
Sprintbacklog
Business conditions
Team capacity
Product backlog
Technology
Current product
28
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 planner, I want to see photos of the hotels.
Code the middle tier (8 hours)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)
29
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 meetings30
Everyone answers 3 questions
• These are not status for the ScrumMaster
• They are commitments in front of peers
What did you do yesterday?1
What will you do today?2
Is anything in your way?3
31
The sprint review• Team presents what it accomplished during
the sprint
• Typically takes the form of a demo of new features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world
32
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
Start / Stop / Continue
• Whole team gathers and discusses what they’d like to:
Start doing
Stop doing
Continue doingThis is just one of many ways to
do a sprint retrospective.
34
•Product owner•ScrumMaster•Team
RolesScrum framework
•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting
Ceremonies
•Product backlog•Sprint backlog•Burndown charts•Definition of Done
Artifacts
35
Product backlog
This is the product backlog
36
•The features, functions, requirements, enhancements and fixes
•A list of all desired work on the project
•Ideally expressed such that each item has value to the users or customers of the product
•Ordered by the product owner
•Re-ordered at the start of each sprint
A sample product backlogBacklog 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 reservation.
3
As a hotel employee, I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
... 30
... 50
37
Or use T-Shirt sizes (S/M/L)
The sprint goal• A short statement of what the work will be
focused on during the sprint
Database Application
Financial services
Life Sciences
Support features necessary for population genetics studies.
Support more technical indicators than company ABC with real-time, streaming data.
Make the application run on SQL Server in addition to Oracle.
38
The Sprint Backlog
Definition
• subset of product backlog
• selected for this sprint
• plan for delivering the increment and realising the sprint goal
39
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
Definition of Done
• Wanneer is een taak (een stuk code) af?
41
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 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, and8. Standard, well-known design principles have been adhered to.
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
Definition of Done
• Tested & bugfree• Deployed to test server,
so PO can test• All user actions• All supported browsers•IE7/8•Chrome•Firefox•Safari on Mac• Comments in code
43
• Refactoring• Code reviewed when
needed• Remember to check
the Style_guideline• Maintain wiki page• Maintain ERD document• Versions of components• License overview• Check the constraints
ResponsibilitiesPO
Team
Scrum Master
Scrum
• Lightweight
• Simple to understand
• Extremely difficult to master
45
Sprint 1 Backlog
46
TO-DO DOING DONE
What is Agile?
Scrum
XP
Kanban
XP - eXtreme Programming
47
• DEVELOPMENT approach
XP Practices
48
Sprint 1 Backlog
49
TO-DO DOING DONE
What is Agile?
Scrum
XP
Kanban
On day in Kanban land
50
On day in Kanban land
51
On day in Kanban land
52
On day in Kanban land
53
On day in Kanban land
54
On day in Kanban land
55
On day in Kanban land
56
On day in Kanban land
57
On day in Kanban land
58
On day in Kanban land
59
On day in Kanban land
60
On day in Kanban land
61
Sprint 1 Backlog
62
TO-DO DOING DONE
What is Agile?
Scrum
XP
Kanban
Sprint 2 Backlog
63
TO-DO DOING DONE
XP Game
Context
Sprint 2 Backlog
64
TO-DO DOING DONE
XP Game
Context
65
The Rhineland Way
66
Anglo-american RhinelandBoss 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
Cynefin
67
Visible Order C&E obvious
Hidden Order C&E discoverable
Complex Un-order C&E coherent in retrospect
Chaotic Un-order No perceivable C&E
Sense Categorise Respond
Act Sense
Respond
68
Visible Order C&E obvious
Hidden Order C&E discoverable
Complex Un-order C&E coherent in retrospect
Chaotic Un-order No perceivable C&E
Novel Practice
Best Practice
Good Practice
Worst Practice
69
Intervention types
70
Empirically Known The domain of
the actual Legitimate best practice
STANDARD PROCEDURES PROCESS RE-ENGINEERING
Empirically Knowable The domain of the probable
Analytical/Reductionist SCENARIO PLANNING SYSTEMS THINKING
Complex The domain of many
possibilities Pattern Management
PERSPECTIVE FILTERS COMPLEX ADAPTIVE SYSTEMS
Chaos The domain of the
inconceivable Stability focused intervention
ENACTMENT TOOLS CRISIS MANAGEMENT
House of commons
71
RhinelandersAnglo-americans
Cynefin observers
Position: current Anglo-american management
style is the best for our companies
Position: we definitely need to change to The Rhineland
Way
Observe the debate:were the solutions
(interventions) in line with the 4 Cynefin domains?
Sprint 2 Backlog
72
TO-DO DOING DONE
XP Game
Context
Credits• Several slides have been taken from the
Redistributable Scrum Introduction - Scrum Alliance
73