Getting the most from Scrum and Agile.pdf

Succeed with Scrum and Agile
Henrik Berglund – Cedur
Datakonsult AB
– 15+ years of working as a consultant with
software engineering
– 10 years as Software Lead for a family of
Bluetooth software products
– 10+ years of experience with Agile
methods
henrik@cedur.se
+46 709 400864
Getting the most from
Scrum & Agile
2013-01-08
Henrik Berglund
Twitter: @henrikber

Welcome!
After you have read this:
- Take a seat
- Take one minute to fill out the warm-up
questions
- Find someone to compare and discuss
your answers with
(Yes, right now…)

What problem have you seen?
Form teams
Create a poster on a wall
Summarize in 10 minutes

1980
Basic, 6502, 68k asm
1993
Agile/Embedded
Teams
XP,
Scrum
1999
Scrum/agile
coach
2008
2010
ADA
LiTH LISP, Prolog,
Pascal
C, C++,
Flex, yacc
Perl, VBA, C#,
Tcl, bash
Henrik
Berglund
SS7, TCP

Topics
Basic principles
Agile
Scrum
Requirements
Release Planning, tracking, controlling
Sprint Planning, tracking, controlling
Roles
Scaling
Teams
Change, making sustainable progress
Scrum simulation
The technical piece of the agile puzzle

Tell the person next to you what you think
is the best way to learn something in a
course like this.
1 min

Basic principles
very simple
very important

What are we trying to do?
In your team, on the wall, create a
summary that defines what a successful
project is.
Success?
12 months
requirements
Great job!
management
funding

customers
owners
teams
individuals
Value
Learning
Job satisfaction
Profit

Traditional success definition
according to initial
specification on time on budget

Great ideas (speculation)
About new product /project
”requirements”
We predict these things will be valuable

Waste Value
Source: Chaos report, Standish
35% of requirements change
60% of features rarely or never used
Lousy predictions, why?

At 7:50, specify plan for the day:
Problem to be solved: Keep room temperature 21 C
(There is no thermometer in the room)
8:00 Element on, level 3
8:30 AC on, medium cold
….
…..
Exercise: List all variables we need
to consider. (e.g. number of persons
in room)

The solution
– empirical process control
Transparency
Inspect
Adapt
Don’t try to predict all variables,
work with feedback

Plan things
before starting?
Best approach depends on problem!
How can we choose?
Use empirical approach
(Adapt to what we know)

© 1993-2011 Scrum.org, All Rights Reserved Slide 16
27 March 2011
Think about the products you develop.
Rate complexity of requirements from 1-10
Well known in detail,
Everyone agrees, no
misunderstandings, no
unclarities, stable, never
changes
Unknown, people
have different
interpretations,
difficult to get
consensus/clarity,
unstable, changes
frequently
1
10

27 March 2011
Rate complexity of technology used from 1-
10
We know everything
about the
technologies used in
solutions. Nothing
new. It is very stable.
No surprises. No
changes
A lot of new
unknown things.
Things are new
and unknown to
us. Many things
are changing.
Many things are
unstable.
1
10

27 March 2011
Rate complexity of people issues from 1-10
Human issues never add
complexity. It is so easy to
work together! Everyone
agrees, we quickly and
correctly understand
eachother. No politics.
Everyone behaves
transparently and predictable
1
10
Having people involved
adds significant complexity.
There are different
(sometimes hidden)
agendas, different
opinions, communication
problems, unexpexted
changes and
misunderstandings.

Technology
Far from
Certainty
Close to Certainty
Requirements
Well
known,
stable
Unknown,
unstable
Simple
Complicated
Complex
Chaos
Recepies
Empirical
(Scrum)
What process is effective?
Source: Ralph Stacey, University of Herfordshire
People

Three legs of empirical process control
1. Transparency
2. Inspect
3. Adapt

Empirical process control in, Agile/Scrum/XP
Feedback cycles!
Pairing
Developer tests
Continuous integration
Daily Scrum
Sprint review
seconds
minutes
hours
days
weeks

What is agile?
Why does your organization
want to be agile?

Agile Manifesto,
Snowbird Utah Feb 11-13, 2001 www.agilemanifesto.org
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
Exercise: What do each of
these have to do with empiric
process control?

12 principles behind the agile
manifesto
• 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.
• 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 self-organizing teams.
• At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Goal of agile development
Deliver according
to initial specification,
on time, on budget
Adapt to actual
conditions, deliver
maximum value

Agile, what is being used
VERSIONONE, 3rd Annual Survey,
”The State of Agile Development”
2008
Scrum
49%
Scrum
& XP 22%
XP
8%
Other,
Unknown
21%

Exercise: Communicating
requirements
3 straight line
elements
2 curved line
elements
Sample product vision
Requirements
team
Artist
vision

Research by McCarthy and Monk, 1994
Effective
Communication
effectiveness
Ineffective
Cold Hot
Richness (“temperature”) of
communication channel
Document
Audio
recording
2 people
on email
Video
recording
2 people at
whiteboard
Communication Effectiveness

As unemployed I can search
for jobs, so that I can find jobs
that I would like to apply for
As a user
As a user
As a user
As a user
I can pay with credit card,
so that it is easy to buy things
User Stories – examples

User Stories – the card
Short description used
as reminder and for
planning
A promise about a
future conversation
Template: Readable by users
Describes things of
value to users
As <role>
As <role>
As <role>
As <role>
I can <action>,
I can <action>,
I can <action>,
I can <action>,
so that, <value of action>

Card Conversation Confirmation
As a user
As a user
As a user
As a user
so that it is easy to buy
things
things
things
things

