Scenes From a Scrum Transition

S I M O N R O B E R T S & S T E FA N R O O C K

S C E N E S F R O M A S C R U MT R A N S I T I O N

S C R U M I N T H E E N T E R P R I S E

S C R U M C E N T E R G M B H & I T- A G I L E G M B H

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 first read Ken Schwaber’s book “The Enterprise and Scrum”1, 1 Ken Schwaber. The Enterprise andScrum. Microsoft Press, Redmond, WA,USA, first 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 initialsuccess through hard work (mostly by the teams, Scrum Masters andProduct Owners!) with some carefully selected and valuable pilotprojects. It was time to start scaling up, consolidating these initialsuccesses by rolling out to more teams in different areas of the busi-ness. At the same time we were hitting organisational impedimentsthat 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 anenterprise transition.

Ken’s book inspired me to look into using Scrum itself to organisethe transition. We addressed both of these points and persuadedthe Chief Information Office of the company to take on the role ofProduct Owner for a transition team, organised using Scrum. Thiswas supplemented by starting to build up a Scrum competencecentre within the organisation, whose primary role was to supportthe development teams who actually generate the business valuetrough coaching and training.

Of course, any large agile transition is not without its problems—alarge amount of inertia needs to be overcome to get a large organisa-tion moving. Some five years later, Scrum is very much alive at theorganisation in question. Starting in 2010, I was asked, together withStefan and other coaches, to help another large organisation moveto agile methods. This time I suggested right from the start that wetake a more strategic approach and we immediately started buildinga transition team and organising ourselves using Scrum. Two years


later, around 1500 people have been trained in at least the basics ofScrum (many are Certified ScrumMasters, Certified Scrum ProductOwners or Certified Scrum Developers) and there are around 60

stable Scrum teams sprinting on an ongoing basis. This book drawson experiences gathered during these and other, smaller scale agiletransitions.

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 Scrumfor software development. We also offered coaching and trainingagile XP and Scrum. In 2005 I co-founded it-agile to focus completelyon agile approaches and of course we applied agile to it-agile itself.

In 2008 I supported a Scrum enterprise transition (company sizeroughly 200 employees) that started from the IT—the most commonorigin of Scrum transitions. I looked after the company continuouslysince then. The change is sustainable, a lot has been achieved and thejourney is still going on.

In 2010 I was asked to support a much larger transition effecting4000 employees (yes, it is the same Simon mentioned). Simon, meand other coaches worked together to move the enterprise. One in-teresting aspect here is that the transition didn’t start from the IT butthe business side of the company. We faced a lot of challenges. Westruggled with some of these and we succeeded with others. Twoyears later Scrum is installed permanently for specific business areas.

The content of this book is based on these and several other Scrumtransitions 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 onwhat actually happened, although they took part at several differentorganisations.

The main body of this book is based around the following ninescenes:

• Kickoff and Pilot, where a coach and the sponsor of the transitiontalk about what the motivation for adopting agile methods (object-ives) and the choice of a pilot project.

• Scrum Enterprise Transition Decision, where the early resultsare 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 transition’s Product Owner anda coach discuss the transition backlog (i.e. product backlog for thetransition).

• Roadmap Planning, which shows how the innovation game“Prune the Product Tree” can be used to give the transition a littlemore structure.

• Dimensional Planning, which shows how transition epics can bebroken down into smaller user stories that provide tangible benefitto 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 descriptionsneed 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 comesfrom unexpected places sometimes.

• Success and Outlook, where the sponsor and coach reflect onprogress so far and discuss the next steps.

For each scene, the dialogue between the protagonists is followed bya short commentary where we discuss the issues further.

Appendices describe our approach for using Scrum for organisingchange and a selection of models that are useful when building thetransition backlog.

About the Authors

Simon Roberts

