Cricket & Agile Software Delivery

Tldr; Ever since the Indian men’s cricket team pulled off an improbable, once in a generation heist, I couldn’t help but find parallels to how agile they were as a team and how I could relate their day to software delivery. A shining example. 

Hard Deadline

The final day of the final cricket test, a mammoth total to beat, against a formidable opponent and a team that was not the “A” team. Injuries had decimated the group. The spirit though, was strong. 

This could very well be a hard deadline software project, in a team riddled with attrition or lack of generalists. Pick your favourite constraint / adversity. 

Then, they pulled it off. Was this a fluke, based on random heroics of individuals or just plain divine intervention? 

None of the above, this was a well oiled group going about their business. They knew their strengths, they knew their goals, and focused on the basics, just as a mature Agile team would, lets break the day down into the key phases that one must go through to find that elusive consistency with quality. 

Plan

It’s oh so tempting to walk out and get batting ain’t it? No matter how talented your team is, without a plan, you’re staring at variable outcomes basis luck and heroics There will be wins, but there will be no consistency. This is not craft. 

The group began their day and planned for one thing, which was to not lose wickets and try to keep a scoring rate without losing wickets. Not too conservative, not too aggressive. 

Define what your group can do (velocity), basis past performance of the group that is available. If you can’t tell, start conservatively. Conservative = Slow you say? We’ll tackle that in the end. Conservative please. Walk before you run and all those metaphors. 

Having estimated how much your team can pull, figure out what all you can do, size up your opposition, each formidable story by story. Break down larger and more complex stories into smaller chunks (they will be more achievable to get DONE). 

Find Consistency

You’ve figured what you’re capable of, you’ve sized up the opposition and now it’s time to begin executing. Execution is all about starting small, playing your strengths and finishing / achieving more. 

The team set out at target in each session and kept at it, controlling wickets lost, and more importantly attacking the target in two’s. This is a construct of cricket you say. It is, but it’s also an invaluable tactic when knocking off stories in your sprints. Two engineers to a story, finish more things. Like a left / right hand combination, pair engineers who will benefit from working with each other. 

With workman-like ethic, the cricket team went about reaching their first milestone, where they had a healthy run-rate, had frustrated the opposition by being patient and taking their chances when they emerged. Slowly, gnawing away at the total. Small wins. Conservative, slow, consistent. 

This was a group that had met their first milestone. They had hit consistency with what they had planned. With this information and with velocity (wickets) in hand they took in the new information and revised their goal. They decided they would get more aggressive, they might lose more wickets, but they’d accelerate one part of the equation. Starting with a conservative target, wickets + runs, now, having met that target, the Agile team decided to ramp up one aspect of the goal (runs). 

Raise The Stakes

Accepting new information and being open to change, is Agile. Raising the stakes, means uncertainty. They would lose wickets, but it was a calculated risk. This is typically when an Agile team recognises that it is executing better than what they had planned, and decide to pick up more items to execute from the prioritized backlog. 

Items could be left incomplete, an “iceberg” story might be lurking, the team might be burnt out. There could be several unknowns, but the group is committed to delivering more value, and thus, powers on. 

A key fork in the road that many teams skip here, to their detriment is, Plan. Don’t forget to plan. The Indian team didn’t forget. Each move was calculated. 

To this end, I always recommend that the team practice JIT (Just-In-Time) Planning, take the blows as they come, plan with the best information available when needed. Don’t plan for items that you won’t even reach, which is then, lost time during execution. 

Timeboxes are your friend here. The Indian cricket team think tank did not obsess over the next phase of the game. They weighed the risks, set a stop loss, something like, lets not lose more than X wickets, and went to town. This is a great way to go, where the team decides how much damage is enough, and relies on telemetry via stand-ups, and daily task movement, to figure out if their elevated goal is still reachable within their risk parameters. 

The Indian team met this elevated goal with elan as well. Not to say that they did not suffer losses, they did, but it gave them a platform, from where a result, that might have seemed untenable at the start of the day was within grasp. This is the feeling when a massive epic nears completion, nobody felt that a feature was doable, but steady chipping away at the problem yields outcomes. Head down, focus, finish more things. 

Moonshot, Magic 

Even the best teams needs breaks. Call it luck, cricketing gods, architecture gods - whatever deity you fancy. The teams that emerge on the other side, are the ones that put themselves in a situation to maximise when a break comes along. This is exactly what the Indian cricket team did. 

The stage was set through the previous sessions and the group had an elevated outcome within reach. It’s valuable to note, that through the day, through the entire execution, each team member stayed true to their roles and skillsets. They were fearless, because they focused on their given roles and tasks. They were not bogged down by thinking about the larger outcome, there were other role-players who did that, presumably in the dressing room and from the stands. 

The role of senior engineers and leaders in the team is to empower their team to fire and focus on execution as they piece the jigsaw together, so that together, as a team, they can get to the outcome. Everyone worrying about everything is not an efficient use of the mind. There’s something be said about being fearless in engineering as well, thats a whole article by itself! 

Rishabh Pant would go on to say that he just played his usual aggressive game in the end, took the chances he got and converted them to bring home an improbable win, a test series win that made you believe in sports. It’s telling to listen to his interviews, undoubtedly there must have been nerves, but as he had demonstrated earlier in the series as well, he played his assigned role, and when he hit his high notes, there was no stopping him. 

An engineer in the zone, who delivers value every day, is a happy and confident engineer, and she is best placed to find the Zone and break through to that greatness circle. 

Retrospect

Since we’re being so Agile, we must end with a retrospective. This game had examples of everything that a strong software delivery team can mimic. Coaches preparing the team with roles, adapting to change and ensuring that they reacted to the changing situation around them. 

Players, who showed discipline, this is most important, and the hardest to crack. A mature Agile team is all about habits and discipline. Muscle memory wins. Drills and set pieces reign. You put yourself in positions and then when that break comes your way, you have a shot at creating magic. Starting conservative, yes, can be slow, but it builds confidence in the team and then you can accelerate and scale up. 

Every player on that team stood up and made a difference, they were not awed by the situation, they focused on what they could do, not what others expected of them. They did not focus on losing their star players or the adversity and unfairness that they could easily use as a crutch. They simply executed their plan, reacted to change and catapulted into the history books. 

Moonshot, achieved.