Improving Collaboration and Planning With Lean Product Development: Patterns of Success and Failure. By Alan Shalloway

Transcription

1 Improving Collaboration and Planning With Lean Product Development: Patterns of Success and Failure By Alan Shalloway

2 Introduction "We cannot solve our problems with the same thinking we used when we created them." - Albert Einstein Many companies attempt to become Agile by taking the simplistic approach of adopting Scrum for a few teams and then trying to scale by continuing the team adoption of Scrum. Our experience is that they often then run into a set of challenges that either prevent scaling, or even result in losing some of the gains they ve achieved. We do not think this is a coincidence. Most large organizations find that scaling Scrum to be difficult. And it is. Achieving anything new across an organization is difficult. It is really more of a people problem than a technical problem. The vast success that Scrum has had at the team level has led many people to believe that it can have similar success across teams at the enterprise level. After all, an organization is merely a group of teams. Unfortunately the dynamics of teams of teams is quite different from the dynamics of teams of individuals. Scrum does not scale well. I do not think this statement is in dispute. I think what is in dispute is why. Scrum is a framework that has cross-functional teams self-organize and deliver software incrementally. There are many, good, power concepts here. However, these are all based around a close-knit team working on a reasonably defined problem adding specific value to a known customer. Software development at the enterprise level is both much more complex and much less defined. To solve this more complex problems new understanding is needed in the areas of organizational people dynamics and how to coordinate work across teams and how to create. Furthermore, a more holistic view of the problem other than a bottom-up team driven approach is needed. It is not Scrum s fault it will often not scale anymore than it is the fault of a hammer that it won t turn a screw well. Scrum, used properly, can be a very good team solution. But if you are trying to get to agility at scale, a larger framework to work from in order to avoid the risk of your Agile efforts stagnating is almost always useful. We must acknowledge the limitations of our good tools in order to find better ones. From our 1 work with hundreds of companies, ranging from teams of 4 to development groups of 4000, we ve seen patterns of success and failure in Agile initiatives. The patterns of failure have three common aspects: A focus on teams instead of an holistic, organizational approach A tendency towards a minimalistic framework without an underlying model on which to base decisions other than inspect and adapt Learning is achieved by working and then reflecting on if the work has been efficient. The focus is on learning at specific times. Conversely, we ve seen the following with the patterns of success: 1 When I refer to our I mean Net Objectives. We ve been helping companies with their software development efforts since 1999 and are one of the most experienced Scrum, XP, Kanban and Lean company in business. Copyright 2011, Net Objectives 2

3 A business-driven, holistic view A model that is useful to guide actions and assist in making decisions when challenges arise Learning is achieved by providing a continuous backdrop of what is happening along with our expected results. The focus is on continuous learning. Essentially, we ve come to the conclusion that an holistic, business-driven, approach that includes understanding how and software development works that focuses on the continuous education of our people is necessary for agility at a large scale. We believe that the patterns of stagnation of Agile adoption we ve seen are not due to people doing things wrong but is rather a pattern in the nature of the problem of achieving agility at scale. This book presents more effective methods to create Agile at scale in a software development organizations, whether they be product or IT oriented, then the common method of having teams learn Scrum and then attempt to coordinate with each other. The book starts by discussing the differences between business agility and team agility. This difference lays the groundwork for the needed shift in perspective that many in the Agile community have not made. Essentially this shift is to look at the enterprise as a complete system in order for it to become Agile instead of taking a bottom-up only approach. We will also use the models of product development flow to help us better understand that nature of the challenges we frequently encounter. These models will be presented as needed, so no prior understanding will be required of the reader. Is this Book For You? Patterns of Agile Stagnation Net Objectives has worked with hundreds of companies since our inception in We started out with technical training but within a year or two moved into Agile methods because it was clear technical practices were not always the problems teams were facing. We first started helping teams with extreme Programming (XP) and Scrum. When we saw challenges in scaling these methods we turned to Lean. When Kanban came on the scene we expanded our offerings to include that so that we could help even more organizations where Scrum seemed difficult or ineffective. In many ways we ve come full circle because much of our work now is helping companies use Scrum to get off the plateau they ve found themselves on. And, of course, we re still helping people with better design and programming methods. This book addresses many of the challenges we ve seen most companies starting with Scrum encounter when they attempt to go beyond a few teams. It also will provide insights into how to start at a larger scale. To us, Scrum is a good team framework that many people have attempted to take beyond its sweet spot. If you are a fan of Scrum, please don t take this a negative statement about it. Scrum is great to take an organization to a certain level, but if you want to take it throughout the enterprise, more is needed. That s what this book is about. Challenges that this book will help you solve: We ve seen many teams having initial success with Agile often describe their experience as one of the following: Copyright 2011, Net Objectives 3

