tsJensen

A quest for software excellence...

How Agile Software Development is Like Farming

I grew up on a small farm in eastern Utah a few miles west of Roosevelt. My dad is still farming but on a smaller scale these days. He and my mom dropped by for a visit the other day. They asked about work and as I described to them what I do, it struck me that there are many similarities between agile software development and farming.

Here are a few that came to mind:

Agile Architecture and Development Aspects Farming Agile Software Development
Strategy The strategic decisions for the next growing season are often made in advance of the current season’s harvest. Will a new well be required to water the south forty? Strategies to improve existing systems and even to plow them under and rebuild them are often hatched before the existing system goes live. Will we move this system to cloud for improved availability?
Non-Functional Requirements Before building a new barn or corral, thought must be given to the usability of the gate, the reliability of the roof, and the performance of the cattle chute. Before building that new system or drastically modifying an existing one, much of the same thought process needs to occur.
Budget While we could plow more acres per day with a new tractor, can we get what we need out of the tractor we have even if we have to work forty more hours? What opportunity will those forty additional hours afford us? Should we buy new big iron or enter into that hosting contract for improved performance? Or should we invest in improved engineering practices to improve code performance and storage requirements?
Milestones On a hay farm, progress through the summer is measured in hay crops. For me that was 3 crops before going back to school. All work revolved around watering the hay, cutting the hay, baling the hay, and hauling the hay. Then repeat. Each milestone or set of sprints in agile development often take on a repetitive structure allowing the team to achieve a rhythm or cadence that moves the software toward completion.
Sprints 6 days (Monday through Saturday) – Only  after I started my professional career did I realize most people don’t work on Saturday. I’ve never been able to completely accept that pattern in my own life. 2 weeks (most often) – sometimes a different interval works better. It probably depends on what you’re growing.
Sprint Planning 1 day (Sunday) 1 day (part of the 10 days in the 2 weeks)
Stand Up Every day at 6am. Lasts less than 15 minutes is identified and then tasks are begun as work from the previous day was most often discussed at dinner after dark. This includes identifying what equipment broke down the day before and who will fix it and when but rarely includes much discussion of how. The how is known. Usually at a more reasonable time. Since we didn’t eat dinner together, we review quickly what happened and discuss what will happen today. We also identify problems that occurred, but this works best if the resolution of such problems are taken offline.
Retrospectives At the end of the week or when a crop was put up, we took a little time out for a picnic or a day trip to the city. We reflected on how we could work together better—or how my brother and I could stop fighting long enough to get some work done. When done properly in the agile / scrum process, the retrospective has the power to improve a team’s ability identify and keep what worked and improve what didn’t.
Tactical Action When the baler breaks down in the middle of the wee hours of the morning while you’re baling hay that needs to be baled now, you get off the tractor and you fix it right then if at all possible. Sometimes, when its broken, you need to get up in the middle of the night and fix it. And then you figure out how to avoid that scenario in the future. Bugs are a part of software life but if you’re killing the same bug over and over again, it may be time to get a new baler.
Preventive Maintenance If you don’t grease the baler before you start chewing up forty acres of hay that needs to be harvested, you will find yourself fixing the baler at the most inopportune time. Far better to replace that worn out knotter and grease up the plunger before you put it to work. Systems deployed and left to their own devices have a tendency to break when you can least afford it. But systems and software that receive regular attention and care will provide longer service and fewer headaches. That extra tube of grease can be invaluable.

There is one very big difference between software and farming. The former pays better and is easier.