Overall I enjoyed “The Enterprise and Scrum” by Ken Schwaber because it had some great examples of how Scrum can work within a large enterprise. It was a little tough to follow through some of the example uses given for different business enterprises. The final chapter for me was very good. It goes into detail about how a company, through its habits/behaviors and relationships, slowly works itself out of competition.

The first couple of chapters were dedicated to describing how an enterprise can adopt Scrum. It was broken down by first assessing whether Scrum has value to your enterprise. Next Ken provided steps for introducing Scrum and then provided a timeline for the first year. After that he talked about handling our natural resistance to change, after all our belief system is potentially being rocked.

He then gave some good examples of enterprises adopting Scrum. The start of this chapter is worth quoting. “Adopting Scrum in an enterprise is like looking into the abyss, girding oneself for an epic journey, and then making the plunge. What will be discovered and have to be conquered is different in each enterprise; what is common is the courage to start and then persist. Most enterprises that have a compelling need to change take the easy way out—they hire management consultants, buy another business to distract themselves, or reorganize. Scrum is soul-searching by examining failures and dysfunctions, not based on philosophical whim. It is a perilous journey, but probably the only one worth making, because it is the serious business of self-improvement. It is taking a hard look in the mirror every day, every month, and doing something about what one sees.” Well said Ken!

In the latter chapters Ken gives practices, processes and techniques that help adopt Scrum at an enterprise level. He started off by covering how to organize the work of the enterprise. I had a hard time relating to this chapter but it could have been because I read it while tired. The next chapter confused me when I read the title, “Engineering Practices” because I think of pair programming, Test Driven Development (TDD), Continuous Integration (CI) but that is the developer in me. This chapter was about integrating the enterprise work.

The last two chapters on people practices and the relationship between product management/customer and the development team were really good. Each of these chapters gave different practices for particular situations. The two that resonated most with me in the people practices chapter were practice #4, “How People are Managed” and practice #9, “Scarce Skills Needed by Many Teams”. If the scarce resource can’t attend the sprint planning meeting and make a commitment with the team, that work shouldn’t be included in the sprint/iteration goal.

The last chapter was great, it is the written description of some snippets from Ken’s Google Tech Talk called “Scrum et al.”. I have watched it countless times. In this chapter he highlights the common ways that the relationship between the customer and development team break down. When this happens the team is forced into a situation where they cut quality and begin the journey of creating a design dead application where its ability to produce new features will be hamstrung by the fragile core code.

For those trying to scale Scrum at the enterprise level, I think Ken gives some good examples and techniques to try. Much of it boils down to people and understanding what they are doing that may be hindering their ability to achieve their goals. If an enterprise adopts Scrum they need to be prepared to look deep when things start to surface as a result of the transparency that Scrum provides and think about what is most important to them.

For an additional review, check out Mike Cohn’s take on the book.