September 1, 2021
Several months ago I contracted with a company to install a fence in my backyard. It was primarily for privacy but it was also intended to keep all the critters out of the yard. We live near a forest preserve and even though it is a suburb of Chicago, we get everything from deer to raccoons, possums and skunks.
We also have neighbors on each side of our property that have dogs as pets. Our existing chain link fence, though unsightly, keeps each dog in their own yard.
Little did I know that my fencing contractor wasn’t familiar with agile ways of working.
Though not what I would consider a major purchase, a fence is a relatively large investment. I met with the contractor and we discussed the material and height of the fence. But we didn’t really discuss how the fence would be installed. I figured he was the expert and I trusted his approach. Which was a mistake – I should have asked more questions about how he was going to install it.
Things started off pretty well and I wasn’t concerned. When he first arrived, he asked me if my neighbors on either side had dogs. I told him both did. I thought that he would factor that into his approach. Unfortunately he did not.
So apparently the way my contractor planned to install the fence was linear and not iterative. Like a waterfall project, he was going to do each activity just one time and I would see the value in the final delivery. It goes something like this:
As a linear approach, it looks like this:
Does this sound like a solid or agile approach to you? Plan the work and then work the plan.
Unfortunately, it didn’t go as I hoped. What I thought would be just 3-4 days of work has turned into 3 weeks of work.
You see my contractor completed steps 1-3 and was on step 4. Then we received a significant amount of rain which filled the post holes and stopped work until it dried.
In the meantime, the current state of this project is somewhere between started and finished. All the old fencing materials and the brush is stacked up in the backyard along with all the new materials. No section of fencing is complete – it is all in progress.
While that is probably not a big issue, the fence is no longer there to contain the neighbor’s dogs. In addition to using my backyard as their new bathroom, the dogs on either side are not overly friendly to each other. I can see them rush toward each other in the new DMZ that my yard has become as if they are ready to fight for the new territory.
I am no fencing expert, but the results of this exercise led me to believe that agile ways of working would have been better.
Rather than using the waterfall approach with the final value delivered only at the very end, what if we used an agile approach? What if we broke the work down into smaller chunks or increments?
The backyard is fenced on 3 sides and an easy way to divide into increments was to focus on one side at a time. The steps may remain the same, but our focus is just on one of the 3 sides at a time. Since we are going to go through this process 3 times, perhaps it would make sense to include a short retro after each cycle:
Using an incremental or agile approach, the contractor would only remove the fencing on one side at a time and then install the new fencing on that side. Some of the benefits of this approach include:
So why do people continue to use the waterfall approach?
Or rather, perceived efficiency.
It is more efficient to do everything at once. Whether you are removing an old fence or digging new fence poles, it is more efficient for you as a worker to do all of that job until it is done.
And so it goes with all types of knowledge work. Most people feel like as long as they have the code open or have started drafting the document, they might as well finish it before handing it off or starting the next step.
We have to look at the bigger picture and avoid trying to make ourselves more efficient. We need to take a system-wide view and not try to optimize locally.