Source: http://cukes.info/
Confirmation - ”Gherkin” - ATDD

Source: http://www.manning.com/free/green_adzic.html
Confirmation – FitNesse - ATDD

I have a problem
What happened in the F16 case?
real teams
We can design a
solutions for that
stakeholder

Exercise: How does your organization
use documents/text?

Stories - size
• Keep high priority stories small, e.g. 2-3 days
• Epics – large stories
• Themes – grouping of stories to ease planning
and prioritizing
• Backlog maintenance

INVEST Guidelines- Bill Wake
• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

Details: Stories - Advantages
• Encourages verbal rather than written communication
• Understandable by both customers and developers
• Right size for planning
• Works with iterative development
– Focus on user value
– Easy to split up as backlog order changes
• Encourages deferring detail until maximum knowledge is
available

Estimating
What value do we get from estimating?
(Why do we do it?)
What techniques do you use?
Who estimates?
When?
Why?

Estimating in story points
1 2 3 5 8 …(13, 20, 40, 100)
Relative estimates

Details: Planning Poker
1. Each team member is dealt a set of cards.
2. The meeting moderator picks a feature to estimate.
3. The person who knows the feature best describes it.
4. The team asks questions to clarify the feature.
5. Every team member silently makes an estimate and picks a card.
6. Everyone turns their card over at the same time. If the estimates differ
significantly, the highest and the lowest bidder explain their selection.
7. Repeat the previous two steps until estimates converge.

Scrum Master
Product Owner
Development Team
”Scrum Team”

Assign roles for Scrum simulation
Development Team,
plans and performs
work, optimizes process
Scrum Master, works in team
also, checks rules, leads
retrospective
Product Owner, orders
backlog, determines
acceptance criteria,
accepts/rejects stories
Special instructions in
envelope…

Rules for Scrum simulation
1. Only one requirement in progress in a team,
including PO check/review
2. No re-work
DONE!

1
1
1
1
First pick baseline card
Estimate 21 cards
in 30 minutes
Planning Poker
Discuss requirement
Show cards at same time
Discuss differences
Individually estimate

Release planning of three sprints, each 5 minutes
1
1
1
1
(cards marked iteration1)
(cards marked
iteration1 or 2)
Try to pick cards to optimize
business value
(cards marked
Iteration1, 2 or 3)

Release planning, II
1
1
1
1
RELEASE
BURNDOWN
Make two forecasts:
Forecast:
business
value : 3800
total storypoints
done in three sprints
34
business value done
in three sprints

Flow in Scrum
daily
scrum
sprint
review
retrospective
product
backlog
sprint
backlog
increment
24h
sprint
1-4 weeks
sprint
planning

Did you ever work on a project...
- Where everything was fine until end of the
project, then problem after problem was
discovered and actually it was quite delayed.
Whistle if you did!
Transparency

- Where everyone was trying to hide the fact that
they were probably not on schedule. Everyone
hoped that someone else would have to cave in
first and admit that they were late
Transparency
Clap your hands if you did!

- That was delivered on schedule, but then there
were a lot of trouble reports. For months the
team did not have time to do anything but fixing
reported defects.
Transparency
Stomp your feet if you did!

daily
scrum
sprint
review
retrospective
product
backlog
sprint
backlog
increment
24h
sprint
1-4 weeks
sprint
planning

Definition of done
increment
What has been done to the increment (and thus also, what has
not yet been done)
Example of things to include:
- coded
- unit tested
- design documentation created
- …

increment
If no work is remaining, this is
the most transparent

Definition of done
increment
Who owns it?
Who can change it?

As an amazon customer I get
recommentations for books,
so that I easily can buy
books I will enjoy but
did not know about
Splitting big features

sprint 3
sprint1
sprint2
Logic
DB
UI
Requirements breakdown
Traditional

Emergent architecture
93 things todo
3 months
No progress
Shipped in 7 months
61 things done
Next iteration did not use any of these 32!
Scrum
Example: Primavera & iManage

Requirements breakdown
sprint 3
sprint1
sprint2
Logic
DB
UI
Traditional ”Sashimi”
Sprint
1
Sprint
2
Sprint
3

backlog
grooming
sprint
planning
daily
scrum
sprint
review
retrospective
release
burndown
product
backlog
sprint
backlog
sprint
burndown
24h
increment

Backlog grooming
Everyone spends 5-10% of each sprint
Prepare for coming sprints

Backlog grooming
So that we know just enough about requirements
when sprints start
study
research
discuss
mockups
spikes

Backlog grooming
To keep product backlog transparent and in good
shape.
estimate
break down
reformulate

Product Backlog - todo list for product
Development Team
Product Owner
Estimate
5
It shall be possible to pay using
MasterCard
Order in backlog
#2
Estimate
13

Product Backlog
Ordered by Product Owner
– Usually at Theme level
Do first
Do last
What are some
advantages of
keeping an
ordered backlog?

Product Backlog,
how much details do you need?
Get enough accuracy for
release estimates
Note, more effort yields very little beyond a certain
point
Fine grained
Larger chunks
Just enough so that work flows
smoothly during iterations
Minimize work spent on low-priority stories

Release planning
Velocity =
# of Story points
Team can get to
Done per sprint
Iteration 1
Iteration 4
Iteration 3
Iteration 2
Iteration 5
Iteration 6
Iteration 7
…
Release 1
Release 2

Example, what velocity to use
Latest 3
average
Story points
1 5 12
Lowest
Highest

Tracking status - release burndown
Work
remaining
Story points
Sprints
1 5 15
12
20
100
200
21
Changed
Scope

