An Introduction to Agile and Scrum
By Alf Ogundeyin
© conchango 2006
www.conchango.com
Agenda
•
Introduction
•
The Agile Principles
•
Introduction to Scrum
•
Roles
•
Scrum Meetings
•
The Sprint
•
User Stories
•
Estimation and Planning
•
The Scrum Team
•
Defining Done
•
Questions and Answers
© conchango 2006
www.conchango.com
Introduction
By Alf Ogundeyin
© conchango 2006
www.conchango.com
Tarnished IT Projects
Traditional approaches to application development have resulted in high
failure rates
•
•
Traditional methodologies can prove bureaucratic and slow to deliver
The business can’t conceptualise all requirements in one go, let alone
document completely
Business is changing, the longer the project the greater the risk
Traditional methodologies focus on the process rather than empowering
people
Source: Forrester Research Inc
•
•
•
© conchango 2006
www.conchango.com
Wasted Effort
Features and Functions Used in a Typical System
Often or Always
Used: 20%
Sometimes
16%
Rarely
19%
Never
45%
Often
13%
Always
7%
Rarely or Never
Used: 64%
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
© conchango 2006
www.conchango.com
Origins of Waterfall
From: “Managing the
Development of Large
Software Systems” by
Winston W. Royce (1970)
System Requirements
Software Requirements
Analysis
Program Design
Coding
Testing
Operations
“I believe in this concept, but the implementation described above is risky and
invites failure.”
© conchango 2006
www.conchango.com
The Agile Principles
© conchango 2006
www.conchango.com
What is Agile?
Agile
Agile Software Development is an umbrella term for
approaches to software development that follow the principle
of ‘Inspect and Adapt’ and advocate team empowerment
• “Agile” approaches emerged concurrently from a number of
leading thinkers who were successfully delivering software
with “Lighter” methods in the 1990s
• Out of a meeting at Freebird in 2001 to find commonality
between their approaches came the Agile Manifesto
• Agile methods include DSDM, Extreme Programming (XP),
SCRUM, FDD and Crystal
© conchango 2006
www.conchango.com
The Agile Manifesto
While there is value in the items on the right, we value the
items on the left more.
Individuals & Interactions
Customer Collaboration
Responding to Change
Working Software
over
over
over
over
Processes & Tools
Contract Negotiation
Following a Plan
Comprehensive Documentation
“Inspect and Adapt”
© conchango 2006
www.conchango.com
Agile Manifesto Principles 1 of 2
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.
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 to- face conversation.
© conchango 2006
www.conchango.com
Agile Manifesto Principles 2 of 2
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.
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 selforganizing teams.
At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
© conchango 2006
www.conchango.com
Introduction to Scrum
© conchango 2006
www.conchango.com
Scrum Timeline
1986 Harvard Business Review article
1996 SCRUM techniques published at conferences
2001 Agile Manifesto
2001 Agile Software Development with SCRUM book
2003 SCRUM certification
2004 Agile Project Management with SCRUM book
2004 SCRUM Alliance
© conchango 2006
www.conchango.com
Scrum Overview
Scrum provides the project delivery approach:
• Improve communications and maximises co-operation
• Incremental & Iterative – 2 to 4 week iterations delivering production
quality code
• Regular input and feedback from users/business
• Continual focus on highest priority business requirements
• Analysis, design, development, testing performed throughout
iteration
• Self organising cross-functional teams - including the customer
• Minimal creation of “Interim” documents - focus on working software
• Inspect & Adapt at the end of every iteration
© conchango 2006
www.conchango.com
Scrum on a Slide
© conchango 2006
www.conchango.com
Maintain Intensity
Waterfall
Scrums
Months
© Mike Cohn, Mountain Goat Software
© conchango 2006
www.conchango.com
Scrum Rhythm
Product
Backlog
Sprint
Planning
Sprint
Daily Scrums
Sprint
Sprint
Review Retrospective
Potentially
Shippable
Code
Iterate
© conchango 2006
www.conchango.com
The Product Backlog and the
Product Owner
© conchango 2006
www.conchango.com
Product Backlog
•
Prioritised list of product or project requirements
• Expressed in business language, ideally User Stories
• Not a detailed breakdown of requirement, can be 1 sentence
• Prioritised, by business value, at beginning of each Sprint
•
Anyone can contribute items for the backlog
• But they will be prioritised along with all other requirements
•
One person (Product Owner) is responsible for prioritisation
and making sure requirements are well formed
•
High level estimates
• Size only - can use Story Points
• Planning Poker
© conchango 2006
www.conchango.com
Exercise
Role of the Product Owner
Pair with someone, turn to each other and discuss what are the
responsibilities of the Product Owner
You have 5 minutes
© conchango 2006
www.conchango.com
Product Owner
•
•
•
•
Voice of the customer
Manages the Vision
Defines customer value-added and the
key features of the product
Continuously refines requirements
•
Sets development schedule by
prioritising the Backlog
•
Works with others to estimate items on
Product Backlog
•
Responsible for the project success and
ROI
Decides on release date, content and
budget
•
© conchango 2006
www.conchango.com
Product Owner
•
•
•
•
•
•
•
Creates and updates the release plan
and reports
Manages stakeholders and interests
proactively
Selects the Sprint Goal, steers and
guides the work, answers questions on a
daily basis
Attends all Scrum meetings
Accepts or rejects work results in the
Sprint Review meeting
Available to the Team for clarifications
during the Sprint
Takes advice from the Team on Product
Backlog dependencies
© conchango 2006
www.conchango.com
Characteristics of a Product Owner
•
•
•
•
•
•
•
Understands customer needs
thoroughly
Able to create and communicate the
product vision
Empowered to make decisions, is
decisive and knows when to say no
Has good working relationships with
the stakeholders
Has good working relationships with
the team
Understands value creation
Leader and facilitator
Product Owner = Superman?
© conchango 2006
www.conchango.com
The Scrum Master and the Team
© conchango 2006
www.conchango.com
Scrum Master
•
Responsible for establishing SCRUM
practices and rules, ensures the process
is followed
•
Shields the team from distractions and
helps remove obstacles.
•
Ensures that the team is fully functional,
productive and improves quality
•
Enables close cooperation across all roles
and functions and removes barriers
•
Educates everyone on the Scrum process
© conchango 2006
www.conchango.com
The Sheep Dog
•
An important part of the Scrum Masters role is to ring fence the
team so that they can concentrate on their Sprint Backlog
•
•
•
The Scrum Master is inward facing
•
•
•
•
Disruptive outside influences
Irrelevant meetings
Morale
Remove impediments
Environment
The Scrum Master is outward facing
•
•
•
Educating the organisation
Removing organisational impediments
Managing external communications
© conchango 2006
www.conchango.com
Chickens and Pigs
Members of Scrum Team are known as Pigs
because they are committed to delivering
Sprint Goal.
People who are involved but not
dedicated to the project are known as
Chickens. They can attend Scrum
meetings but only as observers.
© conchango 2006
www.conchango.com
Scrum Team
•
Responsible for committing to work
•
Cross-functional
•
Self-organizing
•
Authority to do whatever is needed to meet
commitment
•
Ideal team Size 5 – 9
•
Demonstrates iteration output to Product
Owner, users and stakeholders
© conchango 2006
www.conchango.com
Scrum Meetings
© conchango 2006
www.conchango.com
ScrumMaster
Scrum Team
Product Owner
Sprint Planning Meeting
Input
Updated Product
Backlog
Sprint Goal
Team Capacity
Business
Conditions
Definition of
Done
Input
Sprint Planning
Meeting
Output
Sprint Backlog
© conchango 2006
www.conchango.com
Sprint Planning
Determine the work that can be completed next Sprint
•
Two parts to Planning:
•
Choose Goal: the Team and the Product Owner
collaborate to decide how much of the prioritised
backlog can be turned into potentially shippable
functionality
•
Create Sprint Backlog: the Team defines the tasks
required to build that functionality during the next
Sprint, including estimates to achieve the Definition
of Done
© conchango 2006
www.conchango.com
Sprint Planning
•
Things to note:
• Make sure the Backlog is prioritised beforehand
• Not only the highest priority items have to be chosen!
• Use previous Sprint results to inform estimation
• Take cards from previous Sprint with you
• If planning is taking too long don’t rush it – schedule a session for the
next day
• Success or failure of the entire Sprint relies on this session
• Don’t underestimate how long estimation takes (!)
• Get input from content leads and architects, and data and migration
• Make a nice organised wall-chart to begin the next Sprint with
© conchango 2006
www.conchango.com
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 is in your way?
•
For synchronization not problem solving!
•
Not a Scrum master status meeting,
commitments between peers
© conchango 2006
www.conchango.com
The Sprint Backlog
Story
Not Started
Done
In Progress
As a online customer,
I need to be able to Login
So that I can securely
Access my account details
8
As a online customer,
I need the ability to change
my password, so that I can
be confident my account ....
5
As a site administrator,
I need to be able to disable
accounts so that I can stop
access on the clients request
3
As a prospective customer,
I want to request an account
So that I can become a client
And manage my accounts
13
© conchango 2006
www.conchango.com
Sprint Review
Demonstrate what was achieved in the Sprint and collect feedback
•
The Team presents, not the Scrum Master
• Typically a demo of new features
• or underlying architecture etc
•
Informal
• No more than 2 hours prep
• Avoid slides
•
Whole team participates
•
Invite anyone and everyone
© conchango 2006
www.conchango.com
Sprint Review
Sprint Review Agenda:
1. Intro – what the purpose of the meeting is and the agenda
2. Describe the Sprint Goal
3. Point out which Product Backlog Items were committed to
4. Explain which ones were completed
5. Have a look at key moments on the Sprint Burndown – honestly
6. Demonstrate completed features by product backlog item and answer questions
7. Check the Definition of Done for each of the product backlog items
8. Debrief: Poll each stakeholder one by one for their views
© conchango 2006
www.conchango.com
Sprint Review
Possible results of the Sprint Review
• Put unfinished features back onto the Product Backlog
• as well-worded product backlog items
• Remove items that were unexpectedly completed
• Adjust the team
• Reprioritise the Product Backlog
• to take advantage of completed work
• Release!
• Stop the project
• Add teams to speed up the project
© conchango 2006
www.conchango.com
Sprint Retrospective
Take a look at what is and what isn’t working
•
Team and Scrum Master participate
• Product Owner also allowed if involved during Sprint
•
Can get emotional
•
Exercise-driven
•
Drive out actions, tasks for next backlog
•
Or add to wallchart in team area
© conchango 2006
www.conchango.com
Sprint Retrospective
•
Agenda:
•
Set the Stage
10-15%
•
Gather Data
15-20%
•
Generate Insight
15-20%
•
Decide What To Do
20-25%
•
Close
10-15%
•
(Breaks
10-15%)
N.B. These timings include explanation and shuffle time
© conchango 2006
www.conchango.com
The Sprint
© conchango 2006
www.conchango.com
Sprint
•
A fixed period to accomplish the
Sprint Goal, which is agreed
between the team and the Product
Owner
•
Sprint lengths usually range from
2 to 4 weeks
•
Once a Sprint has started only the
Scrum Team can add or remove
items in Sprint Backlog
•
Abnormal termination of Sprint is
called for when the Sprint Goal no
longer makes sense – extreme
circumstances only
© conchango 2006
www.conchango.com
Sprint Length
•
Factors to consider
•
•
•
•
•
•
•
•
How long the business can go without changing its mind
Pick a length that spreads intensity appropriately
Ability to reliably predict effort on tasks several weeks out
Length of the overall release
Amount of uncertainty on the project
The overhead of iterating
Experience and cohesion of the team
You cannot change your Sprint length
•
•
•
•
Except e.g. Release Sprint
Sustainable working
Cadence
Predictability
© conchango 2006
www.conchango.com
Sprint Backlog Contents
•
The list emerges during Sprint planning
•
The Sprint backlog is a list of tasks that defines a Team's work for a
Sprint
•
The tasks are what the Team has defined as being required to turn
committed Product Backlog items into system functionality
• Task size: 1-16 hours
• Estimated as a team
•
The Sprint Backlog should be updated daily
• After the Scrum Meeting works well
• Or when a task is completed
•
Anything that gets done should be visible on the backlog
• Emergent tasks are added by the team to the backlog throughout the
Sprint
© conchango 2006
www.conchango.com
Sprint 0 – Project Initiation
Just enough to get the team up and running
•
Amount of time and effort will vary from project to project
•
•
•
Architectural complexity
Predictability and commitment required for functionality and delivery timescale
Potential Sprint 0 Tasks/Deliverables
•
•
•
•
•
•
•
Business Case and funding
Vision
Initial Product Backlog
Initial Release plan
Stakeholder buy in
Assemble team
Logistics
© conchango 2006
www.conchango.com
User Stories
© conchango 2006
www.conchango.com
User Stories
•
User Stories are an established method of clear communication
between the team and the business
© conchango 2006
www.conchango.com
What makes a good story?
•
INVEST acronym can be found in Mike Cohn’s “User Stories
Applied”
© conchango 2006
www.conchango.com
Exercise – Backlog Shaping Workshop
• Split into teams of about 5 people
• You will use as an example a project that one of you is on, that
person becomes the Product Owner
• Elect one person as a Scrum Master, whoever you feel is most
suitable
• The rest of you are the team
Create an initial product backlog for the project you have selected
• Try to identify the most important requirements for the project
• Think how they can be broken up to give slice’s of business value
• Try to write the them as user stories
• Continually prioritise
© conchango 2006
www.conchango.com
Estimation and Planning Poker
© conchango 2006
www.conchango.com
Estimating Using Story Points
This takes the relative sizing of each item into
account
• Pick a reference task and estimate that
• Then estimate the sizes of all the other tasks in
comparison
• E.g. if story 1 has been given a size of 2
and story 2 feels a bit bigger it will be
given a 3
© conchango 2006
www.conchango.com
Exercise – Planning Poker
• For our prioritised Product Backlog that we produced in the previous
exercise we are now going to supply some estimates, so back in
your teams
© conchango 2006
www.conchango.com
The Scrum Team
© conchango 2006
www.conchango.com
Team Responsibilities
•
Working in a Scrum team is slightly different than a traditional team
•
•
•
•
•
•
You are now committing to the iteration target, as a team
You now have the authority to do anything you need to hit your target
You are working closely with people with other skillsets
The way you communicate inside and outside the team has changed
You are now being allowed to work rather than being instructed to work
This means you have a slightly different role
•
•
•
•
TEAM focus, not individual
Much more face-to-face communication
You are trusted and empowered to solve problems
Your skills are used in a different way…
© conchango 2006
www.conchango.com
Scrum Team Members
•
A Scrum team acts as a self-organising unit with the right to do anything
they need to in order to hit the Sprint target
•
They manage their own interactions with users and stakeholders, they
promote and stick to the Scrum rules and they focus on one thing: delivery
© conchango 2006
www.conchango.com
As a Scrum Team Member...
•
Communication
•
•
•
•
•
•
Ownership/Responsibility
•
•
•
•
Values face to face communication
Manage environment to promote communication and teamwork
Takes part in the daily stand-up meeting
Brings challenges into the open, not sweeping them under the carpet
Identifies impediments and shares them with the team
Takes ownership of all the work the team commits to
Follows up actions from the team retrospectives, looks to continually improve
Meets with Product Owner, users and stakeholders frequently to clarify tasks
and monitor progress
Teamwork
•
•
•
•
•
Solves rather than blames
Asks for assistance or guidance when required
Is aware of what the other team members are doing
Helps other team members, professionally and personally
You have fun delivering working software
© conchango 2006
www.conchango.com
Business Analysis in Scrum - Overview
•
Scrum analysis is a highly evolutionary and collaborative process
•
•
In Scrum, analysis is not a phase of the project nor a task in a project plan
Actively working together with developers and project stakeholders
on a just-in-time basis to:
•
•
•
•
understand the domain
identify what needs to be built
to estimate that functionality
to prioritize the functionality
and in the process optionally producing
artefacts that are just barely good enough
© conchango 2006
www.conchango.com
A Business Analyst in Scrum…
•
Collaboration/Communication
• Primary goal is to identify and understand what your project
stakeholders needs, and communicate this to everyone involved
• Promotes understanding of, and agreement with, the overall vision of
the project
• Communication rich: prefers conversations to documentation and email
• Works as closely as possible with Product Owner and stakeholders
• Helps to transfer skills rather than specialise in analysis
•
Working methods
• Works in an iterative i.e. cyclical fashion: design and analysis rely on
each other
• Works in an incremental fashion: systems don’t have to be built all in
one go
• May take the role of stakeholder if they are unavailable
• May work a sprint ahead of the team to make sure backlog items are
just good enough
© conchango 2006
www.conchango.com
Testers in Scrum - Overview
•
A Scrum tester takes more of a quality assurance role than that of a
basic tester
•
They collaborate with the analysts and developers to break down
tasks to achieve the definition of ‘Done’
•
They start work at the very beginning
of a Sprint, developing test strategies and
automated unit tests etc rather than waiting
for code to be developed
•
They act as the conscience of the team!
© conchango 2006
www.conchango.com
A Tester in Scrum…
•
Quality
•
•
•
•
•
•
Collaboration
•
•
•
•
Helps the business owner to assess the level of quality in a delivered release
Cares about getting work done right first time
Encourages team members to follow the principles of quality
Uses more judgement, the application of more expertise about what's good and
what's not, has confidence in own knowledge of what good looks like
Owns all the items in the Definition of Done
Works closely with business users to gain their input into their understanding of
how the system should function as early as possible
Collaborates with team members rather than working in isolation
Seeks product information individually through testing, and work with other team
members to figure out what to test, rather than testing from requirements
Working Methods
•
•
•
•
•
•
Tests the software continuously throughout its development
Tests within each iteration, rather than at the end of a development lifecycle
Writes test scripts at the same time or before the developer is coding
Works towards the notion that the test scripts document the system functionality
Decides what to test when a product is still unfinished
Works with other teams to maximise efficiency and effectiveness of testing
© conchango 2006
www.conchango.com
Developers in Scrum - Overview
•
A Scrum developer is known within the organisation as:
•
•
•
Trusted
Empowered
An active team member
rather than a machine which processes requirements handed to
them by analysts
•
The Scrum developer collaborates with
architects, analysts and testers within their
team to build production-quality code,
preferring conversations over documents
to clarify requirements
© conchango 2006
www.conchango.com
A Developer in Scrum…
•
Responsible and Empowered
• Participates in planning the next Sprint, advising the team on which
features can realistically be committed to
• Advises on estimation of the full set of tasks required to get those
features to ‘Done’ i.e. production-quality
• Takes responsibility for the outcomes of all work done by the whole
team, not just their own tasks
• Takes an active role in Sprint Review sessions, presenting clearly to
large groups of people if necessary
• Participates confidently in Sprint Retrospective sessions to improve how
the team works in future Sprints
•
Collaborates
• Works closely with the Product Owner and stakeholders to ensure the
features built satisfy their current needs
• Shares knowledge between team members, especially for any tasks
that affects the whole team, e.g. deployments
© conchango 2006
www.conchango.com
Others in Scrum…
Architects, User Experience, Authors, Marketing, DBA’s, and other
domain experts often work across multiple Scrum Teams, but will
sometimes be part of the team
•
Need to agree how other domain experts will interact with the team
before the start of each sprint
•
Often architects and user experience designers work just ahead of
the team
• Ideally ‘just ahead’ means that the work is done as part of the team in a
sprint
• For new Scrum teams ‘just ahead’ will probably mean a sprint ahead to
make sure product backlog items are just good enough in order for the
team to start
© conchango 2006
www.conchango.com
Defining Done
© conchango 2006
www.conchango.com
Exercise – Defining Done
Pair with someone, turn to each other and share short answers to the following
for 5 minutes:
•
What does “done” mean in your current project?
•
What issues do you see with this definition of done?
•
How would you address them?
•
What engineering problems do you see with this approach?
•
How would you rectify them?
© conchango 2006
www.conchango.com
Definition of Done
Some example of items that may appear on a teams definition of DONE:
•
•
•
•
•
•
•
•
•
Coding standards followed and checked.
No outstanding bugs
Evidence of testing (Unit, System, Regression, Platform(s), Automation,
Usability, Confirmation)
Documentation (User, Technical)
Update component roadmap
Peer reviewed (pair programming counts as peer review)
90 percent code coverage achieved
Build and package changes are communicated to build master (i.e.
introducing a new file or something) and build is deployed
Task list hours are updated and task is closed out
© conchango 2006
www.conchango.com
Scrum Top 10 Tips
© conchango 2006
www.conchango.com
1 – Always Deliver
•
Focus on delivering functionality that has
business value
•
Always deliver functionality you can
demonstrate at the end of the sprint
•
Always fix the sprint length at the
beginning of the sprint NEVER extend
the sprint end date
© conchango 2006
www.conchango.com
1 – Always deliver no matter how small
•
Login screen
•
•
•
•
Key Principle
Master Pages
Exception handling
framework
Initial database schema
Data Access blocks
Each Sprint must deliver business value
Business
Functionality
Functionality
Architecture
building blocks
Sprints
© conchango 2006
www.conchango.com
2 – Deliver Slices of Business Value
•
In order to deliver functionality of value to the business in a short
amount of time software needs to be delivered incrementally
•
•
•
•
•
•
Tracer Bullets
Layer functionality, simple, then build on it
Functionality should cut across all layers of the architecture
Integrate often to drive out incompatibilities
Continually review priority of business requirements
•
User group and/or representative relationship is key
•
At the beginning of the project
•
After every iteration
Ensure that “Technical” features/architecture directly support priority
business features
•
Use business language to show the benefit of “Technical” work
© conchango 2006
www.conchango.com
3 – Done
•
Planning
The sprint has strict, well defined boundaries
•
•
Analysis
Entry Criteria
Exit Criteria
Product backlog item
Definition of done
Design
Code
Unit Test
This is a minimal
baseline, but extend
done as far as
possible,
System Tested
UAT Test
Performance
UAT Accepted
Pilot
Live
© conchango 2006
www.conchango.com
4 – Quality is King
Engineering Practices
Those practices at the top
of the pyramid represent the
pinnacle of development
engineering practices,
whereas those at the
bottom represent the
foundations without which
those practices at the top
would not usually take
place.
Find bugs quickly
Fix them as soon as you can
Don’t get into “Bug Debt”
Otherwise you’ll need a
“Bug fix” iteration
© conchango 2006
www.conchango.com
5 – Reciprocal Commitments
•
A fundamental trust building framework
•
The team commits to deliver functionality within the sprint
•
The stakeholders commit to not changing the work the team
committed to within the sprint
•
DO NOT ever change the work committed to in the sprint.
•
•
This breaks the established trust.
The next sprint the order of work can be changed
© conchango 2006
www.conchango.com
6 – Release Value Early
•
Shorter release cycles provide many benefits:
• Realises the value in the code sooner
• Reduced gap between specification and production - increases
likelihood of solution relevancy
• Reduces risk
• Production feedback
•
Need to work with the business to be pragmatic
•
•
•
•
Minimum set of functionality that provides value
Legacy of sign-off – specify everything just in case!
Release in a single region or market or customer
Competition is a good motivator: Region with the smallest set of
functionality can go live first!
© conchango 2006
www.conchango.com
7 - Get User Group Feedback
Get regular user feedback on the functionality delivered in each
iteration
•
•
•
•
•
Usually harder than it should be
User review presentation at the end of each iteration
Breakout groups to work through the functionality
Provide access to test previous iteration’s delivery
Structure user testing and feedback by asking specific questions
If feedback is not successfully gathered the system is unlikely to deliver
what the users want or need
© conchango 2006
www.conchango.com
8 – Prioritise Work
In a sprint always work on the highest priority items as a team
• Avoid cherry picking tasks which are easy to complete
• Work down the sprint backlog as a team from the top, to ensure the
highest priority items get ‘Done’
© conchango 2006
www.conchango.com
Review Product
Backlog & Define
Sprint Backlog
Sprint 3
UAT Test
Deploy
Build-Test
Design
Analyse
9 – Don’t do “Mini-waterfalls”
User Review
& Feedback
© conchango 2006
www.conchango.com
9 – Don’t do “Mini-waterfalls”
•
Key indicators
• Too much documentation
• Time taken from defining a feature to receiving it into test (can also
indicate that features are too big)
• Developers and/or Testers bored twiddling thumbs for first ½ of iteration
• Runaway defect count at the end of an iteration
• Large quantity of untested code at the end of the iteration
• Failure to deliver production quality code
© conchango 2006
www.conchango.com
10 - Evolve Architecture
•
Delay design decisions until last responsible moment
• Maximises information before commitment
• Minimises opportunity of change before software is delivered
• But don’t procrastinate!
•
Do ‘enough’ architecture
•
•
•
•
•
•
Varies per project
Identify the areas of high cost of change
Enough to start developing
Keep doing it until the project ends
Architecture will be more flexible
Keep documentation light
• Loss of fidelity in translation to document form
• Resistance to change once its “on paper”
• Diagram the essentials but don’t be precious as they will need to change
© conchango 2006
www.conchango.com
Agile Resources
•
Books
•
•
•
•
•
“Implementing Lean Software Development: From Concept to Cash” by Mary
Poppendieck and Tom Poppendieck
“Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle
“Agile Estimating and Planning” by Mike Cohn
“Agile Retrospectives” by Esther Derby and Diana Larsen
Web resources
•
•
•
•
www.agilealliance.org
www.controlchaos.com
www.scrumalliance.org
www.scrumforteamsystem.com (by Conchango)
© conchango 2006
www.conchango.com
Questions?
mark.summers@conchango.com
http://blogs.conchango.com
www.scrum-master.com
© conchango 2006
www.conchango.com
Scrum Smells
© conchango 2006
www.conchango.com
Scrum Smells – Bug Debt
•
Symptoms
•
•
•
•
•
•
Discussion
•
•
•
Teams worry about how to manage issues that they find in testing
Outstanding ‘known’ bugs at the end of the sprint, which mean the stories fail
their acceptance tests
Testing only happens at the end of a sprint
The team have a high number of bugs at any one time
System crashes at Sprint Review
System with a large bug debt is unstable and therefore it is difficult to add new
features
People waste time managing the backlog of bugs
Actions
•
•
Fix bugs as early as possible
Stop the line culture, when a problem is found the whole line stops to investigate
• Fix the problem
• Learn from the problem and make sure it never happens again
© conchango 2006
www.conchango.com
Scrum Smells – Loss of Rhythm
•
Symptoms
•
•
•
•
•
•
Discussion
•
•
Daily Scrum ritual is inconsistent or is drifting (subtly changing)
Daily Scrums are skipped or meeting times vary
Sprint durations are inconsistent or change arbitrarily mid-sprint
Sprint planning ritual is inconsistent or drifts
Sprint planning meetings are skipped
Rhythm helps make routine things routine
Actions
•
•
•
•
•
Scrum Master enforces the process
Clarify expectations
Conduct training
Be consistent
Resort to mommy rules
© conchango 2006
www.conchango.com
Scrum Smells – Poor Backlog Management
•
Symptoms
•
•
•
•
•
•
•
•
Discussion
•
•
A Product Backlog doesn’t exist
An unmanageably large number of Product Backlog Items exist
All the Product Backlog is fully defined
The top of the Product Backlog is not good enough for items to be accepted into
the next sprint
The Product Backlog is not driven by someone who understands and can speak
for the customer’s needs
The Product Backlog is not prioritized
Product Backlog Items are not estimated by the team
The Product Backlog is what the business uses to drive the development
Actions
•
•
•
Scrum Masters responsibility to enforce the process
Conduct training
Mommy rules
© conchango 2006
www.conchango.com
Scrum Smells – Missing Pigs
•
Symptoms
•
•
•
Team members failing to attend Daily Stand-up meetings
Even when developers attend Scrums reliably, they can be absent in other ways:
• Perfunctory reports
• Withdrawal or non-participation
• Disruptive behavior
Discussion
•
Scrums are about the team achieving results and synchronising towards a
common goal
•
Actions for:
•
Circumstantial Problems
•
•
•
•
•
•
Establish rhythm
Role model
Change meeting time and location
Explanation, persuasion and negotiation
Embrace technology
Reorganise team
•
Behavioral Problems
•
•
•
•
•
•
Act from knowledge
Clarify expectations
Individual accommodation
Shuffle the team
Manage the personality
Be a heavy
© conchango 2006
www.conchango.com
Scrum Smells – Talking Chickens
•
Symptoms
•
•
•
•
•
•
Discussion
•
•
External stakeholders talk in the daily Scrums
Features are selected or priorities switched outside of sprint planning meetings
The team cannot make purely technical decisions without an outsider’s blessing
Status reports are required outside sprint planning meetings
Team managers or executives who sponsor the team receive requests to
influence the team
There is a balance between the business being involved to answer questions
and the business trying to influence the team during the sprint
Actions
•
•
•
•
•
•
Be consistent
Conduct training
Have a contract on how people work together
Move chickens away from the pig-pen
Bring the chicken into the Scrum
Remember you’re a sheepdog!
© conchango 2006
www.conchango.com
Scrum Smells – Other Smells
•
Disengaged Product Owner
•
•
Missing Domain Experts
•
•
Work is assigned by the Scrum Master rather than signed up for by developers
Specialized Job Roles
•
•
The wild fluctuations shown on a team’s initial sprint burn-down charts continue
to be seen in much later sprints.
Scrum Master Assigns Work
•
•
The right people are not available to the team at the right time
Persistent Signatures
•
•
The Product Owner is not available to answer questions and/or the Product
Backlog is not good enough for the team to start work
A project team has highly specialized job roles or descriptions such as Architect,
Designer, DBA, or Tester
The Daily Scrum is For the Scrum Master
•
The Daily Scrum feels like it is a status update from the team members to the
Scrum Master
© conchango 2006
www.conchango.com
Quality
© conchango 2006
www.conchango.com
Quality is King
Engineering Practices
Those practices at the top
of the pyramid represent the
pinnacle of development
engineering practices,
whereas those at the
bottom represent the
foundations without which
those practices at the top
would not usually take
place.
Find bugs quickly
Fix them as soon as you can
Don’t get into “Bug Debt”
Otherwise you’ll need a
“Bug fix” iteration
© conchango 2006
www.conchango.com
Continuous Integration
“Continuous Integration is a software development
practice where members of a team integrate their work
frequently, usually each person integrates at least daily
- leading to multiple integrations per day. Each integration
is verified by an automated build (including test) to detect
integration errors as quickly as possible. Many teams find
that this approach leads to significantly reduced integration
problems and allows a team to develop cohesive software
more rapidly.”
--Martin Fowler, May 2006
(http://www.martinfowler.com/articles/continuousIntegration.html).
© conchango 2006
www.conchango.com
Practices of Continuous Integration
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Maintain a single source repository
Automate the build
Make your build self-testing
Everyone commits at least every day
Every commit should build the mainline on an integration machine
Keep the build fast
Test in a clone of the production environment
Make it easy for anyone to get the latest executable
Everyone can see what’s happening
Automate deployment
Teams have found that they get the best quality results when they combine
Continuous Integration with Test Driven Development (TDD)
© conchango 2006
www.conchango.com
Build Quality In
Manual: As
Early as
Possible
Business Facing
Acceptance Tests
Business Intent
(Design of the Product)
Unit Tests
Developer Intent
(Design of the Code)
Usability Testing
Exploratory Testing
Production Testing
Load Testing, Production
Resilience, Security Leaks, Etc,
Technology Facing
From Brian Marick
© conchango 2006
www.conchango.com
Nested Synchronisation
 Every few minutes
•
•
Build and run unit tests
STOP if the tests don’t pass
 Every day
•
•
Run acceptance tests
STOP if the tests don’t pass
 Every week
•
•
Run production tests
STOP if the tests don’t pass
 Every iteration
•
Deployment-ready code
Every Release:
Deployed and Running in Production
Every Iteration:
Deployment Ready Code
Weekly Integration
Test
Daily
Acceptance Test
 Every release
•
Deploy and run in production
10
minute
build
test
From Mary Poppendieck
© conchango 2006
www.conchango.com
Refactoring
Continuous Improvement of the Code-Base
•
Just-in-time NOT Just-in-Case
• Start with what you know is needed now
• Add features only when you know you need them
• Refactor: Simplify the code based on what you know now
•
Maintain a Simple, Clean Design
• No features ahead of their time
• No features after their time
• No Repetition
•
Safety First!
• You can’t refactor without test harnesses
© conchango 2006
www.conchango.com