Baseball Conference on the mound

Photo by Nick Schweitzer used with permission

This is the twelve in a series of blog posts about how we can learn about software architecture by studying and comparing it to the sport of Baseball. This series was inspired by the book Management by Baseball.

I noted a couple of years ago that baseball was one of the few or the only sport that allowed coaches on the field of play, referring to the fact that when a team is up to bat, two coaches are allowed on the field in coaches boxes. In addition, a pitching coach or manager is allowed to visit the pitcher’s mound when his team is in the field of play. They are almost always joined by the catcher during the conference on the mound, but they can be joined by players from the infield as well (as the photo above shows occasionally you can get all the players from the infield on the mound). The most common reasons for a manager to visit the mound are to:

Remove a pitcher from the game in favor of another pitcher
As a stall tactic to allow a pitcher in the bullpen time to warm up
Review the pitcher’s approach to the upcoming batter, especially when the batter is coming up as a pinch hitter
Coordinate the defense when there are runners on base
Calm the nerves of the pitcher in a big game situation You can sum up all of these specific reasons for visiting the mound as needing to make an adjustment to the game plan.

In this series I have always drawn the parallel between the baseball team’s managers and coaches with the architects on a software development project. I think of the players as the developers on the software development project. I don’t mean to say that the architect is a higher level than the developers; it is just that their role is different. The architect, like the baseball team’s manager, has to do a bunch of work upfront to line up the correct team and prepare them for the game. The developer, like the baseball players, play just as critical of a role (or maybe more critical) in the success during the game. What I have not spent much time discussing in this series is how the architect and the developers actually communicate with each other before and during the software development project. But the conference on the mound gives us a good chance to discuss how the developers and the architect can adjust the “game plan” during the project.

The team standup

I talked about Scrum a couple of years ago and I am still a fan of it, but the part that I have always liked the best was the daily scrum (sometimes called a team stand-up). A stand-up got its name from the fact that the meeting was so quick and to the point, that there was no need to even sit down. Even though traditionalists encourage the no sitting rule, it is often violated. The “meeting” is a ~10-15 minute check point where all of the team members come together, and when done in the most traditional fashion, it looks a lot like Nick’s photograph above. The main purpose of the stand-up is to frequently make sure that everyone on the team is on the same page and to identify any issues that need to be addressed. Quick issues can be addressed in the stand-up, but more complex issues are deferred for a follow-up with just a subset of the team. Scrum and other agile methodologies encourage this to be done on a daily basis, although in practice it can be adjusted to 3 or 4 times a week.

Not exactly like the conference on the mound

There is one key difference between the team stand-up and the conference on the mound in the game of baseball: frequency. The strength of the team stand-up is that you are meeting quite frequently (even if it is for just a short amount of time). That luxury is not afforded in baseball; you are only allowed to visit the mound once per inning. A subsequent visit to the mound requires the pitcher to be pulled from the game in favor of a relief pitcher. The purpose of this is to keep the game moving along, the game would get too long if they manager and other players were allowed to visit the mound as often as they wished. Fortunately as developers and architects we have the luxury of frequency.