Managing fixed date, fixed scope
Work
remaining
Story points
Sprints
1 5 15
12
20
100
200
21
Time buffer
Feature
buffer
Promise this
Promise
this

Good velocity
Innovation or stable velocity ?
What about value?

Sprint planning
sprint
planning
daily
scrum
sprint
review
retrospective
release
burndown
product
backlog
sprint
backlog
sprint
burndown
24h
increment

Sprint planning, part1
Development
Team
Product owner
We select this
much
Perform backlog maintenance as
needed (5 min – several hours)
Define a sprint goal
-Motivate!
-Give wiggle room
regarding functionality
Timebox for 30 day sprints: 4h

Why can the team decide how much
work to take on?
20
18
15
10
Dead core
Because pushing work
in makes development
go slow and will destroy
one of the companies
Most valueable assets

Key to agility: Definition of done
Teams pull as much
work they can get to
Done in a sprint

Sprint planning, part2
– Team plans out sprint
– Creates Sprint Backlog
– Team makes a forecast
As a User, I…
8 points
As a User, I…
5 points
Code the
4h
Test the
2h
Test the
2h Code the..
8h
Code the..
4h
Code the..
8h
Story TODO
Selected
Product Backlog (tasks,
smaller than 1 day)
Timebox for 30 day sprints: 4h

Exercise, sprint backlog, 5 min
• Select, plan, break down and estimate story 5
and 18 from XP game, iteration 1
Find card
Make additions
C
Story TODO
Sort deck in
four piles
10s

What if we can’t find a sprint goal?

Daily Scrum
sprint
planning
daily
scrum
sprint
review
retrospective
release
burndown
product
backlog
sprint
backlog
sprint
burndown
24h
increment

Daily Scrum - purpose
Tactical planning
meeting for
Development Team:
As a User, I…
8 points
As a User, I…
5 points
Code the
4h
Testthe
2h
Testthe
2h
Code the..
8h
Code the..
4h
Code the..
8h
Testthe...
2h
Code the..
8h
Code the..
4h
Story TODO
In
process Done
Impediments
Bumdown
- Are we on track?
- What is our plan
for today?
- What is our plan
for the sprint?
- What can be
improved?

Details: Daily Scrum
• Daily standup meeting for
Development Team to
inspect/adapt
• ScrumMaster and Product
Owner can optionally attend
• Time boxed to 15 min
• Same time, same place every
day
• Update task board
• Three questions:
– What did you do yesterday?
– What will you do today?
– Are there any impediments in
your way?
• Team commit to each other!

Status tracking – work remaining
As a User, I…
8 points
As a User, I…
5 points
Code the
4h
Testthe
2h
Testthe
2h
Code the..
8h
Code the..
4h
Code the..
8h
Testthe...
2h
Code the..
8h
Code the..
4h
Story TODO
In
process Done
Impediments
Bumdown
Code the
GUI
Work remaining,
updated every day
by Team
Total work
remaining,
updated every day
by Team
8h
Tracking time spent is NOT part of Scrum and may cay cause
lowered development speed, lowered quality and loss in predictability!

Impediments
• Think outside of the box!
– What if this would be the ideal work environment.
What would be different?
– What could help us to be more productive, both
as individuals and as a team?
– Try changing the question: “With what could
someone assist me today?”

Typical Impediments
• The department VP has asked me to work on something else
"for a day or two."
• I don’t have time to work since I am required to perform <non
value adding activity>
• I need help debugging/learning ______
• My ____ broke and I need a new one today.
• I can't get the ____ group to give me any time and I need to
meet with them.
• I still haven't got the software I ordered a month ago.
• Required to attend various meetings not needed to meet
sprint goal

What if Daily Scrums are useless?

Management involvement
• Manager assigns two slots
for impediments
• Slots are filled by team
• Team decides if
impediment is solved
• After 2-3 months…free
slots start top appear…
Idea by Mattias Skarin, Crisp AB, 2009

Tracking status during the sprint

Visual tools
As a User, I…
8 points
As a User, I…
5 points
Code the
4h
Test the
2h
Test the
2h
Code the..
8h
Code the..
4h
Code the..
8h
Test the...
2h
Code the..
8h
Code the..
4h
Story TODO
In
process Done
Impediments
Burndown

If the sprint proves to be non viable
Business conditions change so that sprint will be of no
value
Technology proves unworkable
Team is interfered with

Abnormal sprint termination
sprint
planning
daily
scrum
sprint
review
retrospective
release
burndown
product
backlog
sprint
backlog
sprint
burndown
24h
backlog
grooming
abnormal
sprint
termination
increment

What if the CEO walks in
…and asks a team member to just do a few
weeks of work for an important demo
Discuss with your team, 5 min
This is clearly within the power of the CEO isn’t it?
How does Scrum handle this? What happens with
the team and the sprint goal?

Sprint review
sprint
planning
daily
scrum
sprint
review
retrospective
release
burndown
product
backlog
sprint
backlog
sprint
burndown
24h
backlog
grooming
increment

product
backlog
increment
Sprint review
How far have we come?
What is done and what is not?
What are some future scenarios/possibilities?
Transparency
Collaboration

What if there is nothing to review?

Retrospective
sprint
planning
daily
scrum
sprint
review
retrospective
release
burndown
product
backlog
sprint
backlog
sprint
burndown
24h
backlog
grooming
increment

Details: Retrospective
• Time-boxed to 3-hours
• Attended by Team, Scrum Master and
optionally Product Owner
• What went well?
• What can be improved in the next sprint?

What if retrospectives are waste?

