Product Owner increasing software quality

A week or two ago I got the feeling of hearing product owner complaining about software quality and developers talking more and more about fixing bugs and telling the product owner in the sprint review there “are still small things to do, to finally be done”. To be sure if my feeling was right, I asked the product owner for their opinion regarding the quality of the delivered software. I didn’t have to wait very long to receive answers to my question every single one telling me the same in different wording. In short “Yes quality sucks!”

Everyone dealing with Scrum or Agile Methods stumbles sooner or later over Extreme Programming practices like pair programming, code-review, continuous integration, unit- and acceptance tests, refactoring and test-driven development(short TDD) to name the best known. There are some more like behavior-driven development(BDD) for example and all practices mentioned are intended to help developers write better code.

Having problems with quality we take the standard tools into account and some might think it will be the last word of wisdom on that subject. Isn’t the developer always the problem? I thought about it a while and identified the product owner as someone able to help with quality. Of course it’s nothing new and we all know the product owner is a very important role in the scrum process. Nevertheless not much is written about how the product owner is able to pull the strings on the team beside a good vision and good user stories.

A lack of commitment by the team might be caused by the Product Owner, because he makes it to easy for the team in the review. Sentences like “There is one thing to do, but it won’t take longer than an hour.” are okay, but not when they are coming every review you have. The Product Owner should be very cautious about saying okay to everything, which has an one hour of work left. The team might get the feeling it is nothing bad to not be done and will use that fact to get more and more sloppy. No wonder, no one cares. Something else are frequent disturbances by the Product Owner. Yes it’s okay to have questions, but it’s not okay to stop the team members from concentrating on their commitment. There is time to talk about other things or, if not there should be time and space made available to do so.

The frequent disturbances are something the Product Owner can avoid by reminding himself of the effects when he gets disturbed in his work and by agreeing with the team on a time and space, where questions can be discussed. Maybe after the daily scrum or in the Estimation Meeting. Always ask yourself as a Product Owner “Is it really urgent or can it wait till the next daily?”.

What about the the first problem? How can the Product Owner can help the team to take their commitment seriously? First: Learn to say no!

There is something left to do? It takes five minutes? That means the story isn’t done? Yes? Story declined!

Why so harsh you ask? Because it is there responsibility and they are trying to forward it to you! They are responsible for delivering the stories and at the point you are accepting the stories it is your responsibility and as the Product Owner that means to take responsibility in front of the customer. The Product Owner is in the misery of standing in the front line taking all the hits whenever something goes wrong, that’s why he often says yes to a story just to avoid any trouble, because of not delivering.
I don’t know, but maybe it’s easier to tell the customer there is a bug, because every software has bugs(sigh!) or it’s almost done but there is something I can show you. Please don’t start doing anything like that and if you do stop it now! Be honest to your customer and even more important to yourself.

To prevent any room for discussion following the first rule it is very important to have good acceptance criteria. The place to get them is the Sprint Planning I or when writing the stories. When you discuss the stories find a compromise both can live with and very important write the acceptance criteria down and have them handy in the review. There are not helpful, when nobody knows them after two weeks.
The third advise is a very mighty one. Have your customers in the review. Put the pressure on the team and let them present the stories directly to the customer. Could there be something else to encourage the team? I don’t think so. How would you as a customer react, when you must hear there is something left to do, but you were told the they are doing Scrum and delivers potentially shippable increments of your product and now what? I wouldn’t be amused.

“Could there [be] something else to “,”when you must [hear] the[re] is something left to do”,”told the[y] [are] do[ing] Scrum”

One thought on “Product Owner increasing software quality”

  1. Hey Wolfgang,

    nice article. I think it brilliantly reflects the “stop the line” approach of lean-thinking. Letting the team go on with “only five minutes of rework” every sprint, undermines their commitment and leads to worse quality software every sprint.

    Thanks for sharing your insights.

Leave a Reply

Your email address will not be published. Required fields are marked *