Intro

One of the really fascinating things about writing software is that after you've done it for a while, you realize how the processes and mindset that you use can apply to just about everything around you. A perfect example is Bryan Watts' article on finding humanity in software. Sometimes the software process helps you understand the non-software task and other times it's just the opposite. Today I'm going to highlight how the Agile methodology fits in with cutting grass. Before we go any further, the answer is yes, I wrote the rough draft in my head during multiple summer sessions of lawn mowing.

Architecture Decisions

Before you begin on any project you have to make a few upfront decisions that will set the tone for the entire process. How big is my yard? Do I need a riding mower or can I be just as successful with a walk-behind? It's tempting to just say you need the best and most expensive tools but you'll have wasted a lot of money and storage space if you bought a rider to mow 100 sq. ft. of grass.

Some decisions can be swapped out relatively cheap and easy while others would require a massive effort to change. If you decide later that you want to mulch the grass as you cut, most of the time you can just swap the blade out. If you were too conservative with your budget up front and ignored the self-propelled mowers then you're out of luck and have to replace the whole thing.

This same discussion happens at the start of any new software project. What platform and data storage should we use? Do we need a whole suite of cloud products or can we get by with lower level hardware? It depends on how much grass you're planning to cut. The analogy of our mulching blades applies here, as well: if we start with SQL Server Express we can eventually graduate to Azure SQL databases that we can keep scaling up. On the other hand if we learn that we should have gone with a NoSQL datastore, that's a larger effort.

Scoping/Refinement

You've purchased and assembled the mower and you're rarin' to go. Don't just drive out into the grass and start hacking at it. You need to plan out your overall sense of attack and set your scope. Are you also using the string trimmer and edging in this session? Are you only committing to mowing the front yard first and saving the back yard as a stretch goal? Setting your scope ahead of time helps you avoid making a mistake by over committing and cutting a straight line from the front yard to the back, requiring you to finish the entire yard.

When you're ready to start writing code in a new project it's tempting to write a grand framework that handles everything you can think of but that creates a huge upfront investment with nothing shippable for multiple iterations. Agile is focused on being able to ship a working version of the project at the end of each iteration and being able to pivot your priorities if they change over time. If you only mow the front yard first, you could put the backyard on hold and deal with some other hot issue that springs up.

Iterations/Retro

When I'm cutting the grass, I like to think of each line as a hyperspeed version of an agile iteration. When you start the line, you look across to where the line will finish and aim the mower before you start moving. This is sort of like sprint planning: you've started adjacent from the previous line, you've made a very short term goal, you've decided how you're going to get there, and you walk the line with your eyes only on the end of that iteration.

Let's stretch the analogy further and talk about how you committed to only cutting the grass in that line and you're not going to veer off in some random direction. You might spot other things that need to be done later in the task but you're just mentally filing those away in your backlog. Everyone loves the happy path but there is also the possibility of your iteration getting blown up when you discover that your kids left a toy in the yard.

When you get to the end of your line and turn around, it's a great time to have a little retrospective on how that previous line went. Was it straight? Did you miss a spot? If you followed the line before it and you still were curved, you might be a victim of grass debt and entitled to compensation.

Grass Debt

Grass Debt isn't a real thing but I think of it as the analog of Tech Debt. If you introduce a curve into your lines and all subsequent lines follow each other, you'll soon have a yard full of mismatched curves. This is like introducing tech debt into your code that you just work around but never correct the core problem. In both scenarios, it's generally preferred to pay back debt as soon as you can. If your next line is perfectly straight but you have to drift back into the previous one, you've corrected the problem for all future iterations even if you didn't cut as much grass as possible. On the other hand, some debt is acceptable. If you can tell it's going to rain soon or your software has a hard deadline approaching, it's better to finish the job and accept that not all of the lines are straight. I'm a fan of the .NET Rocks podcast and one of their tenants is that "shipping is a feature".

Conclusion

As you might have guessed, mowing the lawn is generally a boring task if you forget to charge your headphones. If you ever find yourself in a similar situation, think of how you would model that thing with software and then write an article about it. It seems like a silly exercise but will only improve your skills at modeling real processes in the workplace.