A Scrum Reading List

On a recent project I played a pretty active, if informal, role as an agile coach, in addition to my development duties. Which meant I did a lot of reading on plane flights, watched a lot of Jeff Sutherland videos, and got to the point where I could quote the Scrum Guide in chapter and verse. I'm not a certified anything (well at least as far as Agile is concerned), but the material started to make sense to me in a fairly coherent way, so I thought it might be useful to assemble a list of resources that influenced my thinking, and what I learned from them.

The Scrum Guide

We've got to start here. If you are doing daily stand-ups and have someone on the team with the title of Scrum Master, you owe it to yourself and your team to read the rules of the game you are playing. A few things are not obvious.

• The Product Owner is god of the backlog. She is not a committee, and she cannot be overruled. This allows the developers to proceed with confidence, and not manage the mixed messages and swirling tides of change that are endemic to an organization of any size. Just as a well defined interface allows you to write clean, maintainable code, an empowered product owner allows a development team to act with boldness and efficiency.
• The Development Team is god of the sprint. The authority of the product owner ends when the sprint begins. (" Only the Development Team can change its Sprint Backlog during a Sprint.") This allows the development team to make decisions about how to operate at peek efficiency in both the short and the long term. Business priorities influence what comes into the sprint, but then development priorities take over for the length of the iteration.
• The Scrum Master is god of the time-box. And this is really important. The key thing about Scrum is that everything is time-boxed: the daily scrum, the planning session, the review, the retro. And the sprint. And the workday. And this is important because the point of Scrum is to gain knowledge, to find out what is hard and what is not. And developers do not like to walk away form problems or discussions. This is where the Scrum Master needs to blow the whistle and say: "Done, cooking challenge over. Time for the judges to taste what you've made."
• The Development Team is a thing. "Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule." In other words, if there are certain tasks that only a "front-end" dev can do, or only a QA person is allowed to do, you are not doing Scrum. You may have experts in each area, but in a pinch, anyone can do anything. As Jeff Sutherland pungently put it on Twitter:
  

  If you are the only person on your #Scrum team that can do a particular job, you should be fired. #Crossfunctional #Agile #XMfg #ScrumLab

  — Jeff Sutherland (@jeffsutherland) April 9, 2015

  
  
• The Sprint Goal is a thing. This is what the team commits to doing, and this is what the team reports on each day. And this is not the same as the list of backlog items that the team plans to get done in the sprint. The fact that the team commits to a goal and not a list of items is intentional, since the team may learn that the specific backlog items are not feasible in the sprint, setting up a constructive negotiation with the PO over how to satisfy the goal. Again, this is important. Scrum is predicated on the notion that we don't know how hard things will turn out to be: we do sprints to learn that. And for the data coming out of sprints to be of maximum usefulness, it's important to be trying to do specific, focused things. "We found out Search was a lot harder than we thought" is useful data. "We found out tickets 3144, 3299, and 4417 are a lot harder than we thought" is not. Goals provide focus and clarity. As Roman Pichler writes:
  

  When selecting your sprint goal, remember that trying out new things requires failure. Failure creates the empirical data required to make informed assumptions about what should and can be done next. Failing early helps you succeed in the long term.

• It's a Sprint Review, not just a demo. The point is to get the developers and the stakeholders interacting and collaborating. The scrum guide section on the Sprint Review contains a pretty detailed recipe for making this happen.
• Transparency is the whole point of Scrum, and transparency is hard.
  

  The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

Software in 30 Days

Written by the two creators of Scrum, this book can be considered authoritative. I found the first few chapters extremely useful, especially the first two chapters, which lay out a case for empiricism ("let's find out how doable this is") over predictive ("we'll get it done by date X") approaches. If anyone on your team uses the phrase "failed a sprint," have them read chapter two:

Empiricism means that we will not be sure of how much work we will get done until it is done.

The development team's job is, in addition to writing software, to provide data to the organization. The organization can then decide whether the product is the right thing for the team to be doing. The book is written in a somewhat dry, case-study focused manner, but is dense with information on how to build a scrum capacity in an organization.

Scrum: The Art of Doing Twice the Work in Half the Time

This is a much more personal book, written by Jeff Sutherland in partnership with his son JJ Sutherland, who used scrum to organize the news-gathering operations of the NPR Cairo bureau during the Tahrir Square uprising. The book focuses on the psychological and philosophical aspects of Scrum, and has a strongly autobiographical focus. it begins with the story of how Jeff Sutherland turned around a platoon at West Point that had more than a century of tradition as the worst of the school, through focused, actionable feedback. This lays a foundation for the belief that any team can be turned around, if given the right conditions for success. It's a great read, and full of actionable insights:

