Quick software development and chicken

I had a plan for the long weekend. I recently bought a small farm, and have a lot of work to do to clean the barn and organize my horse gear as well as unpack and organize the house. My plan is almost like this:

  1. Take the remaining straw outside the granary to the storage shed.
  2. Clean the feed room and organize feeds and treats in rodent-proof containers.
  3. Place the round pen next to the barn.
  4. Trim my little paso fino mare’s hooves.

On Friday I removed a lot of hay bales when my husband shot an old riding lawnmower and tried to control our weedy pasture. That’s where everything turned upside down.


Because of course a wheel fell from Longmawer, which was forced to go down the street to a local repair shop to get a new bolt. Which led to a conversation with the repair man who had some extra young chickens that he wanted to get rid of. Which meant throwing away everything and turning the old goat shed into a chicken coop. Which should have been taken one day but should have taken two instead because of course the goat shed was about 4 inches square which meant that a functional door for the cage was much more complicated than it should have been engineered. Then there was the wild “chasing chickens around a crazy barnyard” escape that consumed the little energy we had left.

My barn is still a dusty mess, but I have the fancy little chicken coop in Prince Edward County.


In hindsight, there seems to be more in common between agriculture and software development than I realize. Of course I have worked on many projects where I have inserted myself into the project plan equivalent to broken wheels. There are two ways to respond to a situation. One is “I didn’t plan on taking chickens until next spring. I have a barn to clean. I’m sure this guy can find another house for his chickens. “Another response is,” Well, I’m finally planning to get chickens. This is an opportunity to speed up my planning. Now with a little investment, I can decorate my cage and eat home-grown eggs in the fall. “

A response comes from a waterfall mentality; The other reaction expresses a quick philosophy.

We need to be willing and able to adapt to changing business needs in order to develop agile software. But agility is more than a means to an end. It is more than just the ability to rearrange activities and re-think dependencies.

Quick software development is a conversation that leads us to discover opportunities.

My husband can go to the big box store to buy parts of Lonmawar. But he wanted to get acquainted with the local repair shop. And once there, it was the only neighbor to pass during the day and admire the backyard chicken racing. One thing leads to another.

Is your organization’s approach to agility paving the way for both formal and informal communication, leading to understanding, discovery and opportunity? Or are you adding a layer of bureaucracy and process that suppresses the free exchange of ideas? Are you giving your teams the freedom to decide how to acquire extra parts for their lunar mavericks, or are all design choices being made from above? Often, what I have witnessed is the latter. Development teams, often offshore and overworked, are under constant pressure to provide more code. Backlog became a funnel of work rather than a forum for conversation and innovation.

If your goal is “more code for less money” then your “smart conversion” is bound to disappoint. If your goal is “technology-driven business results” then focus on enabling backdoor conversations. Break down walls between groups or at least replace them with friendly picket fences that people can lean on.

Leave a Reply

Your email address will not be published.