Book ‘Succeeding with Agile. Software Development Using Scrum’ by Mike Cohn

A few days ago I have finished reading Mike Cohn’s book “Succeeding with Agile: Software Development Using Scrum“. Here is my short review and thoughts about it. Succeeding with Agile. Software Development Using Scrum

Part I “Getting started” is not very useful for teams that already use Scrum. It lists benefits of transition to Scrum, describes patterns for adopting Scrum and common problems that organizations face when integrating Scrum. Nevertheless, there is one useful idea that existing Scrum-teams could take from the first part of the book: Scrum doesn’t have final point of adopting. You cannot say at one moment that you have finished incorporating Scrum and stop this process. On the contrary, team should constantly improve the process iterating towards more effective Scrum.

The second part describes Scrum roles and human factors in details. Mike devotes the whole chapter to the description of Scrum Master and Product Owner roles. As I am a Scrum Master in my team, it was very interesting to learn Mike’s thoughts on this role. The author lists six main attributes a good Scrum Master must have:

  1. Responsible
  2. Humble
  3. Collaborative
  4. Committed
  5. Influential
  6. Knowledgeable

On the whole, Scrum Master is a humble and responsible person, whose main duty is not to command but to help the team to achieve its goals. The author makes a good comparison of Scrum Master with the conductor of the orchestra.

Mike notes that a Product Owner role is no less important than the role of Scrum Master. While Scrum Master is a person who helps the team to achieve its goal, Product Owner is the one who defines this goal. Attributes of good Product Owner:

  1. Available
  2. Business-savvy
  3. Communicative
  4. Decisive
  5. Empowered

Besides, Mike argues persuasively that “each team needs exactly one product owner”. Unfortunately, in our project the situation with PO is pretty bad. We have a nominal Product Owner but he is located in a remote office and the team never contacts him directly. The role of a real PO is performed by Business Analysts, who also design specifications (with different level of details). Out of qualities listed they can’t be honestly described as business-savvy, decisive and empowered. It causes frequent problems, like changes in acceptance criteria and even redeveloping of accepted US after showcase for the Business. Moreover, we don’t work with just one PO. During a sprint we can work on US for 3-5 different PO.

Further the author emphasizes how important is the use of appropriate Agile technical practices in the process. In theory, team can go without them but these techniques increase efficiency greatly. Mike mentions the following Agile practices:

  • Test-Driven Development
  • Refactoring
  • Collective Ownership
  • Continuous Integration
  • Pair Programming

Again, our team (and other teams too) has drawbacks in this area. We have some progress in refactoring and continuous integration, but we don’t use any other techniques. Now, when I see how weak we are in the use of practices described, I’m going to discuss it with the team on nearest retrospective review and we’ll start their gradual introduction in our process.

The third part of the book named “Teams” starts from the discussion of Scrum-team structure. The author mentions ‘Two-Pizza’ rule (the size of the team should be small enough to be fed by two pizzas). Mike provides statistics of dependency between team size and efficiency. The most impressive is the following chart. It demonstrates how much time is required for different teams to complete the same project:

Team size and performance

It turns out, that if your team consists of 10 engineers, you can transfer three of them to another team and you’ll finish the project 1.5 times faster J. Indeed, my previous team consisted of 10 persons and it caused constant problems like increased coordination efforts, loss of focus, over-specialization, etc. After reorganization, when the new team consists of only 7 engineers, all these problems went away and team efficiency increased noticeably.

The author describes two models of team composition in detail – Component Teams (every team is responsible for one product layer, like server/client, backend/frontend, etc.) and Feature Teams (every team is responsible for end-to-end functionality delivery). The author argues strongly for the model of Feature teams because:

  • Feature teams are better able to evaluate the impact of design decisions.
  • Feature teams reduce waste created by hand-offs.
  • It ensures that the right people are talking.
  • Component teams create risk to the schedule.
  • It keeps the focus on delivering features.

In our project the model of component teams has been chosen and all drawbacks that the author describes are applicable for our process.

“Planning” chapter was one of the most important and useful for me. Very often during work on current release it becomes obvious that the full project scope could not be completed on schedule. There are four possible alternatives in this case:

  1. Cut quality
  2. Add human resources
  3. Shift the Release
  4. Adjust (decrease) Release scope