Retrospectives: Getting started
www.cedur.se/agile-blog

“PST favorites”
Timeline
Fishbowl
Remember the future
The race car and the abyss
Happyness metric
Perfection game
Starfish
See/hear/feel
Problem tree
Root cause analysis
Appreciation game
Sailboat
Like/Learn/Lack/Long for
World café
Design thinking
A word of praise
Team radar
Circles and soup
Open space

Solve problems, not symptoms
Problem: Smoke in my bedroom
Bad solution: Open window and go back to
sleep
Good solution:
- Find source of smoke
- Oops there is a fire in the basement…
- ?
- ?

Cause-effect diagrams
Source: http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf
Defects release to
production
Angry customers
Problem
Teams demotivated
Loss of team members
Problem
Teams
disrupted
Stress
Releases not
properly tested
Lack of test
automation
Not enough
time to write
test scripts
Scope of sprint not
reduced
Root cause
Lack of tools &
training in test
automation
Root cause
Hotfixes
required

Product Owner
Product Owner
Stakeholders
Product Backlog
R1
R2
…
Release
Plan
Release
Burndown
what’s missing…?

Development Team
Backlog Grooming,
5-10%
6 +/-3 persons
Potentially Shippable
Product Increment
Product Backlog
Sprint Backlog
Self managing
Self optimizing

Scrum Master
• Responsible for Scrum process
• Teaches Scrum to everyone
involved in project
• Facilitates teamwork
• Coaches team and individuals
• Removes impediments outside
team reach
Scrum

Mixing roles
• PO can be on the Development Team (part
time developer)
• SM can also be on Development Team (part
time developer)
• PO should not be same person as SM
– What to do, How to do it, conflicts of interest

PO ”proxy PO”
product
backog

PO ”proxy PO”
delays
misunderstandings

PO
Exercise: How can one
PO do all this?

I have a problem
Remember the F16 case?
real teams
We can design a
solutions for that
stakeholder

PO
Real teams
product
backog
ideas
strategies
problems
ideas
solutions
decisions

Coordinating work of 15 teams…

The bigger pattern
Complexity, self organization

Containers
Differences
Exchanges
When more is unknown than known (complex
problems) - best addressed with self organization
Source: G Eoyang

Release planning for <= 15 teams
Sprints (2w)
Releases
2-3 months
Release
planning 2d

Release planning meeting
Release business goals
Architectural goals
Iterative team planning, 1 h
What have we planned
What will we plan next
Problems

Synchronizing teams – Continuous
integration
User Interface
Service layer
Components
Persistence Layer
Scrum
Team
Scrum
Team
Scrum
Team
• All teams use same
code base
• Integrates several
times a day
• Test automation and
modern CM tools
needed
• Moving (an extremely
difficult) synch problem
to code level makes
problem easy!

Synchronizing teams –
“Scrum of Scrums” meeting
• What has my team
done that may affect
others?
• What will my team do
that may affect
others?
• What problems are
my team having that
with whitch it could
use help from other
teams?
Scrum
Team
Scrum
Team
Scrum
Team
Team representatives
Scrum of Scrums,
a problem solving meeting,often > 15 min
Source: “Succeeding with Agile”, Mike Cohn

“Office”
Integration team
“Word” team
“Excel” team
“Powerpoint” team
Needed in big/complex projects
Looks for unknown or unattended
interfaces between teams.
Develops facilities to integrate,
build and test work of feature teams

Working with non-agile teams
Stub out their interfaces and simulate them
Scrum
Done
Done
Done
Done
Done
Done
Done
Done
Hardware/waterfall
Work with them to improve definition of done

Scrum Simulation
Think about how this feels

Exercise: Scrum Simulation
Three Iterations
- Sprint Planning, 5 min
- Sprint, 5 min
- Review 2 min
- Retrospective, 5 min
Goal: Maximize business value
Rules:
- Only one story in progress at a time,
including PO check/review
- No rework! 1
1
1
1
sprint PO can choose stories
from sprint
1 1
2 1, 2
3 1, 2, 3

Release planning
1
1
1
1
RELEASE
BURNDOWN
& Make a forecast:
-storypoints done in three sprints (each 5 min)
-business value done in three sprints
Forecast:
business value

Sprint planning 5 min
PO orders requirements
to maximize business
value
Team plans how to
perform work
1
1
1
1
1
1
1
1
1
1
1
1

Sprint Review
1
1
1
1
RELEASE
BURNDOWN
What was done?
Update release plan & burndown
Update forecasts:
- of storypoints remaining
- of total business value

Sprint retrospective 5 min
Scrum Master leads team in
analysis:
• What worked well?
• What could have worked
better?
• Pick a few improvemens
for next sprint
Write result from sprint
on score-board:
• Story points
• Business value

Slack
creativity,
learning,
cross team collaboration

Exercise: 60 Steps
• Goal: Walk 60, real, big steps in 60 seconds
• 1) Managers: Command workers:
– Start/Stop
– Left/Right
– Faster/Slower
• 2) Workers, manage your own work

What do you think about forming
teams
Fill out the handout: 2
minutes
Form pairs, discuss results:
5 minutes

Bottleneck of software development

Team formation model Bruce Tuckman, 1965
Forming
Storming
Norming
Performing
Team start
activities

Projects: assign work to individuals
A
Product
Project a1
Project a2
B Project b1 Project b2
Persons
(previously known
as ”resources”)
Product

Product development using persons
working in teams
A
Product
B
Product
Backlog ”A”
Backlog ”B”
”Tigers”
”The A-Team”
”Blueberries”