Simon Roberts MBA is a founder of ScrumCenter GmbH, and isbased in Berlin, Germany. He is an agile coach and Certified ScrumTrainer with a background in software engineering. He has appliedScrum (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 ManagementSM, Scrum andKanban in achieving these goals.

He can be contacted via email at [email protected],blogs at http://simonroberts.de and is @srob on twitter.

Simon Roberts


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 adeveloper, coach, consultant and trainer. He has in-depth experienceswith Scrum, Kanban, eXtreme Programming and Feature-Driven-Development.

He is an author and speaker on agile topics and is a CertifiedScrum Trainer.

He can be contacted via email at [email protected], blogs athttp://stefanroock.de and is @StefanRoock on twitter.

Stefan Roock

1Kickoff and Pilot

1.1 Role Play

Roles: Sponsor, Coach

Sponsor

We’ve heard that everyone is going “Agile”. We don’t really knowwhat that might mean for us, but we think that we should give it atry.

Coach

OK. Do you have any objectives in mind? What do you want toachieve?

Sponsor

Basically three things:

1. We heard that we should concentrate on making our customershappy, the term “customer delight” seems to be very popular atthe moment and we’ve definitely got a problem in this area. Someof our key mobile apps have only got one star ratings in the appstore. So increasing customer satisfaction is really important forus.

2. We’ve noticed that a lot of our staff members are going sick muchtoo often. We commissioned an employee survey and the mainfactor seems to be burn out. Our staff are telling us it is the regularfirefighting 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 costscan be reduced.


Coach

I think that Scrum can help you to address the first two points. Forexample, Scrum will enable you to release more often, so that yourteams can use the feedback from the app store to drive customersatisfaction higher. With Scrum the pace of work will be more even,so that burn out should be less of a problem. We call this sustainablepace. That is not to say that you won’t be able to request people doovertime when there are emergencies but overtime should no longerbe a standard part of projects.

Coach

I’m 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 newways of working. Your teams will become faster over time, probablymuch faster than they are at the moment. I’ve got another question,what’s the technical quality of your products like?

Sponsor

I don’t really know. What I do know is that there are a lot of bugsin one of our main products. My colleague told me that one of histeams is currently using 40% of their capacity to tackle critical prob-lem reports.

Coach

OK—that sounds like there is a technical quality problem! I pro-pose that we initially focus on improving customer satisfaction, teammember satisfaction and quality. During the coaching engagementwe should meet regularly, and we’ll have the opportunity to prioritisethe 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 fasterand more effective and their productivity will be better than everbefore.


Coach

We already spoke about a pilot and identified a product that is im-portant and valuable but has minimal dependencies to other teamsand projects. This should give us the best possible chance of successwhilst delivering a really valuable result.

Sponsor

Yes—it is the “CDP—Cat Dating Platform (C2C—Cat to Cat ofcourse)”—it’s one of our most visible products. It is an iOS app thatis free to download and use. It should be very valuable for the usersand at the same time it should generate lots of leads for our otherservices. CDP is quite self-contained and we will be able to identifyand assign a full-time team for the next release. The current problemis that the app has a very bad app store rating—just one star—andwe need six months to develop each new version.

Coach

Then we should start right away! I’ll train the team in the basicsnext Monday and I’ll help the Scrum team to create and estimate aproduct backlog so that we can start the first sprint on Friday.

Sponsor

Excellent, I’m looking forward to the first results!

1.2 Commentary

The goal of a Scrum introduction should not be doing Scrum. Scrumis a means and not an end.

Scrum can increase productivity, quality, customer satisfaction,employee satisfaction, ROI and reduce time-to-market. Dependent onwhat the primary goal is, a different strategy and focus for the Scrumintroduction might be needed. Trying to achieve everything at onceleads to an unfocused fuzzy Scrum transition with less probabilityof success. In particular, we recommend that you should choose thepilot project according to the primary goal.

We recommend to be sharp and clear about what should beachieved. Stephen Bungay recommends to answer the Spice Girls’question: “Tell me what you want, what you really, really want”.

2Scrum 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.I’m delighted.

Coach

Yes it’s been a real success.

CEO

Now I would like to achieve the same or even better results for all ofour projects and roll-out Scrum in the whole company. How can wedo that?

Coach

I propose that we organise your “Scrum Enterprise Transition” withScrum!

CEO

That sounds interesting. Can that really work? We are not developinga product. Who would be the Product Owner? Who would be in theteam?

Coach

The product would be more effective Scrum development teams andmore agility in the organisation.


CEO

OK. And what about the roles?

Coach

The Product Owner in Scrum is responsible for the success of theproduct. Who should be responsible for the success of the Scrumtransition and will be measured on its results?

CEO

Well, me!.

Coach

Then you would be the first choice candidate as Product Owner.

CEO

Aha. But I’ve already got too much to do. Does the Product Ownerhave to be full-time?

Coach

For the Scrum transition I would rather have you as a not full-timeProduct Owner than a deputy as a full-time Product Owner. But youwill 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 don’t havetime for that then perhaps the transition is not so important and youshould perhaps consider whether someone else should take on therole.

CEO

That’s a lot clearer now. I think that I can make time. It won’t be easybut the Scrum transition is very important for us. So I’m the PO.

Coach

And probably you should have a PO assistant who can support you.

CEO

I like assistants. I’ll take one of those! And who should be in theteam?


Coach

The transition team should be cross-functional and able to do thetransition. That will need a mixture of senior managers and experts.

CEO

And such a group of jokers can organise themselves?

Coach

That’s why a transition team needs a Scrum Master. I offer to take onthat role.

CEO

(relieved)The job is yours!.

2.2 Commentary

A Scrum transition is a complex challenge that should be approachedwith an inspect & adapt mindset. Therefore it is quite natural tointroduce Scrum by using Scrum. The result (i.e. product) of thetransition is an agile organisation.

The Scrum transition team needs to have the team members thatcan make the change happen. This includes managers. The ProductOwner should be a top manager who is really committed to theScrum transition. In an appendix we look at factors affecting themakeup of the transition Scrum team.

3Transition 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. Let’s take a look at what you have.


Here we go:

• As the CEO I want to cut down time-to-market to 6 months so thatwe react to the market.

• As the CEO I want to double customer satisfaction to stabilise ourcustomer base.

• As the CEO I want to have transparency on product performanceso that I can decide on what product products to invest in.

• As a Product Owner I want to work directly with customers andusers so that I can incorporate their feedback directly into theproduct backlog.

• As a Product Owner I want to start development with roughlysketched features we that we can learn and incorporate feedbackduring development.

• As a Product Owner I want to place orders to outsourcing partnersin a Scrum compatible way so that I can work with the externalteam collaboratively.


• As a Product Owner I want to place orders to outsourcing partnerswithin 2 weeks to start development early and reduce time-to-market.

• As a Product Owner I want to be empowered to prioritise theproduct backlog so that I can actively management business valueand risk of the product.

• As a Product Owner I want to work with the team in a long-termrelationship to establish trust and shared work habits.

• As a Product Owner I want to have testers in my teams to ensurethe quality of the product.

• As a team member I want to work co-located with the rest of myteam 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 first Sprint to ensure qualityfrom the beginning.

• As a team member I want to be a full-time team member so that Ican focus and avoid multitasking.

• As a ScrumMaster/Product Owner/team member I want to par-ticipate in role specific Scrum training so that I have the basicknowledge to work effectively with Scrum.

Coach

That’s great. I like your work so far. I was wondering if you have anyideas on how we can actually facilitate the change?

Product Owner

Yes, John Kotter’s ideas on “reasons why transitions fail” looks in-teresting. He turned it into a list of things not to forget during atransition:

• 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


• Keeping the Change Rolling

• Anchoring Changes in the Organisation

Coach

Your user stories address mainly the fifth point “Empowering Oth-ers”. We should write user stories for the other areas as well.


That sounds reasonable but wouldn’t that lead to a fairly complextransition backlog?

Coach

It could do. We can do some roadmap planning to see the biggerpicture.

3.2 Commentary

Enabling Scrum is not only a question of the mechanics. We needa strong vision to get everybody on board and ultimately a Scrumtransition is also a cultural change.

4Roadmap Planning

4.1 Role Play



Welcome to our roadmap planning meeting. Our coach wants toshow us an interesting technique to support roadmap planning. Wehaven’t really managed to get on top of planning the transition tocreate tangible results for the organisation.

With this technique we should be able to improve our transitionbacklog.

Coach

Today we will play the innovation game “Prune the Product Tree”.The idea is that the tree grows as the organisation is transformed intoan agile organisation. We will plan collaboratively by sticking post-itsrepresenting change in our organisation (leaves or fruit in the tree)and we will identify multiple releases, each of which will have tan-gible benefits (in particular focussed on more effective developmentteams). Some of the basics, that must be addressed at the start will bepositioned in the roots of the tree. In every release we will focus ontransforming additional different parts of the organisation to Scrum.In every release there will be some overarching topics, particularlybased on Kotter’s change leadership principles. We can think of theseprinciples as the constant breeze that keeps the transformation mov-ing.

Coach

Let’s try to fill the tree collaboratively and see if we can start to buildour roadmap!



Let’s 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 weneed guidance on the direction. Carrying out roadmap planningfor the transition with focus on the larger achievements without thedetails provides this direction.

5Incremental Transition with Dimensional Planning

5.1 Role Play


Coach

I was wondering if you are satisfied with the progress so far?


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 ofmore agility?


Well not really!

Coach

You are working hard and creating a lot of concepts and PowerPointpresentations. However, there is no discernible improvement in theorganisation, it is working the same after 2 sprints as it was beforethe start of the transition. We’ve only got a real product incrementif there is a demonstrable change in the organisation’s effectiveness(more agility), no matter how small.



You’re 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 sprintbut there is only progress when the complete epic is done and thatwill take many sprints. Perhaps we should work without sprints?

Coach

You are practically doing that already. You don’t deliver a product in-crement at the end of each sprint. I don’t want to give up so quickly!I’d like us to try a different approach to splitting epics into smallerstories. Are you up for it?


Of course!

Coach

So I’d like to explain the concept of dimensional planning. Withdimensional planning, you can divide an epic by means of the depthof the implementation of a piece of functionality or change in anorganisation. We can use a road metaphor:

• The most rudimentary depth is the dirt track, which representsa manual workaround or manual process. The objective of thechange can be reached even when the approach is uncomfortableand prone to errors. For an order management system that couldmean 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 bareminimum implementation of the change. For our order manage-ment system that could mean that the invoice will be generatedautomatically but will only contain the basic information such asaddress, date, total amount and tax amount.

• The next depth is an asphalted road, which represents a decentimplementation of the change. In our order management systemwe introduce the detailed breakdown of the order, discount andearly payment discount.

• and finally, we have a highway, which represents a full implement-ation of the change. Our order management system could includeadditional functionality for personalising the layout of invoices.



That’s a very interesting new perspective. I’ve got an epic here that’sconcerned with engaging suppliers for outsourcing purposes. Wewant our purchasing department to offer a more agile engagementapproach:

“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 won’tbe constrained to use only fixed 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 membersfrom 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 thatwhen taken alone still makes some sense. What do you think?


(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 fixed-price project with acceptancecarried out completely by the Product Owner (and not by the QAor by purchasing departments).

2. A contract template is prepared and established which enablesacceptance to be in the hands of Product Owners.

3. A pilot project is run as a fixed-price project with the possibilityfor requirements to be exchanged for others as long as work hasn’tstarted (“Money for Nothing, Change for Free”).

4. This contract form is encapsulated in a template which can bereused.


5. A pilot project is run with a fixed-price but where the suppliermakes no commitments about the amount of functionality thatwill be delivered (design to cost).


7. A pilot project is run on a pure time and materials basis.


Coach

It looks good. Every story is a small step, and each step represents asmall improvement. Do you think that each of the the stories can becompleted within a sprint?


Yes I think so—obviously I’ll have to ask the team but it looks goodso far. We will definitely try this technique. Thank you very much!

5.2 Commentary

It is not obvious how to create product increments of the Scrumtransition every few weeks. Since the product of the transition teamis an agile organisation, the product increments should be a some-how more agile organisation. Dimensional Planning is a great tool toshrink changes to the organisation so that they fit into typical sprintlengths.

6Human Resources

6.1 Role Play

Roles: Human Resources Manager, Coach

Coach

Thanks for agreeing to see me. I’d like to talk with you about acouple of issues that have been surfaced as part of the agile trans-ition. We made some good progress. Customer satisfaction improvedand more people download your apps. We also noticed that someof the managers have incentive programmes in place that are notvery well aligned with product success. Their bonuses often relateto in-time delivery of releases not product success. Sometimes thisis leading them to make decisions that harm the product success butensures their bonus—such as delivering an incomplete and buggyversion of the product on time instead of delaying it until the qualityis right.

HR Manager

I understand. What could we do as an alternative?

Coach

I suggest to define a bonus for the whole team instead of bonuses forthe managers only.

HR Manager

I can imagine that. But we have to think though the idea. That wouldbe a large change and we would need consulting support. Anythingelse?


Coach

Yes. We recognised that some employees, especially Product Ownersand Scrum Masters, feel a bit lost. They say that their career optionsare less clear now.

HR Manager

Then we should create job descriptions for Product Owners andScrum Masters and anchor them within our career and HR develop-ment systems.

Coach

That sounds great. There is one issue left. We have recognised thatrecruiting staff focuses on technical skills only. But it is important tohave a good mix of personalities within a team as well. And while aspecialisation is useful Scrum team members need to be generalistsas well. We call these people generalising specialists and they havea T-shaped skill set. They have one or two specialisation’s like Javaprogramming and basics skills in other disciplines like testing anddatabase administration. Do you have an idea how to recruit thesepeople in the future?

HR Manager

No, not really. Currently the functional managers are responsible forrecruiting new employees. Many managers tend to choose employeeswith personalities and skills similar to their own.

Coach

We don’t need a solution immediately. Let’s write some User Storieswith 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 aScrum enterprise transition. Other departments of the company aremore or less affected and put constraints on the teams. The trans-ition team has to deal with these interrelations to make the wholecompany more agile.

7The 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 thetraining.

Coach

But why?

Programmer 1

Since they don’t know what this training is about.

Coach

OK. It should be possible to explain what the training is about to theworks council. I think we should meet with them.


Programmer 1

But that was only the beginning. The works council forbade teamDelta to use their task-board any longer.

Coach

What the hell?

Programmer 1

The task board shows who is working on what. The task boardmakes the individual performance of the team members transpar-ent and comparable.

Coach

I can even understand that—in a way. Did anybody from team Deltacomplain about the task-board?

Programmer 1

No, quite the opposite. Every member of team Delta wants to staywith the task-board. But the works council fear that this could resultin a precedent that forces every employee to show what he doeson a detailed level. Therefore one arbitrary employee complainingabout the task-board of another team is sufficient input for the workscouncil to get into action.

Coach

Heavy stuff.

Programmer 1

And still there is more to come. The works council also prohibiteddevelopers from doing Coding Dojos.

Coach

I can’t believe that. Developers do Coding Dojos to enhance theirdevelopment skills. How could that possibly be evil?

Programmer 1

In the Coding Dojo it becomes very visible for every participant howgood everybody else is. Similar to the task-board the Coding Dojo


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 workscouncil is there to protect the interests of the employees and thecouncil might see increased transparency as a threat. Our advice is toinvolve the works council in the transition:

• Get them onboard and negotiate an agreement about the introduc-tion of increased transparency and more flexible working. In someorganisations this might be a lengthy process, nevertheless, it isnot worth the risk to the transition of not doing it.

• Put in safeguards to make sure that transparency will not be usedto hound notionally weaker staff members. For example, CodingDojos should be open for team members but not, perhaps, man-agers.

• Keep the emphasis on continuous improvement for teams ratherthan identifying who is “the weakest link”.

8Agile 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 assurancedoesn’t work properly. I think the testers need coaching.

Coach

Ah. That is not the way Scrum handles the situation. The goal is todeliver high quality in the first place. We don’t try to test quality intothe 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. Thatway you ensure a high coverage with automated tests. It is proventhat TDD decreases the bug count and increases the quality of theinternal software design.

Programmer 2

(Opens a drawer and puts a document on his desk)


This is my employment contract.(skims through the document)It doesn’t say that I have to test. Therefore I won’t.

Coach

Hrmpf. OK. What about Pair Programming? Two developers pair ina front of one computer and program together. There is a continuouspeer review and a lot of errors are detected and corrected immedi-ately.

Programmer 2

That sounds plausible, but as a man you can’t possibly do suchthings!

8.2 Commentary

Technical staff can also find it difficult to make the change to agile.It requires more flexibility, for example, everyone needs to contrib-ute to testing, even programmers, some of which might considerthemselves too important to do such work. It is important that man-agement sends a consistent message here—i.e. that working outsideof a person’s core speciality is not only allowed but expected. Thiscan be challenging for functional managers (e.g. for the manager ofa test department or of a team of Java programmers), who will mostlikely feel threatened by their people needing to work outside of theirspeciality. They often raise an argument about efficiency, saying forexample, that it cannot possibly be the right thing to do for expensiveprogrammers to do the work of relatively less expensive testers. Thisis an example of the usually mistaken belief that optimal utilisationresults in the best results for the company. The reserve is usuallytrue—optimal utilisation of a particular team member usually resultsin suboptimal team results and hence suboptimal outcome generationfrom the whole team.

9Success and Outlook

9.1 Role Play

Roles: Sponsor, Coach

Coach

Hello. I remember our first meeting a year ago when we talked aboutyour goals for the agile transition. What was achieved?

Sponsor

Hmm. Customer satisfaction has increased—our first Scrum pilotproduct now has a three and a half stars rating in the app store andseveral other products are rated higher today than one year ago.Statistics about bugs in production show that the bug rate decreasedby 40% relative to one year ago.

We have also just finalised a new agreement with the works coun-cil so that Scrum is now officially part of the way we work. In partic-ular:

1. The Scrum roles are now officially anchored in the career paths.

2. Flexibility is now part of every team member’s agreed job descrip-tion so that, for example, programmers can also test.

3. Self-organisation is now officially accepted by the works councilso that teams can genuinely figure out how to reach objectivesthemselves.

It’s going to be really difficult to get rid of Scrum now (not that wewant to!). That is very positive. By the way, I haven’t noticed thespeedup that you promised yet.


Coach

That’s some great progress and it was very challenging to overcomesome the organisational impediments and there is still much roomfor improvement. By the way: I never promised a speedup. But I stillthink we can improve productivity when we focus on impedimentremoval and support of the teams.

Sponsor

Let’s 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 NetPromoter Companies Thrive in a Customer-Driven World. Harvard Business Press,Boston, Mass., revised and expandededition, 2011

"What’s the probability that you would recommend this productto a friend or colleague?" We want to use the NPS for all productsso that we get direct and fast feedback about customer satisfac-tion. This feedback will help the Product Owners to prioritise theproduct backlogs.

2. Introduction of continuous deployment. A lot of teams do greatwork and develop products fast. But we still need too much timeuntil the products are shipped to the customers. This goes hand inhand with the Net Promoter Score. When we measure the NPS wewant to react fast.

3. Educate more internal Scrum coaches. We don’t want to be de-pendent on external coaches forever. Every business unit shouldhave its own Scrum coaches.

I’m looking forward to the future - especially to really delighting ourcustomers.

9.2 Commentary

When starting with the Scrum transition expectations may be toohigh. These expectations may not be met but still the company typ-ically improves a lot. Or as one of our clients phrased it: “We didn’tachieve what we wished for in the beginning. Now we have a clearerpicture of what is possible. With this picture in mind we achievedreally a lot.”

AScrum 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 andinfluential), often this will be the sponsor of the change. Ideallythe Product Owner should be a member of the C-suite (e.g. CTOor CIO).

• The team should form what John Kotter calls a “powerful leadingcoalition”1. 1 John Kotter. Leading Change. Harvard

Business Review Press, 1st edition, 1996

• The transition team will also need a Scrum Master. This mightinitially be a coach from a company that helps the organisationto move to agile methods (as in the examples in this book) oran experienced internal Scrum Master. In the former case, werecommend to moving to an internal person as Scrum Master sothat the organisation is not dependent on external consultants inthe long term.

Figure A.1: Scrum for Organising aTransition


A.1 Building the Transition Team

The team should form what John Kotter calls a “powerful leadingcoalition”2. When building the team, care should be taken to ensure 2 John Kotter. Leading Change. Harvard

Business Review Press, 1st edition, 1996that the following characteristics are covered:

• Position power: key players/main line managers so that those leftout 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 thatare directly concerned with making the change.

Backlog Items for Facilitating the Transition

Kotter’s Leading Change provides inspiration for appropriate back-log items to get the change going and to keep it rolling. Another richsource of ideas for backlog items comes from the patterns describedby Mary Manns and Linda Rising in “Fearless Change: Patterns forIntroducing New Ideas”3. 3 Mary Manns and Linda Rising. Fear-

less Change: Patterns for Introducing NewIdeas. Addison-Wesley, 1 edition, 2004

Backlog Items that Represent Change

Other backlog items will be directly concerned with making thenecessary changes. For example:

• Transitioning a business unit or department to agile.

• Introducing an agile compatible approach for outsourcing work toa supplier.

• Introducing an agile compatible incentives.


Figure A.2: Models and Approachesthat Contribute to the Transition Back-log

BTransition Backlog User Stories

This section contains example transition backlog stories. These in-clude stories for facilitating the change which are inspired by variouschange management and leadership approaches (e.g. by Kotter’s“Change Leadership” and Rising and Mann’s “Fearless Change”),as well as stories associated with actually transforming parts of theorganisation to agile. The latter includes service departments (e.g.human resources and purchasing) and value generating businessunits.

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. bypublishing 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:


– Position power: key players/main line managers so that thoseleft out cannot easily block

– Expertise: so that informed and intelligent decisions are made

– Credibility: enough people with good reputations so that itsguidance 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 continuous—it needs to continue as a back-ground activity indefinitely

– 90% of surveyed employees can state the vision and explainwhy it is important

Empower Others to Act—Scrum 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 fill the Product Owner role effectively

Acceptance Criteria

• PO holds the budget for the product after initial approval

– PO can make final decisions about feature inclusion and priorit-isation/ordering


Empower Others to Act—Scrum Masters

As a Scrum Master

I need to be empowered to uphold the rules of Scrum and protect myteam

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 otherScrum Team members

– Managers and stakeholders respect the efforts of the ScrumMaster to protect the team

Empower Others to Act—Scrum Development Teams

As a development team

we want to be empowered to make technical decisions about ourproduct

to maximise our motivation and identification 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 carriedout by the team (PO accepts or rejects)

– The architecture is owned by the team (or teams for multi-teamScrum) within the constraints of the enterprise architecture

– The team is autonomous—the team does not need to go outsidethe team to get work done on a regular basis

Create Quick Wins


we need to implement quick wins

to increase acceptance of the transition

Acceptance Criteria

• Quick wins with positive outcomes identified and delivered on anongoing basis.

– Success stories from quick wins captured and communicatedwithin the organisation.


Keep the Change Rolling


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 identified

• Agreement with “owners” of the part of the organisation achieved

• Coaching capacity identified

• Coaching has started

Anchor Changes in the Organisation

As an agile organisation

we want to anchor agility in the organisation’s DNA

so that agile is robust and sustainable

Acceptance Criteria

• Are the changes part of the story that everyone tells about the waythat we do things here?

Bibliography

[1] John Kotter. Leading Change. Harvard Business Review Press, 1stedition, 1996.

[2] Mary Manns and Linda Rising. Fearless Change: Patterns forIntroducing 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 expandededition, 2011.

[4] Ken Schwaber. The Enterprise and Scrum. Microsoft Press, Red-mond, WA, USA, first edition, 2007.

Index

Agile Engineering Practices, 9, 35

Certified Scrum Developer, 8

Certified Scrum Product Owner, 8

Certified 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

fixed-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

Date post:	26-Dec-2015
Category:	Documents
Upload:	okhou2
View:	18 times
Download:	4 times

Scenes From a Scrum Transition

Documents