One’s a must, two’s a plus
Now that baseball season is about to start (unless you play in the major leagues), I want to share a baseball-related aphorism that applies just as well to agile teams working within a sprint.
Both of my sons had the privilege of playing for some great baseball coaches as they worked their way from Little League to American Legion to high school baseball. One in particular, Bryan Bendowski, coached them in various levels of American Legion baseball and achieved that desired, but rare trifecta of teaching the kids well (he was always teaching, in practice and in games), achieving great success on the field, and having the kids find their love of the game of baseball.
Bryan used many different adages to encourage his teams to play smart baseball, but the one that sticks in my mind above all the rest is one that he’d shout out during both practices and games whenever our team was in the field in a double-play situation. A double-play situation is when the other team has a runner on first and possibly second and/or third as well with less than 2 outs. Since the runner on first creates a force out situation at second base (there may be other force outs if there are other runners on base), a hard hit ground ball in the infield might be turned into two outs, otherwise known as a double play.
“One’s a must, two’s a plus!”, he’d loudly announce to the team. Usually, you then would hear the infielders echoing “One’s a must, two’s a plus!” to each other to reinforce the message.
What does “One’s a must, two’s a plus!” mean? It means our preferred outcome is to turn a double play and get two outs at once, but our primary and “mandatory” objective is to ensure the team gets at least one person out on an infield ground ball.
Why is he shouting that out to the team? One reason is that it reminds them that this is a double play situation, which means the infielders adjust their pre-pitch positioning to put themselves in best position to turn two.
But then why does he make such a point of emphasizing that the team needs to get at least one out? There are two reasons for that. One is that in order to turn a double play, your execution has to be crisp and quick. Sometimes, the person fielding the ground ball rushes too much trying to turn a double play and winds up taking their eyes off the ground ball or throwing the ball errantly. Other times, the shortstop or second baseman who has to catch the ball for the first out at second base and then turn to throw the ball to first base to get the second out may think about throwing the ball before they have caught the ball and winds up dropping it. He’s telling the players not to rush so much that you don’t get anyone out and also that if something unexpected happens, like a bad bounce or it takes a long time to get the ball ready to throw, scrap the double play and get the sure out (usually at first base). The second reason he emphasizes this is that if no outs are recorded, not only are we no closer to ending the inning (three outs are required to end an inning), but the other team will also have an extra man on base. While getting two outs is clearly the most beneficial outcome to the team, not getting a single out on the play is more costly on the downside. I won’t get into math, but you can calculate expected runs scored in an inning based on the number of outs and the number of runners on base (see https://gregstoll.com/~gregstoll/baseball/runsperinning.html for an example). Furthermore, while teams can often win games after giving up a run in an inning, giving up multiple runs in an inning very often leads to defeat. By not rushing to the point of making an unforced error and by getting at least one out, the chances of giving up a run and most especially multiple runs in that inning goes way down.
So I know you are saying, “Thanks for the baseball lesson, but how does this apply to agile software development?” Thanks for asking! Think about a scrum team that is working on multiple user stories in a sprint. In baseball, turning a double play requires execution by several individuals and successful handoffs (namely the baseball), while closing user stories requires execution by individuals, teamwork in pair programming, and handoffs for things like reviews and validation. Just as in baseball, trying to do too many stories may distract focus, create dependencies, and result in the team completing zero stories in a sprint, Furthermore, like getting two outs, the scrum team would love to get all the stories done, and also like the baseball example, it would be just as disastrous to not fully complete a single user story in the sprint as it is to not get a single out on the double-play ball. Not getting at least the one user story done means we don’t have an increment, we don’t have potentially shippable software, and we aren’t getting any feedback from our customers. Plus, just as recording the first out in baseball often settles down a team and gives them confidence to get the remaining outs, closing the first story builds momentum and confidence on the team for closing additional stories. Closing stories, like getting outs, is a habit, and the more we focus on building that muscle memory and getting good at closing a story, the more likely we will build the capability to increase our velocity and close multiple stories.
Hopefully, the scrum team is already using a work in progress (WIP) limitation to avoid too much work in progress at once, but usually teams will have at least two stories in motion at once. Just like in baseball where stuff happens that may not even be in the team’s control (bad bounce of the ball, the fielder slips, one or more of the runners runs very fast) that minimizes the chance of getting two outs and the players need to adapt to ensure they at least get one person out, scrum teams have to be prepared to adapt their plans, focus their joint efforts on the story that is most closable, and ensure that this story gets closed before the end of the sprint (which is akin to the end of an inning). Isn’t adaptation one of the primary reasons scrum teams meet in their daily standup?
To stretch the comparison even further, baseball teams don’t get any runs for getting baserunners to first, second, or third base. They can load the bases every inning, but if no one ever touches home plate, the team can’t win the game. The number of runs is the only number that counts on the scoreboard. Likewise, scrum teams can work on lots of different user stories in a sprint, but if they don’t close any of the stories, they have not produced any value for their customers and they will have nothing to show for their efforts at the sprint review. Customer value is what drives the success of our efforts, and closing user stories is what allows us to provide value to our customers.
To summarize, in order to maximize the value we produce in a sprint, a sprint team should:
Limit their WIP to a very small number of stories (I’d suggest two, but that depends on how big your team is - but there again, smaller is usually better)
Work their sprint board from right to left, meaning focus first on working stories that are closest to being closable before pulling in something further away
Use their daily standup meeting to adapt their plan to current conditions as needed to ensure the optimization of stories closed in the sprint
Ensure you are communicating and collaborating with your teammates so that each of you is in the right position to help each other out
So the next time you and your teammates get together in your daily standup, make sure you tell each other, “One’s a must, two’s a plus!”
Play ball!