Experts/generalists
- Low speed, low value!
+ Solutions with great
properties
I can do this
efficiently!
I can do this
efficiently!
I can do this
efficiently!
value

What can you do?
+ Speed, value, learning!
Could you work
with me on this?
I can do this
efficiently!
I’ll try!
value

R&D Team performance
Performance
Time together
Months Years
Switch a member every
one or two years to keep
improving…
Work with
enabling
conditions &
team building
to maximise
probability this
will happen Most groups

A few tips on how to get good results
with teams

Whistle if you ever has held your opinion
back to avoid conflict or to avoid hurting
a co-workers feelings

Trust
Open (positive)
conflict
Innovation
synergy

• History, what do everyone bring
• Goals for individuals, the team and the
organization
• Work process
• Development practices
• Team rules
• Conflict management
Teamstartups, use 1-2 days to work through:

After this effort I
want to have ….
We are curious, courageous and take the lead
in our organization on exploring how to
develop great innovative teams. Each of us
take responsibility for this.
We will increase our market share by
developing a product with best
performance in market

“Journey lines”, what do everyone bring
Idea first found in “Coaching Agile teams”

Make decisions by consensus
Yes
Yes Yes
Yes
Yes
No

Faster to consensus with fist-to-five
It’s a great idea and I
will be one of the
leaders in
implementing it.
I’m not in total agreement
but feel comfortable to let
this decision or a
proposal pass without
further discussion.
I think it’s a good
idea/decision and will
work for it.
I need to talk more on
the proposal and
require changes for it to
pass.
I still need to discuss
certain issues and
suggest changes that
should be made.
I am more comfortable
with the proposal but
would like to discuss
some minor issues

Blueberries – team agreements
Definition of done
Meetings, length, time
How to develop sw, design, test, collaboration etc
ways of working together…

Everyone will attend our working meetings. It is
not ok to schedule other conflicting work/personal
activities
No headphones in team area
We value differences in opinion/experience.
Everyone will make their opinion known
When we get into conflict, each of us will take
responsibility to work through it
When team agreements is not kept, each of us
will call on this behaviour
Blueberries, agreements continued

New to Scrum? – Clarify responsibilities
Line
manager
Scrum
Master
Scrum
Product
Owner
Development
Team
…
Line
manager
Project
manager
Product
owner
…
This
That
And
this
This
also

Make a co-located workspace available
• Co-locating teams at
least doubles
productivity
”How Does Radical Collocation Help a Team Succeed?”, Teasley
et al
• 30 meters apart is same as truly
remote
”The Organization and Architecture of Innovation”, Allen & Henn

Desks to support teamwork/pairing
Remote!?!

Team rooms/facilities – what is
needed?
Conference
rooms
Light
Pairing stations
Areas for
individual
work/calls
Plants
Whiteboards
Walls
Personal
space

Inverted U table setup
Conference
rooms
Light
Pairing stations
Areas for
individual
work/calls
Plants
Whiteboards
Walls
Personal
space

Details: Co-location
• Provide facilities, let team decide when to co-locate
• Working in a well-designed co-located space must be made
feel like a privilege
• One team/room. Provide noise isolation
• Provide adjacent conference rooms for meetings and hotelling
cubicles for work/private time away from team
• Make sure tables support pairing
• Write down team rules
• Update performance evaluation systems

Details: Self organizing team– Why?
• Whats’s bad about telling people the best way
to perform their work?
– Slows down inspect/adapt cycle
– Takes responsibility away
– Lessens commitment, energy and buy in
– Hinders continuous improvements

Details: How to lead/coach self
organizing teams
• How can we lead without commanding?
– Facilitate discussions
– Ask open questions
– Help analyze thinking/problem solving
– Let team fail, learn and assume responsibility

Feedback
When you
<specific action>
I <…>
Really?
#&%~!

Calling broken agreements
The agreement is important
to me. How do you feel
about it?
I noticed that you did not
keep the agreement, and
that is not ok with me!
The boy’s got
skills!
#&%~!
<Make a new
agreement about
how to treat your
agreements>

Conflict management
• Any upset, fear, or conflict, when thoroughly
viewed, will disappear
• Upset people tend to repeat themselves
C. Avery

Conflict resolution - The listen protocol
”A” is what I think
You think ”A”,
is that right?
Yes (or no)
Is there more?
Yes (or no)
I think ”B”
You think ”B”, is
that right?
Switch
to
next
chunk
Lisa Sten
…

Tell the person next to you about a
change you have been involved in
- What happened?
- Why?
1 min

Why change?
To improve
to adapt
to fix problems

Change something on yourself!
Change something on someone else!

What happens when problems are exposed?
Problem
Fix problem
Keep problem
Responsibility
Process
Independent of part of world,
age, culture, gender, education, …

RESPONSIBILITY
OBLIGATION
SHAME
JUSTIFY
LAY BLAME
The Responsibility ProcessTM
Christopher Avery & Bill McCarley

The how-to model
Three keys to responsibility
1. Intention
2. Awareness
3. Confront

Key three: confront
What can I do
about this?
How did I
create this?
What
do I want?
What can I learn
from this?

#%&!@!
I can see that
you are justifying
Helping others to responsibility

Can only be self applied!
Dissapointingly, you can’t tell others to
change
But on the other hand you don’t need
to!
Problems will be fixed anyway!

What is your mindset?
Lay blame
(blame someone else)
Justify
(blame circumstances)
Shame
(blame yourself)
Obligation
(should, have to, must…)
Responsibility
What do I want? What
can I do?

What do you think?
Could this responsibility
stuff also apply to
me?

