Transcript Slide 1

Scrum is
Honesty
Visibility
Common Sense
Jens Ostergaard
www.houseofscrum.com
www.scrumtrain.com
1
Waterfall and opacity
• Give me all requirements, otherwise it will
cost you!
www.scrumtrain.com
2
Feature Use – Keep It Lean
Often or Always
Used: 20%
Rarely
19%
Sometimes
16%
Never
45%
Often
13%
Always
7%
Rarely or Never
Used: 64%
Standish Group study reported at XP2002 by Jim Johnson, Chairman
www.scrumtrain.com
3
Certified Scrum Product Owner
4
• Emergence
– Impossible to know all requirements in advance
– ”Thinking harder” and ”thinking longer” can
uncover some requirements, but
EVERY PROJECT HAS SOME
EMERGENT REQUIREMENTS
– Emergent requirements are those that we
cannot identify in advance
www.scrumtrain.com
5
• So what do we do
– We talk more, write less
But write if you have to
– Show software to users
– Acknowledge that requirements emerge
And all that this implies
– Progressively refine our understanding of the
product
– Express this progressive refinement in the
product backlog
www.scrumtrain.com
6
Defined Processes
• Command and Control for simple projects
•
Enforce that what happens is the same as what is planned
•
Use change control to manage change
www.scrumtrain.com
7
Empirical Processes
• When you can’t define things enough so that they
run unattended and produce repeatable, acceptable
quality output;
•
Empirical models are used when the activities are
not predictable, are non-linear, and are too complex
to define in repeatable detail; and
•
Control is through inspection and adaptation.
www.scrumtrain.com
8
Start with
Plan and all
requirements
Start with
Goals and
some high
priority
requirements
Predictive
End with all requirements
completed
Scrum Empirical
www.scrumtrain.com
End with Goals
met
9
Time boxes, Roles, Rules
www.scrumtrain.com
10
www.scrumtrain.com
11
www.scrumtrain.com
12
Risk
Waterfall
Define
Sign-off
Design
False security
Sign-off
Develop
More uncertainty
Deploy
Sign-off
Uncertainty
Suprise!
Timeboxed
Agile
Prioriterer
kravene –
designe,
utvikle, test
Uncertainty
Feedback
Prioriterer
kravene –
designe,
utvikle, test
Feedback
Prioriterer
kravene –
designe,
utvikle, test
Safer
www.scrumtrain.com
Feedback
Safe
Prioriterer
kravene –
designe,
utvikle, test

