Working with Proxy Customers

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

Derek Neighbors: I am Derek Neighbors.

Roy vandeWater: I am Roy vandeWater

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?

Increasing Customer Participation

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: 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: 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.

Proxy User Challenges

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.

Extreme Measures, Really Not That Extreme

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.

Lack Of Presence, Gets Poor Results

Drew: 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.

Follow The Money

Roy: 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.

Release Early, Release Often

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 the final product, right? That’s a clear thing. You are not just releasing the first release…

[crosstalk]

Derek: …Sure.

Alan: Well that’s…that was crappy, so let’s try again.

Derek: Absolutely. That should follow with whoever is releasing that product, should do that. I totally agree with that expectation is to be set. You can’t just release and say “This is awesome, it’s totally finished”! We had this exact example with Migo here, right? Where they released this product and they’re like “We’ve got this totally awesome finished product.” Everybody was all excited, go home and play with it and found out that it was still completely in development stage. Which most of the people here would have been completely fine with but it was presented as a finished product and that’s what totally killed it for everybody, I think.

I don’t want to divert too much here but I think that one of the things we see is that…A fundamental shift that has happened is, we don’t do box software anymore. The concept of version here is gone. The best example of this right now today is Facebook. I mean, Facebook is probably different every single time you log in to it. It’s got new functionalities shipping nearly every single day. When features come on, they’re not fully baked.

They’re not fully where they need to be but people’s expectations are, “It’s OK because it’s going to continue to improve or continue to change.” It’s not the world where you walked into egghead or best‑buy or 2999 and you got version 1.0 and it was going to be another year before you get the next version.

People are a lot more forgiving about a current product state than they ever have been in the past. When you’re talking about absent product owners or proxies, for me, the most telling part of a product owner or a customer is their commitment to the product.

It is a red flag in every way [inaudible 0:11:11] perform when I see a product owner, a proxy user or a proxy product owner put in place because there is not enough time. It’s really hard to feel important as a team if, “Hey, this is a company’s next big thing. This is what we are bent our future on. This is the most important thing,” but I can’t give you 20 minutes for a planning meeting for questions.

I can’t partake in a 20 minute demo to tell you what it is. To me, that is so indicative of how that stakeholder or that customer really cares about the features set. That’s why I have no problem doing extreme. If you can’t show up for the demo meeting on a regular basis and give feedback, we’re done.

At the end of the day, you are not going to want to write the check for this because you really don’t care about it. If I threaten that I am not going to do it and you really care about it, you will find a way to get to that meeting or to get your input in, because not getting it done is not an acceptable answer.

Drew: Yeah, I totally agree. I think a key concept here is the concept of iteration. If by 1 iteration, be it a week or 2 weeks, we should be able to know that sort of thing. Is the product owner or whoever was put in place to be the product owner, do they care about the product?

If it is in their hands and they can see it, they can improve it, “Yeah I like it,” or “No, it’s going the wrong direction.” If it takes you 3 months to figure out whether they really like it or not then your iteration’s probably aren’t real iterations.

Roy: This is something in recent… sorry I was co training a Scrum Master class last week. It’s always interesting in those classes when I did the portion that talked about the definition of done.

When you turn to the class and tell them you need to create the definition of done, let them expand and keep including stuff until every sprint you can give it to your end‑user.

You could see the fear on half the attendees’ audience faces because there is a whole new concept to them to actually deliver something and deliver it often.

Jade: I have been told by so many teams that that’s impossible.” How could we ever deliver anything in two weeks? That’s just insane. We could never do that.”

You don’t have to release the whole product but, can you deliver something of value in that short amount of time? If you can’t, you probably doing something wrong.

Derek: Are you questioning our two sprint release sprint?

Jade: Yeah, that’s right.

[laughter]

Derek: I think it goes back to what Derrick was saying about things like Facebook where you can have incremental value added week by week or even day by day and I think that’s the key.

If I can’t spend one week or two weeks, and work on something that has real value that people can really use, then what’s the point of working on that. When you do that and release it, then you’re releasing something real.

Jade: I do think we need to be careful with that generalization. That works really great for web software, but in an embedded world there are other constraints to pin on your market world, where that’s not just possible to deliver to the market that fast, but you should be able to have some sort of internal delivery system where you are delivering something that is of value and is of production quality for each sprint.

Roy: In the embedded world, I spent a lot of time there. The goal we always have is to be able to do sprint demos such that those few times that we actually had the VP or the CEO or somebody who doesn’t understand engineering, they could still see the demo and see value being produced from that demo even if it was just a prototype word, so that you try to pull all the way down to the end user and the non techie so that the business value is evident.

Derek: At least some feedback where they can see that value.

Roy: That’s as far as I’ve got with this question at the moment anyway. I don’t expect this podcast will solve those questions forever.

[laughter]

Roy: We will hear more of it over again.

Jade: Yeah, definitely.

[background music]

Jade: Well, thanks for joining us for this scrumcast and we will catch you next time.