I don’t care to fix any problems
I get payed
anyway

Fixing problems, what’s in it for you?
Thousands of knowledge
worker diary entries reviewed
- What happened?
- Good day/bad day?
Source: Teresa Amabile and Steven Kramer, Harvard
Business Review: “What Really Motivates Workers,
http://hbr.org/2010/01/the-hbr-list-breakthrough-ideas-for-
2010/ar/1

What people dislike
#1 reason for bad days at work:
Encountering roadblocks to
meaningful accomplishment

What people enjoy
75% of all good days at work
were linked to progress
and overcoming obstacles

Thus, to enjoy work more
Download poster
and hang it at your workplace:
www.cedur.se/downloads/rpm.pdf

www.christopheravery.com
20+ years of focus on ”just” this…
The Responsibility ProcessTM

Change PART II
If what you want involves others
What can you do?

The illusion of control
Random ticket numbers Picked their own ticket numbers
Asked 4x more for tickets

People do not like other people’s
ideas. They like their own ideas
...4 times as much

Getting everyone to contribute
Yeah yeah, whatever.
Can I go back to actually
working now?”

Spread of agile knowledge on an
average team
Gap is too wide, very few
can contribute to
discussions
Scrum/agile knowledge/experience
Persons
Expert
Clueless

Required for buy in and sustainable
change
Everyone can
contribute to
discussion!
Scrum
agile
XP lean
teams
change
Common
pool of ideas
Buy in,
Sustainable change
Continous improvements

Arguments and persuasion
… and further proof that
my idea is awesome…
Now, get started!
Blah Blah Blah

2%
14%
34%
34%
16%
Innovators: New things
Early adopters: Reasons
Early majority: Success
Late majority:
Safety
Some pressure
Laggards:
Extreme pressure,
Fool proof
What people need to change

Have patience
Take it step by step
Don’t take resistance personal

Why do people not cooperate?
What’s in it
for me?
Do you know?

Summary
Scrum
agile
XP lean
teams
change
The Responsibility Process
TM
RESPONSIBILITY
OBLIGATION
SHAME
JUSTIFY
LAY BLAME
persuasion
Problem exposed
keep
fix
What’s in it
for me?
Take it step
by step

Tell someone you did not talk to so far
which ideas about change you found
interesting or useful.
1 min

Think of a really small problem you are
having One that you can fix yourself
tomorrow, before lunch, without involving
anyone else. Write down what you are
going to do to fix it
1 min

The technical piece of the agile puzzle
Flexibility
Speed
Quality
Predictability
Product lifetime ROI

Exercise: Done I
• Work in pairs. Do
the math on your
handout. 3
minutes
• Report: What did
you get?

Discussion
Perhaps developers are perfectionists that try to
produce beautiful code just to please their
ego’s?
Would we be able to decrease lifetime cost of
software if developers just learned what ”good
enough” quality is?

Conclusion
• Stop adding defects…
• Just about anything you do to increase quality
will increase product ROI
• Increasing quality increases development
speed,it is NOT a tradeoff!

So we have 0 defects when we are
done
Surely nobody can compete with us now?

When you are programming, what share of your
time do you think you spend reading existing
code, trying to understand how it works so that
you can make some changes…?
50%?
90%?

Readability pays off
• ”Code that works” is a very weak definition of
done
• How can we create readable code?
– When it works (every 10 minutes if you do TDD),
refactor for simplicity and readability
– Pairing/collective code ownership, you cannot
determine what code looks like to someone that
does not know what you know

This is not a problem, we have very
good developers
• Yes, I’m sure you have. Most companies do!
• AND, most of them did not yet have the
opportunity to practice their agile skill-set. It
takes months and years to learn…
• Learning curve for developers learning agile
practices is quite steep, but the technical part
is what makes the rest work, so you just need
to learn.

What do developers need to learn?
• Writing Clean Code
• Test Driven Development
• Simple Design
• Pairing
• Refactoring
• Working with legacy code

How can we learn all this…
• Get an onsite developent coach to pair with team
for several months
• Run some inhouse coding Dojos with an expert
• Attend a hands-on TDD/agile development course
• Watch out TDD videos/Katas on the net
• Books, create a study group
• Practice…, pair

People writing about/teaching this:
• Bob Martin
• Michael Feathers
• Ron Jeffries
• Roy Osherove
• Kent Beck
• James Shore
• …

Except from making us extremely fast and removing all defects
Are there any additional advantages?
Yes – the technical piece of the puzzle actually is what makes
iterative incremental development possible

EXtreme Programming, XP
• Flattening cost of change curve
• Embrace change
Cost
of
Change
Traditional
Requirements Analysis and
Design
Coding Testing in the
Large
Production
Time
XP, Most changes
Cost
of
Change
Time

Extreme Programming (XP), practices
Customer
Customer
Customer
Customer
Tests
Tests
Tests
Tests
Planning
Planning
Planning
Planning
Game
Game
Game
Game
Whole
Whole
Whole
Whole
Team
Team
Team
Team
Small
Small
Small
Small
Releases
Releases
Releases
Releases
Test
Test
Test
Test-
--
-Driven
Driven
Driven
Driven
Development
Development
Development
Development
Simple
Simple
Simple
Simple
Design
Design
Design
Design
Pair
Pair
Pair
Pair
Programming
Programming
Programming
Programming
Refactoring
Refactoring
Refactoring
Refactoring
Continuous
Continuous
Continuous
Continuous
Integration
Integration
Integration
Integration
Coding
Coding
Coding
Coding
Standard
Standard
Standard
Standard
Collective
Collective
Collective
Collective
Ownership
Ownership
Ownership
Ownership
Sustainable
Sustainable
Sustainable
Sustainable
Pace
Pace
Pace
Pace
Metaphor
Metaphor
Metaphor
Metaphor

