Among the various extra-curriculars that take up my downtime, baseball
is up there.  Baseball was a passion for much of my youth.  As I got older and my attention turned towards my career and the world at large, the dawn of Michael Lewis’ “Moneyball” changed my view on baseball entirely.  Baseball became, for better or for worse – less interesting to watch for 180 days a year and more intrigiung to capture in the snapshots of statistics and numbers that engulfed baseball in the early 2000′s.  Lewis was demonstrating not a new approach to how baseball was played, but how Oakland A’s manager Billy Beane was simpy exploiting an efficiency that none of his contemporaries had (yet) uncovered.
So recently I found myself thinking about the role of the manager in baseball.  As other teams began looking at the Oakland model for constructing successful, cost-conscious rosters, many copied their formula.  Others began to look for other efficiencies.  But the manager role – the ultimate “chicken” contrasted to the players as pigs, has only had cursory evalution for their affect on the outcome of the game.  These evaluations are subjective by and large, and have all concluded in one way or form that managers tend to have zero net effect on the success or failure of a team.  But baseball managers are perhaps one of the most agile practitioners today.  They must be responsive, they must have enough foresight to plan only enough in that they can mitigate risk, but not so much as to commit themselves to a shortsighted approach.  Their sprints are innings, their releases are games.  They create ample time to adjust and replan.  They are agile creatures – perhaps the original agile management style.
Every Game is a Release
Before every game, the manager has a plan to build.  The lineup is first and foremost.  It ultimately has very little affect on the outcome of the game, provided that the manager has planned for his best hitters to be part of the game.  Additionally and potentially irrelevant statistically – the manager will prioritize his lineup which will offer the most potential value for that game.  The catcher amy be different depending on his own starting pitcher.  Lefthanded hitters, statistically vulnerable to left-handed pitching may sit on the bench to start the game while statistically inferior players fill-in for the handicapped lefthander.  Some players may be removed from the roster entirely, optioned to a monior league affiliate to allow for superior options to be available in the case the need arises.
The analogy here, is release planning.  Just like the manager has an assortment of players, we have a backlog.  Each story offers value that may change from one sprint to the next.  Each story may shuffle in priority from one sprint to the next.  But the focus is always on ensuring that during a release we are planning to ensure that we are successful in every area of our sprints during the release while aiming to maximize the success of our teams over the entirety of the release.
Every Inning is a Sprint
Baseball is a strange game in that every inning, the defense controls the ball.  There are 9 innings in a game, and 3 outs per inning.  These are our resources.  As a manager, my job is to allow my team to execute while intervening only when resource mismanagement is certain.  I may pinch hit for a hitter in order to maximize run production while minimizing outs.  Conversely, I may change pitchers frequently to ensure my competition is least able to use their resources to their fullest.
Managing sprints is a task in managing your resources optimally.  Each sprint we start with our planning meeting where we identify what resources are available for the current sprint.  Then, based on various factors – we figure in what we can get done during the sprint.  How we get there may change, but the goal is always part of a theme.  In baseball, this is a touch of a stretch – but it’s hard to think that a manager going into the 9th down by 3 isn’t planning his decisions on maximizing on-base percentage that inning with the prospect of his best power hitter in the dugout.  Often times when a team hasn’t scored the tying or lead run but is threatening to score, the bullpen will warm up, a proactive response to something which may not be certain.  A lot of baseball management is about thinking foreward just far enough to be prepared for what you know is next and not focusing too much on the possibilities in September while it’s still May.
Baseball Teams Are Self-Managing
This is more hypothetically true than true in reality.  It’s not unheard of for players to be managers as well.  But unlike professional American football where the level of specialization and differentiation between offensive and defensive roles is stark, or professional basketball where the players can succeed independently of the team, even if the team fails – baseball players are incredibly independent in their affect on any given contest.  While Michael Jordan and Kobe Bryant may have singlehandedly one NBA titles for their respective teams, Derek Jeter and Curt Schilling would have not won their rings were it not for the complimentary (but not cooperative) talents of the players that surround them.  They exhibit classic examples of game theory where the benefits of the strength of their performance are best realized by them only when realized by all.  That is a key trait of the self-organizing team.
What Baseball Can Tell Us About Software
While these two things are markedly different, baseball managers and players are clear examples of self-sufficient and practical agile applications.  Managers aim to minimize risk and maximize prdocution while only planning for the factors that are at hand or probable rather thah trying to account for any possible scenario.  This is not too indifferent from how a ScrumMaster must operate.  If baseball managers went into game 1 concerned about game 60, they would be accused of guesswork and incompetence.  Uncertainty would doom their plan, the pundits would not.  This is not at all indifferent from Agile software teams that learn from recent results and apply the lessons from the most recent experiences immediately.

