I had a plan for my long weekend. I’ve recently bought a small farm, and there’s a lot of work to be done clearing out the barn and organizing my horse gear as well as unpacking and organizing the house. My plan went approximately like this:
- Move the remaining hay out of the barn into the storage shed.
- Clean up the feed room and organize the feed and treats into rodent-proof containers.
- Set up the round pen beside the barn.
- Trim and rasp the hooves of my little Paso Fino mare.
On Friday I did move a lot of hay bales while my husband fired up the old riding lawnmower and tried to tame our weedy pastures. That’s where it all went sideways.
Because of course a wheel fell off the lawnmower, which necessitated a trip down the road to the local repair shop to get a new bolt. Which resulted in a conversation with the repair guy who had some extra young hens he wanted to get rid of. Which meant dropping everything and converting the old goat shed into a chicken coop. Which should have taken one day but instead took two because of course the goat shed was about 4 inches out of square which meant that engineering a functional door for the coop was a lot trickier than it should have been. Then there was the wild “chase that one crazy escaped chicken around the barnyard” escapade which consumed what little remaining energy we had left.
My barn is still a dusty mess, but I have the fanciest little chicken coop in Prince Edward County.
On reflection, it seems that farming and software development have more in common than I realized. Certainly I’ve worked on a lot of projects where the equivalent of the broken wheel inserted itself in the project plan. There are two ways to react to the situation. One is “I wasn’t planning to get chickens until next spring. I’ve got a barn to clean. I’m sure this guy can find another home for his chickens.” The other reaction is “Well, I am planning to get chickens eventually. This is an opportunity to accelerate my plan. With a small investment now, I can equip my coop and be eating home-grown eggs by fall.”
One response comes from a waterfall mindset; the other response manifests the Agile philosophy.
Agile software development requires us to be willing and able to adjust scope based on changing business need. But agility is more than a better way to manage scope. It’s even more than the ability to re-sequence activities and re-think dependencies.
Agile software development is about having the conversation that leads us to the discovery of the opportunity.
My husband COULD have gone to the big box store to buy the lawnmower part. But he wanted to get acquainted with the local repair shop. And once there, it was only neighborly to pass the time of day and admire the backyard chicken run. One thing leads to another.
Is your organization’s approach to Agile opening the pathways to communication, both formal and informal, that lead to understanding, discovery, and opportunity? Or are you adding layers of bureaucracy and process which stifle the free exchange of ideas? Are you giving your teams the freedom to decide how to acquire the spare part for their lawnmower, or are all design choices being made from the top down? Too often, what I’ve witnessed is the latter. Development teams, often offshored and overworked, are under constant pressure to deliver ever more code. The backlog becomes a funnel of tasks instead of a forum for conversation and innovation.
If your goal is “more code for less money” then your “Agile transformation” is bound to disappoint. If your goal is “better business outcomes enabled by technology” then focus on enabling backyard conversations. Tear down the walls between teams or at least replace them with friendly picket fences that folks can lean over.
