How I Used Agile to Landscape My Backyard

When I was first exposed to Agile, Scrum, whatever-it's-called, I didn't get it. At the time, I thought Agile was its tools - things like Jira, VersionOne - and 15-minute meetings in which we remained standing and shared our feelings with each other.

Over time, however, it became clear that there was more to it than those things; that Agile wasn't the tools used to execute it. Agile is a way of thinking - a mindset.

In June of 2015, 6 months into my exposure to Agile, I was beginning to catch the vision of the methodology and its implications on our software development team. I started intently studying it and experimenting with ways to execute it better. I read one article in which the author detailed how she had used Agile to renovate her kitchen. I wondered if that was something we could use as a family.

One afternoon, I was surveying our disaster of a backyard. I reminisced about the time when we moved into our home, the yard was 3000 sq. ft. of pristine Kentucky Blue Grass. Having moved from California, however, we did not know about "winterizing" a Utah yard required turning off a stop-and-waste valve. Not surprisingly, our sprinklers in the backyard ruptured in mid-February when the snow was 8 inches deep. Thinking that we could manually water our backyard, we elected to not fix the system before summer. Long story short, the backyard went from manageable to unwieldy in a matter of weeks. Here is what it looked like the day we demoed it (08/15/15):

Obviously, this wasn't a great place for the kids or for hosting guests. We knew it was a problem that had to be fixed. So I began dissecting the problem by envisioning the project iteratively. I broke the beginning to end into iterative features. I used user stories to highlight the features of the finished product. I should mention that this was a good exercise personally because there were no contractual implications or "market" impacts of my user stories.

The persona used was "family member," so:

As a family member, I want a backyard that is nothing but dirt, so that edging can be easily installed.

Now, I understand that maybe this user story is too "big," vague, or even kitschy, but what I was able to do was ask myself if I could reasonably complete the task of reducing the space to nothing but dirt in one day - one day being the time during which I had help available (I only had help available on Saturdays, and I didn't want to infringe on people's weekends, so I limited the availability to a few hours each Saturday). Based on the hands I had available and the equipment I had scheduled, I knew this could be done in a matter of hours. We took the above picture on August 15th, 2015, at around 6:30 am and the below picture in the same exact spot at around noon that same day:

---

My next feature was based on having edging in place, but this time the "so that" convention indicated we wanted edging installed so as to partition the space into functional areas: a dedicated space for recreation and others for planters. Based on what I knew of available resources, I reasoned we could do this in one day, as well. The below picture was taken the following Saturday, August 22nd, after a few hours labor by a handful of friends:

---

This was several hundred feet of trenching and back-breaking installation of the black edging.

The finished product above. In total, the project took 22 days to complete - we had a goal of doing it in 21; 50 people, and we came in under budget.

So what I'm trying to illustrate here is Agile is not its tools. In the case above, Agile wasn't the pickaxe, the mini-skid, or the shovels. It was the way we approached the project, the iterative nature and sizing of the features and tasks, responding to change, identification of dependencies i.e., which features needed to be in place before others could be done, and the subsequent resource planning. There were many instances in which I was asked, "Do you have this tool?" And I'd respond, "I didn't know I'd need that until now," and then I'd go a buy one. In so doing, we only had that which we actually needed. In traditional waterfall approaches, I'd need to examine the project as a whole and attempt to predict what tools I would need, purchase them ahead of time, and hope they were used - this would undoubtedly balloon my costs. There were numerous instances in which we were confronted with unforeseen changes, but we dealt with them - because we knew going into this that they'd reveal themselves - and moved on.