I recently had the opportunity to give a lightning talk at a local agile meetup. If you’ve not been to a lightning talk (which I keep wanting to type as ‘lightening’…probably because it resembles ‘enlightening’) these are presentations you give that last 5 minutes or less.
You can use slides or not, but you will have to fit what you have to say in 300 seconds. It is a great opportunity to try out an idea on a friendly crowd. And I find that the time constraint forces you to examine, distill and re-examine your ideas in a healthy way.
For visuals, I had a single slide with 3 images on it. The rough transcript of the talk is below.
Now that I’m at the end of this set of articles, a retrospective is in order.
I’m very pleased with the final shelves. They’ve been doing everything I need a shelf to do for months now, with no maintenance required. You have to love a feature that doesn’t require any support after go-live.
When I started writing these articles, I was curious what would come of it. I made a few key mistakes that prompted me to explore the project from an agile context, but I wasn’t sure what I would uncover.
Along the way I realized that “agile” is at risk of becoming a meaningless term. People are throwing “agile” in front of everything (including articles on home improvement projects).
The nice thing about agile is that it is a set of principles; a philosophy. And like any philosophy it has its strict adherents and its loose followers. It has those espousing the “right” way to practice agile and those that are bit more loose in their interpretation.
This can lead to ambiguity or confusion, but it also provides an opportunity for each of us to identify what we mean when we use the word “agile”.
This set of articles forced me to articulate what agile means to me.
If I reduce it to its basest essence, being agile to me is about assuming that you are wrong.
Each shelf has 4 hanging supports. Each support is made of 2 – 12 inch pieces of slotted angle iron. So with 2 shelves left, I needed to attach 16 pieces together to make 8 pieces.
For the first set of shelves, I did this in-place by attaching the first piece to the ceiling mount and then the second piece to the first piece. It worked fine, but was a little slow going since you are working on a ladder with your arms above your head.
I decided that since I’d proved my design worked on the first set of shelves, I could optimize this process.
I measured the length of a hanging support from one of the first shelves and then pre-assembled the 8 remaining hanging supports I would need. To save time, I didn’t leave the bolts loose, I went ahead and fully tightened them with a wrench, saving another step I wouldn’t have to do later on the ladder.
Impressed with my own cleverness, I started to build the last set of shelves. I hung one shelf and then tested by opening the garage door.
An Eventually Successful Attempt at Continuous Improvement
With the first door done (two shelves), it was time to work on the second one. I had a mini-retrospective at this point. I asked myself what I’d learned and what I wanted to do differently. A few things came to mind. First was: More Power
As far as the length of the brackets, I wasn’t sure if my ceiling joists would line up with where I needed my shelves to be. Rather than take the time to figure it out, and potentially end up with smaller shelves due to where the joists were relative to the garage doors, I decided to be less efficient in my use of materials.
I decided to use larger brackets and hang them across several joists. This would allow me to position the shelf wherever I needed, rather than locking me into the location of the ceiling joists. In programming terms, I created loose coupling between the ceiling joists and the location of the shelf.
This would be more expensive. I would have to buy longer pieces of angle iron to bridge the gap between the joists, but it gave me two key advantages. First, I didn’t have to determine up front exactly where the shelves would hang. It reduced up front planning and allowed me to defer key decisions. Second, I didn’t have to reassess the size of the shelves relative to where I could hang the ceiling brackets.
I had to remind myself that my goal was a set of 2 foot by 4 foot shelves over each garage door. That was the only goal that mattered. Optimizing to use less materials (optimizing to reduce cost) was going to take me away from my goal. I also realized a secondary goal: To finish the project quickly. Because I was doing this on my own time and I highly value my time, I was willing to make some concessions on cost.
In terms of the iron triangle, I fixed my scope, wanted to control my schedule and was willing to give a bit on cost. Which, now that I think about it is not the way most software projects run…
Ok, so I was inspired, but wasn’t ready to build anything just yet. I started where most research starts these days–the internet. Specifically Google and Amazon. I was looking for a Commercial Off-The-Shelf (COTS) solution to my problem. Basically, something I could buy and it would just work. This is almost always a great place to start, but a difficult one for some software teams to embrace.
I started the project with a simple goal: Clean out the garage
Now that I’m done, I realize there is a better word for it than ‘clean’. I refactored my garage. From Wikipedia:
Code refactoring is the process of restructuring existing computer code — changing the factoring — without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility.
I didn’t change its external behavior or its key ability-tos (storing things including 2 cars), but I reduced complexity, improved maintainability and made it more extensible (freed up or created more storage space).
Over the years the garage had become disorganized, marginally usable and the cruft was visible wherever you looked. I’m sure you’ll find no relationship whatsoever to any applications or code you’ve worked on.
There were bugs. Literal bugs and a healthy ecosystem of black-widow spiders to eat the bugs. While I’m all in support of the circle of life, I prefer it to be on the outside, rather than the inside of my house.
Last week I built some hanging shelves in my garage. Midway through the process, I realized that it was an excellent opportunity to view the project through the lens of agile software development.
There were things I did that benefitted from what I’ve learned about agile development, and mistakes I made that could have been prevented if I’d been following agile principles properly. This article is an exploration of those ideas… and instructions for building shelves.
Bottom line up front (BLUF). If you want instructions for building hanging garage shelves, they are here. They are completely devoid of any discussion of agile development.
If you want to hear the story of building the shelves and how it relates to agile software development, read on.