XP Practices
COLLECTIVE OWNERSHIP
CONTINUOUS INTEGRATION
SHORT RELEASES
PLANNING GAME
ON-SITE CUSTOMER
40 HOUR WEEK
METAPHOR
REFACTORING
PAIR PROGRAMMING
CODING STANDARDS
SIMPLE DESIGN
TESTING

Possible Uses of Automated Tests
• Finding defects early
• Safety net for regression testing
• Communicating with customer
– Executable requirements
• Design method – safely growing systems
– TDD

Test Automation Pyramid
Unit Tests / Component Tests
Acceptance Tests
(API/Service Layer)
GUI
Tests
Manual Tests
Biggest ROI
by far!

TDD Cycles, Outside - In
Write a failing
acceptance test
Write a failing
unit test
Make the test
pass
Refactor

Snap your fingers if you have
experienced solving your own problem
just by explaining it to someone…

Why?
• The Costs and Benefits of Pair Programming
– Alistair Cockburn, Laurie Williams
– Takes 15% more time
– Improves design quality, reduces defects, reduces staffing risk,
enhances technical skills, improves team communications and is
considered more enjoyable
– Extra investment paid back 15-60 times by reduced test costs
• Pair helps each other to stay on the agile path…
• Long term effects of stimulating a learning organization
• ”Promiscuous Pairing and Beginner’s Mind: Embrace
Inexperience”
– Arlo Belshee study

How
• Driver
– Focuses on how to implement current method
• Partner
– Thinking more strategically
– Is this whole approach going to work?
– What are some more tests that may not work yet?
– Can the system be simplified so that the current problem disappears?
• ”May I drive?”
• Pair switching, how often?
– Consider “Ping Pong TDD”
• How to get started?

Agile Testing
TDD, Test Driven Development
“Developers reach deadlines faster if
they skip TDD in the same way that
skydivers reach the ground faster if they
skip parachutes“, Joakim Karlsson, Blueplane 2007

Unit tests
• Protects against regression
failures
• Enables refactoring and
emergent design
• Pass quickly (< 10 minutes)
Goal: Test complete system,
4000 tests,
in < 10 minutes
Unit Tests
Acceptance
Tests
GUI
Tests

End-to-end (system) tests
• Measure of demonstrable
progress
–Take a while to make pass
–Hard to setup and keep
working
–Optionally readable/defined
by customer
Unit Tests
Acceptance
Tests
GUI
Tests

The warmup questions
Re-visit your warp up questions from day 1.
Check each question, did you change your mind
about anything or get new insights?

What problems have you seen
Re-visit your team poster from day 1.
For each problem, do you think anything we
covered during these days could be worth trying
to improve the situation? What?

Thank you!
Henrik Berglund – Cedur AB
henrik@cedur.se
twitter: @henrikber
I offer life time support on this class. Feel free to give me a call and
talk about scrum, agile, lean and teams!
Also take a look at our agile blogs, recommended books, videos,
sites and articles at http://www.cedur.se

About Toyota
• What is the source of their greatness?
– Toyota Saying: Making things is about making
people
Isao Kato, student of Taichii Ohno, Father of TPS
• Respect People
• Continuous improvements
– Faster – Better - Cheaper

Seven principles of Lean Software
Development
• Eliminate waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole

Lower the water to expose the rocks

Queue theory –
The utilization paradox
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cycle
time
(hours)
Load
Large batches
Medium batches
Small batches
High performance Thrashing!
Cycle
time
(hours)

The seven wastes
• Partially done work, WIP
• Extra features
• Relearning
• Handoffs
• Task switching
• Delays
• Defects

Gaining a competitive edge using agile with
contracts and partners

Fixed price contracts
• Trying to limit scope
– Makes scope grow…
• Transfer risk to seller
– But who owns the risk really…
• Controlling scope and managing change
– But these costs dominate most vendor-supplier relationships
• Often awarded to lowest bidder
– So winner need to create profit by charging for change…does not align
interests of seller buyer

Turning fixed price contracts in to win-win
• We will deliver this project iteratively and incrementally
• Every iteration we will show you what we have build and ask for your
feedback
• Before every iteration you can change the priorities any way you like
• If you want to add new stuff that is no problem as long as you remove
something else of similar size
• Whenever you like you can stop the project and put it in production.
• When you do that we will charge you 20% of the remaining project cost as
compensation for loss of income

Lean contracts and cooperation
• T5 story
• Toyota philosophy
– Contract types to align interests
• For more info:
– Take a look at our three part newsletter about
contracts and cooperation at
www.cedur.se/Newsletter.html

Retrospective
- brainstorm, prioritize
Week2 Week3
Week1
Good Can get better
Theme3 Theme 4
We want to
work on this
the most!
Theme 2
Theme 1

Retrospective
- cause-effect diagrams
Source: http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf
Defects release to
production
Angry customers
Problem
Teams demotivated
Loss of team members
Problem
Teams
disrupted
Stress
Releases not
properly tested
Lack of test
automation
Not enough
time to write
test scripts
Scope of sprint not
reduced
Root cause
Lack of tools &
training in test
automation
Root cause
Hotfixes
required

Retrospective
- countermeasures
Root
cause!
Root
cause!
Suggested
countermeasures
What do we expect?
Who will do what,
when?

