An extended entertaining tete a tete

I had the pleasure of meeting Jeff McKenna last weekend. I took him around the city a little bit and had lunch with him as we chatted about various things, with discussions about Scrum taking up about half of the time. He was very engaging. He started programming in the sixties as a young teenager and talked about a seven pass compiler! Blimey! Glad I didn’t have to go through that wringer. Must have been fun in someways, but surely not pure joy when an error was thrown up on the sixth pass. He was also among the vanguard of the Smalltalk community. That is why meeting him was also a privilege. Such a spectrum of experience! He has I’m sure a store of stories to narrate and observations to make, only a small portion I could listen to.

In any case, one of the points he made really well was how you can always break a seemingly big story (feature) into much smaller parts. Many people who come from a traditional background seem to struggle with the idea of taking a functionality from description to implementation in just one sprint.  They think “well, our application is complex (glossing over the fact that complex and complicated are different) and we can’t implement anything meaningful in a two week sprint”. Indulging in some levity he makes the point thus “you can break it down to a few keystrokes!” Touche! But the point is serious. You can take it from people who have seen a really wide range of computer software applications, many times more that the average Mac, that one can always, always break functionality down to a couple of days of work. Surely within a development environment this is possible. There may be other organisational barriers that mean that the implementation cannot be taken into pre-production (or whatever) within a two week timebox, but the point of Scrum is to remove as many of these barriers as possible.

More on this later .

Advertisement

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.