Persuasive and Communication is the art of negotiation.
Getting the most from Scrum and Agile.pdf
1. 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
2. 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…)
3. What problem have you seen?
Form teams
Create a poster on a wall
Summarize in 10 minutes
8. 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
12. Waste Value
Source: Chaos report, Standish
35% of requirements change
60% of features rarely or never used
Lousy predictions, why?
13. 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)
14. The solution
– empirical process control
Transparency
Inspect
Adapt
Don’t try to predict all variables,
work with feedback
19. 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
20. Three legs of empirical process control
1. Transparency
2. Inspect
3. Adapt
21. Empirical process control in, Agile/Scrum/XP
Feedback cycles!
Pairing
Developer tests
Continuous integration
Daily Scrum
Sprint review
seconds
minutes
hours
days
weeks
24. 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?
25. 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.
26. Goal of agile development
Deliver according
to initial specification,
on time, on budget
Adapt to actual
conditions, deliver
maximum value
27. 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%
29. 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
30. As unemployed I can search
As unemployed I can search
As unemployed I can search
As unemployed I can search
for jobs, so that I can find jobs
for jobs, so that I can find jobs
for jobs, so that I can find jobs
for jobs, so that I can find jobs
that I would like to apply for
that I would like to apply for
that I would like to apply for
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,
I can pay with credit card,
I can pay with credit card,
I can pay with credit card,
so that it is easy to buy things
so that it is easy to buy things
so that it is easy to buy things
so that it is easy to buy things
User Stories – examples
31. 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>
so that, <value of action>
so that, <value of action>
so that, <value of action>
32. Card Conversation Confirmation
As a user
As a user
As a user
As a user
I can pay with credit card,
I can pay with credit card,
I can pay with credit card,
I can pay with credit card,
so that it is easy to buy
so that it is easy to buy
so that it is easy to buy
so that it is easy to buy
things
things
things
things
38. 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
39. INVEST Guidelines- Bill Wake
• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable
40. 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
41. Estimating
What value do we get from estimating?
(Why do we do it?)
What techniques do you use?
Who estimates?
When?
Why?
44. 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.
47. 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…
48. Rules for Scrum simulation
1. Only one requirement in progress in a team,
including PO check/review
2. No re-work
DONE!
49. 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
50. 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)
53. 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
54. Did you ever work on a project...
- 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!
55. Did you ever work on a project...
- 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!
57. 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
- …
64. 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
68. Backlog grooming
So that we know just enough about requirements
when sprints start
study
research
discuss
mockups
spikes
69. Backlog grooming
To keep product backlog transparent and in good
shape.
estimate
break down
reformulate
70. 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
71. Product Backlog
Ordered by Product Owner
– Usually at Theme level
Do first
Do last
What are some
advantages of
keeping an
ordered backlog?
72. 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
74. 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
80. 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
81. 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
82. Key to agility: Definition of done
Teams pull as much
work they can get to
Done in a sprint
83. 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
84. 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
88. 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?
89. 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!
90. 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!
91. 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?”
92. 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
94. 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
96. 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
97.
98.
99. 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
101. 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?
106. 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?
110. “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
111. 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…
- ?
- ?
112. 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
117. 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
118. 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
131. Release planning for <= 15 teams
Sprints (2w)
Releases
2-3 months
Release
planning 2d
132. Release planning meeting
Release business goals
Architectural goals
Iterative team planning, 1 h
What have we planned
What will we plan next
Problems
133. 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!
134. 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
135. “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
136. 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
138. 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
143. 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
150. Team formation model Bruce Tuckman, 1965
Forming
Storming
Norming
Performing
Team start
activities
151. Projects: assign work to individuals
A
Product
Project a1
Project a2
B Project b1 Project b2
Persons
(previously known
as ”resources”)
Product
152. Product development using persons
working in teams
A
Product
B
Product
Backlog ”A”
Backlog ”B”
”Tigers”
”The A-Team”
”Blueberries”
153. 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
154. What can you do?
+ Speed, value, learning!
Could you work
with me on this?
I can do this
efficiently!
I’ll try!
value
155. 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
156. A few tips on how to get good results
with teams
157. Whistle if you ever has held your opinion
back to avoid conflict or to avoid hurting
a co-workers feelings
159. • 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:
160. 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
163. 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
164. Blueberries – team agreements
Definition of done
Meetings, length, time
How to develop sw, design, test, collaboration etc
ways of working together…
165. 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
166. 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
167. 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
169. Team rooms/facilities – what is
needed?
Conference
rooms
Light
Pairing stations
Areas for
individual
work/calls
Plants
Whiteboards
Walls
Personal
space
170. Inverted U table setup
Conference
rooms
Light
Pairing stations
Areas for
individual
work/calls
Plants
Whiteboards
Walls
Personal
space
173. 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
174. 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
175. 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
177. 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>
178. Conflict management
• Any upset, fear, or conflict, when thoroughly
viewed, will disappear
• Upset people tend to repeat themselves
C. Avery
179. 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
…
187. What happens when problems are exposed?
Problem
Fix problem
Keep problem
Responsibility
Process
Independent of part of world,
age, culture, gender, education, …
190. Key three: confront
What can I do
about this?
How did I
create this?
What
do I want?
What can I learn
from this?
191. #%&!@!
I can see that
you are justifying
Helping others to responsibility
192. 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!
193. 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?
194. What do you think?
Could this responsibility
stuff also apply to
me?
195. I don’t care to fix any problems
I get payed
anyway
196. 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
197. What people dislike
#1 reason for bad days at work:
Encountering roadblocks to
meaningful accomplishment
198. What people enjoy
75% of all good days at work
were linked to progress
and overcoming obstacles
199. Thus, to enjoy work more
Download poster
and hang it at your workplace:
www.cedur.se/downloads/rpm.pdf
202. The illusion of control
Random ticket numbers Picked their own ticket numbers
Asked 4x more for tickets
203. People do not like other people’s
ideas. They like their own ideas
...4 times as much
204. Getting everyone to contribute
Yeah yeah, whatever.
Can I go back to actually
working now?”
205. 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
206. 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
208. 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
212. Tell someone you did not talk to so far
which ideas about change you found
interesting or useful.
1 min
213. 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
216. The technical piece of the agile puzzle
Flexibility
Speed
Quality
Predictability
Product lifetime ROI
217. Exercise: Done I
• Work in pairs. Do
the math on your
handout. 3
minutes
• Report: What did
you get?
218. 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?
219. 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!
220. So we have 0 defects when we are
done
Surely nobody can compete with us now?
221. 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%?
222. 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
223. 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.
224. What do developers need to learn?
• Writing Clean Code
• Test Driven Development
• Simple Design
• Pairing
• Refactoring
• Working with legacy code
225. 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
226. People writing about/teaching this:
• Bob Martin
• Michael Feathers
• Ron Jeffries
• Roy Osherove
• Kent Beck
• James Shore
• …
227. 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
228. 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
229. 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
230. 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
231. Possible Uses of Automated Tests
• Finding defects early
• Safety net for regression testing
• Communicating with customer
– Executable requirements
• Design method – safely growing systems
– TDD
232. Test Automation Pyramid
Unit Tests / Component Tests
Acceptance Tests
(API/Service Layer)
GUI
Tests
Manual Tests
Biggest ROI
by far!
233. TDD Cycles, Outside - In
Write a failing
acceptance test
Write a failing
unit test
Make the test
pass
Refactor
234. Snap your fingers if you have
experienced solving your own problem
just by explaining it to someone…
236. 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
237. 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?
238. 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
239. 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
240. 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
243. 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?
244. 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?
245. 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
249. 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
250. Seven principles of Lean Software
Development
• Eliminate waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole
253. 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)
254. The seven wastes
• Partially done work, WIP
• Extra features
• Relearning
• Handoffs
• Task switching
• Delays
• Defects
256. 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
257. 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
258. 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
262. 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
264. 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
266. 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
267. 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
268. 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?
• …
269. Team charter = norms + more
• team norms, communication rules
• meetings
• planning & estimation
• technology
• engineering rules
• ready
• definition of done
271. 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?
272. 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
274. 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.
275. 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
276. 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.
277. 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.