Wednesday, April 20, 2016

The stories you need to tell to product owners

"I could add this new reporting feature in less than a week", says the developer. "But that would not include the cleaning up and changing of components we should do in the same area", he continues. "We probably should just say the feature takes a month, because we have to be able to change the components too", he concludes.

Ever heard this monolog? The idea that you need to come up with a different story for your product owner, because they understand only features and not the technical maintenance work. The idea that all the technical maintenance work should be baked into the work, even if it transforms the scope of the work?

We ended up reframing this discussion. Let's be nice to the product owners, and enable them the fact that the feature is in the production sooner. It gets real feedback sooner, and it starts paying itself back sooner. And let's trust that it is ok to do the needed cleanup after, without baking it in.

Sometimes, the feature-orientation and control of the product owners causes development teams some peculiar behaviors. So this post is a start of my new thing to focus on: what could we do so that the relationship of the perspectives wouldn't be based on rules (who gets to decide what) but on trust and collaboration.