Working with Proxy Users with Alan Dayley

Episode 41

January 04, 2012

16:17

TBD

tbd

The Agile Weekly Crew and Alan Dayley discuss working with proxy users.

Episode Notes

Jade Meskill, Derek Neighbors, Roy van de Water, Drew LeSueur are joined by Alan Dayley to discuss working with proxy users.

How can we encourage customers to participate more?

Do we really need customers to participate more?

Are there things we can do to mitigate lack of product ownership?

Transcript

Jade Meskill:  Hello and welcome to another episode of SCRUMcast. I am Jade Meskill

Derek Neighbors:  I am Derek Neighbors.

Roy van de Water:  I am Roy van de Water

Drew LeSueur I am Drew LeSueur.

Alan Dayley:  I am Alan Dayley.

Jade:  All right Alan, so you had an interesting question for us. Why don’t you go ahead and ask the group?

Alan:  Well, we continue to encounter the issue where companies and teams talk about how they are able to talk to the customer’s office. They would like, for example, the extremes from, the customer only shows up for a review or the customer proxy, if you will. Maybe the product owner doesn’t really know everything that the customer wants, all the way to, we haven’t seen our customer in six months.

What are some of the issues or ways that we can to help encourage customer to participate more. Do they really need to participate more? Are there things we can do to mitigate these sorts of things. That’s been something I’ve encountered just recently.

Derek LeSueur:  OK. When you say customer, do you mean end‑user of the product? Do you mean the person who’s paying for the product? What do you really mean by customer?

Alan Dayley:  In the, two cases I can think of at the moment. In one case is the sponsor; the customer that’s paying for it, but they’re contracting with someone to build a app for their customers. In the other case, it’s an end‑user where somebody is paying for a specific development to happen and they just disappear after the initial couple of rounds looking at a product backlog or something.

Derek:  In both cases there’s a proxy user of some kind?

Alan:  Yes.

Derek:  What is the team’s challenge with a proxy user? Is it that the proxy user just doesn’t have enough information, so, “Hey, how do you want this implemented? Do you want it in red and green in the proxy user’s?” The answer is, “I don’t know”? Is it a matter of the proxy user says, “Oh, green,” and then when you go do this print review, the actual customer says, “Why is this green? I clearly wanted this to be red” and then the team is frustrated that they…

Alan:  It’s more of the latter. There’s a story told to me recently of a project that went on for three months and when it was delivered to the absent person paying for it; the customer, it was considered a failure because just too many things were wrong. Yet the team was frustrated because all along they were asking for participation, and obviously didn’t have it from the right person.

I suggested things like, “Well, stop working,” all the extreme stuff. You bring up extremes to make people think and have conversations, but the extremes sometimes aren’t practical to implement.

Jade:  Did the team know that the person they were dealing with was the wrong person, or were they under the impression that this person had the proper authority and decision‑making power?

Alan:  I don’t know the answer to that question, in this specific case.

Derek:  I think sometimes the extreme thing is really not all that extreme. What I mean by that is, I’ve seen this a lot in third party development. It certainly can happen in enterprise development as well. If you don’t have the stakeholder or the customer, the person who’s actually paying for the work, really signing off on the work or being an active participant in the work, and you get to the end or at some milestone and virtually all of the work to date that is done has to be thrown out, which is more extreme?

Either not getting paid, if you’re a third party developer, for six weeks’ worth a work, which I don’t know about you, but most people would say, “That’s pretty extreme, to work for six weeks and not get paid,” or in an enterprise type of project that you do work for six weeks and it gets drawn out, and now you’ve lost six weeks worth a budget, which is the converse to doing that. Sometimes I think that’s not as extreme.

I would say, “Could you use your definition of ‘done’ to help mitigate some of this?” Could you start to say, “Maybe we don’t need the customer in every detail or available every day, every stand‑up, or every planning meeting, but could we get to a point that in order to have sign off it has to be signed off by the actual customer? In that way, we’re never getting more than a sprint’s worth of work done.”

What we’ve done in the past ‑‑ we had done some third party development work in the past. One of the things we’d do is a kind of a mini little contract. We say, “When we’re going to engage with you as a team, these are the things that we will do. We will have a planning meeting every sprint, we will have a daily scrum every sprint. We will review the budget as part of the sprint review. We’ll review progress, how we are recording the release planning every sprint.

We expect you to do these things. We expect you to be there for every planning meeting for clarification. You don’t have to be there in person, but you have to be available if we have a question, you are there to answer the phone if we need clarification. I think you can say if you’re not willing to live up to your half of the contract, we can’t live up to our half of the contract.

Drew LeSueur:  I think we’ve tried in the past when we were still doing that type of consulting work. We tried to use proxy product owners every once in a while where the actual person or head of the organization or whatever that was actually paying us to do the work wasn’t able to meet with us and would have a subordinate meet with us.

I think it’s…Pretty much in all cases it ended up rather poorly where we either had a problem where the person that got delegated to be our proxy product owner either didn’t know enough about the product to make his decisions, or every time we bring something up in the planning meeting, he’d say “Oh I don’t know the answer to that. I got to go back to the product owner” and we get a response a week later which for us is a whole sprint, or we’d have the other example that Derek gave, where they’d go ahead and make a decision and then we find out three weeks or four weeks down the road when the actual product owner gets a chance to look at it that none of it is the way that he intended.

Roy van de Water:  I think following the money is a important lesson to learn here. Who’s really signing the check and making sure that they’re involved in some way. Especially that there is some feedback mechanism for that person to be able to let you know that, if they have created a proxy or delegated some of that, but that person is actually making correct, informed decisions and if they’re not, there needs to be a retrospective or some time for reflection to help the real product owner understand that that person is telling the team to do the wrong things and that issue has to be has to be dealt with.

That’s not the teams fault. They don’t know. They are being told that this person fully represents me and is your product owner, listen to them, but if that person’s not doing the right thing, there needs to be some feedback mechanism between that proxy and the real product owner to address a lot of those concerns.

Derek:  Even when you have the real product owner being your product owner and you are not going through a proxy, I’ve been on multiple projects where the real product owner made bad decisions because they didn’t get the product out the door fast enough and into users hands.

They made all these assumptions about what the requirements were, based off what they thought users would like, whereas if they had released early, like within a month rather than six months, they may have saved themselves five months of development time realizing that the user had no interest in the product or had a significant amount of interest in one feature but none of the others, or didn’t care about certain defects or whatever the case was.

I think, even if you have the actual product owner at the development team, you should push the product owner to release his product as early as possible. I don’t know who said it but I really like to quote that “you should be embarrassed about your first release of whatever product that you are working on.”

Jade:  [laughs] How does that contrast with “you only have one chance to make a first impression”?

Derek:  That’s a good question. I don’t know. I think that in the past, that was probably more true than it is today. You are seeing with…I’ve seen multiple times now where there are products that are coming out, where they are almost offering data access to users. They get to use it for free or at a discounted rate.

You see that with Google, with Gmail when that first came out. You see it with games every once in a while too like, “Minecraft” is a really good example of this. Where users today and especially in my generation, are OK with having an incomplete product, they’d rather have an incomplete product for less or even for the same price but earlier on…

Alan:  You little kids.

Derek:  …than have a fully developed product that’s perfect.

Alan:  The expectation is being set, that you are an early access user. That this is not th