The Baseball Manager and Agile: How America’s Game Forces It’s Decision Makers to Be Responsive

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.

(more…)

Integrating Your QA Staff with Engineering in SCRUM

As much as I love automated testing, I have come to live with the fact that teams migrating from waterfall approaches to development to SCRUM often try to maintain the team structures they are familiar with.  At times, this typically means an engineering staff that sucks at writing tests, and a QA staff that is still very much attuned to the finer grained edge and corner cases.  Each of these parts of your team adds value to a SCRUM project.  Integrating them to avoid bottlenecks, stay lean, and deliver with quality is a clever trick.

(more…)

An Omniscient Learning Approach to Mock-based TDD

I recently posted about why I think mocks are simply the easiest way to get the most bang for your buck in automated software testing.  But integrating it as part of a process is hard, and teaching it is even harder.  Young developers seem to have a hard time grasping the idea of testing isolated units of code.  I’ll confess – for a long time, much of my unit testing involved setting up the appropriate test environments – Spring containers for persistence units, test databases, you name it.  It’s expensive to test this way, and there are only so many situations when integration tests are valuable.  On lean, agile teams – code coverage isn’t held in as high regard as having working software.  On lean, agile teams – tests are a driver towards design, but they do need to be rooted in some level of initial thought on how a problem needs to be solved.

(more…)

Mocks – the only thing separating complex TDD from value-added TDD

About two years back when I started getting completely fascist about test-driven development, the complexity was always “gee, i have an application container and I need to involve it in my unit tests so that I can get full test coverage !!111oneeleventy.”

This typically meant providing a real collaborator, like a PersistenceUnit in Java, so that I could test trivial operations like persisting an entity.  At the time, I challenged a manager on this:

What are we really testing?  Are we testing OUR requirement, or are we testing something we should reasonably expect Hibernate to do on the basis of our initial technology selection?

Code coverage I believe is pretty overrated.  No one cares whether or not you can prove your method to persist an entity works because the developers of Hibernate/TopLink/LINQ to SQL have already proved this through their unit tests. What you are building when you write a test that actually checks the database to see if your middleware used a pre-packaged object-relational manpping framework correctly is an integration test.  There’s certainly value to integration testing with data access layers, particularly when difficult to test components of your middleware (like stored procedures and triggers) are involved.  Saving that however, the focus of test-driven development – namely unit tests, should be on the business logic that is proprietary to your applicatiom, be it the front-end or the middle tier.

Now, suffice to say that to a good number of developers and architects this isn’t news, but if you really want to isolate the code which you wrote that is specific to your business rules and requirements – mocking frameworks are the way to go.  Particularly in an Agile project where we can readily identify certain injected dependencies (like an EntityManager, for example) as a collaborator of the class under test, your unit test is really interested in asking the question based on this interaction with this external component, how should I expect my logic to react?

In these scenarios of course, I mock or stub the EntityManager.  In the past, a fool like me would have tried to load a container within my unit test environment.  This is actually an integration test, in addition to the fact that it is costly and doesn’t add the value a truly isolated unit test which focuses on the code you wrote does.

In .Net, RhinoMocks is scalding hot with it’s supprt for mocking through lambda’s.  In JEE, I’ve fallen in love with Mockito.

So, stop worrying about how you can get JBoss running so that your CI environment can execute inside of it.  Instead, use mocks to give your code the resources it needs to vet out the conditions in your own code that you want to test.