4 The first few Scrum pilots were successful, but now they can t extend it to other teams They had initial success with Scrum but their teams have stopped improving and are even sliding back Their first few teams wanted to become Agile but they are now finding resistance from other teams to go to Agile Their pilot was successful but those not involved in it are claiming Agile has hurt them. Their teams individually work well but they can t release quickly when a project requires the collaboration of multiple teams. Do any of these sound familiar? If so, you will find this book of great value. If not, please get in touch with us as we d like to know what you are doing! (seriously). You ll discover that each of these challenges stems from either the company not taking an holistic approach in their transition to Agile methods or due to a lack of understanding the basic principles of product development flow. One of the intents of this book is to make the reason that these patterns exist. By the end of this book you ll both understand why these patterns occur and what to do about them. Let s describe each of these in a little more detail. The first few Scrum pilots were successful, but now they can t extend it to other teams. This often happens because of the nature of the teams involved or that the true challenges in the organization aren t at the team level. The challenge here is that the root cause of the impediments facing the team are: 1) too much work is hitting the teams 2) there are key players in the development organization that can t readily accommodate all of the needs of the team teams We have found that an understanding of flow is required to solve these challenges. Furthermore, when you have key players that need to be shared by teams, the best economical and effective solution is often not having true-cross functional teams. Scrum s prescriptive framework does not give much advice on how to break it and teams attempting to do Scrum without the cross-functional teams it demands often devolve into poor implementations of Scrum. We ve also seen where a pilot is successful because the teams are created as co-located cross-functional teams in an otherwise siloed organization. Our experience has shown that doing this alone will improve productivity by 200% at least even if they don t change their work methods. However, sometimes it is easy enough to create a few teams like this and much more difficult to move the entire organization over to this structure. This can happen when key folks are put in the pilots. Unfortunately, this makes them less available to the rest of the organization. While a few pilots can be done this way, eventually, the lack of getting to the real problem of poor management of the limited number of people with key skills catches up with the organization. They had initial success with Scrum but their teams have stopped improving and are even sliding back. There are many reasons for this. Mostly we ve seen it occur for a combination of the following: Copyright 2011, Net Objectives 4

5 1) the teams have made enough progress that they are no longer in the pain that motivated their transition to Scrum 2) they are getting bogged down by using less efficient methods than are possible 3) they have improved their teams but haven t figured out how to get the teams to work together better One of our services is a Scrum tune-up. Basically we go in and talk to teams that have been using Scrum and see how we can make them more effective. We often find that their retrospections have gotten to be pretty mundane and not very useful. The serious pain they had been experiencing is gone and at the end of a sprint they just want to get on to the next one. Alternatively, they have been trying to do too much at the end of every sprint and have gotten cynical about continued improvements. We also see teams doing Mike Cohn s planning poker which can be good in many circumstances. But in many others, methods such as relative estimation or James Grenning s planning poker (same name different method) works much better. Intra-team collaboration (that is, team members working together) is quite different from inter-team collaboration. Teams are often motivated by and/or measured differently. This can make team collaboration a challenge. While some teams figure out how to solve this problem, we ve found that the principles of product development flow to be extremely useful in helping figure out how teams can better work together. Their first few teams wanted to become Agile but they are now finding resistance from other teams to go to Agile. Geoffrey Moore s crossing the chasm is often quoted and almost as often misunderstood. You often here talk about companies as being early adopters and that those doing Agile the last few years are early adopters. However, it is actually people that are early or late adopters. What often happens in a company is that the early adopters decide to go Agile, get success and then have management try to spread it to the others, who are not early adopters. This has a couple of problems. First, the people now doing Agile aren t necessarily comfortable with it. Second, Agile cannot really be imposed on teams very well. Their pilot was successful but those not involved in it are claiming Agile has hurt them. We came across a company that had a very successful pilot project by putting their best people together to work on one project. Not surprisingly, it was a big success. Unfortunately, some of these people had important skills in either domain knowledge, legacy code knowledge or just plain skills. By putting them on the pilot projects they were less available to other projects, thereby hurting these projects. Their teams individually work well but they can t release quickly when a project requires the collaboration of multiple teams. Getting a cross-functional team to work together well is not that difficult. Unfortunately, getting several teams with different motivations to work together is another issue altogether. Releasing cross-team products on a regular basis requires a different skill set than just building stories at a team level. If any of the cases seem familiar to you in your organization this book will definitely be of help to you. Many in the Agile space are convinced that a bottom-up only, team centric approach can solve the Copyright 2011, Net Objectives 5

6 impediments individual teams face. We have seen that sometimes organizations solve these. But more often they have little idea how to do so. In our own consulting practices we ve often gone into organizations and in a manner of days, provided them key insights based on the theories of flow based development that helped them get past the challenges that had stymied them. We ve come to the conclusion that there are many dynamics at play in an organization that is moving to more effective Agile methods and that merely learning team frameworks leaves on at risk of not having access to the insights they will need to continue learning and moving forward. This book will provide many insights and case studies that illustrate how to take an Agile endeavor to the next level. Organization of this Book This book has the following chapters: 1. Introduction Is This Book For You? Organization Of This Book 2. The Business Case For Agility Delivering In Stages Why Product Portfolio Management Must Be Across Products Incremental Discovery Of Value 3. The Value Stream What Is Value Stream Mapping? Why You Must Look At Time Why You Must Look At The Whole 4. Enterprise Agility Requires A Different Perspective Laws Assist Us Not Constrain Us 5. High Level Release Planning (Pareto Vs Parkinson s) 6. Team Organization For Enterprise Agility Dynamic Feature Teams Coordinating Backlogs To Coordinate Teams Optional Case Studies Assigning Projects To Teams With Pull Managing Work Flow From Business Stakeholders To Multiple Teams 7. Lean In A Nutshell 8. Beginning Your Agile Transition Where To Start Your Agile Transition When To Use Scrum, When To Use Kanban, When To Use Something Else It may seem odd that the beginning your Agile transition is the last chapter. The reason for this anomaly is that one will be better armed to know where and how to start if one understands the problems one will face down the road and methods to assist with them. Hence, we hold the beginning Agile chapter for last because that is when one will find it most useful to read it. Copyright 2011, Net Objectives 6

7 Good reading. Alan Shalloway CEO, Net Objectives Copyright 2011, Net Objectives 7