Part of Being Agile means Charging Ground Balls
Baseball is a mesmerizing dance measured in increments of time & distance. In many ways, so is Agile.
I’m truly enjoying watching the 2019 World Series. There are many reasons for my delight, but the biggest is watching the high-level of execution by both teams … while the players are having boatloads of fun.
It makes me wonder aloud, “Why can’t the same happen for agile software engineering teams?” Then I remember, oh, it’s because we often punish failure that sometimes results from ‘responsible acts of commission.’
Art of the Ground Ball
One of the aspects of baseball I’ve always appreciated is great infield play. Such play shines under the circumstances as the perfectly placed bunt, a rocket shot line-drive, or that ever-elusive, error inducing, bouncing “ground ball with eyes.”
It’s that evasive ground ball that also reminds me of instances in agile software development where the unknown unknowns abruptly reveal themselves in ways that evade every adorned ritual, automated test, and other processes we have in place.
The question is, how can we, as individuals and teams, make winning plays on those proverbial ground balls we encounter in the form of discoveries, bugs, outages, performance issues, and failed hypotheses?
Art of Charging the Ball
Baseball is a game of inches and seconds disguised in a field of play measured in feet and innings. To understand this, watch a little league game live, then a professional game live.
In little league, you’ll often see players who wait on their heels for the ball to come to them. One of two things often happens, neither of them good:
- they are too late or too poorly positioned to make a play; or
- the ball takes an unexpected bounce past them (or worse, into their face).
Similarly, I’ve seen individuals assigned to development teams do the same, where they sit at their workstations, waiting for work to be assigned to them.
In the pros you’ll see infielders aggressively close the distance by ‘charging the ball’ … but doing so in a way that is both skillful and safe by:
- Shifting to align with the batter, base runners, and field conditions;
- Physically set oneself to move as quickly to the right as to left, forward as backward;
- Staying low to reduce head eye movement and reduce injuries due to bad hops;
- Fielding the ball on the outside of their glove-side leg;
- Shifting their weight to the opposite leg to throw the ball; and
- Bare-handing the ball only if there is no other option.
In the same way, I’ve witnessed high-functioning agile individuals and teams “Welcome changing requirements, even late in development …” by aggressively taking ownership of bounding unknown unknowns by:
- Positioning themselves so they can keep their eyes focused on the issue;
- Engaging best practices to more quickly to capture the issue;
- Avoiding entrenching their implementation in inflexible or complex ways;
- Anchoring their understanding in data so they can effectively communicate the issue; and
- Avoiding rock-star heroics.
Art of Committing Errors
I recall in 1994 watching an Oriole’s game with my first baseball coach, my Dad. The play-by-play announcer referred to ‘Iron Man’ Cal Ripken’s 17 errors the previous season. This was quickly challenged by the color commentator reminding everyone that predecessor and mentor Brooks Robinson (arguably the greatest defensive player that ever lived) also committed 17 errors in 1970, the year ‘The Birds’ won the World Series against ‘The Big Red Machine.’
Then my Dad spoke up, saying, “Yeah, that’s because Robinson would make plays on balls that would cause mere mortals to soil themselves.” The same is true with Ripken, where a 1990 LA Times article stated, “The plays were so difficult, they probably would have been scored hits instead of errors …”
What the name of Earl Weaver does this talk of errors have to do with Agile? Simple. We will not see similar high levels of play by our developers nor product owners unless our work culture offers psychological safety when it comes to ‘mistakes of responsible commission.’
Conclusion
The bottom line is that management isn’t incentivized to invest in agile if engineering team members … and product owners … simply stand on their heels and wait for the play to come to them.
Similarly, engineering teams and product people have little incentive to aggressively “… satisfy the customer through early and continuous delivery of valuable software” unless they can also enjoy the growth mindset that comes with celebrating and learning from failures …
… rather than punishing people for errors that sometimes occur while attempting to make difficult plays.
The alternative is a vicious cycle where development teams feel stuck in a feature factory because management doesn’t feel or want development teams taking the initiative.
I’d be interested to hear your thoughts on this.
Go Nats!
