Agile Foundation Trainer: Rachel Davies rachel@agilexp.com
Examples in UK
1
Waterfall
Phases of activity focused on a fixed-scope release. What are the pros and cons?
Agile
Concurrent activity to create continuous flow of releases. What are the pros and cons?
2
Agile Benefits
Version One – State of Agile Survey 2009 - 2,570 respondents from 88 countries
Exploring Agile Parameters
What can we do if a project is late?
3
Project Variables
Agile sets Time, Resources, Quality as constants Flex Scope
Embrace Change! • Agile development embraces change • Agile delivers value early and often • Agility requires involvement of business throughout the lifecycle
4
Family of Agile Methods
Code
• Extreme Programming (XP) • Scrum • Lean / Kanban • DSDM / Atern Project
Agile History
199 6
199 3
RAD DSDM
200 1
RUP FDD Scrum
XP
“Agile” Manifesto
No w
Kanban
5
Agile Manifesto • Shared values and principles for better ways to develop software (2001) • www.agilemanifesto.org
Agile Values Individuals & Interactions over Processes & Tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan While there is value in the items on the right, we value the items on the left more.
6
Agile Manifesto Principles (1) • Our highest priority is to satisfy the Customer through early and continuous delivery of valuable software • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project.
Agile Manifesto Principles (2) • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done • The most efficient and effective method of conveying information to and within a development team is face-toface conversation. • Working software is the primary measure of progress • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
7
Agile Manifesto Principles (3) • Continuous attention to technical excellence and good design enhances agility. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Scrum framework Roles
•Product Owner •ScrumMaster •Team Ceremonies •Sprint Planning •Sprint Review •Sprint Retrospective •Daily Scrum Artifacts
•Product Backlog •Sprint Backlog •Burndown chart
8
Basic Scrum Lifecycle
Sprints
• Plan the project as a series of time boxed Sprints • Each Sprint delivers a product increment of production ready software • Testing happens inside the Sprint not afterwards • Choose a standard length for Sprints, e.g. 2 weeks or 1 month
9
Product Increments • Develop product increments • Each increment is available for release • Business decision whether to put each release out
Sprints 0 1 2 3 4
1
Interim Releases
Final Deployment 2
5 6 7 8
3 9 1 1 1 0 1 2
Example Sprint
P L A N D E V
D E V E L O P
D E V E L O P
D E V E L O P
D E V E L O P
D E V E L O P
D E V E L O P
D E V E L O P
D E V E L O P
D E M O R E T R O
Most teams set their sprint length at 2 weeks
10
Start from Sprint Zero is a short sprint that precedes product development to establish initial artefacts • • • • • •
Mission statement User research and initial Design Release Plan Risks & Logs High level technical architecture Technical infrastructure for development (test tools, etc)
Product Backlog • Prioritized list of work to be performed to develop product • Anyone can contribute items for the backlog • One person (Product Owner) is responsible for prioritisation
11
Sprint Planning P R O D U C T B A C K L O G
User Stories with tests
Tasks
Internal to team, understood in detail Future deliverables, interesting to stakeholders. Not fully defined
S P R I N T B A C K L O G
Visible Plans • The Team Board shows what the team are working on today and how much is left.
12
Agile Roles
Product Owner
• Sets Vision and steers towards it • Works with stakeholders and Scrum team but is the only person that prioritizes
13
The Team
Between 5 and 10 team members • Cross-functional • Self-organising • Dedicated
Scrum Master
• Facilitates meetings • Shields the team • Helps remove roadblocks
14
Whole Team Between 5 and 10 team members • Cross-functional • Self-organizing
Current sprint
Future sprint
Agile Meetings
15
Sprint Planning To establish a realistic commitment for the Sprint
Stories
Understand + Estimate
Goal + Tasks
Daily Scrum
Daily 15 minute status meeting Team stands in a circle facing each other Each team member answers 3 questions: What have you done since the last Scrum? What will you do between now and the next Scrum? What got in your way of doing work? For synchronization not problem solving!
16
Sprint Review A meeting where the team demonstrates working software at the end of a Sprint to customer and stakeholders. • Visible progress • Opportunity for feedback
Sprint Retrospective At the end of the sprint, the team looks back to identify process improvements for the next sprint What happened?
Sprint x
What to change?
Sprint x+1
17
Scrum Works because .. Scrum creates leverage through: • Focus on goal • Visible progress and results • Removing interruptions • Daily review of issues • Accepted responsibility • Simple rules
User Stories • User stories explain what the software needs to do from a user perspective. • Knowing who the user is and what problems they are trying to solve helps us develop better software.
18
Planning with Stories • User Stories are a tool for collaborative planning. • Describe Product Backlog items as User Stories. • Help the team to develop a common understanding of what needs to be developed in successive sprints.
User Stories A User Story describes what the system does from a user perspective. There are three components that make a story: • Card story text on an index card • Conversation with customer and developers • Confirmation acceptance tests Don’t think of stories as mini-requirements specs!
19
Planning with User Stories
Questions help find context Ask questions to uncover the user stories.. • • • •
Who will use it? What problem are they trying to solve? What’s their goal? Why is this valuable to them?
Understand this before diving into solution details
?
20
The Conversation Stories can help to keep conversation at the level where it can understood Developers need to get time with business people to understand who needs the feature and why People (business, domain experts, user experience) on-site available to talk to developers and testers in place of documents.
The Card Story text is free form but a commonly used format is: â&#x20AC;&#x153;As <user role> I need <capability> so that <business benefit>â&#x20AC;?
Or you can simply state the user goal A story needs a name so that you can refer to it in Daily Scrum meetings. It might also need a reference number if you have a lot of them.
21
Story Example Find a book by ISBN
As a book buyer, I want to be able to find a book by entering the ISBN number so that I can find a specific book quickly
User Stories are elaborated with Examples
For each story likely to be worked on in next sprint
Have a conversation about examples
Customer, Developer & Tester
List tests on back of story card
22
The Confirmation How do we know when we are Done? • Work though examples • Get enough detail to turn into an automated test • Note down scenarios in planning • Become test scripts in the sprint
• Try this format • GIVEN <context> • WHEN <do action> • THEN <result>
Define Done • Work with the team to agree a Definition of Done • Only demonstrate items that are Done-Done.
23
Epic
User Stories
Acceptance Tests T
T
T
T T
Sometimes creating acceptance tests uncovers new stories
Beware of Epics
Sometimes a story is too large to be implemented in a single sprint, we call these Epics. Such stories will need to be broken down for reliable estimates.
24
Estimating in Points • • • •
Release plans items are estimated in points that represent: Size not effort Is this piece of work bigger than another? Not how long will it take X to do this
Group by size-complexity
Use a story card matrix to keep your estimates consistent (triangulation)
25
Velocity Velocity is a measure of a teamâ&#x20AC;&#x2122;s rate of progress. Velocity is calculated by summing the estimates for each product backlog item that the team completed during the sprint
Sprint 1 Any incomplete stories need to be re-estimated Sprint 2
Large stories (epics) waiting to be broken down
26
Estimating Scale Why Fibonacci scale? 0, 1, 2, 3, 5, 8, 13..
• Stories vary by orders of magnitude • Gaps keep scale short • Broad estimates not precise • 21 or 22 points is not interesting discussion
Explore Known-Unknowns • Spike to get a better estimate. • A spike is a time-boxed investigation with the goal of producing an estimate for a user story rather than producing code. • Once the team has a better understanding of the work involved, they can reconsider the estimate.
27
Product Burndown Chart
Product Burnup Chart
Helps the Product Owner make scope decisions for Product Release
28
Agile Development Practices
Test Driven Development • Write a failing automated test before changing any code • Shows if changes break existing behaviour • Only write enough code to pass test
29
Continuous Integration • Integrate and test changes after no more than a couple of hours development • Automatically build the whole system and run all of the tests in less than 10 minutes • Broken tests must be fixed acceptable before moving onto next task
Refactoring
Refactoring is changing the structure of code without changing behaviour • Decluttering the code helps make code easy to maintain • Prolongs the life of the code •
30
Further reading Ken Schwaber • “Agile Project Management with Scrum” Mike Cohn • “User Stories Applied” • “Agile Estimating and Planning” • “Succeeding with Agile” Esther Derby & Diana Larsen • “Agile Retrospectives” Rachel Davies & Liz Sedley • “Agile Coaching”
vies Rachel Da gilexp.com rachel@a .com/ w.agilexp w w / :/ p t ht
31