The VOC, but who is the customer?

A recent post encouraging proactive steps to gather the VOC leaves the issue of “who is the customer?” well alone, since a generic answer would be vague, it is heavily context sensitive. Many good ideas are presented here.

An intriguing point made here is that, these are solutions to a situation “…particularly where there is little time to do any early user research”. You must consider what is underlying such a train of thought carefully.   I hear this sentiment sometimes and it is almost surely leading to building of the wrong product! So lot of activity will ensue, but progress in terms of generating ROI may is certainly not ensured! In other words it is a case of leap before you look. This is not to say what’s written in the above mentioned post is wrong, or that it is recommending ignoring user research. It just is trying to work around a poor decision.

As usual since my blog is about Scrum,  here I’ll try to relate this situation with the product owner’s role. To cut a long story short, it’s the PO’s responsibility to bring the VOC into the project. Identifying and engaging with customer(s) or potential customers and the difficult balancing act that may be needed is in the PO’s court. Again it is difficult to provide general advice that is practical but it certainly helps to make as much activity around this as visible as possible. The transparency of such interactions will mean a very significant reduction in dysfunctional behaviour. So as far as the teams are concerned the PO is the customer, albeit,  one who follows the rules of Scrum.

Advertisement

Sprint Review undone: Part-II

Please see previous post for the context.

Lack of prioritization (within Sprint).

The overall result (certainly from a PO view point) is nothing delivered. Many teams see this in a very different way. This reminds me of a story: Mike was looking for his shoes,  and his servant who was responsible for taking care of them was trying to find them. All the while Mike’s irritation was increasing, after some time  the servant said in a voice where consolation and triumph were nicely blended “Well here’s one shoe!”. To which Mike replied “What’s the good of one shoe, you duffer!”.

Well, what of the poor PO. What did (s)he get for the patience? Nothing!

The team has worked and actually done(on the average) about 80% of each item!

This statement demonstrates the inherent weakness of the traditional means of assessing s/w development progress.  In other words percentage done. In the Scrum world we should strive to get a story/item ‘done‘ unambiguously in accordance with a strong DoD.  But I digress somewhat….

So the vital point is that: it is better to complete 80% of the items 100% (ie ‘done‘), than do 100% of the item 80% (ie, none are done). This is possible if the priority of items/stories chosen for a sprint is   considered and acted upon. So the higher priority stories must be taken up first, and all efforts must be made to complete these, before focusing on the completion of the lower priority items. This consciously applied pretty much ensures that the PO gets at least a couple of items. Moreover they are very possibly the highest priority items! So the PO can potentially derive value out of them sooner. The SRM cannot be viewed as a disaster, an important benefit.