www.scrumtrain.com1 scrum is honesty visibility common sense jens ostergaard

www.scrumtrain.com 1

Scrum is

Honesty

Visibility

Common SenseJens Ostergaard

www.houseofscrum.com

Waterfall and opacity

• Give me all requirements, otherwise it will cost you!


Feature Use – Keep It Lean


Always7%

Often13%

Sometimes16%

Rarely19%

Never45%

Standish Group study reported at XP2002 by Jim Johnson, Chairman

Often or Always Used: 20%

Rarely or NeverUsed: 64%

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 SOMEEMERGENT REQUIREMENTS

– Emergent requirements are those that we cannot identify in advance


• 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



• 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


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.


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


Time boxes, Roles, Rules

Risk


Define Design DevelopSign-off DeploySign-off Sign-off

Suprise!

Waterfall

False security UncertaintyMore uncertainty

Prioriterer kravene – designe,

utvikle, test


utvikle, test


utvikle, test

Feedback


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



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.


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


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.



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.


• 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


Environment

• Everyone in same location• Open space without barriers

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


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?


”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……..



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.


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


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.


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


Change for free!


Ret

urn

of I

nves

tmen

t

Time

20%

Need this one too!

Dump this one

Money for Nothing!


Ret

urn

of I

nves

tmen

t

Time

40%

Abort!

Supplier gets 20%

Courtesy of Geir Amsjø


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.


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.


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.

www.scrumtrain.com1 scrum is honesty visibility common sense jens ostergaard

Documents

project features

product express

product backlog

project progress

high priority requirements

use change control

predictive scrum empirical

empirical processes