Another reason that software projects suck

The dev team needs to see the client, preferably face-to-face but directly in any case. Communicating directly is hard enough. Going through the fake client to figure out what the real client wants is impossible.

Regular fans are surely aware of my “funny and accurate” (says Steve Belovich) paper on the eight reasons “Why Your Software Project Sucks.” I kept it to eight because you have to stop somewhere, and also because I have this nifty photo of myself with a “Magic 8-Ball” to go with it.

But today I’m re-encountering an issue not on my original list of eight. It’s the one where you can’t possibly fulfill expectations because the client is not your client.

So the other day…

I’m hearing from the client. He says “the clients” are getting kind of nervous about not seeing our running code on the QA server.

Yes, I said that right. The client–this one guy–is referring to “the clients” in third-person plural.

We’d had this discussion before. I’d asked the one guy, like three weeks ago maybe, who specifically is the client. Who is the decision-maker? Who is this for? And at the time he’d said yeah, it was just him.

Okay. Got it. We meet with you only, with talk with you only, we provide updates to you only.

Sure.

I know there are customers behind the customer. That’s fine. You don’t implement projects in a vacuum. They are done for reasons, and those reasons usually have to do with other people. But you still have to have a clear definition of who’s in and who’s not in.

Very briefly, and oversimplified a little, if someone thinks they need access to your QA server they are either part of your team or they are the client. If they are your client they need to be at your standups or represented at your standups. If they are not your client then the project is a black box to them.

It goes like this

One of the awesomest things about the Agile concept is transparency. We’re used to thinking of it in terms of the client seeing what’s going on via wall displays, virtual boards, listening at a Daily Scrum, and so on.

But transparency is inherently a two-way phenomenon! The dev team needs to see the client, preferably face-to-face but directly in any case. Communicating directly is hard enough. Going through the fake client to figure out what the real client wants is… impossible.

What’s beyond impossible? Whatever the word for that is, it applies to doing this all when the identity of the client is in flux depending on how anxious everyone is feeling.

See, when there’s transparency one way and not the other way, you don’t call it transparency. It’s like one of those windows they have on cop shows where the lieutenant watches the interrogation but all the suspect sees is a mirror.

My solution

Project owners, you simply have to pick a story. Either the project is yours and you take responsibility for everything behind you, or you have to¬† bring the actual client into the process. Having invisible clients isn’t playing fair, and it will not get you what you want.

Leave a Reply

Your email address will not be published. Required fields are marked *