0 evaluări0% au considerat acest document util (0 voturi)
87 vizualizări49 pagini
Simon roberts and stefan roock are the Authors of "scrum for organisational change" their book is based on Ken Schwaber's book "the Enterprise and Scrum" simon was consulting at a large German insurance company helping them to introduce agile methods.
Simon roberts and stefan roock are the Authors of "scrum for organisational change" their book is based on Ken Schwaber's book "the Enterprise and Scrum" simon was consulting at a large German insurance company helping them to introduce agile methods.
Simon roberts and stefan roock are the Authors of "scrum for organisational change" their book is based on Ken Schwaber's book "the Enterprise and Scrum" simon was consulting at a large German insurance company helping them to introduce agile methods.
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