SI MON ROBERT S & ST EFAN ROOCK

SCENES F ROM A SCRUM

T RANSI T I ON
SCRUM I N T HE ENT ERPRI SE
SCRUMCENT ER GMBH & I T- AGI L E GMBH
Contents
Preface 7
Introductory Words from Simon 7
Introductory Words from Stefan 8
How this Book is Structured 8
About the Authors 9
1 Kickoff and Pilot 11
1.1 Role Play 11
1.2 Commentary 13
2 Scrum Enterprise Transition Decision 15
2.1 Role Play 15
2.2 Commentary 17
3 Transition Backlog 19
3.1 Role Play 19
3.2 Commentary 21
4 Roadmap Planning 23
4.1 Role Play 23
4.2 Commentary 24
4 simon roberts & stefan roock
5 Incremental Transition with Dimensional Planning 25
5.1 Role Play 25
5.2 Commentary 28
6 Human Resources 29
6.1 Role Play 29
6.2 Commentary 30
7 The Works Council Intervenes 31
7.1 Role Play 31
7.2 Commentary 33
8 Agile Engineering Practices 35
8.1 Role Play 35
8.2 Commentary 36
9 Success and Outlook 37
9.1 Role Play 37
9.2 Commentary 38
A Scrum for Organising Change 39
A.1 Building the Transition Team 40
A.2 Building the Transition Backlog 40
B Transition Backlog User Stories 43
B.1 User Stories for Change Leadership 43
Bibliography 47
Index 49
List of Figures
4.1 Transition Roadmap Planning with Prune the Product Tree 24
A.1 Scrum for Organising a Transition 39
A.2 Models and Approaches that Contribute to the Transition Backlog 41
Version: 1.21
Preface
Introductory Words from Simon
When I rst read Ken Schwabers book The Enterprise and Scrum
1
,
1
Ken Schwaber. The Enterprise and
Scrum. Microsoft Press, Redmond, WA,
USA, rst edition, 2007
in late 2007, I was consulting at a large German insurance company,
helping them to introduce agile methods (based on Scrum with eX-
treme Programming engineering practices). We had had some initial
success through hard work (mostly by the teams, Scrum Masters and
Product Owners!) with some carefully selected and valuable pilot
projects. It was time to start scaling up, consolidating these initial
successes by rolling out to more teams in different areas of the busi-
ness. At the same time we were hitting organisational impediments
that were slowing the teams down and realised that we needed:
1. Support from top management to help remove those tricky imped-
iments, and
2. A more strategic approach, where moving to agile is treated as an
enterprise transition.
Kens book inspired me to look into using Scrum itself to organise
the transition. We addressed both of these points and persuaded
the Chief Information Ofce of the company to take on the role of
Product Owner for a transition team, organised using Scrum. This
was supplemented by starting to build up a Scrum competence
centre within the organisation, whose primary role was to support
the development teams who actually generate the business value
trough coaching and training.
Of course, any large agile transition is not without its problemsa
large amount of inertia needs to be overcome to get a large organisa-
tion moving. Some ve years later, Scrum is very much alive at the
organisation in question. Starting in 2010, I was asked, together with
Stefan and other coaches, to help another large organisation move
to agile methods. This time I suggested right from the start that we
take a more strategic approach and we immediately started building
a transition team and organising ourselves using Scrum. Two years
8 simon roberts & stefan roock
later, around 1500 people have been trained in at least the basics of
Scrum (many are Certied ScrumMasters, Certied Scrum Product
Owners or Certied Scrum Developers) and there are around 60
stable Scrum teams sprinting on an ongoing basis. This book draws
on experiences gathered during these and other, smaller scale agile
transitions.
Introductory Words from Stefan
I started using eXtreme Programming in 1999 as a teacher in Univer-
sity. In 2000 I co-founded a company that used XP and later Scrum
for software development. We also offered coaching and training
agile XP and Scrum. In 2005 I co-founded it-agile to focus completely
on agile approaches and of course we applied agile to it-agile itself.
In 2008 I supported a Scrum enterprise transition (company size
roughly 200 employees) that started from the ITthe most common
origin of Scrum transitions. I looked after the company continuously
since then. The change is sustainable, a lot has been achieved and the
journey is still going on.
In 2010 I was asked to support a much larger transition effecting
4000 employees (yes, it is the same Simon mentioned). Simon, me
and other coaches worked together to move the enterprise. One in-
teresting aspect here is that the transition didnt start from the IT but
the business side of the company. We faced a lot of challenges. We
struggled with some of these and we succeeded with others. Two
years later Scrum is installed permanently for specic business areas.
The content of this book is based on these and several other Scrum
transitions I participated in or know of due to my it-agile colleagues.
How this Book is Structured
By means of nine scenes in the life of a Scrum Enterprise Transition,
this book summarises some of our experiences in helping organisa-
tions to transition to agile methods. All of the scenes are based on
what actually happened, although they took part at several different
organisations.
The main body of this book is based around the following nine
scenes:
Kickoff and Pilot, where a coach and the sponsor of the transition
talk about what the motivation for adopting agile methods (object-
ives) and the choice of a pilot project.
Scrum Enterprise Transition Decision, where the early results
are discussed with the CEO of the company, and a decision to
scenes from a scrum transition 9
organise the introduction of agile methods using Scrum is taken.
The Transition Backlog, where the transitions Product Owner and
a coach discuss the transition backlog (i.e. product backlog for the
transition).
Roadmap Planning, which shows how the innovation game
Prune the Product Tree can be used to give the transition a little
more structure.
Dimensional Planning, which shows how transition epics can be
broken down into smaller user stories that provide tangible benet
to the organisation by the end of every sprint.
Human Resources, which shows how some of the human re-
source management issues such as incentives and job descriptions
need to tackled during a large-scale introduction of Scrum.
The Works Council Intervenes, illustrating the importance of get-
ting the Works Council on board.
Agile Engineering Practices, which shows how resistance comes
from unexpected places sometimes.
Success and Outlook, where the sponsor and coach reect on
progress so far and discuss the next steps.
For each scene, the dialogue between the protagonists is followed by
a short commentary where we discuss the issues further.
Appendices describe our approach for using Scrum for organising
change and a selection of models that are useful when building the
transition backlog.
About the Authors
Simon Roberts
Simon Roberts MBA is a founder of ScrumCenter GmbH, and is
based in Berlin, Germany. He is an agile coach and Certied Scrum
Trainer with a background in software engineering. He has applied
Scrum (almost always with practices from eXtreme Programming)
since 2002 and lightweight/agile methods since the late 1990s.
He is currently focussed on helping executives in large organisa-
tions to achieve their goals through the use and support of agility.
He advocates a combination of Radical Management
SM
, Scrum and
Kanban in achieving these goals.
He can be contacted via email at simon.roberts@scrumcenter.com,
blogs at http://simonroberts.de and is @srob on twitter.
Simon Roberts
10 simon roberts & stefan roock
Stefan Roock
Stefan Roock is a senior consultant with it-agile, based in Hamburg,
Germany. Since 1999, he has taken part in dozens of projects as a
developer, coach, consultant and trainer. He has in-depth experiences
with Scrum, Kanban, eXtreme Programming and Feature-Driven-
Development.
He is an author and speaker on agile topics and is a Certied
Scrum Trainer.
He can be contacted via email at stefan.roock@it-agile.de, blogs at
http://stefanroock.de and is @StefanRoock on twitter.
Stefan Roock
1
Kickoff and Pilot
1.1 Role Play
Roles: Sponsor, Coach
Sponsor
Weve heard that everyone is going Agile. We dont really know
what that might mean for us, but we think that we should give it a
try.
Coach
OK. Do you have any objectives in mind? What do you want to
achieve?
Sponsor
Basically three things:
1. We heard that we should concentrate on making our customers
happy, the term customer delight seems to be very popular at
the moment and weve denitely got a problem in this area. Some
of our key mobile apps have only got one star ratings in the app
store. So increasing customer satisfaction is really important for
us.
2. Weve noticed that a lot of our staff members are going sick much
too often. We commissioned an employee survey and the main
factor seems to be burn out. Our staff are telling us it is the regular
reghting shortly before the end of projects that is the problem.
We have heard that Agile might help us with this.
3. And of course we want to be much faster in delivery so that costs
can be reduced.
12 simon roberts & stefan roock
Coach
I think that Scrum can help you to address the rst two points. For
example, Scrum will enable you to release more often, so that your
teams can use the feedback from the app store to drive customer
satisfaction higher. With Scrum the pace of work will be more even,
so that burn out should be less of a problem. We call this sustainable
pace. That is not to say that you wont be able to request people do
overtime when there are emergencies but overtime should no longer
be a standard part of projects.
Coach
Im not so sure about your third objective (faster and with lower costs
/ more productivity). At the start it might even be slower with agile,
because your team members and managers will need to learn new
ways of working. Your teams will become faster over time, probably
much faster than they are at the moment. Ive got another question,
whats the technical quality of your products like?
Sponsor
I dont really know. What I do know is that there are a lot of bugs
in one of our main products. My colleague told me that one of his
teams is currently using 40% of their capacity to tackle critical prob-
lem reports.
Coach
OKthat sounds like there is a technical quality problem! I pro-
pose that we initially focus on improving customer satisfaction, team
member satisfaction and quality. During the coaching engagement
we should meet regularly, and well have the opportunity to prioritise
the objectives differently and to agree different objectives if necessary.
Sponsor
Sounds good. I agree.
Coach
Remember: if we implement this carefully, your team will be faster
and more effective and their productivity will be better than ever
before.
scenes from a scrum transition 13
Coach
We already spoke about a pilot and identied a product that is im-
portant and valuable but has minimal dependencies to other teams
and projects. This should give us the best possible chance of success
whilst delivering a really valuable result.
Sponsor
Yesit is the CDPCat Dating Platform (C2CCat to Cat of
course)its one of our most visible products. It is an iOS app that
is free to download and use. It should be very valuable for the users
and at the same time it should generate lots of leads for our other
services. CDP is quite self-contained and we will be able to identify
and assign a full-time team for the next release. The current problem
is that the app has a very bad app store ratingjust one starand
we need six months to develop each new version.
Coach
Then we should start right away! Ill train the team in the basics
next Monday and Ill help the Scrum team to create and estimate a
product backlog so that we can start the rst sprint on Friday.
Sponsor
Excellent, Im looking forward to the rst results!
1.2 Commentary
The goal of a Scrum introduction should not be doing Scrum. Scrum
is a means and not an end.
Scrum can increase productivity, quality, customer satisfaction,
employee satisfaction, ROI and reduce time-to-market. Dependent on
what the primary goal is, a different strategy and focus for the Scrum
introduction might be needed. Trying to achieve everything at once
leads to an unfocused fuzzy Scrum transition with less probability
of success. In particular, we recommend that you should choose the
pilot project according to the primary goal.
We recommend to be sharp and clear about what should be
achieved. Stephen Bungay recommends to answer the Spice Girls
question: Tell me what you want, what you really, really want.
2
Scrum Enterprise Transition Decision
2.1 Role Play
Roles: CEO, Coach
CEO
As far as I can see, the Scrum pilot project has turned out very well.
Im delighted.
Coach
Yes its been a real success.
CEO
Now I would like to achieve the same or even better results for all of
our projects and roll-out Scrum in the whole company. How can we
do that?
Coach
I propose that we organise your Scrum Enterprise Transition with
Scrum!
CEO
That sounds interesting. Can that really work? We are not developing
a product. Who would be the Product Owner? Who would be in the
team?
Coach
The product would be more effective Scrum development teams and
more agility in the organisation.
16 simon roberts & stefan roock
CEO
OK. And what about the roles?
Coach
The Product Owner in Scrum is responsible for the success of the
product. Who should be responsible for the success of the Scrum
transition and will be measured on its results?
CEO
Well, me!.
Coach
Then you would be the rst choice candidate as Product Owner.
CEO
Aha. But Ive already got too much to do. Does the Product Owner
have to be full-time?
Coach
For the Scrum transition I would rather have you as a not full-time
Product Owner than a deputy as a full-time Product Owner. But you
will need to make time to carry out your ownership of the transition.
At a minimum you should perform the transition backlog priorit-
isation and take part in sprint review meetings. If you dont have
time for that then perhaps the transition is not so important and you
should perhaps consider whether someone else should take on the
role.
CEO
Thats a lot clearer now. I think that I can make time. It wont be easy
but the Scrum transition is very important for us. So Im the PO.
Coach
And probably you should have a PO assistant who can support you.
CEO
I like assistants. Ill take one of those! And who should be in the
team?
scenes from a scrum transition 17
Coach
The transition team should be cross-functional and able to do the
transition. That will need a mixture of senior managers and experts.
CEO
And such a group of jokers can organise themselves?
Coach
Thats why a transition team needs a Scrum Master. I offer to take on
that role.
CEO
(relieved)
The job is yours!.
2.2 Commentary
A Scrum transition is a complex challenge that should be approached
with an inspect & adapt mindset. Therefore it is quite natural to
introduce Scrum by using Scrum. The result (i.e. product) of the
transition is an agile organisation.
The Scrum transition team needs to have the team members that
can make the change happen. This includes managers. The Product
Owner should be a top manager who is really committed to the
Scrum transition. In an appendix we look at factors affecting the
makeup of the transition Scrum team.
3
Transition Backlog
3.1 Role Play
Roles: Product Owner of Transition Team, Coach
Product Owner of Transition Team
I already prepared some user stories for the transition backlog.
Would you have a look at them?
Coach
Sure. Lets take a look at what you have.
Product Owner of Transition Team
Here we go:
As the CEO I want to cut down time-to-market to 6 months so that
we react to the market.
As the CEO I want to double customer satisfaction to stabilise our
customer base.
As the CEO I want to have transparency on product performance
so that I can decide on what product products to invest in.
As a Product Owner I want to work directly with customers and
users so that I can incorporate their feedback directly into the
product backlog.
As a Product Owner I want to start development with roughly
sketched features we that we can learn and incorporate feedback
during development.
As a Product Owner I want to place orders to outsourcing partners
in a Scrum compatible way so that I can work with the external
team collaboratively.
20 simon roberts & stefan roock
As a Product Owner I want to place orders to outsourcing partners
within 2 weeks to start development early and reduce time-to-
market.
As a Product Owner I want to be empowered to prioritise the
product backlog so that I can actively management business value
and risk of the product.
As a Product Owner I want to work with the team in a long-term
relationship to establish trust and shared work habits.
As a Product Owner I want to have testers in my teams to ensure
the quality of the product.
As a team member I want to work co-located with the rest of my
team to increase the communication bandwidth.
As a team member I want to work with a stable test and integra-
tion environment from day 1 of the rst Sprint to ensure quality
from the beginning.
As a team member I want to be a full-time team member so that I
can focus and avoid multitasking.
As a ScrumMaster/Product Owner/team member I want to par-
ticipate in role specic Scrum training so that I have the basic
knowledge to work effectively with Scrum.
Coach
Thats great. I like your work so far. I was wondering if you have any
ideas on how we can actually facilitate the change?
Product Owner
Yes, John Kotters ideas on reasons why transitions fail looks in-
teresting. He turned it into a list of things not to forget during a
transition:
Establishing a Sense of Urgency
Creating a Guiding Coalition
Developing a Change Vision
Communicating the Vision
Empowering Others to Act on the Vision
Generating Short-term Wins
scenes from a scrum transition 21
Keeping the Change Rolling
Anchoring Changes in the Organisation
Coach
Your user stories address mainly the fth point Empowering Oth-
ers. We should write user stories for the other areas as well.
Product Owner of Transition Team
That sounds reasonable but wouldnt that lead to a fairly complex
transition backlog?
Coach
It could do. We can do some roadmap planning to see the bigger
picture.
3.2 Commentary
Enabling Scrum is not only a question of the mechanics. We need
a strong vision to get everybody on board and ultimately a Scrum
transition is also a cultural change.
4
Roadmap Planning
4.1 Role Play
Roles: Product Owner of Transition Team, Coach
Product Owner of Transition Team
Welcome to our roadmap planning meeting. Our coach wants to
show us an interesting technique to support roadmap planning. We
havent really managed to get on top of planning the transition to
create tangible results for the organisation.
With this technique we should be able to improve our transition
backlog.
Coach
Today we will play the innovation game Prune the Product Tree.
The idea is that the tree grows as the organisation is transformed into
an agile organisation. We will plan collaboratively by sticking post-its
representing change in our organisation (leaves or fruit in the tree)
and we will identify multiple releases, each of which will have tan-
gible benets (in particular focussed on more effective development
teams). Some of the basics, that must be addressed at the start will be
positioned in the roots of the tree. In every release we will focus on
transforming additional different parts of the organisation to Scrum.
In every release there will be some overarching topics, particularly
based on Kotters change leadership principles. We can think of these
principles as the constant breeze that keeps the transformation mov-
ing.
Coach
Lets try to ll the tree collaboratively and see if we can start to build
our roadmap!
24 simon roberts & stefan roock
Product Owner of Transition Team
Lets go! (pre-prepared post-its).
Figure 4.1: Transition Roadmap Plan-
ning with Prune the Product Tree
4.2 Commentary
We inspect & adapt our way through the Scrum transition and we
need guidance on the direction. Carrying out roadmap planning
for the transition with focus on the larger achievements without the
details provides this direction.
5
Incremental Transition with Dimensional Planning
5.1 Role Play
Roles: Product Owner of Transition Team, Coach
Coach
I was wondering if you are satised with the progress so far?
Product Owner of Transition Team
We are completing a lot of story points. In the last sprint almost 30%
more than in the previous sprint. I think it is going pretty well.
Coach
Have you noticed an improvement in the organisation in terms of
more agility?
Product Owner of Transition Team
Well not really!
Coach
You are working hard and creating a lot of concepts and PowerPoint
presentations. However, there is no discernible improvement in the
organisation, it is working the same after 2 sprints as it was before
the start of the transition. Weve only got a real product increment
if there is a demonstrable change in the organisations effectiveness
(more agility), no matter how small.
26 simon roberts & stefan roock
Product Owner of Transition Team
Youre right. But how can we do that? We split the epic in the trans-
ition backlog into smaller stories which can be completed in a sprint
but there is only progress when the complete epic is done and that
will take many sprints. Perhaps we should work without sprints?
Coach
You are practically doing that already. You dont deliver a product in-
crement at the end of each sprint. I dont want to give up so quickly!
Id like us to try a different approach to splitting epics into smaller
stories. Are you up for it?
Product Owner of Transition Team
Of course!
Coach
So Id like to explain the concept of dimensional planning. With
dimensional planning, you can divide an epic by means of the depth
of the implementation of a piece of functionality or change in an
organisation. We can use a road metaphor:
The most rudimentary depth is the dirt track, which represents
a manual workaround or manual process. The objective of the
change can be reached even when the approach is uncomfortable
and prone to errors. For an order management system that could
mean that the user must execute an SQL script and paste the res-
ults in a word template.
The next depth is a cobblestone road, which represents a bare
minimum implementation of the change. For our order manage-
ment system that could mean that the invoice will be generated
automatically but will only contain the basic information such as
address, date, total amount and tax amount.
The next depth is an asphalted road, which represents a decent
implementation of the change. In our order management system
we introduce the detailed breakdown of the order, discount and
early payment discount.
and nally, we have a highway, which represents a full implement-
ation of the change. Our order management system could include
additional functionality for personalising the layout of invoices.
scenes from a scrum transition 27
Product Owner of Transition Team
Thats a very interesting new perspective. Ive got an epic here thats
concerned with engaging suppliers for outsourcing purposes. We
want our purchasing department to offer a more agile engagement
approach:
As a Product Owner for a development team, I want to engage sup-
pliers on a time and materials basis so that for agile projects we wont
be constrained to use only xed price contracts.
Up to now we have broken this down into the following stories:
1. Explain Scrum to the purchasing manager.
2. Develop a concept for engaging on the basis of time and materials.
3. Get the agreement of the purchasing manager for the concept.
4. Derive concrete instructions for the purchasing team members
from the concept.
5. Explain the instructions to the purchasing team members.
How would that look in dimensional planning?
Coach
We need to identify the smallest possible version of this epic that
when taken alone still makes some sense. What do you think?
Product Owner of Transition Team
(Over to audience - working in small groups)
Perhaps we could break the epic down into the following stories:
1. A pilot project is ordered as a xed-price project with acceptance
carried out completely by the Product Owner (and not by the QA
or by purchasing departments).
2. A contract template is prepared and established which enables
acceptance to be in the hands of Product Owners.
3. A pilot project is run as a xed-price project with the possibility
for requirements to be exchanged for others as long as work hasnt
started (Money for Nothing, Change for Free).
4. This contract form is encapsulated in a template which can be
reused.
28 simon roberts & stefan roock
5. A pilot project is run with a xed-price but where the supplier
makes no commitments about the amount of functionality that
will be delivered (design to cost).
6. This contract form is encapsulated in a template which can be
reused.
7. A pilot project is run on a pure time and materials basis.
8. This contract form is encapsulated in a template which can be
reused.
Coach
It looks good. Every story is a small step, and each step represents a
small improvement. Do you think that each of the the stories can be
completed within a sprint?
Product Owner of Transition Team
Yes I think soobviously Ill have to ask the team but it looks good
so far. We will denitely try this technique. Thank you very much!
5.2 Commentary
It is not obvious how to create product increments of the Scrum
transition every few weeks. Since the product of the transition team
is an agile organisation, the product increments should be a some-
how more agile organisation. Dimensional Planning is a great tool to
shrink changes to the organisation so that they t into typical sprint
lengths.
6
Human Resources
6.1 Role Play
Roles: Human Resources Manager, Coach
Coach
Thanks for agreeing to see me. Id like to talk with you about a
couple of issues that have been surfaced as part of the agile trans-
ition. We made some good progress. Customer satisfaction improved
and more people download your apps. We also noticed that some
of the managers have incentive programmes in place that are not
very well aligned with product success. Their bonuses often relate
to in-time delivery of releases not product success. Sometimes this
is leading them to make decisions that harm the product success but
ensures their bonussuch as delivering an incomplete and buggy
version of the product on time instead of delaying it until the quality
is right.
HR Manager
I understand. What could we do as an alternative?
Coach
I suggest to dene a bonus for the whole team instead of bonuses for
the managers only.
HR Manager
I can imagine that. But we have to think though the idea. That would
be a large change and we would need consulting support. Anything
else?
30 simon roberts & stefan roock
Coach
Yes. We recognised that some employees, especially Product Owners
and Scrum Masters, feel a bit lost. They say that their career options
are less clear now.
HR Manager
Then we should create job descriptions for Product Owners and
Scrum Masters and anchor them within our career and HR develop-
ment systems.
Coach
That sounds great. There is one issue left. We have recognised that
recruiting staff focuses on technical skills only. But it is important to
have a good mix of personalities within a team as well. And while a
specialisation is useful Scrum team members need to be generalists
as well. We call these people generalising specialists and they have
a T-shaped skill set. They have one or two specialisations like Java
programming and basics skills in other disciplines like testing and
database administration. Do you have an idea how to recruit these
people in the future?
HR Manager
No, not really. Currently the functional managers are responsible for
recruiting new employees. Many managers tend to choose employees
with personalities and skills similar to their own.
Coach
We dont need a solution immediately. Lets write some User Stories
with the three issues we discussed. The Product Owner of the trans-
ition will prioritise the User Stories within the transition backlog.
6.2 Commentary
Just working with product teams is not enough to succeed with a
Scrum enterprise transition. Other departments of the company are
more or less affected and put constraints on the teams. The trans-
ition team has to deal with these interrelations to make the whole
company more agile.
7
The Works Council Intervenes
7.1 Role Play
Roles: Programmer 1, Coach
Coach
Hi. How are you?
Programmer 1
It is a bit chaotic here in the moment. The works council intervened.
Coach
To what extent?
Programmer 1
I registered for the retrospective training that was offered in the con-
text of the Scrum transition. But the works council cancelled the
training.
Coach
But why?
Programmer 1
Since they dont know what this training is about.
Coach
OK. It should be possible to explain what the training is about to the
works council. I think we should meet with them.
32 simon roberts & stefan roock
Programmer 1
But that was only the beginning. The works council forbade team
Delta to use their task-board any longer.
Coach
What the hell?
Programmer 1
The task board shows who is working on what. The task board
makes the individual performance of the team members transpar-
ent and comparable.
Coach
I can even understand thatin a way. Did anybody from team Delta
complain about the task-board?
Programmer 1
No, quite the opposite. Every member of team Delta wants to stay
with the task-board. But the works council fear that this could result
in a precedent that forces every employee to show what he does
on a detailed level. Therefore one arbitrary employee complaining
about the task-board of another team is sufcient input for the works
council to get into action.
Coach
Heavy stuff.
Programmer 1
And still there is more to come. The works council also prohibited
developers from doing Coding Dojos.
Coach
I cant believe that. Developers do Coding Dojos to enhance their
development skills. How could that possibly be evil?
Programmer 1
In the Coding Dojo it becomes very visible for every participant how
good everybody else is. Similar to the task-board the Coding Dojo
scenes from a scrum transition 33
could be used for individual performance evaluation and compar-
ison.
Coach
I see, there is still a lot for us to do.
7.2 Commentary
This is a genuine issue in many organisations. After all, the works
council is there to protect the interests of the employees and the
council might see increased transparency as a threat. Our advice is to
involve the works council in the transition:
Get them onboard and negotiate an agreement about the introduc-
tion of increased transparency and more exible working. In some
organisations this might be a lengthy process, nevertheless, it is
not worth the risk to the transition of not doing it.
Put in safeguards to make sure that transparency will not be used
to hound notionally weaker staff members. For example, Coding
Dojos should be open for team members but not, perhaps, man-
agers.
Keep the emphasis on continuous improvement for teams rather
than identifying who is the weakest link.
8
Agile Engineering Practices
8.1 Role Play
Roles: Programmer 2, Coach
Coach
What is the biggest problem from your point of view?
Programmer 2
We have tons of bugs in the production system. Quality assurance
doesnt work properly. I think the testers need coaching.
Coach
Ah. That is not the way Scrum handles the situation. The goal is to
deliver high quality in the rst place. We dont try to test quality into
the system after the fact.
Programmer 2
How could that be possible?
Coach
One popular practice is Test Driven Development (TDD). You pro-
gram automated unit tests before you write production code. That
way you ensure a high coverage with automated tests. It is proven
that TDD decreases the bug count and increases the quality of the
internal software design.
Programmer 2
(Opens a drawer and puts a document on his desk)
36 simon roberts & stefan roock
This is my employment contract.
(skims through the document)
It doesnt say that I have to test. Therefore I wont.
Coach
Hrmpf. OK. What about Pair Programming? Two developers pair in
a front of one computer and program together. There is a continuous
peer review and a lot of errors are detected and corrected immedi-
ately.
Programmer 2
That sounds plausible, but as a man you cant possibly do such
things!
8.2 Commentary
Technical staff can also nd it difcult to make the change to agile.
It requires more exibility, for example, everyone needs to contrib-
ute to testing, even programmers, some of which might consider
themselves too important to do such work. It is important that man-
agement sends a consistent message herei.e. that working outside
of a persons core speciality is not only allowed but expected. This
can be challenging for functional managers (e.g. for the manager of
a test department or of a team of Java programmers), who will most
likely feel threatened by their people needing to work outside of their
speciality. They often raise an argument about efciency, saying for
example, that it cannot possibly be the right thing to do for expensive
programmers to do the work of relatively less expensive testers. This
is an example of the usually mistaken belief that optimal utilisation
results in the best results for the company. The reserve is usually
trueoptimal utilisation of a particular team member usually results
in suboptimal team results and hence suboptimal outcome generation
from the whole team.
9
Success and Outlook
9.1 Role Play
Roles: Sponsor, Coach
Coach
Hello. I remember our rst meeting a year ago when we talked about
your goals for the agile transition. What was achieved?
Sponsor
Hmm. Customer satisfaction has increasedour rst Scrum pilot
product now has a three and a half stars rating in the app store and
several other products are rated higher today than one year ago.
Statistics about bugs in production show that the bug rate decreased
by 40% relative to one year ago.
We have also just nalised a new agreement with the works coun-
cil so that Scrum is now ofcially part of the way we work. In partic-
ular:
1. The Scrum roles are now ofcially anchored in the career paths.
2. Flexibility is now part of every team members agreed job descrip-
tion so that, for example, programmers can also test.
3. Self-organisation is now ofcially accepted by the works council
so that teams can genuinely gure out how to reach objectives
themselves.
Its going to be really difcult to get rid of Scrum now (not that we
want to!). That is very positive. By the way, I havent noticed the
speedup that you promised yet.
38 simon roberts & stefan roock
Coach
Thats some great progress and it was very challenging to overcome
some the organisational impediments and there is still much room
for improvement. By the way: I never promised a speedup. But I still
think we can improve productivity when we focus on impediment
removal and support of the teams.
Sponsor
Lets have a look at the topmost items in the transition backlog:
1. Introduction of Net Promoter Score (NPS) - the ultimate question:
1 1
Frederick Reichheld and Rob Markey.
The Ultimate Question 2.0: How Net
Promoter Companies Thrive in a Customer-
Driven World. Harvard Business Press,
Boston, Mass., revised and expanded
edition, 2011
"Whats the probability that you would recommend this product
to a friend or colleague?" We want to use the NPS for all products
so that we get direct and fast feedback about customer satisfac-
tion. This feedback will help the Product Owners to prioritise the
product backlogs.
2. Introduction of continuous deployment. A lot of teams do great
work and develop products fast. But we still need too much time
until the products are shipped to the customers. This goes hand in
hand with the Net Promoter Score. When we measure the NPS we
want to react fast.
3. Educate more internal Scrum coaches. We dont want to be de-
pendent on external coaches forever. Every business unit should
have its own Scrum coaches.
Im looking forward to the future - especially to really delighting our
customers.
9.2 Commentary
When starting with the Scrum transition expectations may be too
high. These expectations may not be met but still the company typ-
ically improves a lot. Or as one of our clients phrased it: We didnt
achieve what we wished for in the beginning. Now we have a clearer
picture of what is possible. With this picture in mind we achieved
really a lot.
A
Scrum for Organising Change
Scrum can be a very effective way of organising change initiatives.
When used for organising change:
The Product Owner, should be a senior person (empowered and
inuential), often this will be the sponsor of the change. Ideally
the Product Owner should be a member of the C-suite (e.g. CTO
or CIO).
The team should form what John Kotter calls a powerful leading
coalition
1
.
1
John Kotter. Leading Change. Harvard
Business Review Press, 1st edition, 1996
The transition team will also need a Scrum Master. This might
initially be a coach from a company that helps the organisation
to move to agile methods (as in the examples in this book) or
an experienced internal Scrum Master. In the former case, we
recommend to moving to an internal person as Scrum Master so
that the organisation is not dependent on external consultants in
the long term.
Figure A.1: Scrum for Organising a
Transition
40 simon roberts & stefan roock
A.1 Building the Transition Team
The team should form what John Kotter calls a powerful leading
coalition
2
. When building the team, care should be taken to ensure
2
John Kotter. Leading Change. Harvard
Business Review Press, 1st edition, 1996
that the following characteristics are covered:
Position power: key players/main line managers so that those left
out cannot easily block.
Expertise: so that informed and intelligent decisions are made.
Credibility: enough people with good reputations so that its guid-
ance will be credible with others.
Leadership: are there enough proven leaders in the team?
A.2 Building the Transition Backlog
The transition backlog (i.e. the product backlog for a transition team),
will be composed of items which facilitate the change and items that
are directly concerned with making the change.
Backlog Items for Facilitating the Transition
Kotters Leading Change provides inspiration for appropriate back-
log items to get the change going and to keep it rolling. Another rich
source of ideas for backlog items comes from the patterns described
by Mary Manns and Linda Rising in Fearless Change: Patterns for
Introducing New Ideas
3
.
3
Mary Manns and Linda Rising. Fear-
less Change: Patterns for Introducing New
Ideas. Addison-Wesley, 1 edition, 2004
Backlog Items that Represent Change
Other backlog items will be directly concerned with making the
necessary changes. For example:
Transitioning a business unit or department to agile.
Introducing an agile compatible approach for outsourcing work to
a supplier.
Introducing an agile compatible incentives.
scenes from a scrum transition 41
Figure A.2: Models and Approaches
that Contribute to the Transition Back-
log
B
Transition Backlog User Stories
This section contains example transition backlog stories. These in-
clude stories for facilitating the change which are inspired by various
change management and leadership approaches (e.g. by Kotters
Change Leadership and Rising and Manns Fearless Change),
as well as stories associated with actually transforming parts of the
organisation to agile. The latter includes service departments (e.g.
human resources and purchasing) and value generating business
units.
B.1 User Stories for Change Leadership
Sense of Urgency
As an employee
I need to understand why the agile transition is necessary
so that I can give it my full support
Acceptance Criteria
The necessity for the transition has been communicated (e.g. by
publishing the true state of customer satisfaction)
When asked, employees can explain the reason behind the trans-
ition
Powerful Guiding Coalition
As the transition Scrum team
we need to be a powerful guiding coalition
to maximise our effectiveness
Acceptance Criteria
The transition team should include people with:
44 simon roberts & stefan roock
Position power: key players/main line managers so that those
left out cannot easily block
Expertise: so that informed and intelligent decisions are made
Credibility: enough people with good reputations so that its
guidance will be credible with others
Leadership: are there enough proven leaders in the team?
Create a Vision
As members of the senior management team
we need to understand the vision behind the transition
so that we understand it and give our support for it
Acceptance Criteria
Vision created
Vision includes measurable objectives for introducing agile
(acceptance criteria for the transition)
Vision fully supported by senior management team
Communicate the Vision
As employees
we want to understand the vision behind the transition
so that we understand where we are heading
Acceptance Criteria
Vision communicated using multiple channels (internal blogs,
all-hands-meetings, workshops, training etc.)
Communication is continuousit needs to continue as a back-
ground activity indenitely
90% of surveyed employees can state the vision and explain
why it is important
Empower Others to ActScrum Product Owners
As a Product Owner of a development team
I need to be empowered to make business decisions about my product
so that I can ll the Product Owner role effectively
Acceptance Criteria
PO holds the budget for the product after initial approval
PO can make nal decisions about feature inclusion and priorit-
isation/ordering
scenes from a scrum transition 45
Empower Others to ActScrum Masters
As a Scrum Master
I need to be empowered to uphold the rules of Scrum and protect my
team
so that my team has an environment in which it can be be effective
Acceptance Criteria
The Scrum Master role is taken seriously by managers and other
Scrum Team members
Managers and stakeholders respect the efforts of the Scrum
Master to protect the team
Empower Others to ActScrum Development Teams
As a development team
we want to be empowered to make technical decisions about our
product
to maximise our motivation and identication with the product
Acceptance Criteria
The team makes decisions about realisation, with minimum con-
straints
No approval is required outside of the team for work carried
out by the team (PO accepts or rejects)
The architecture is owned by the team (or teams for multi-team
Scrum) within the constraints of the enterprise architecture
The team is autonomousthe team does not need to go outside
the team to get work done on a regular basis
Create Quick Wins
As the transition Scrum team
we need to implement quick wins
to increase acceptance of the transition
Acceptance Criteria
Quick wins with positive outcomes identied and delivered on an
ongoing basis.
Success stories from quick wins captured and communicated
within the organisation.
46 simon roberts & stefan roock
Keep the Change Rolling
As the transition Scrum team
we need to continuously identify and transition new parts of the or-
ganisation to agile
so that the change does not lose momentum
Acceptance Criteria
New parts of the business to transition identied
Agreement with owners of the part of the organisation achieved
Coaching capacity identied
Coaching has started
Anchor Changes in the Organisation
As an agile organisation
we want to anchor agility in the organisations DNA
so that agile is robust and sustainable
Acceptance Criteria
Are the changes part of the story that everyone tells about the way
that we do things here?
Bibliography
[1] John Kotter. Leading Change. Harvard Business Review Press, 1st
edition, 1996.
[2] Mary Manns and Linda Rising. Fearless Change: Patterns for
Introducing New Ideas. Addison-Wesley, 1 edition, 2004.
[3] Frederick Reichheld and Rob Markey. The Ultimate Question 2.0:
How Net Promoter Companies Thrive in a Customer-Driven World.
Harvard Business Press, Boston, Mass., revised and expanded
edition, 2011.
[4] Ken Schwaber. The Enterprise and Scrum. Microsoft Press, Red-
mond, WA, USA, rst edition, 2007.
Index
Agile Engineering Practices, 9, 35
Certied Scrum Developer, 8
Certied Scrum Product Owner, 8
Certied ScrumMaster, 8
Coding Dojo, 32
design to cost, 28
Dimensional Planning, 9, 25
employment contract, 36
Enterprise Transition, 7, 8, 15
eXtreme Programming, 7, 8
Fearless Change, 40, 43
xed-price, 27
Human Resources, 9, 29, 43
Kotter, 20, 23, 39, 40
Money for Nothing, Change for Free,
27
Net Promoter Score, 38
Pair Programming, 36
Product Owner, 7, 9, 17
Prune the Product Tree, 9, 23
purchasing, 27, 43
Roadmap Planning, 9, 23, 24
Scrum Master, 7, 39
task board, 32
Test Driven Development, 35
time and materials, 28
Transition Backlog, 9, 40, 43
Transition Team, 7, 17, 39, 40
Works Council, 9, 31