Details: Two hour retrospective example
• Check In 5 minutes
• Timeline 10 minutes
• What went well 10 minutes
• What could be better 10 minutes
• Sort/prioritize, select a
few issues to work on 5 minutes
• Root cause analysis 45 minutes
– 5 why
• Design experiments to
address root cause(s) of
problems 20 minutes
• Switch time 15 minutes

5 dysfunctions of a team
Patric Lenconi 2002
Absence of Trust
Fear of Conflict
Lack of Commitment
Avoidance of
Accountability
Inattention
to results
Conflict: The primary
engine of creativity and
innovation,
R Hiefertz, Director of the Leadership Education Project,
Harvard University

Teambuilding, 5 Conversations
1. Focus on collective task
2. What motivates each of us?
3. What do each of us contribute?
4. Team rules
5. Setting bold goals. Anticipate conflict,
breakthroughs and synergy

Team norms, is it ok to…
• …read mail during meetings
• …take notes on a laptop during meetings
• …answer the mobile and leave room during meetings
• …be late for meetings
• …take on part time work in another project
• …ask others questions at any time
• …make personal calls in team area
• …use a speaker phone in team area
• …wear headphones in team area
• …plan your work so that others need to work late (you may not mind
working late yourself)
• …not calling on others when agreements are broken?
• …

Team charter = norms + more
• team norms, communication rules
• meetings
• planning & estimation
• technology
• engineering rules
• ready
• definition of done

Details: IEEE style requirements
• IEEE 830, shall, should
– The system shall accept Visa, MasterCard and American express cards
– The system shall charge the credit cards before the job posting is placed on the site
– The system shall give the user a unique confirmation number
• Cons:
– Documenting requirements at this level is tedious, error-prone and very time
consuming
– Boring to read, realistically not everyone that needs to a read 300 page spec like
this will.
– Level of detail makes it hard to grasp big picture
– Describes behavior of software, not behavior or goals of user => ”64% statistic”
– Implies that software is complete when it fulfils a list of requirements, not when it
fulfils user’s goals
– Cost of each requirement is not visible until all requirements are written down =>
analys phase => waste
• Is it possible to write all requirements upfront at start?
– Users have different and better opinions when they see the software
– Change of scope?

Details: Use cases
• Use cases
Jacobsson (1992), Cockburn (2001)
• Focus on business value
• Too large for use as unit in
iteration planning
• Focus on completeness
• Permanent artifacts
• Prone to include details like UI
design
• Written to document
agreement with customer
Use Case Title: Pay for a job posting
Primary Actor: Recruiter
Level: Actor goal
Precondition: The job information has been entered but is
not viewable
Minimal Guarantees: None
Success Guarantees: Job is posted; recruiter’s credit card
is charged
Main Success Scenario:
1. Recruiter submits credit card number date and authentication
information.
2. System validates credit card
3. System charges credit card full amount.
4. Job posting is made viewable to Job Seekers.
5. Recruiter is given a unique confirmation number.
Extensions
2a: The card is not of a type accepted by the system.
2a1: The system notifies the user to use a different card.
2b: The card is expired:
2b1: The system notifies the user to use a different card.
2c: The card is expired:
2c1: The system notifies the user to use a different card.
3a: The card has insufficient available credit to post the ad.
3a1: The system charges as much as it can to the current credit card
3a2: The user is told about the problem and asked to enter a second
credit card for the remaining charge.
The use case continue at Step 2

Planning Poker
1. Each team member is dealt a set of cards.
2. The meeting moderator picks a feature to estimate.
3. The person who knows the feature best describes it.
4. The team asks questions to clarify the feature.
5. Every team member silently makes an estimate and picks a card.
6. Everyone turns their card over at the same time. If the estimates differ
significantly, the highest and the lowest bidder explain their selection.
7. Repeat the previous two steps until estimates converge.
Tip: Place a two-minute hourglass on the table. If discussions drag on,
anyone can turn over the timer. When the sand runs out, a new round of
estimates is played.

Details: Why planning poker works
Research shows that these points improve
accuracy:
• Bring together multiple expert opinions
• Ask estimators to justify estimates
• Average individual estimates
• Group discussions

Details: Tips for estimation
• Focus on the relative size, not the absolute size of features. Features estimated
as size "three" should be about three times as big [large?] as features
estimated as size "one".
• Collect a set of features of each size and make sure everyone has this available
to use as a baseline.
• Estimate in abstract story points, not in ideal man-days or hours.
• Re-estimate a feature only if you learn something that changes its relative size
compared to other features. Do not re-estimate as the team picks up speed.
Measuring speed is what velocity is used for.
• Keep estimates of high-priority features within one order of magnitude, i.e. 1-
10×.
• Estimate low-priority features in larger chunks and with less accuracy. Break
down these features and refine the estimates as their priority rises with time.

Details: Tips for handling estimates
• Set aside 10% of the time of each iteration to estimate and groom the
backlog. Make sure that features likely to be selected for the next iteration
are well enough known so that their implementation will not be blocked.
• Use a fixed "definition of done" to determine when an item is finished –
e.g. unit test coverage 95%, reviewed, refactored, integration tested, load
tested, documented, acceptance tested…
Do not try to finish items within the exact estimated time. See “definition
of done” above.
• Report time remaining on items, not time spent. Reporting of time spent
creates an incentive to lower quality to finish items within the estimated
time. See “definition of done” above.

Getting the most from Scrum and Agile.pdf

Recommended

Recommended

More Related Content

Similar to Getting the most from Scrum and Agile.pdf

Similar to Getting the most from Scrum and Agile.pdf (20)

Recently uploaded

Recently uploaded (20)

Getting the most from Scrum and Agile.pdf