Real World Agile

This weekend I had a problem to solve and when thinking about it, I thought how I would solve the issue as if it were a software problem as it raises some interesting points about being agile and how people get it wrong.

The Problem

We had a broken door handle on our bathroom, which has been irritating us for some time. We decided to remove it the other week and replace it but were left with a slight issue. When we removed the latch from the door we found it was round, whereas the new one was rectangular, it looked like this:

We realised at this point that we needed to shave away some of the door so we put off the job for another weekend, which meant we had no handle or lock on our bathroom door, not a major issue but annoying.

This Saturday my wife decided she was fed up with the door so decided to shave the wood away and put the latch in, which after much noise and swearing she achieved. This was great but now presented us with a much more pressing and imminent problem, which was that we had a baby sitter arriving shortly and we couldn’t leave the door in this state as she could potentially end up locked in the bathroom with no handle and then who knows what might happen!

Solutions

Here we were left with a typical problem not unlike one you would be presented with in a software development scenario. We really needed to have a handle on the bathroom door, and needed it ASAP but simply didn’t have the time to complete the job 100%, so what to do?

After some discussion,  and much the my wife’s displeasure, we decided to put the handles on both sides and as many screws as we could do in time. This would mean the handle was functional and worked so it could be used. She would have much preferred that I 100% completed a handle on one side before starting the other but as it turned out we only managed to get 4 screws in during the time we had, so only one handle would have been done, leaving the door unusable.

What we actually ended up with was a solution that still needed some work, but solved the immediate problem.

Technical Debt

Now some people may argue that by only putting in 4 out of 8 screws we accumulated technical debt. I personally don’t believe this is true, this wasn’t really debt, what we had done is complete a first iteration. It may have been that someone (my wife most likely) had decided they didn’t like the handles and wanted different ones for example and in this scenario we would only have 4 screws to remove rather than 8. This is the point of getting the least done before getting the product in front of your end users, providing that it works as it ought to, but with potential for more gold plating at a later date.

Technical debt for me would have been one of the following:

• Not putting the handles on and leaving the bolt through the middle. This would have worked and really could have been the bear minimum but would also have been really prone to breaking and would require immediate extra work to fix it.
• Super gluing the handles on. This would have been fast to implement and would have solved the problem but would have resulted in extra work being done to remove the handles and then refit them properly at a later date.
• Putting some sort of easier fitting handle or knob on, which would have needed to be removed at some point to be replaced by the real handles.

The reason why I consider these all debt as they require extra work or risk that wouldn’t have been necessary if the work was done to an acceptable standard in the first place.

Why such a strange blog post?

So why post this at all? Well the reason why is because so many teams don’t understand being agile. I’ve seen people who would happily have just put a handle on one side of the door, or super glued the handles, or even just left the bolt in the door and all these solutions are a bad idea. It’s important to prioritise what needs to be done first, and how that can be done to a standard where it can actually be given to the interested parties to try it out, without investing extra time in polishing something that isn’t a requirement yet.

You could also argue we shouldn’t have put the latch in the door just before going to dinner, but I’m sure you’ve all seen developers start a piece of work or bring in some framework or product to solve a problem when it isn’t really required at that time, creating a false priority that needs to be actioned, I’ll blog about that another day.