Lessons from the Cupboard

As we continue to use Kanban and some elements from Scrum to manage our family life, I often experience learning moments that I can take back to my job of building software. What originated as a drive towards kaizen at home, is in fact permeating through my life and deepening my understanding and application of lean and agile systems thinking.

One of these learning moments recently came about as my husband and I tackled one of our weekend cards – re-attaching a cupboard door in one of the bedrooms.

Over the years, we’ve had to call out the landlord’s maintenance team every few months to do this. Frustrated with the fact that the doors usually come off again within a couple of months, we recently decided to take on this little task ourselves.

With little or no experience in household maintenance we set upon this task with gusto. Later, I sat back with a cup of coffee and contemplated how graphically this task had illustrated some important aspects of making good decisions as a Product Owner on a software team.

Learning new skills takes time

Although we did eventually get the cupboard door up and learnt a lot about wood filler, sanding and hinges along the way, it took us at least three times as long as it would have taken the maintenance guy.  Fortunately, we suspected as much going into the task and we had set aside most of an afternoon to get it done. However, I became frustrated that it was taking longer than I had secretly hoped, leading to a questionable suggestion on my part, aimed at getting the door up quicker.

As a Product Owner, it’s frustrating when your team tells you they need more time for a specific feature because the person (or persons) doing the work will be learning a new area of the software, or even a new programming language. It’s very easy to fall in the trap of publicly accepting that cross-skilling and pair programming are necessary, but privately hoping for faster delivery. This way, you set yourself up for disappointment, and your team for failure, because you may start measuring their progress not by what they told you, but by what you are hoping for. You may even be tempted to cut corners, as a result.

Cutting corners causes technical debt

At one point, we were having trouble getting the bottom two hinges to align properly with the door frame. My husband was convinced that we had to take the door off again completely and do it all over again, since he suspected that it would be easier doing it that way. I was frustrated with how long it was taking to get the door up and I suggested that we just leave it as is – at least the door was up. Of course, leaving it like that would mean that the door would just come off again that much sooner, causing us to have to do it all again anyway.

We took the door off, figured out what we did wrong the first time, and did it properly.

As an agile Product Owner in an iterative process, there is often a heavy focus on delivering features that are “good enough”.  You are supposed to focus on delivering real business value, not allowing unnecessary time to be spent on gold-plating. But that doesn’t mean that you should allow (or instruct!) your team to cut corners. Shoddy workmanship is not equal to “good enough” software. It’s technical debt that you will have to repay at some point.

This entry was posted in Agile Software Development and tagged , , , , . Bookmark the permalink.

2 Responses to Lessons from the Cupboard

  1. Jim Benson says:

    What I like most about this post is that it shows we’re all human. We make decisions based both on knowledge and on emotion. Sometimes emotion is our ally, sometimes it’s not.

    I suspect that even though you said, “arrrgh just leave the crooked door up” that it was not hard to talk you into calming down and doing a good job.

    I run into this all the time, I tell people that we need to work toward quality and often become frustrated when inanimate objects don’t bend to my will. I’m very forgiving of people, but things like doors – don’t get me started….

    • Indeed, I quickly realized that doing it over was the right call. One of the things I also really like about Personal Kanban in my life is that it confronts me with my own foibles. It’s not easy to hide when you’re procrastinating or when you’re doing “busywork” instead of valuable work.

      This applies particularly to work, but also to interpersonal interactions sometimes. Seeing our door-hanging exercise in a PO perspective made it much easier to admit that I was wrong. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s