www.scrumtrain.com1 scrum is honesty visibility common sense jens ostergaard
TRANSCRIPT
Feature Use – Keep It Lean
www.scrumtrain.com 3
Always7%
Often13%
Sometimes16%
Rarely19%
Never45%
Standish Group study reported at XP2002 by Jim Johnson, Chairman
Often or Always Used: 20%
Rarely or NeverUsed: 64%
• Emergence
– Impossible to know all requirements in advance
– ”Thinking harder” and ”thinking longer” can uncover some requirements, but
EVERY PROJECT HAS SOMEEMERGENT 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
www.scrumtrain.com 7
• Command and Control for simple projects
• Enforce that what happens is the same as what is planned
• Use change control to manage change
Defined Processes
www.scrumtrain.com 8
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 9
Predictive
Scrum - Empirical
Start with Plan and all requirements
End with all requirements completed
Start with Goals and some high priority requirements
End with Goals met
Risk
www.scrumtrain.com 13
Define Design DevelopSign-off DeploySign-off Sign-off
Suprise!
Waterfall
False security UncertaintyMore uncertainty
Prioriterer kravene – designe,
utvikle, test
Prioriterer kravene – designe,
utvikle, test
Prioriterer kravene – designe,
utvikle, test
Feedback
Prioriterer kravene – designe,
utvikle, test
Feedback Feedback
Agile
Timeboxed
Uncertainty SafeSafer
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
www.scrumtrain.com 15
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.
16
Copyright 1993-2010, ADM, All Rights Reserved v1.3
Product Owner
►Defines the features of the product►Manages project features and release to optimize return on
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
DevelopmentTeam
►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
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►No more than 9 people
Scrum Master
►Ensures that the team is fully functional, productive and improves 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
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
www.scrumtrain.com 20
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 21
• 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
Roles – Dev Teams
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 28
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 29
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.
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
Change for free!
www.scrumtrain.com 33
Ret
urn
of I
nves
tmen
t
Time
20%
Need this one too!
Dump this one
Money for Nothing!
www.scrumtrain.com 34
Ret
urn
of I
nves
tmen
t
Time
40%
Abort!
Supplier gets 20%
Courtesy of Geir Amsjø
www.scrumtrain.com 35
Basic truths about team motivation1. 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 36
Basic truths about team performance1. 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 37
Basic truths about team composition1. 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.