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.