Planning Triangle

The author gives convincing arguments that in most cases decrease of release scope is the best alternative. I fully agree with Mike on this point. If team (or organization) takes this approach, then it’s highly important to work on features and User Stories by their priorities. In this case the items with lowest priorities will be dropped when release date approaches, and it will hurt Business requirements least of all.

The fourth part “The Organization” describes Scrum scaling issues, work of distributed teams, mixing Scrum with other software development methodologies and transfer of Scrum to other parts of organization. The most useful part for me was a description of relationships between Team and Scrum Master and between Team and Product Owner. The author deviates from common advice that team members shouldn’t report to Scrum Master but Mike strongly advices against the practice when Product Owner has power over the team. The author says: “The ScrumMaster and product owner do not need to be peers on the company’s org chart, but they should treat each other as peers and partners on the project.” I’d add that Product Owner and Scrum Master (with the Team) are in inevitable contradiction with each other and it’s very hard to defend your position when Product Owner is your boss.

To summarize, “Succeeding with Agile” is a great book and I advise to read it for all who use Scrum. And the book is definitely “Must Have” for all Scrum Masters and Product Owners. While studying the book I came up with the list of issues we have in our team and the whole organization, which should be discussed and eliminated:

  • Lack of real Product Owners who satisfy all PO requirements.
  • Ignoring of essential Agile technical practices like Test-Driven Development and Pair Programming.
  • Split into component teams, not for feature teams. This point is probably the hardest to fix because it requires team rearrangement (at least partial) and great process alternation.

Among other advantages, “Succeeding with Agile” provides references to other books that could be useful for all interested in Scrum and Agile. Here I’ll list the books I’ve added to my backlog with short descriptions by Mike Cohn:

“Agile project management: Creating innovative products” by Jim Highsmith

The most popular book on agile project management. The second edition adds chapters on release planning, scaling, governance, and measure to an already complete table of contents.

“Extreme programming adventures in C#” by Ron Jeffries

An intriguing book in which we read along as Ron Jeffries teaches himself C# by pair programming with Chet Hendrickson. The book isn’t intended specifically to teach C# programming. Rather, it is an excellent introduction to the type of fast feedback programming practiced on Scrum teams.

“Practices of an agile developer: Working in the real world” by Venkat Subramaniam and Andy Hunt

This short book collects nearly 50 tips aimed at programmers on any agile project. Each tip (such as “Let Design Guide, Not Dictate”) includes a description of the practice and how it should feel when it is being done well.

“Peopleware: Productive projects and teams” by Tom DeMarco and Timothy Lister

It is impossible to say enough good things about this book. I remember the day in 1989 when my CEO told me, “After reading Peopleware this weekend, I am going to completely change our development group.” She did, and the group excelled because of it. This book is full of advice on helping teams achieve their fullest potential.

“The wisdom of teams: Creating the high-performance organization” Jon Katzenbach and Douglas Smith

An early classic on the subject of teams that has stood the test of time. Covers every aspect of teams including the stages they progress through, who should be on them, who should lead them, the role of management in working with them, and more.

“Agile product management with Scrum: Creating products that customers love” by Roman Pichler

The most complete coverage available of the role of the product owner. Pichler clarifies the key differences between traditional and agile product management while providing useful tips to product owners.

“Scaling lean & agile development: Thinking and organizational tools for large-scale Scrum” by Craig Larman and Bas Vodde

This book covers many topics, but in Chapter 11, Larman and Vodde focus specifically on large-scale Scrum. They present two frameworks for scaling Scrum: one for scaling up to ten teams, another for scaling beyond that.

“Scaling software agility: Best practices for large enterprises” by Dean Leffingwell

This book focuses on two different types of scaling: scaling agile within large organizations and scaling agile on large projects. A bit more emphasis is on the former type of scaling, but both are covered. The heart of the book, Part II, focuses on seven agile practices and how to scale them: teams, planning at two levels, iterations, small releases, concurrent testing, continuous integration, and regular reflection.

This entry was posted in Books and tagged , , , . Bookmark the permalink.

Leave a Reply