13
Emergency Procedures
1. Do something different (be creative)
2. Get help from someone outside the team
3. Decrease Scope
4. Abort Sprint
www.scrumtrain.com
14
Change!!!
1. Product Owner is used to “throwing the project
over the wall” and holding
engineering/development responsible for meeting
needs. Scrum puts this responsibility back on the
Product Owner through the inspect and adapt
and the Sprint Review.
2. Developers are not used to inspecting each
other’s progress daily to adapt their work to
optimize the chances of delivering (an increment)
every Sprint.
www.scrumtrain.com
15
► Defines the features of the product
► Manages project features and release to optimize return on
Product Owner
investment (ROI)
► Prioritizes features according to market value
► Inspects increment and makes adaptations to project
► Can change features and priority every sprint
► Communicates project progress and status
► Cross-functional, seven plus/minus two members
► Commits / Forecasts to what it feels it can accomplish
► Has authority to do everything within existing standards and
Development
Team
guidelines to reach the iteration goal
► Manages itself and its work
► Collaborates with Product Owner to optimize value
► Demos work results to the Product Owner
►
more that
thanthe
9 people
► No
Ensures
team is fully functional, productive and improves
Scrum Master
quality
► Enables close cooperation across all roles and functions and removes
barriers
► Shields the team from external interferences
► Ensures that the process is followed
► Teaches Product Owner and Development Team how to fulfill their
roles
16
Copyright 1993-2010, ADM, All Rights Reserved v1.3
What Is Being Made Visible?
• When the Team says “done,” what does that mean?
• Maintaining trust with Product Owner by not “hiding”
undone work.
• Functionality has been code reviewed, functionality
has been integrated and built, acceptance tests have
been run, and documentation has been created.
• QA environment for this has automated acceptance
testing tools.
www.scrumtrain.com
17
User Story Template
As a/an <type of user>,
I want <some goal>
so that <some reason>
The “so that” line is generally considered
optional, but used as a default
www.scrumtrain.com
18
Day in Life of ScrumMaster
•
Ensure everyone is doing what they have agreed to do
•
Determine where Scrum is compared to where it could be and update your own
Scrum impediment backlog
•
A dead (fired) ScrumMaster is a useless ScrumMaster and,
•
Use all of your senses, including common sense, and remember that you have no
authority.
www.scrumtrain.com
19
Product Owner
•
•
•
•
•
•
Develops and maintains the Product
Backlog;
Orders the Product Backlog;
Empowered to make decisions for all
customers and users;
Attends Sprint planning meeting and
Sprint review meeting;
Presents and explains Product Backlog to
team; and,
Manages the vision, ROI, and releases.
www.scrumtrain.com
20
Roles – Dev Teams
• Self-organizing;
• Three to nine;
• Cross-functional with no roles;
• Has the business and technical domain skills to
build an increment of functionality
• Commits to sprint goal / forecast work;
• Not for everyone;
• Full autonomy and authority during a Sprint.
•Ask forgiveness, not permission
www.scrumtrain.com
21
Environment
•
•
Everyone in same location
Open space without barriers
www.scrumtrain.com
22
www.scrumtrain.com
23
Sprint Planning
•
1 hour per part per week
•
1st – for team to select Product Backlog and sets goal with Product Owner
•
2nd - for team to define Sprint Backlog to build functionality
•
Anyone can attend, but primary conversation and work is between team and
Product Owner
www.scrumtrain.com
24
Daily Scrums
•
•
•
•
Daily 15 minute meeting
Same place and time every day
Meeting room
Three questions
- What have you done since last meeting?
- What will you do before next meeting?
- What is in your way?
www.scrumtrain.com
25
”If I had known how the questions from the Daily Scrum are used today I
would have framed them differently, but it is to late to change it now”
Jeff Sutherland – April 2012
•
•
•
Yesterday I helped the team by………
Today I will help the team by……..
I am blocked from helping the team by……..
www.scrumtrain.com
26
www.scrumtrain.com
27
Sprint Review includes at least the following 1
•
•
•
The Product Owner identifies what has been done
and what hasn’t been done.
The Team discusses what went well during the Sprint
and what problems it ran into, and how it solved these
problems.
The Team then demonstrates the work that is done
and answers questions.
www.scrumtrain.com
28
Sprint Review includes at least the following 2
•
•
The Product Owner then discusses the Product
Backlog as it stands. He or she projects likely
completion dates with various velocity assumptions.
The entire group then collaborates about what it has
seen and what this means regarding what to do next.
The Sprint Review provides valuable input to
subsequent Sprint Planning meeting.
www.scrumtrain.com
29
Sprint Retrospective
• Process improvement at end of every Sprint
• Facilitated by ScrumMaster (another Scrum Master)
• What went well, what could be improved.
• “Project Retrospectives,” Norman Kerth
• “Agile Retrospectives”, Esther Derby – Diane Larsen
www.scrumtrain.com
30
The normal situation
• Client send out tender to 3+ potential suppliers.
Everything is equally important. Total of let’s say 5 M$.
• All suppliers place a bid of around 5 M$.
• One chosen and contract signed.
• Change requests start coming in from day one. All
changes are expensive. Project end up with a total of
let’s say 8 M$.
• After acceptance there still are more work to do because
of bugs and that some functionality are not really
completed or useful.
• Project cost end up on 10 M$ - delivered late.
www.scrumtrain.com
31
The alternative
• Supplier guarantee functionality of high quality (Done, done, done)
• Changes are included with these rules
– Changes in priorities are free if total contract work is not
changed
– New features may be added for free in Product Backlog if
features of equal work are removed from Product Backlog.
• Customer may abort contract at any time. Supplier gets a
percentage of what’s left of contract.
• Requirement on Customer:
– Preferable act as Product Owner
– Functionality is prioritized by ROI
– Customer follows the project closely and give feedback
www.scrumtrain.com
32
Return of Investment
Change for free!
Need this one too!
Dump this one
20%
www.scrumtrain.com
Time
33
Return of Investment
Money for Nothing!
Supplier
gets 20%
Abort!
40%
Courtesy www.scrumtrain.com
of Geir Amsjø
Time
34
Basic truths about team motivation
1.
People are most productive when they manage themselves;
2.
People take their commitment more seriously than other people’s
commitment for them;
3.
People always do the best they can; and,
4.
Under pressure to “work harder,” developers automatically and
increasingly reduce quality.
www.scrumtrain.com
35
Basic truths about team performance
1.
Teams and people do their best work when they aren’t interrupted;
2.
Teams improve most when they solve their own problems; and,
3.
Broad-band, face-to-face communications is the most productive way for
teams to work together.
www.scrumtrain.com
36
Basic truths about team composition
1.
Teams are more productive than the same number of individuals;
2.
The optimum size team is around five people, and no more than nine;
3.
Products are more robust when a team has all of the cross-functional
skills focused on the work; and,
4.
Changes in team composition ruin productivity.
www.scrumtrain.com
37