Among the various extra-curriculars that take up my downtime, baseball is up there.  Baseball was a passion for much of my youth.  As I got older and my attention turned towards my career and the world at large, the dawn of Michael Lewis’ “Moneyball” changed my view on baseball entirely.  Baseball became, for better or for worse – less interesting to watch for 180 days a year and more intriguing to capture in the snapshots of statistics and numbers that engulfed baseball in the early 2000′s.  Lewis was demonstrating not a new approach to how baseball was played, but how Oakland A’s manager Billy Beane was simply exploiting an efficiency that none of his contemporaries had (yet) uncovered.

So recently I found myself thinking about the role of the manager in baseball.  As other teams began looking at the Oakland model for constructing successful, cost-conscious rosters, many copied their formula.  Others began to look for other efficiencies.  But the manager role – the ultimate “chicken” contrasted to the players as pigs, has only had cursory evaluation for their affect on the outcome of the game.  These evaluations are subjective by and large, and have all concluded in one way or form that managers tend to have zero net effect on the success or failure of a team.  But baseball managers are perhaps one of the most agile practitioners today.  They must be responsive, they must have enough foresight to plan only enough in that they can mitigate risk, but not so much as to commit themselves to a shortsighted approach.  Their sprints are innings, their releases are games.  They create ample time to adjust and re-plan.  They are agile creatures – perhaps the original agile management style.

Every Game is a Release

Before every game, the manager has a plan to build.  The lineup is first and foremost.  It ultimately has very little affect on the outcome of the game, provided that the manager has planned for his best hitters to be part of the game.  Additionally and potentially irrelevant statistically – the manager will prioritize his lineup which will offer the most potential value for that game.  The catcher amy be different depending on his own starting pitcher.  Lefthanded hitters, statistically vulnerable to left-handed pitching may sit on the bench to start the game while statistically inferior players fill-in for the handicapped lefthander.  Some players may be removed from the roster entirely, optioned to a minor league affiliate to allow for superior options to be available in the case the need arises.

The analogy here, is release planning.  Just like the manager has an assortment of players, we have a backlog.  Each story offers value that may change from one sprint to the next.  Each story may shuffle in priority from one sprint to the next.  But the focus is always on ensuring that during a release we are planning to ensure that we are successful in every area of our sprints during the release while aiming to maximize the success of our teams over the entirety of the release.

Every Inning is a Sprint

Baseball is a strange game in that every inning, the defense controls the ball.  There are 9 innings in a game, and 3 outs per inning.  These are our resources.  As a manager, my job is to allow my team to execute while intervening only when resource mismanagement is certain.  I may pinch hit for a hitter in order to maximize run production while minimizing outs.  Conversely, I may change pitchers frequently to ensure my competition is least able to use their resources to their fullest.

Managing sprints is a task in managing your resources optimally.  Each sprint we start with our planning meeting where we identify what resources are available for the current sprint.  Then, based on various factors – we figure in what we can get done during the sprint.  How we get there may change, but the goal is always part of a theme.  In baseball, this is a touch of a stretch – but it’s hard to think that a manager going into the 9th down by 3 isn’t planning his decisions on maximizing on-base percentage that inning with the prospect of his best power hitter in the dugout.  Often times when a team hasn’t scored the tying or lead run but is threatening to score, the bullpen will warm up, a proactive response to something which may not be certain.  A lot of baseball management is about thinking forward just far enough to be prepared for what you know is next and not focusing too much on the possibilities in September while it’s still May.

Baseball Teams Are Self-Managing

This is more hypothetically true than true in reality.  It’s not unheard of for players to be managers as well.  But unlike professional American football where the level of specialization and differentiation between offensive and defensive roles is stark, or professional basketball where the players can succeed independently of the team, even if the team fails – baseball players are incredibly independent in their affect on any given contest.  While Michael Jordan and Kobe Bryant may have single handedly one NBA titles for their respective teams, Derek Jeter and Curt Schilling would have not won their rings were it not for the complimentary (but not cooperative) talents of the players that surround them.  They exhibit classic examples of game theory where the benefits of the strength of their performance are best realized by them only when realized by all.  That is a key trait of the self-organizing team.

What Baseball Can Tell Us About Software

While these two things are markedly different, baseball managers and players are clear examples of self-sufficient and practical agile applications.  Managers aim to minimize risk and maximize production while only planning for the factors that are at hand or probable rather than trying to account for any possible scenario.  This is not too indifferent from how a Scrum-Master must operate.  If baseball managers went into game 1 concerned about game 60, they would be accused of guesswork and incompetence.  Uncertainty would doom their plan, the pundits would not.  This is not at all indifferent from Agile software teams that learn from recent results and apply the lessons from the most recent experiences immediately.