• The Fundamental Attribution Error: You view your own actions as influenced by circumstances, but those of other people as revealing of their fundamental character. You are right about yourself, and wrong about other people. Change the environment, and you will change behaviors.
  
• Cross functionality. Really good teams don't have single person skill sets. They fluidly adept to circumstances. He uses the example of special forces teams, where each role is cross trained so the team is not vulnerable to losing any single member.

  Each team has all the capabilities to carry out the mission from start to finish. And they cross train each skill set. They want to make sure, for example, that if both of the medics get killed, the communications specialist can patch up the weapons specialist.

  Your scrum team will hopefully not be under direct fire, but you can be assured that your QA person will have more than he or she can do at the end of the sprint. If you can all pitch in, you will get vastly more done.
• The ordered backlog as the key to the value of Scrum. Get people working on the high value stuff, and declare victory and move on when the high value/low effort stuff is done. Live by the 80/20 rule.
• Stop the waste (Chapter 5, "Waste is a Crime"). Don't multitask, and don't start things you won't finish. The cost of context switching is deadly. After reading this, I stopped thinking it was a good thing to get started on a story I couldn't finish in a sprint. That's just adding to work in progress, and work in progress is the killer of teams. I also started pushing back on ceremonies like having the entire team on hand on the evening of a deployment. That's just stealing from the next day's productivity. These kinds of things are (politically) easy to accept, and are destructive of team effectiveness. Getting religion on waste is a powerful corrective.
• There are a number of nice practical tips on running Scrum, such as using dog sizes (Is this feature a Chihuahua, a Labrador, or a Great Dane?) to introduce story points, and putting metrics on how valuable a story point is, which creates a healthy pressure to find simple, high value stories.  An effective Product Owner will maximize the dollar value of a story point.

Extreme Programming Explained

Kent Beck's book is from the early days of Agile, but it is very helpful in anchoring the key concepts. I'll call out a few:

• He tells the story of being brought on to a project as a Small Talk consultant, but being mystified at why the code was so incoherent. Then he realized that the four senior devs on the project had all staked out corner offices, and never interacted directly. He fixed this with the first bullpen, and mandatory pair programming. After reading this, I started making it a habit to move my seating every time I started on a project. (As a remote worker now, I make liberal use of Skype, screen shares, and humor to bridge this gap. The main point is that human connections lead to coherent code.)
• He talks in terms of listening, to the customer, to other programmers, and to the system.

  More coaching phrases are "Don't ask me, ask the system" and "Have you written a test case for that yet?" Concrete feedback about the current state of the system is absolutely priceless.

• Assume simplicity. "We should assume that the simplest design we can imagine possibly working will work." This became the Agile Manifesto principle: "Simplicity--the art of maximizing the amount of work not done--is essential."
• Most importantly, he talks about fostering a culture of mutual support, a "mentality of sufficiency," drawing on the work of anthropologist Colin Turnbull, whose books "The Forest People" and "The Mountain People" contrast worlds of sufficiency, where everyone shares, and scarcity, where everyone fights. This is an important thing to get right. This is the difference between developers who share or hoard knowledge, who write clean, maintainable code, or who seek security in silos and obscurity.

Other Resources

• Jeff Sutherland did a series of videos discussing elements of scrum, which I have put into a playlist. I particularly recommend "The Nokia Test," which gives a list of eight actionable levers for improving the efficiency of a team (ordering the backlog, avoiding disrupting sprints, testing during the sprint).
• I haven't read Ken Schwaber's Agile Project Management with Scrum, but have consulted parts of it, and it looks useful. He describes the role of the Scrum Master as a sheep dog, "keeping the flock together and the wolves away," and describes doing just that by informing a stakeholder that he can ask to have the sprint cancelled if he wants to get his pet feature in. Making the cost of disruption plain to the organization, rather than something that is only felt by developers, is a key output of Scrum.
• Agile Retrospectives: Making Good Teams Great is a very useful source book for running retros. A really valuable point is the importance of getting all members of the team on the same page by gathering and visualizing input from the team, so that everyone is working from the same set of facts and experiences.
• David Starr has an excellent Pluralsight course on Scrum. Among other things, it really makes the point well that the Scrum backlog is not a commitment, because you cannot commit to scope. There are no crystal balls, just experiments and data.