I would do whatever was possible to get out of cutting the lawn. I still do, for that matter! Raining in Sudbury? Well, it could make it to Ottawa at any time... that would be unsafe! Inevitably, though, I had to cut it.
Even then, I wasn't going to go out of my way to extend my agony any more than was necessary. The back lawn in particular was quite large, and by itself it took a full hour to cut. I guess I have the process improvement gene turned on, because I spent a good amount of that one hour trying to figure out how to make it something less than, well, one hour. Eventually I figured out what slowed me down - square corners. Each 90 degree turns mean stopping, turning the mower starting again. If I could remove as many of those corners as possible, I would reduce the amount of time it took to cut that lawn.
This particular yard wasn't perfectly rectangular, and had several trees. I determined that there were a few places along the edge I could cut first to remove some of the variance in the shape of the yard, and that I would have to do at least one full pass to cleanly cut the outside perimeter (OK, so I did care a bit about the quality as well!). After that, I kept to cutting in one continuous strip that was curved around the corners rather than square. This didn't bother my Dad at all, so I then set about optimizing the new process.
It took a couple of tries, but I eventually reduced the cutting time from a full hour to 45 minutes. Being a rather impatient teenager at the time, having an extra 15 minutes to do what I wanted was much better than nothing!!
Coaching Point
The teams with whom you work may be used to square corners in their process, their tools or even just their practices. Look for ways to help teams identify where they can round off those corners to reduce or eliminate disruptions in their flow.
For example, automate anything that the team has to perform more than a single time. Testing, builds, deployments, etc. are all practices that can be automated to some extent and have a tremendous amount of tool support now. I've worked with teams that automated the creation of a developer's work environment so that a new person on the team could be up and running in minutes!
Even partial automation can be helpful. If complete automation of a test is difficult or expensive to do, can the setup and/or evaluation of the results be automated? Could you use Perl or Ruby to write a script that put a database in a known state prior to executing a test? Rather than poring over a huge log file, would a shell script that simply grepped the results work? When evaluating the UX of a particular portion of an application, can an automated script be used to get the tester to the point where the human eyeball takes over? Could that same script pause, prompting for a pass/fail decision from the tester?
Of course, it takes time to determine the level of automation that works best for a team. After all, I didn't simply come up with the one true way to cut that lawn in one day - it took several iterations before I was able to figure out the optimal approach. There's also a cost associated with creating and supporting the automation tools and environment, which is best done by the team or teams who are using the automation tools. The people using the tools have the most vested interest in seeing them work and improve further!
In the end, these "rounded corners" will keep the team moving ahead at a steady pace in the long term. They promote flow and allow the team to accommodate changes as they learn more about what they're building.
Oh yeah, after I moved out of my parents' house, my Dad bought a riding mower. Cutting the grass is now considered fun, I'm told. I have never had the opportunity to use the riding mower myself. I'm sure there's another lesson there somewhere! :)
Were you paid a fixed price to mow the lawn? Or hourly?
ReplyDelete