Book Review – Succeeding with Agile: Software Development Using Scrum
I have been a fan of Mike Cohn and his latest book Succeeding with Agile: Software Development Using Scrum is another great book. He blends a good mix of theoretical and practical techniques drawn from his past experiences. This book doesn’t show you how the Scrum Framework works, but it is more of a cookbook of good practices and suggestions that you can help you succeed with Scrum. So if you are new to Scrum or looking for an introduction to Scrum I suggest you read some other sources first such as the Scrum Guide (by Schwaber and Sutherland) or the Scrum Primer (by Deemer, Benefield, Larman and Vodde) and then coming back to this book for tips and advice as you implement Scrum.
I was able to relate to some of Mike’s observations with my own experience and found myself nodding my head in agreement to some of his sections on ‘objections’ and various stories throughout the book. As a result, the book felt very personable as I felt like I have been there done that. He does offer some practical advice when dealing with the various ‘objections’ that you may encounter along the way. He also points out the challenges in adopting and transitioning to agile. The following is an important quote from the book:
I’ve personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an “Agile Office” to which new Scrum teams could turn for advice. The company’s failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.
A common theme throughout the book is that there is no ‘standard’ way of doing agile and that it must be adapted to the organizational context and project. He devotes a whole chapter, ‘ADAPTing to Scrum’ [Chapter 2] to this topic.
Although it is mainly centered on Scrum, Mike describes various other techniques and methods to produce a handbook that is thorough and complete for any Agile practitioner. Scattered throughout the book are real-world case studies drawn from the Mike’s experience helping many software organizations adopt Scrum, and ‘things to try now’ sections based on his advice offer practical, quick ways of coming up to speed fast. I really liked the chapters on New Roles [Chapter 7] and Changed Roles [Chapter 8] where he describes the 3 key Scrum roles but also identifies how the traditional roles changes to fit into an agile development framework.
I highly recommend reading this book as part of your Agile training, whether you are implementing Scrum for the first time or an experienced practitioner. It is an easy and good read.
RSS - Posts
Hi Christopher,
I am sure this is an interesting book. I would like to share my thoughts regarding the case study of the failed Scrum implementation you quote from the book. It says: “The company’s failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization… They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department.”
My question is: if a Scrum implementation requires changes not only in development organization but also in other department, then does Scrum offer the methodology, practices to follow and body of knowledge to guide and do all these changes? Because otherwise it sounds like: “we can tell you how to implement Scrum in development organization but you need to adapt also other organizations to it”.
How?
Stan
Hi Stan,
Thanks for the visit and dropping note.
You raise a very good question. Scrum does not solve the problems. It is a framework that quickly makes impediments, issues and organizational dysfunctions to Product Owner and Team’s effectiveness quickly visible.
One reason why some people struggle with agile projects is because of the transparency of the work that’s being done, including what’s getting in the way.
One good (recent) example is a marketing manager promised some features to a client. However, the team was already to capacity and could not take on the new work. In the end the team worked longer hours to complete the new features, albeit at a lower quality. This type of dysfunction continued for many years. But with the introduction of Scrum, and having a prioritized backlog clearly visible and whereby the team only works from the backlog from top to bottom at a sustainable pace, marketing had to adjust its behavior and how it approaches selling products. This example has nothing to do with Waterfall or Agile processes, but Scrum identified an organizational dysfunction that they had to solve. Each organization is unique and therefore, solutions to organizational dysfunctions are unique. So Scrum provides a framework for people to explore ways to resolve problems by inspecting and adapting its process, people, tools and product.
Agile and marketing-development dysfunction
Hi Christopher,
Thanks for your reply. The example of a sales manager who sells to a client features that development team cannot develop on time is a classical story. It’s because there is often disconnect between the goal of marketing and sales guys – to sell as much as they can – and the limited production capacity of the company. It is good that introduction of Scrum helped identify this “dysfunction” as you call it although I think it should have been visible without Scrum as well.
Having said this was a good example, still life is not simple and this example shows just part of the story. Let’s look at it from customer point of view. The company has sold a solution to the customer which means this is what they need. If the company cannot deliver on time the customer will not be happy. Just selling less to them in order to keep the promise and deliver on time wouldn’t make them happy either. The only way is to deliver on time what customer needs, not less, not later.
I have had opportunities to be on the side of the customer when we expected delivery from an agile team. The customer has a big system used by thousand of employees on daily basis. The team has to deliver a new system. The new system must replace the legacy one in one move, not step by step and not feature by feature because this would cause a mess and would be too costly. Unfortunately, because the new system is being developed using agile methodology, the team cannot commit to clear schedule and scope “as it was in the past”. And it is irrelevant if the promises in the past were kept strictly or not. Now we don’t have even the promise. You can imagine that the customer would start wandering why new agile methodology should be used …
In my work as a project manager I use agile principles but also use traditional ones because every approach has its strengths and weaknesses.