Do Better Scrum
Do Better Scrum
Do Better Scrum
What is Scrum?................................... 7
Derivation....................................................................8
The Essence of Scrum..............................................9
Applicability of Scrum.......................................... 10
Will Scrum succeed in my organization?....... 10
Getting Better..................................51
Shu Ha Ri................................................................... 52
A pattern language for hyper-productivity.. 52
More about Impediments................................... 55
Story Maps................................................................ 56
Release Planning using a burnup chart......... 56
Adopting Scrum...............................31
Getting Help.....................................59
Understanding Scrum.....................15
Starting Scrum......................................................... 32
#1 Train the Scrum Team...................................... 32
#2 Establish the Vision.......................................... 33
#3 Form the initial Product Backlog................ 33
#4 Order the backlog items by value.............. 34
#5 Size the backlog items.................................... 35
#6 Re-order the backlog by additional factors.
36
#7 Create a rough-cut release plan.................. 36
#8 Plan and start the first Sprint....................... 37
All rights reserved. This book or any portion thereof may not be reproduced or used in any
manner whatsoever without the express written permission of the writer except for the use of
brief quotations in a book review.
PART
ONE
What is Scrum?
DO BETTER SCRUM
Derivation
Scrum is a management framework within which complex products can be developed. Scrum
is derived from work in knowledge management, complex adaptive systems and empirical
process control theory. The acknowledged genesis is a research paper The New, New Product
Development Game by Nonaka and Takeuchi [Nonaka 1986]. Indirectly Scrum draws much from
what we know as Lean.
Scrum is by far the most popular of the Agile methods. In 2013 72% of teams who would claim
to be agile are using Scrum alone or in combination with other methods [VersionOne 2013]. For
more information about Agile and other methods, see Chapter 9 More on Agile and Lean.
In August 2012 Gartner published a research paper entitled The End of the Waterfall as We Know
It in which they claim that long-duration Waterfall projects are the highest risk way to deliver
software [Gartner 2012].
Scrum provides a platform for people to work together effectively and relentlessly makes visible
every problem that gets in its way.
I have found that C-level managers are able to understand and identify with the following simple
model that contrasts the traditional project management model with the Agile model.
In the traditional predictive model, the project manager attempts to constrain scope in order to
provide reliable estimates for time and cost. In practice we experience a triple constraint or iron
8
WHAT IS SCRUM?
triangle situation and quality may become an undesired variable. In Agile we accept time and
cost as real constraints. The product manager then works with the delivery team to maximize
value by delivering iteratively and incrementally. The plan is regularly adapted to match reality.
(How could we ever believe the other way around could work?)
I find that senior level stakeholders are delighted to discover that time and cost can be fixed or
at least managed in increments. Naturally there is initial anxiety around scope being variable.
I overcome this by seeking their permission to conduct an experiment with clearly defined
constraints.
DO BETTER SCRUM
Applicability of Scrum
While Scrum was first applied to development of software products, it is suited to all types
of complex work. It is used today to manage software and hardware development, support,
advertising and marketing, churches and entire organizations.
10
WHAT IS SCRUM?
More importantly, I think, I can refer them to many people I have witnessed over the past eight
years make a personal transition from huge frustration to renewed joy in their work.
Nevertheless success with Agile depends on you! The implementation of Agile methods in your
organization will succeed or fail based on the recognition and acceptance that introducing Agile
initiates huge and unavoidable changes within the organization.
Learning the rules of one or other Agile method is not the difficult part. It is the effective
management of the resulting waves of change at all levels in the organization, including its
impact on the organizations culture, that will ultimately determine success or failure.
Scrum offers a way for the organization to unlock more of the unlimited potential of its people.
Scrum (and any Agile method) also comes with associated costs, which are measured in multiple
currencies, only one of which is money. You need to invest in understanding the economic value
proposition that this presents before you proceed much beyond some initial experiments.
Lastly, an organizational transition to Agile will take years. No matter what size your organization, how
aligned you think the culture is, or any other factor you imagine may smooth your path, it may take five
to ten years to get really good and to institutionalize these new ways of working. So get ready for a long
journey. And enjoy the ride!
11
DO BETTER SCRUM
12
WHAT IS SCRUM?
13
PART
TWO
Understanding Scrum
DO BETTER SCRUM
Self-organization
Self-organization does not at all imply a laissez-faire approach; on the contrary, self-organized
teams are highly disciplined. Self-organization occurs within agreed upon constraints. Within
these they are given full autonomy and voluntarily make commitments to one another. They
accept responsibility and accountability for delivering to these commitments within the limits
of their control. They are encouraged to take reasonable risks and to learn through failure and
self-reflection. Self-organizing teams exhibit high trust and possess high intrinsic motivation.
Teams new to Scrum will require some encouragement to explore their new, broader boundaries
and to take ownership. They frequently need to overcome strong muscle memory of the poor
ways in which they have worked and been managed, perhaps for many years.
Self-organization is not an option in Scrum; it is a core principle. Without this, high-performing
teams will not happen. Caveat emptor!
Development Team members are programmers, testers, analysts, architects,
designers, writers, and even usersanyone who contributes to doing the work.
The Development Team is cross-functional, which means that its members
between them possess sufficient skills to do the work required to deliver the
contracted product increment. Cross-functional does NOT mean that everyone
can perform every task. Nevertheless, the best Team Members may be described
as T-shaped people as opposed to I-shaped people [Reinertsen 2009].
I-shaped people have a single specialist skill to offer the team, while T-shaped
people complement their specialist skill with additional generalist skills. This
they are able to assist their colleagues in multiple ways to delivery the contracted
product increment.
16
UNDERSTANDING SCRUM
Product Owner
The Scrum Product Owners primary responsibility is to optimize return on investment (ROI) by
ensuring that the Scrum Team Members are engaged in delivering the currently most valuable
product features.
The Product Owners primary job is to focus on effectiveness, that is building the right product for
her customers.
The responsibilities of the Product Owner role are:
Ensuring the existence of a shared vision for the Product
Managing and prioritizing the Product Backlog
Helping the Team Members to understand what to build and why
Accepting the delivered product increment at the end of each iteration
Managing the release plan
Informing stakeholders regarding progress and managing their expectations
Maximizing the economic return of the product.
There is one and only one Product Owner in a Scrum Team. Tobias Mayer has labeled this as the
What Voice [Mayer 2009]. Other people who have a stake in the product are...well...stakeholders!
Metaphor: The Product Owner is a CEO.
17
DO BETTER SCRUM
Development Team
The Development Team is the collection of people responsible for delivering potentially
shippable increments of product functionality at the end of each Sprint.
The Development Teams primary job is to focus on efficiency, that is building the product right
for their Product Owner and users.
The responsibilities of the Development Team are:
Working with the Product Owner and other stakeholders (often users) to progressively refine
up-coming Product Backlog items so they are each well-understood and small enough to
fully complete in one Sprint
Contracting with the Product Owner to deliver a completed increment of the product at the
end of the Sprint
Self-organizing to figure out how to deliver the contracted product incrementand doing
so!
Tracking its own progress daily towards the Sprint Goal
Ensuring that the products design remains sound and the code (or other output) is
maintainable through ongoing refactoring.
Tobias Mayer has labeled the Development Team as the How Tribe [Mayer 2009].
Scrum Master
The Scrum Master manages all aspects of the Scrum Teams process. Since the team is selforganizing around the work, the Scrum Master manages via influence rather than authority.
This is a complete paradigm shift for the leadership of most organizations. It is at once the
hardest thing to grasp in Scrum and yet is its most powerful enabler of improvement in human
performance.
The Scrum Masters primary job is to focus on the Scrum Teams continuous improvement, by
shortening the feedback loops by which they learn. This helps them to get stronger as a team and
thereby work better and faster.
The responsibilities of the Scrum Master role are:
Shepherding the Development Team towards self-organization and continuous improvement
Working to remove organizational impediments to the Development Team
Helping the Product Owner to understand and perform his role
Facilitating Scrum events
Socializing Scrum to the greater organization.
Metaphor: The Scrum Master is a facilitator, coach, mentor and bulldozer! In fact, she is often
called the Team Coach, since the metaphor of a sports coach is often quite apt.
The Scrum Master helps unlock for the Scrum Team the powerful triple intrinsic motivators of
autonomy, mastery and purpose so aptly described by Daniel Pink in his seminal TED talk The
Puzzle of Motivation [Pink 2009] and book Drive: The Surprising Truth About What Motivates Us
[Pink 2011].
The Scrum Master is a leadership role, yet avoids telling the Team Members what work to do or
how to perform it. This is aptly described as Servant Leadership [Greenleaf 2012].
18
UNDERSTANDING SCRUM
Many traditional managers imagine the Scrum Master role as some kind of
administrator, perhaps like a junior project manager. I have seen this mistaken
understanding result in many difficulties with Scrum adoptions. Agile change
agents need to be on their guard for symptoms of this and immediately work to
help managers to grasp the value of this new role.
A related disease is the persistent behavior of allocating a single Scrum Master
to multiple teams. Novice teams generally need a full-time Scrum Master. This is
especially true when the Scrum Master is also inexperienced and the organization
is early in its Scrum adoption.
Michael James offers us a helpful checklist for all the activities a diligent Scrum
Master might do [James 2006].
Other Roles
There is no Project Manager role in Scrum. The responsibilities of the traditional project manager
are divided over the three roles in the Scrum Team:
The Product Owner manages the product (and return on investment)
The Scrum Master manages the process
The Development Team manages itself.
This is challenging to individuals who currently fulfill this role and to managers in organizations
in which they work. Michele Sliger and Stacia Broderick have written a helpful guide to the
transition from Project Manager to Agile Coach [Sliger 2008]. A project manager will usually
adopt one of the designated Scrum roles: perhaps Product Owner if she has domain knowledge;
perhaps Scrum Master if she has good soft skills; perhaps Development Team member if he
enjoys problem-solving.
There are no appointed leaders of the Scrum Team beyond the Product Owner and Scrum
Master; none is required. The need for line managers is reduced, as teams manage themselves
to a great extent. I have seen 40 team members to report directly to a single line manager in an
organization that has made the transition to Agile.
Outside of the Scrum Team there are naturally additional roles within the broader organization.
I have found it helpful to distinguish three such roles and to describe their interaction with the
Scrum Team roles in terms of a simplified communication model:
The Customer, who is financing the work, sometimes known as the Sponsor. She talks mostly
with the Product Owner. Hopefully she also participates in the Sprint Review events.
Users, who will use the Scrum Teams output. Users will mostly interact directly with the
Development Team to help them understand their needs and give them direct feedback
about what they have already delivered. Users will often be engaged directly in writing user
stories, refining the Product Backlog, giving input during Sprint Planning and feedback
during the Sprint Review events.
Managers, who enable the organizational framework within which the Scrum Team operates.
Managers and other stakeholders are mostly taken care of by the Scrum Master, who helps
them to understand how they can best support the Scrum Team to be effective.
19
DO BETTER SCRUM
The interactions between these roles is shown in the following diagram. Note that this is just a
model that illustrates the major communication flows between the three Scrum Team roles and
other major groupings in the organization. In practice communication networks in organizations
are far more complex.
Scrum Events
The Sprint
The Sprint is the heartbeat of the Scrum cycle and the container for all other events. It is
bookmarked by Sprint Planning at the start and by the Sprint Review and Sprint Retrospective
at the end.
The purpose of the Sprint is to meet the Sprint Goal. This is achieved by planning and delivering
Product Backlog items to the Product Owner. The completed Product Backlog items are added
to the Increment which the Product Owner may choose to release at any time. Quality of the
20
UNDERSTANDING SCRUM
Increment is assured by agreeing on a Definition of Done against which every completed item is
measured. The Sprint functions to limit the risk that the organization is wasting scarce skills and
resources on work that is not the most valuable at the time.
The Definition of Done (DoD) is an agreement made between the Development
Team and the Product Owner. It is made public so that everyone is clear what is
included and what is not.
The DoD is a general statement by the teams and applies to all backlog items.
Individual backlog items will have specific conditions of satisfaction or acceptance
criteria.
Scrum teams choose one, two, three or four weeks as their Sprint duration. The length of the
Sprint is fixed and is never extended once the Sprint has begun. This becomes a cadence or
rhythm for the teams work. Every event in Scrum is strictly time-boxed. The time-box is an upper
limit for the duration; it need not use this full time. The time box for each of the Planning (parts 1
& 2), Review and Retrospective events are generally accepted to be one hour per week of Sprint
length. For example, for a two-week Sprint, each of these four events will have a maximum
duration of two hours. Each day during the Sprint the Development Team holds a Daily Scrum.
Should the Scrum Team or its stakeholders discover at any point during the Sprint that the Sprint
Goal is no longer achievable or will no longer serve the organizations needs, the Product Owner
is authorized to terminate the Sprint immediately. On termination, any completed (Done) items
will be reviewed. I suggest the Scrum Team also holds a Retrospective, since terminating a
Sprint is likely a traumatic event for them. Sprint terminations are costly and unusual. Some key
attributes of the event are described in the following sections. First, though, I have collected a
few experiences I think are worth sharing.
I often find two-week Sprints a good length to start with. Its a happy medium
between one week, which can feel frighteningly short for novice Scrum Teams,
and three- or four-week Sprints, which can result in mini-waterfalls. After three
sprints, let the team re-assess the Sprint length and try a different one, if they
wish.
Notwithstanding, I also often start Scrum Teams with one-week Sprints when they
are facing short-term delivery deadlines. Short Sprints provide more feedback
cycles, which are crucial to helping teams home in fast on the outcomes that are
most important to their stakeholders.
Teams need a minimum of three sprints to grasp the new concepts, break down
old habits and start to gel as a team. This three-Sprint rule applies again any time
a change is made, such as adding or removing a member, changing the Sprint
length, etc.
As Jean Tabaka advises [Tabaka 2006], never do Sprint planning on a Monday
morning. The team is not yet at its best and it is the most common day for
holidays and sickness. Never hold reviews or retrospectives on a Friday afternoon.
The team is tired and thinking about the weekend. Therefore choose Sprint
boundaries on Mondays to Thursdays.
Scrum Teams running two-week sprints might be tempted to hold all Sprint
boundary meetings in one day. In other words, start the day with the review,
21
DO BETTER SCRUM
then the retrospective; after lunch do Sprint planning parts 1 and 2. The thinking
is to get all the meetings out of the way and have 9 full days to do the work. In
my experience there are two problems with this approach:
The team does not get that these meetings are part of the workin fact the
most important part to get right!
During the last part of the daySprint planning 2the team is brain-dead.
In such cases I advise conducting the Review and Retrospective in the afternoon
and the do Planning the following morning. Yet, as always, let the team try it out
if they so wish!
Sprint Planning
The Sprint Planning event marks the beginning of each Sprint. Its purpose is for the Scrum Team
to plan the work they will do during this Sprint. It is generally divided into two parts, each with
a distinct purpose.
The first part Sprint Planning (often referred to as SP1) answers the question: What can we
deliver by the end of this Sprint?. So we often call SP1 the What? event. It is really a detailed
requirements workshop. Starting from the top of his Product Backlog, the Product Owner presents
the set of features she would like. The Development Team asks questions to understand the
requirements in sufficient detail to enable them to forecast what they can deliver during the
Sprint. The Development Team alone decides what is achievable, taking into account the Sprint
duration, the size and current capabilities of its members, its Definition of Done, any known
holidays or leave days, likely interruptions to their work, and most importantly any improvements
it committed to during the Sprint Retrospective held just prior this event.
The Product Owner is present throughout SP1 to lead the Development Team in the right
direction and to answer questionsand they will have many. The Scrum Master ensures that
any other stakeholder needed to help the Development Team understand the requirements is
present or on call.
Any new backlog items for inclusion in the current Sprint and not previously estimated will be
sized immediately during this event. This not, however, an excuse to avoid refining the backlog
see below!
At the end of the first part the Development Team contracts with the Product Owner what they
believe they can deliver in the form of running tested features. A team with a reasonably consistent
record of delivery may use its historic velocity as a predictor (known as yesterdays weather).
This is velocity-based planning. Teams starting out can do commitment-based planning; that is,
the team uses it intuition or gut to know what it can do. This may sound unscientific, however
in my experience it forces the members to engage their brains and yields rather good results.
The backlog items the team forecasts it will complete in during the Sprint becomes the basis of
the Sprint backlog.
If part one is a requirements workshop, the second part of Sprint Planning (SP2) is a design
workshop and answers the question: How will we do the work? So we often call Sprint Planning
part two (SP2) the How? event.
In this session the Development Team collaborates to create a high-level design of the features it
has just contracted to deliver. During part two the team may have additional questions regarding
22
UNDERSTANDING SCRUM
the requirements. The Scrum Master must ensure that the Product Owner and, if necessary, other
stakeholders are on call to answer them.
Design, as everything else in Agile, is emergent. Also, the event is time-boxed. So it is normal that
the team wont get the design perfectly completed in this session and will discover more tasks
during the Sprint. This is not a sign that something is wrong. They will simply grab a post-it note
and pen and create more tasks whenever necessary during the Sprint.
An outcome of Sprint Planning is the Sprint Backlog, comprising the functional work items, the
list of tasks and the plan that the team collectively needs to execute in order to turn the chosen
Product Backlog items into running tested features. The Sprint Backlog is most commonly
represented on a physical task board. Scrum Teams that are not collocated will likely use a
software tool to visualize their task board.
You will know that SP2 is working when the Development Team is gathered
together around the white board discussing noisily or even arguing about the
best or right way to implement a feature.
SUMMARY
Purpose
Plan the work for the current Sprint
Timing
At beginning of sprint; one hour per week of sprint length for each part
Audience
The Scrum Team plus any relevant stakeholders
Inputs
Refined Product Backlog; Improvements from previous Sprint Retrospective; Sprint Goal (if
already known).
Outputs
Sprint Backlog
Daily Scrum
The Daily Scrum is one of the primary inspect and adapt points in Scrum. The Development Team
meets to communicate and synchronize its work and create a plan for the next 24 hours. Since
the Development Team is constantly self-organizing towards achieving the Sprint Goal, this
collaboration is essential to ensuring continued progress and avoiding work blockages.
The daily Scrum event is not for reporting progress to the Scrum Master or anyone else. In fact the
Scrum Guide states that the Scrum Master should ensure no-one other than the Development
Team participates [Schwaber 2013]!
The Scrum Masters role is to make sure the Daily Scrum takes place. She will also strive to ensure
that any impediments to the Development Team doing its work are bulldozed out of the way
as fast as possible. The Scrum Master also ensures the events 15-minute time-box is honored.
23
DO BETTER SCRUM
The Daily Scrum is sometimes called the stand-up, since it is invariably held standing up. This helps
to ensure a short meeting! Jason Yip [Yip 2006] provides a useful guide to help ScrumMasters to
run this event well.
As from the July 2013 edition of the Scrum Guide, the Product Owner and other
stakeholders are no longer admitted to the Daily Scrum. Given the purpose of
this event, I cannot see why they would wish to attend anyway!
SUMMARY
Purpose
Synchronize the Development Team; plan the work for the current day
Timing
Daily at the same time; 15 minutes maximum duration
Audience
The Development Team; Scrum Master may facilitate
Inputs
Sprint Backlog
Outputs
Updated Sprint Backlog; (optionally) updated Sprint Burndown Chart.
Sprint Review
The focus of the Sprint Review is the product the Development Team is building.
The Sprint Review is sometimes, and incorrectly, called the Sprint demo. While it does include
a demonstration of the new features completed during the Sprint, its primary purpose is to
inspect what the Development Team has delivered and gather feedback from the attendees to
adapt the plan for the succeeding Sprint. Thus it is much more than a demonstration; it is the
key point in the feedback cycle that ensures that the product development path is adjusted at
minimum monthly.
When asked who should be invited to the Sprint Review, I answer the whole world. My intent
here is to help the Scrum Master and the entire organization understand that the direct attention
and feedback of a broad constituency of the organization is crucial to maximizing the value
the Development Team will deliver in succeeding sprints. Sprint reviews have many possible
outcomes including cessation of the project. In most instances, the Scrum Team is authorized
to continue for another Sprint. I find mature teams may already establish the goal for their next
Sprint during the review. They find this helps maintain the rhythm or flow from Sprint to Sprint.
The Sprint Review is a particularly expensive event, since it usually includes many
stakeholders and senior people. The Development Team must respect this by
setting up and checking their demonstration environment before the meeting.
I teach Development Teams not to surprise their Product Owner during the
Sprint Review: she should be aware beforehand what backlog items they have
completed and will be demonstrating.
24
UNDERSTANDING SCRUM
SUMMARY
Purpose
Stakeholders and Scrum Team inspect the Increment and adapt their plan
Timing
At end of sprint; maximum one hour per week of sprint length
Audience
The Scrum Team plus all interested stakeholders
Inputs
Increment; refined Product Backlog
Outputs
Updated Product Backlog; updated product/release burnup chart; Goal for next Sprint (ideally).
Sprint Retrospective
The Sprint Retrospective is the final event of the Sprint. It follows immediately after the Sprint
Review. It is never omitted, no matter what may have happened during the Sprint!
Whereas the Sprint Review is focussed on the product, the retrospective is focussed on the
processthe way in which the Scrum Team is working together, including their technical skills
and the software development practices and tools they are using.
And whereas the Sprint Review is open to the world, the Sprint Retrospective is restricted to
the members of the Scrum Teamthat is the Product Owner, Development Team members
and Scrum Master. Outsiders, including managers at every level in the organization are strictly
excluded unless specifically invited by consensus of the Scrum Team.
This rule is to be understood in the context of the goal of the event, which is to inspect at a
deep level how the Scrum Team is collaborating and performing and to take action to improve.
This often requires deep introspection and sharing, which in turn requires a safe and secure
environment. Norman Kerths Retrospective Prime Directive undergirds this: Regardless of what
we discover, we understand and truly believe that everyone did the best job they could, given
what they knew at the time, their skills and abilities, the resources available, and the situation at
hand. [Kerth 2001].
Boris Gloger [Gloger 2008] offers a simple pattern called Heartbeat Retrospectives for new teams
to learn to hold valuable retrospectives. Esther Derby and Diana Larsen [Derby and Larsen 2006]
provide an excellent model and a host helpful activities for facilitators of Scrum retrospective
meetings. Jeff Sutherland [Sutherland 2011] has produced a very short (2:30) video that does a
great job of capturing the essence of what the Sprint Retrospective is about.
The Product Owners presence during the Sprint Retrospective is required.
He is a full-fledged member of the Scrum Team. As such, his participation in
evaluating and improving the Scrum Teams process is as necessary as that of
other members.
The Scrum Master has a key responsibility to assure psychological safety during
the Sprint Retrospective. Novice Development Teams with over-bearing Product
Owners (it does happen!) may need to hold their first retrospectives without her
25
DO BETTER SCRUM
until sufficient safety can be guaranteed. Such actions must always be seen as
temporary and are steps on the journey towards agility.
Norm Kerth recommends that teams invest 2% of their working time in running
retrospectives. I have found this to be good advice. And surely this is not such a
high price to pay for learning how to work more effectively and have more fun
together? And yet I find teams cutting the time or skipping them altogether.
Certified Scrum Trainer Alan Cyment goes as far as saying that all you need
to get going with Scrum is an excellent Scrum Master and to start running
retrospectives!
SUMMARY
Purpose
The Scrum Team continuously improves its way of work
Timing
At end of sprint (after the Sprint Review); maximum one hour per week of sprint length
Audience
The Scrum Team (others only by specific invitation of the Scrum Team)
Inputs
Anything useful from the current Sprint
Outputs
Improvement items for implementation during the next Sprint.
Scrum Artifacts
Scrum mandates only these artifacts:
Product Backlog
Sprint Backlog
Increment
While not considered artifacts in Scrum, I consider the Scrum Teams Product Vision and their
Definition of Done important assets. I teach all Scrum Teams to create and make both of these
highly visible in their work space.
Scrum is purposely silent about all other documentation and artifacts. This sometimes leads to
the misunderstanding that agile teams dont need to do any documentation. I coach teams to
produce only those artifacts that are really valuable to themselves and to others in the future. My
test questions are: Who is this for? and What will they do with it? This cuts out worthless work
and unnecessary destruction of forests!
26
UNDERSTANDING SCRUM
Product Backlog
The Product Backlog is simply a list of work items, described at a functional level, that need
to be done over time. Items may be added to the backlog by anyone, but only the Product
Owner has the right (and duty) to determine the order in which they will be executed by the
Development Team. Of course a good Product Owner will negotiate this with stakeholders and
the Development Team.
Requirements are emergent, meaning we do not and cannot know up front every detail about
what we want in a product. Therefore the Product Backlog is a living document and requires
constant refinement to keep it current and useful. Many new items will be added over time;
existing items are disaggregated to multiple, smaller items; some items may be removed on
realizing that a desired feature is no longer needed. Moreover, items may need to be sized in
order to determine the likely relationship between value, time and cost. And, of course, the
order of items in the backlog will change as the relative value between them is seen differently
today from yesterday.
Therefore backlog refinement is a continuous activity that runs in parallel with every Sprint.
The Product Owner convenes regular meetings where the Scrum Team and, if required, other
stakeholders refine the Product Backlog in preparation for future Sprints.
In many cases it is sufficient, and often preferable, to create and maintain the Product Backlog
as a set of stories written on physical 125 x 75 mm (5 x 3) index cards. Ron Jeffries [Jeffries
2005] coined the alliterative triplet Card, Confirmation, Conversation (the 3Cs) to describe how
to work with stories. The stories are written from the perspective of the protagonist. Mike Cohns
book on user stories [Cohn 2004] tells you how.
An outcome of the refinement activity that surprises some people is the shared
learning that occurs by the Development Team members of the business domain
in which they are operating. The positive impact of this is products that are a
better fit to the users needs and less rework (a form of waste). It turns out that
everyone is a winner when the Product Backlog is kept in good shape!
A good Product Owner will be adept at saying no to the addition of inessential
items to the Product Backlog. This is a crucial activity in support of simplicity, the
tenth principle of the Agile Manifesto.
In my experience the members of the Development Team need to devote 5%
to 10% of their time during the Sprint to preparation for forthcoming sprints.
This is important to avoid a stop-start effect at the boundary of every Sprint. The
implication, of course, is that teams are able to spend 90% to 95% of their time
doing the work of the current Sprint!
I coach teams to hold backlog refinement meetings weekly, no matter what the
length of their Sprint. Typically these meetings run for one to two hours and take
place at the same time each week. My experience is that regular, short meetings
are more effective and less draining on the energy levels of the participants.
Between these meetings the Product Owner together with business analysts, if
the organization includes such roles, will work continuously refining the Product
Backlog. This includes defining the conditions of satisfaction (also known as
scenarios) for upcoming backlog items.
27
DO BETTER SCRUM
Sprint Backlog
Most Development Teams will visualize their Sprint Backlog on a task board, which is the physical
representation of the list of work they have contracted to do during the current Sprint. The task
board is an example of a Kanban, a Japanese word meaning token or visible signal. It tells the
Scrum Team and anyone else what work they have planned or the Sprint and their current status.
28
UNDERSTANDING SCRUM
Detractors point out that a story-point burndown chart will look jagged rather than smooth, and
may tend to flatline until near the end of the Sprint. Exactly! So now there is something obvious
to improve on.
Increment
The Increment is the sum of all Product Backlog items that meet the definition of Done by the
end of the Sprint. The Development Team will present this at the Sprint Review. The Product
Owner will determine when to release it.
29
DO BETTER SCRUM
Day 1: Training
Days 2 & 3: Product Workshop
Day 4: Sprinting
30
PART
THREE
Adopting Scrum
DO BETTER SCRUM
Starting Scrum
Ken Schwaber [Schwaber 2007] says there is nothing that needs to be done before starting
Scrum. I interpret this to say that there is no tailoring of the process needed in order to start, as is
required with heavy methodologies. Nevertheless the literature is thin on how to get going and
probably all of us struggled getting our first Scrum team going without outside help.
The best thing you can do is hire an experienced coach. Failing that, you can try using a pattern
that has worked for me with dozens of teams.
Obviously you need a Scrum team. This means a Product Owner, a Scrum Master and three to
nine Development Team members. If this is not yet in place, you may want to start with some
introductory workshops to check the organizational readiness for Scrum, identify stakeholders
for the project or product and form the initial Scrum Team who will do the work. Refer to Chapter
8 Getting Help for more information on these activities.
Then follow this sequence of steps, which will be detailed in the next pages.
I start new teams with a full days training in the essentials of Agile and Scrum.
This is sufficient to start a Scrum Team that has an experienced Scrum Master /
agile coach to support them during their early sprints.
Steps two (visioning) to seven (initial release planning) can be completed
comfortably in a two-day product workshop attended by the entire Scrum Team.
The best workshops are attended by additional stakeholders like enterprise
architects, managers and business people.
On day four, without fail, the Scrum Team is able to commence sprinting!
If the organization is able to provide the Scrum Team with an experienced Scrum
Master, she will facilitate days 24 and I will coach her. If notwhich is more
often the caseI will do so with the novice Scrum Master observing. I try to
follow the see one, do one, teach one learning principle.
ADOPTING SCRUM
33
DO BETTER SCRUM
Template:
In order to reason, as a role, I want functionality.
Example:
In order to obtain cash conveniently, as a bank customer, I want to
withdraw cash via an auto-teller machine (ATM).
Moreover, I favour using the Scenario construct for specifying acceptance tests from Dan Norths
Behaviour Driven Development (BDD) model [North 2006], as shown below.
Template:
Given initial condition(s)
When an event occurs
Then expected outcome(s).
Example:
Given I have $20 in my bank account AND I authenticate myself successfully
When I request a $10 withdrawal
Then I get two $5 notes AND a printed receipt.
Bill Wake suggested the helpful INVEST acronym for the attributes of a good user story [Wake
2003].
At a minimum the Product Backlog needs to contain enough items for the team to plan the first
Sprint. More commonly, the backlog contains all the items that make up the next planned (or
hoped-for) product release.
As a guide, the initial backlog should be 80% complete (but not ordered or sized) by the end
of day one. The first part of day two can be used to add the final 20% and to resolve any open
questions. The overnight break is a very useful hiatus that may spark fresh thinking about the
work.
An advanced Product Backlog technique named Story Mapping has been developed by Jeff
Patton. You will find more detail on this topic in Chapter 7 Getting Better.
34
ADOPTING SCRUM
At the minimum, the Product Owners subjective judgement of the value of one feature against
another might be a starting point. Somewhat better would be a quasi-quantitative relative
weighting using affinity groups or planning poker.
However it is done, it is a core responsibility of the Product Owner to order the backlog. Better
still would be to measure the actual economic value achieved against that predicted.
We size items relative to one another. Why? Because as humans we find this more natural
and the results are more reliable. So its easy to agree that this story is twice the effort of that
one even though we dont know how long each will take to implement.
We size items using units of effort rather than time. Why? Because it allows us to separate the
rate at which a team works from the size of the work. This shields us from having to change
our estimates according to who does the work, or as the teams skills and capacity change
over time. We use story points as units.
We use a non-linear sizing scale because the difference between a 1 and a 2 is obviously
more meaningful, relatively, than that between 20 and 21. My personal preference is to
use the pseudo-Fibonacci numbers : 1, 2, 3, 5, 8, 13, 20, 40 and 100. I define 1 to 8 as the size
range of features a team can delivery in one Sprint. Why? Because it turns out that humans
are rather accurate within about a single order of magnitude of size difference. The higher
numbers are reserved for large stories (epics) that will need to be split into smaller stories
before they can be taken into a Sprint.
35
DO BETTER SCRUM
Size: we will naturally choose to implement a simple (small, less effort) story ahead of a
complex (large, more effort) story if they have similar business value.
Learning: we may choose to implement a story earlier if it will help the team learn about the
business domain or a new technology.
Risk: we may choose to implement a story early because doing so will mitigate an identified
risk. Obvious examples are items that will help establish performance and scalability limits.
We must always remember that the Product Owner has final say on ordering the backlog.
First, of course, we must be sure to know the team size during the Sprintwhether any member
will be away on leave, training, etc. And we must choose the Sprint lengthI usually recommend
two weeks for a new team. And we must create a definition of Done for the teamwhat does it
mean when the team says it has completed a story.
The Scrum Master now picks the first item from the top of the backlog and asks the team can
you complete this item during the Sprint?. She continues to do this until the team is no longer
confident to add items. Counting up the story point values of all the committed items, the team
has its initial estimate of velocity.
This velocity value is used to apportion the remaining backlog items (at least those that have
been estimated) over succeeding sprints. This list of items attached to sprints is our initial release
plan. It is accurate? Certainly not, but it is probably more credible that anything a project manager
could produce before at such an early stage of a project. And as we start work and complete
one Sprint after another, we will begin to chart our actual velocity and use this as a predictor of
future output. So the release plan is a living thing that becomes more and more reliable as we
progress. See Chapter 7 Getting Better for more on release planning.
Dont let the product workshop drag on. It is possible within two days for any
team and any product to prepare enough backlog items for the first few sprints
at least. There is far more value in getting going, inspecting the results and
adapting your plan than by striving to formulate the perfect Product Backlog.
With a new team, new domain or new technology, try to avoid having to create a
release plan until you have completed the first few sprints. A release plan based
36
ADOPTING SCRUM
on wild guesses is not helpful to anyone. Rather get three to five sprints under
the teams belt and then offer your first plan based on the observed velocity
range.
Scrum emphasizes empiricism as the best way to manage the complexity present
in product development. This promotes transparency and acceptance of reality.
Traditional release planning and monitoring techniques measure conformance
with a plan. Be careful not to allow your release planning and monitoring
techniques to subvert the very benefit you seek from Scrum.
37
PART
FOUR
Collocation and Team
Spaces
DO BETTER SCRUM
Team rooms significantly reduce the need for meeting roomsteams can do
Sprint planning, daily meetings and reviews in their room.
Be warned that your architect or office designer may not be much help to you.
She probably has not been trained in the design of collaborative team spaces.
The cost of the changes (drywalls and furniture) will be recovered in one week to
one month! Sounds unbelievable, doesnt it?
40
41
PART
FIVE
Measuring
DO BETTER SCRUM
Starter metrics
With all this in mind I hesitate to offer any concrete metrics here. Nevertheless I will offer a few
starter metrics for consideration. Most are straightforward to implement; some will require
more effort. These are based on my own research and that of other agile practitioners, notably
Pete Behrens [Hundermark 2009]. I would encourage you to view the video and slides to get
both some background on metrics, an explanation of why I have chosen these particular metrics
and some guidance on how to set them up.
Simple metrics:
44
MEASURING
Lastly, be vigilant about how the metrics are used. For example, a velocity chart, whose purpose
is to enhance predictability, may be abused by ascribing the productivity to it, a purpose for
which it is not designed and therefore should be used. For every metric you need carefully and
regularly to compare its intent with the observed outcome. This is a non-trivial activity.
Key Points
The purpose of metrics is learning. So start early. The sooner you establish a baseline, the
earlier you will be able to begin to use data to understand your results and feed this back into
your systems to make better decisions.
Dont let some group of managers in their ivory tower determine metrics. Work with your
team(s) and stakeholders to determine what needs measuring and how to measure it.
What you measure today will not be the right thing to measure tomorrow. Get comfortable
with the idea that your teams metrics will be in a more-or-less constant state of flux. CIO and
Agile coach Marius de Beer reports that the median lifetime of metrics in his multi-national
organization is three months [De Beer 2013].
45
DO BETTER SCRUM
46
PART
SIX
Scaling Scrum to the
organization
DO BETTER SCRUM
Here be dragons!
The first rule of scaling Scrum to multiple team is dont. In other words, be sure that you need
more than a single, effective Scrum team to do the job before you consider using multiple teams.
One study of single team with four to eight members showed it to be 35 times as productive
as the standard [Coplien 1994]. Scrum founder Jeff Sutherland has documented many cases of
hyper-productive Scrum teams [Sutherland 2003-2012].
Before you attempt to introduce Scrum into multiple teams, do it with one team. Do it by the
book. Learn from your mistakes. Walk before you run. Do it well before you try to change the
rules. Follow the ShuHaRi learning model (see Chapter 7 for an explanation of ShuHaRi).
My own experience with scaling Scrum is that starting small and adding only what is needed
as I go is less painful and more successful than starting with a heavy framework and trying to
find bits I can remove. Any attempt to scale Scrum will amplify the need for good design and
development practices. Be sure to focus attention on getting these right. Every scaling situation
is different and requires its own solution. As with everything in Agile, this has to be arrived at via
trial, inspection and adaptation.
The greatest challenges to adopting Agile at scale are organizational. Therefore any scaled
implementation needs careful attention to communication, culture and change management.
I suggest that you accept that there is no silver bullet solution to doing Scrum (or any form of
Agile) at scale. With this mindset I suggest you read broadly what others have done and are doing.
I especially recommend the Larman and Vodde books (above) as well as Henrik Knibergs papers
and presentations. Still worth reading is Ken Schwabers The Enterprise and Scrum [Schwaber
2007]. Mike Cohns Succeeding with Agile [Cohn 2009] also has some useful guidance for applying
Scrum at scale.
If you are a novice and are serious about helping your organization get better, find and hire
an Agile coach who has a verifiable pedigree in applying Agile at the scale you need. This will
shorten your learning curve and lessen the pain!
Lastly, be prepared for a multi-year journey towards organizational agility. Whilst I have seen
tremendous improvements within just a few months, serious sticky change, especially at scale,
will take a long time: think five to ten years. The good news is that it can be a lot of fun with
rewards all along the way.
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
[Larman and Vodde 2008] and Practices for Scaling Lean & Agile Development: Large, Multisite,
and Offshore Product Development with Large-Scale Scrum [Larman and Vodde 2010].
At the same time older frameworks such as the RUP (Rational Unified Process) have had lipstick
applied and been presented with an agile flavour. Such offerings need to be approached with
care and circumspection.
This topic of Agile in the enterprise is an interesting and important space with much new
practice emerging in recent years. I have written about the scaling topic in some detail in my
blog [Hundermark 2014].
DO BETTER SCRUM
50
PART
SEVEN
Getting Better
DO BETTER SCRUM
Shu Ha Ri
The Japanese martial art Aikido defines a model of learning named Shu Ha Ri. The following brief
description is based on an article by Ron Fox [Fox 1995].
The first, Shu, state means to keep, protect or maintain. During this stage the student builds
her technical foundation in the new art being learned. She will carefully copy the techniques
demonstrated by the sensei (teacher) without modification and without necessarily understanding
the underlying rationale. The idea is that the student will learn fastest by following a single path
as defined by the sensei. The sensei, rather than the student, will determine when she is ready
to move to the next stage, Ha. It follows that the Shu level student requires regular access to a
sensei. It follows moreover that the sensei should be operating at the Ri level in order to be an
effective teacher and mentor to his students.
Ha, the second stage, means to detach. The student reflects on the meaning and purpose of
what she has learned. She develops a deeper appreciation of the art beyond simple repetitive
practice. The techniques have been absorbed into her muscle memory. She breaks free from
the traditions to some extent.
The third stage, Ri, means to transcend or go beyond. The student is now a practitioner who
thinks originally and tests her ideas against reality. At the Ri level that student may overtake her
sensei, thereby advancing the art.
Why is this important? Well I see many teams and managers in organizations too impatient to
obtain a solid grounding in the Shu stage. Some are hell-bent on going straight to Ri! As Ron
Jeffries, long-time agilist, says: My advice is to do it by the book, get good at the practices, then
do as you will. Many people want to skip to step three. How do they know?
If Chapter 3 Adopting Scrum was mostly about operating at the Shu level, this chapter is aimed
at the Ha level. As your Agile adoption journey progresses, you will find that Scrum still provides
a minimal yet sufficient framework within which complex problems can be solved. Continuous
improvement can still be achieved simply by doing the essentials well. And when you are ready
you will also discover that there is a world of useful tools to complement what you know. At the
Ha level the basics will be in muscle memory and you can start experimenting with new things
without forgetting the fundamentals of Agile.
GETTING BETTER
My own belief, based on experience working with many teams, is that these patterns are
fundamentally sound and will lead not only to increases in output, but also many of the other
desired improvements mentioned above. Try them. What have you got to lose?
For the sake of brevity I have simply stated each of the nine patterns that make up the Pattern
Language for Hyper-Productive Teams. I have added the briefest of comments where this seemed
necessary. If you want to implement the patterns, I urge you to download the free PDF with full
descriptions of the patterns via the link on Jeffs web site [Sutherland 2013].
Note that the patterns described here are generative patterns. This means that the patterns work
indirectly by attacking the underlying structure of the problem which may not even be manifest.
Generative patterns lead to emergent behavior, which is entirely in keeping with the complex
category of problems that Scrum framework seeks to address.
Stable Teams
Keep teams stable and avoid shuffling people between teams. Stable teams get to know their
capacity, which makes it possible for the business to have some predictability.
Yesterdays Weather
In most cases, the number of Estimation Points completed in the last Sprint is the most reliable
predictor or how many Estimation Points will be completed in the next Sprint.
Estimation Points as described here are often termed Story Points. In many cases simply counting
Stories (Product Backlog items) will suffice.
Focus maximum team effort on one item in the Sprint Backlog to get it done as soon as possible.
Whoever takes this item is Captain of the team. Everyone must help the Captain if they can and noone can interrupt the Captain. As soon as the Captain is Done, whoever takes responsibility for the
next priority backlog item is the new Captain.
Swarming
Development team members and managers may insist that this is inefficient. This may well be
true. Remember that our goal is no longer efficiency, but effectiveness.
Interrupt Pattern
Allot time for interruptions and do not allow the time to be exceeded. Set up three simple rules that
will cause the company to self-organize to avoid disrupting production:
1. The team creates a buffer based on historical data.
2. All requests must go through the Product Owner for triage.
3. If the buffer starts to overflow, the team Sprint must automatically abort the Sprint.
53
DO BETTER SCRUM
Aborting a Sprint has repercussions on delivery dates. Management quickly realizes the cost and
will work to help solve the underlying cause.
Emergency Procedure
When high on the burndown try a technique used routinely by pilots. When bad things happen,
execute the emergency procedure designed specifically for the problem. Do not delay execution
while trying to figure out what is wrong or what to do. In a fighter aircraft you could be dead in less
time than it takes to figure out what is going on. It is the responsibility of the Scrum Master to make
sure the team immediately executes the Scrum Emergency Procedure, preferably by mid-sprint, when
things are going off-track. Emergency Procedure steps (do only as much as necessary):
1. Change the way the work is done. Do something different.
2. Get help, usually by offloading backlog to someone else.
3. Reduce scope.
4. Abort the Sprint and re-plan.
5. Inform management how release dates will be affected.
Scrum is not laissez-faire about achieving the Sprint goal!
Happiness Metric
Before you reject this as fluffy and idealistic nonsense, I challenge you to try it! First read Ben
Linders InfoQ article How to Measure and Analyse Happiness [Linders 2013].
54
GETTING BETTER
55
DO BETTER SCRUM
Story Maps
Jeff Patton [Patton 2008a] developed his Story Mapping concept from the earlier work on
Usage-Centred Design by Larry Constantine and Lucy Lockwood, on Use Cases by Alistair
Cockburn and on User Stories as described by Kent Beck in Extreme Programming. A Story Map
is a two-dimensional depiction of the Product Backlog with a backbone of users activities and
the narrative flow running horizontally from left to right and successive incremental product
releases running vertically from top to bottom. The main building blocks of a Story Map are user
tasks [Patton 2008b]. The figure below shows an example of a Story Map. I teach Story Mapping
in my Product Owner training and use it when coaching teams who are beyond novice level.
56
GETTING BETTER
In this case I deliver some value to my customer at a time she can rely on. And I can deliver more
later if she wishes. Compare this with taking the time I need to deliver a given scope: It removes
the choice I could have offered her.
We must always help stakeholders to understand that the purpose is to providing transparency
so that they know reality and can make appropriate choices. And we must never forget the
principle of adaptive planning that underpins Scrum and Agile.
In theory the lower the variability in the teams velocities measured over successive
sprints, the more precisely the Product Owner can predict the teams future deliveries.
However it is a dangerous practice to encourage the team to aim for perfection here.
A likely outcome of this is either gaming of sizes, leading to a loss of transparency, or
excessive time spent in estimating, resulting in waste. As with all things, balance is
desirable. I have found a range of 20% around the mean to be a good figure.
One teams sizes are generally not comparable to those of another. This is immaterial
unless we have multiple teams working off the same Product Backlog. This is an issue
of scaling Scrum and is quite easily solved, but is not a topic for this little guide.
With many teams I have coached it turns out after the first few sprints that their
velocity did not increase over time. I found this rather surprising until I realized what
57
DO BETTER SCRUM
was happening. As their practices matured and improved, their work got easier and
they naturally gradually decreased their story point estimates. A natural consequence
was an increase in the value delivered per story point. It matters little if the effort a
story point represents changes over time, provided this change is gradual and we are
using some sort of moving average to for planning. I mention this to help you to be
mindful that story points and velocity are neither a measure of input nor output over
the long term; they are simply a planning aid.
Moreover, I hope that the mature Product Owner will herself understand that
neither input nor output are valuable measures; agile teams should be focussed
on maximizing outcomes with the least possible output. And she must educate
stakeholders in this.
58
PART
EIGHT
Getting Help
DO BETTER SCRUM
The guide began with the words Scrum is Simple. Doing Scrum is Hard. Agile trainers and
coaches the world over use metaphors like Scrum is a flashlight to discover what is hidden in
the dark corners of your organization. They will hold that Scrum will not solve a single problem
for you.
So how do you go about using Scrum (or any other method)? Well you can read books like this
one and try to apply what you find. And I certainly hope that you do. However you soon find
things that are hard to figure out on your own. Your specific context is different from what youve
read about. Your colleagues and managers, and you yourself are prone to continue doing what
youve always done, even when you know this is dysfunctional. Change is hard.
If I have learned one thing in my Agile journey it is to seek help. This has been the single most
empowering act for me. And I want to encourage you to do the same. To quote Karl E. Weick and
Kathleen M. Sutcliffe from Managing the Unexpected: It is a sign of strength and confidence to
know when youve reached the limits of your knowledge and know enough to enlist outside
help [Wieck and Sutcliffe 2001].
In this chapter my aim is to help you recognize when you need help, how to get help that is
appropriate to your need. Im mindful that this is a broad topic and I can but scratch the surface.
As usual I provide a set of references I have found useful.
60
GETTING HELP
What is coaching?
It is challenging to find a common definition of coaching. One that I like is The art of facilitating
the performance, learning and development of another [Downey 2003].
Common to most approaches are these characteristics:
It is a structured dialogue between coach and coachee*, with clear expectations, feedback
and accountability;
The coach facilitates self-directed learning and development of the coach;
Coaching aims to enhance well-being and performance of the coachee.
*Some people may have an aversion to the term coachee. However I have not found a better generic
word. Note also that the coachee may be an individual or a group.
Another dimension to coaching in our world is that the Agile coach frequently acts in the
additional roles of teacher, expert advisor and as mentor. The first two are generally based on
expertise in Agile process frameworks (like Scrum). The third is based on personal experience
the coach has in the role of, for example, Scrum Master or Product Owner. A good Agile coach
will make it transparent to the coachee when she is acting in which role.
61
DO BETTER SCRUM
During his research into successful Agile adoptions Agile coach and CIO Marius de Beer observed
that the best organizations combined the use of internal and external coaches [De Beer 2012].
62
GETTING HELP
63
PART
NINE
More on Agile and Lean
DO BETTER SCRUM
Commentary
The Agile Manifesto and its twelve principles have stood up (thus far) for more than a decade.
They remain the litmus test for all Agile methods and practitioners by which to evaluate their
way of working. The most vocal criticism has been the bias towards software development,
when Agile methods are actually more broadly applicable.
A common misconception is that Agile seeks to eliminate all process, documentation, contracting
and planning. Simply reading the value statements should help you spot the fallacy in this.
For more on the history of the manifesto as well as an analysis of the four values and twelve
principles, I suggest you read Martin Fowler and Jim Highsmiths original article in Dr. Dobbs
Journal [Fowler and Highsmith 2001].
66
Scrum
Manages the iterative design and
incremental delivery of value from a
dynamic list of work that is fed by a
continuous assessment of users needs
Defined roles, events & artefacts
Simple to learn; hard to do well
(More) revolutionary change
Sweet spot is for addressing Complex*
problems
The Kanban Method manages a given flow of work by visualizing the workflow, limiting the
quantity of work-in-progress, and removing bottlenecks.
Kanban imposes few rules. This may create an impression of simplicity. In practice it is a
sophisticated method and requires stewardship.
Change with the Kanban Method is evolutionary. This can make Kanban a more palatable
choice for organizations whose culture makes it hard to introduce rapid change.
Scrum, by contrast, attacks complexity head-on and requires a more radical shift in attitude.
Scrum provokes fundamental change. This is hard for organizations and people, but the
results can be astonishing.
It will be wise to familiarize yourself with both methods, or to seek expert advice, so you make
an appropriate choice. You may well profit from using both in different areas of application
or in tandem.
67
DO BETTER SCRUM
A simple, yet excellent guide to Kanban written by Arne Roock is now available [Roock 2012].
The more serious-minded should read David Andersons definitive book on the subject
[Anderson 2010].
*I view the Kanban Method as a goodprobably the besttool for solving problems in the
Complicated domain. Scrum, by contrast, is optimally suited to solving Complex problems.
Some readers will find this a controversial statement. You may find Snowden and Boones HBR
article [Snowden 2007] a helpful reference to understanding complexity.
68
Acknowledgements
The genesis of the first version of this little book was the need, as a sponsor, to provide an
insert to the goodie bag for the first South African Scrum Day in 2009. Since then a number
of people have been kind enough to recommend it and also to suggest improvements. The
agile practitioners I have been fortunate to meet and interact with have all in some measure
influenced what you find written here.
At the risk of omission I want to mention some who have had a significant influence on my
agile journey: Boris Gloger, my Scrum trainer and my first Scrum coach and mentor; Jim Cundiff,
who as MD of the Scrum Alliance encouraged and helped me to found the South African Scrum
User Group (SUGSA); the many people who selflessly gave their time to serve SUGSA during my
tenure: Neil, Sue, Steve, Mike, Carlo, Charl, Evan, Karen G, Karen V, Kevin, Neill and Alwyn; Tobias
Mayer, who encouraged me and promoted this booklet; Pete Behrens and Roger Brown, who
created the CSC programme; Andreas Schliep and Peter Beck, who have collaborated frequently
in training and coaching; Mike Freislich, my first partner at Scrum Sense; Carlo Kruger and
Marius de Beer, my business partners for two years from whom I learned much; David Anderson,
who introduced me to Kanban; Karen Greaves, who co-trained with me more times than I can
remember; and Sigi Kaltenecker, who has mentored me in organizational development over the
past four years.
In addition I have learned so much from other CSTs with whom I have co-trained, Lean/Agile
conference delegates with whom Ive had intensive conversations, participants at my training
classes and from clients I have consulted, coached and mentored during the past eight years.
You are too many to mention by name.
And I want to acknowledge Ken Schwaber, Jeff Sutherland and the other Scrum pioneers who
paved the way for all of us.
My sincere appreciation goes to the volunteers who selflessly took it on themselves to provide
translations of the second version into several popular languages:
You will find links to the soft-copy of this booklet and all available translations at www.agile42.
com/DoBetterScrum. Please send translation requests and offers to info@agile42.com.
I have tried to give proper credit where I have used the work of others. If I have quoted your work
and failed to acknowledge this, please let me know so that I can remedy the error.
70
References
Adkins, Lyssa (2010). Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches and
Project Managers in Transition. Addison-Wesley Professional.
Ambler, Scott M. and Lines, Mark (2012). Disciplined Agile Delivery: A Practitioners Guide to Agile
Software Delivery in the Enterprise. IBM Press.
Anderson, David J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business.
Blue Hole Press.
Argyris, Chris (1977). Double Loop Learning in Organizations.
http://hbr.org/1977/09/double-loop-learning-in-organizations/ar/1
Beaumont, Serge (2009). The Definition of Ready.
http://blog.xebia.com/2009/06/19/the-definition-of-ready/
Beck, Kent with Cynthia Andres (2005). Extreme Programming Explained (second edition). AddisonWesley Professional.
Beedle, Mike (2014). Enterprise Scrum. http://www.enterprisescrum.com/
Cockburn, Alistair (2007). Agile Software Development: The Cooperative Game (2nd edition).
Addison-Wesley Professional.
Cohn, Mike (2004). User Stories Applied. Addison-Wesley Professional.
Cohn, Mike (2006). Agile Estimating and Planning. Prentice Hall.
Cohn, Mike (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley
Professional.
Conway, Melvin (1968). Conways Law.
http://www.melconway.com/Home/Conways_Law.html
Coplien, James O. (1994). Borland Software Craftsmanship: A New Look at Process, Quality and
Productivity. https://sites.google.com/a/gertrudandcope.com/info/Publications/Patterns/Process/
QPW.
De Beer, Marius (2012). Data-driven Agility: An analysis of Agile adoption in North American
organisations. http://www.scrumsense.com/wp-content/uploads/2012/03/Data-driven-Agility.pdf.
De Beer, Marius (2013). Personal correspondence and conversations during 2012 & 2013.
Drucker Peter F. (2001). Management Challenges for the 21st Century. HarperBusiness.
Fowler, Martin and Highsmith, Jim (2001). The Agile Manifesto.
http://www.drdobbs.com/open-source/the-agile-manifesto/184414755.
Fowler, Martin (2005). The New Methodology.
http://www.martinfowler.com/articles/newMethodology.html.
Fox, Ron (1995). Shu Ha Ri. In THE IAIDO NEWSLETTER Volume 7 number 2 #54 FEB 1995. http://
www.aikidofaq.com/essays/tin/shuhari.html.
Gartner (2012). The End of the Waterfall as We Know It.
http://www.gartner.com/id=2127715. (Not available for individual purchase.)
71
VersionOne (2013): The State of Agile Development | 7th Annual Survey. http://www.versionone.
com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf
Wake, William (2003). INVEST in Good Stories, and SMART Tasks.
http://xp123.com/xplor/xp0308/index.shtml.
Weick, Karl E. and Sutcliffe, Kathleen M. (2001). Managing the Unexpected. Jossey-Bass.
Yip, Jason (2006). Its Not Just Standing Up: Patterns of Daily Stand-up Meetings
74