Sometimes, you may come across someone who insists that an agile approach won’t work for them, their project, or their organization. That’s where an analogy outside of software development may help. Mowing the lawn may seem like a strange way to explain the concept of agile development, but bear with me, I think it is a good one.

My house is on a lot that is 160-feet wide by 120-feet deep. I have a large front yard, a side yard, and a reasonable back yard, which I mow with a push mower, not a riding mower. All in all, with edging, sweeping, and mowing, the entire job takes three to four hours.

While three to four hours is a great exercise session, a number of things can get in the way: family plans, how much energy I have, the weather (I live near the Gulf of Mexico, south of Houston), the heat, or my phone battery. This is an all-or-nothing approach, one in which there are no useful or valuable results until the entire job is done; this is, at best, a risky approach, if not a foolish one.

Being an agile advocate, I divided this big job up into six smaller (each one complete on its own) jobs or chunks. Chunk 1 is my front yard. If all I have time to do is that one section, then the house and the yard will look good enough from the street. Chunk 2 is a small strip of the front side yard, completing it with chunk 1 completely finishes off the front of the house. Chunk 3 is the rest of the front-side yard. Chunk 4 is the back-side yard. Chunk 5 is my fenced in back yard. Chunk 6 is a six-foot wide strip of behind my fence. Chunks, like stories, do not have to be equal in size but each chunk should have a value of its own.

There is a natural priority involving Chunk 1, Chunk 2, and then Chunk 3; this combination makes the front of the house look good from any direction. Most of the traffic on our street comes from one direction and with Chunk1 completed, the house and lawn look good from that direction. Completing Chunk 2 after Chunk 1 completely finishes off the front of the house. Following up with Chunk 3 has the house and front lawn looking good from either direction.

See how this applies to agile development? This approach of dividing a large project into several smaller, yet still complete stories is what we do in agile development. There is a natural priority I can follow or I can change the order when needed.

No matter if I spread the work over multiple days or do it all in one day, I get good results. If something prevents me from completing my task all in one day, no problem; what I did complete stands alone and looks good. I can take care of the rest when the weather and other conditions permit.

This approach to “mowing the lawn” is an example of feature-driven iterations. Each iteration should be focused on a single story: a complete, stand-alone section of the yard. The iterations were of varying sizes.

I first used this approach on development projects in the 1980’s. Each iterations was feature-based, in which the length of the iteration was dependent on the chosen feature set. Sometimes an iteration was three-weeks long, sometimes a week. What I did then was a different approach from what we see in agile today in which iterations are of a fixed size.

Being the curious type, I made a change in my method one spring. I mixed my feature-driven approach with a time-box approach. I used a twenty-five minute time box—twenty minutes of active work followed by five minutes of rest or recovery. A rigid twenty minutes of work didn't fit in with my original chunks as all but one chunk takes more than twenty minutes to complete. How seriously did I adhere to the twenty-minute time box? I settled on completing the small job before taking a rest. What's a small job? It involves mowing to the edge of the lot or fence; when twenty minutes is up, mow to the next edge, then break.

Another lesson I learned from mowing the lawn is that you want a collection of stories that have value but fit nicely and snugly within the time box of an iteration. My original set of lawn chunks definitely had value but only one fit within a twenty-minute iteration. If I had been stubborn and refused to make adjustments, then I would have had to either make my iterations longer (and risk getting overheated in the heat of the summer) or accept the fact that the size of my stories overlapped my iterations and, as a result, I would not be able to claim that most of my iterations were complete.

Instead of either of these choices, I choose to adapt. I kept my big stories because they made sense, but I created a new story entitled, “Mow to the Edge” of the lot or curb. This approach means I work a little past every twenty-minute iteration, but by only a few seconds. I still have ample time to recover and get ready for the next iteration. This allows me to fit my work within the confines of the iteration and still deliver a collection of complete stories every iteration.

What doesn't work are stories in which their size do not easily fit within the confines of the iteration. When this happens you wind up with either incomplete stories at the end of the iteration or you might be exhausted because of the workload that extends beyond the iteration and into the recovery time in order to complete the big stories.

This leads to another lesson: short iterations provide built in recovery time. In my old feature driven approach I kept mowing until I was near exhaustion. More than once I've felt a chill in ninety-degree weather. Using twenty-minute iterations followed by five-minute recovery keeps me from ever getting too exhausted, hot, or thirsty.

What can we take from an agile approach to mowing the lawn? We can learn that any project can benefit from an agile approach. Additionally, large projects can be broken down into smaller stories, each complete and with value.

Make sure you always look for the story within the story, and hold true to your iterations and allow time for rest and reflection. Finally, when the work wears you down and you’re challenged on how to apply an agile approach think of me mowing the lawn.