Again today, I take my writing prompt from GeePaw. I have a good purpose in mind. (Added: Dammit. I didn’t expect to end up here.)

The Warm-Up

Last night, Tuesday, at the variously-named Zoom Ensemble, Geek’s Night Out, Friday-night Coding session, GeePaw Hill tabled a topic for next time. And he called his shot on Twitter, shortly after that:

Before you lay on us your pronunciamento about user stories, please to explain where this concept of a univocal “customer” comes from. Cuz if it’s an opium pipe, you know, I feelya, I’m down with that, I done been there, but you oughta call it out for the rest of us, pre-rant.

Only Hill is likely to say “univocal”, which is much more erudite and efficient than “speaking with one voice”, and fits the sentence better to boot. If you read my reply and his … hell, let me just put them here:

Ron
i hear ya. Often the team is pushed in multiple ways by multiple “authorities”. and hasn’t the power to say no. What the PO/cust notion says is for someone to have the authority to make hard calls. Ideally you’d trust the team: that’s rare. Org assigns a person. What else works?
GeePaw
What else than this works suggests that this works. I have not found that to be the case.

I spoze, still working this all out, mind you, that we need a way to enable this person to navigate “target parallelism” realistically.

Many more much smaller steps is my swing at it.

And “target parallelism” might be possible, just now “three from column A, one from B, two from C”. But we can’t do this, teaching them, teaching up their org, without some serious fundamental change in what we teach or how we mentor.

So there’s the setup. Now let me explain what I’m about here. My intention is to set up some obstacles and guard rails for thinking about the question of “univocal”. As he alludes, GeePaw is finding his way to an idea. Knowing GeePaw, I’m sure it’ll be a good one when we get there.

And you know that few if any of us in the Ensemble will wait until someone gets their whole idea laid out before we start asking about it, pecking at it, pulling it apart. And GeePaw, well, he pretty much hates that game. I don’t know if it distracts him, or just ticks him off when what seems off point to him seems to be pounded on by another in the conversation, or what. But I am pretty sure he hates that kind of “discussion”.

So my plan here is to lay out some of the topical points that seem to me to impinge on his topic, and that seem to me to be useful in helping him find his way to his real points.

Well, that and I just want to write about this topic this morning. And I plan to do it in my standard style, which is to say some stuff and see where we wind up. Here goes:

Customer / PO Isn’t Great

We’re talking here about what XP called the “Customer” and what Scrum, dammit, calls the “Product Owner”. We’ll start right off by pointing out that this idea is not the best one in XP or Scrum, dammit.

Kent Beck once said that the notion of the Customer / Programmer distinction seemed to him to be a major flaw in XP, but that he didn’t see how to get rid of it.

Mary Poppendieck, wiser than any three of us, has long held that the Product Owner idea in Scrum, dammit, is inherently wrong. If I understand her, she holds that the whole team should be setting the priorities and deciding what to do.

I think that’s right, and far be it from me to say what Beck thinks, but I’d bet he’d agree with Mary that that’s ideal, even if we don’t see how to make it happen.

But It Addresses a Big Problem

In the experience of the old white guys who wrote the Manifesto, a big problem of the day was that development teams were put under conflicting demands and expected to somehow resolve them. They’d be given 5 Number One Priorities, and they’d receive 137 Requests every single day, and then they’d be told they failed because things didn’t happen as fast as some random power person thought, or didn’t meet some criterion that had never been mentioned.

So the Customer / PO idea is simple at its heart, and it goes like this:

Developers can develop anything. They need clear understanding of what to develop, and there should be a very small limit on what they work on at any given time.

The business has a valid need to get a decent return on the investment of the development time and money.

Therefore, designate a “business-side” person who they trust, with the power and responsibility to decide what will be done, in what order, to what standards–and to decide what will not be done.

This is a simple idea, and if you sat down with any of us, we wouldn’t disagree that there are many disparate goals that a development effort needs to meet, and that no one person can possibly balance those goals. Sometimes there is no viable balance, and usually the balance changes from moment to moment.

But it’s still a decent idea, to have a single “voice” that the team listens to, and to concentrate the responsibility of choosing what to do to that voice, and to leave choosing how to do it with the developers.

GeePaw says he’s never seen it work. I have seen it work quite a few times, initially on C3, and at a few other places I could name. I’ve also seen it not work. Generally it doesn’t work if the Customer / Product Owner doesn’t know the territory, or doesn’t really have the authority to decide.

However, even if it does “work”, it’s a horrendous load to place on a single individual, balancing all the needs of all the stakeholders. Imagine some poor Product Owner with real users clamoring for different new capabilities, the VP of Sales demanding an entirely new major suite of capabilities, the VP of Finance trying to focus development on things that can be capitalized, the developers needing to slow down to refactor because of the rush to ship before last Christmas, and on and on. It can be a horrible job.

A Dilemma, or Multilemma

So we have some serious conflicting needs here. The development will really proceed better if we work on very few things at a time, GeePaw’s “many more much smaller steps”. But this isn’t a solid solution either, because unless those smaller steps all head in a very few sensible directions, we still won’t get anything done. MMMSS works best when the steps are all trying to get to some larger goal.

And the world really does have conflicting goals, requiring some balance of effort and some livable amount of progress against all the important ones.

Worse yet, the organization as a whole surely needs some kind of consistent picture of what’s going on, showing what the balance is, and why it is what it is.

Let’s look at alternatives, if I can think of any.

Alternatives

At base, I think there’s only one viable alternative, which is to fix the Customer / Product Owner bug, and to rest responsibility in the team, not in an individual. That’s easy to say, but not easy to do.

One major obstacle is that many companies, I’d argue most, want to have an individual “in charge” of things. We haven’t cracked the problem of getting companies to become comfortable with the idea of a team operating without some kind of designated numero uno, leader, boss, honcho, big cheese, … and until we do, they’re not going to allow it, and we’re kind of trapped in the Customer / Product Owner space.

And if we can find a place where we can have a team in charge of their product, we need a much expanded notion of “Maker” on such a team. We need makers who make the external communications, makers who find out what customers want, makers who understand budgeting and capital, makers who do all the things teams need done. Why “makers”? Because, on the team, there are only Makers.

Of course a hybrid model is a real possibility. The teams could be embedded in a development organization, or a marketing-product organization. It could have consultation from Finance, who would come in, ask around, get information, set up proper operation, and so on.

A hybrid like that has its own concerns, because each outside agency, like Finance, has its own agenda, and will want to impose demands on the team, and there we are, back with the conflicting demands again.

Is There a Way Out?

I don’t see a simple answer. Neither “Designated Univocal Entity” nor “Team Decides All”, nor “Hybrid Organiztion” will really cut it.

I think it likely that, in general, there is no “solution”. I believe that at least sometimes the Customer / Product Owner idea is a good start, and I believe that ideally, Team Decides All is where we’d like to go.

But the universe is complex, and we’ll never be in balance. Instead, we have to … oh no … we have to … I can’t believe I have to say this …

We have to take many more much smaller steps, and after each one, pick a new step based on all the forces we can sense and understand.

Many more much smaller steps.

Dammit. I didn’t expect to end up here.