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.