In theory it sounds great: “More transparency means better production and happier clients.” The reasoning, we argue, is that transparency builds trust. Trust makes for better vendor-client relationships, and in turn, more clients.
So why isn’t everyone always transparent, then? Simple: because people are bad communicators.
Do you remember developers before they were rich and cool? We called them ‘geeks’, ‘nerds’, ‘dweebs’, and ‘dorks’. The reason for this was that their interests in technology and figuring out how things work far outweighed their interest in social etiquette. They saw it as pointless, and this has had a lasting effect on many individuals who program: they’re either unwilling or unable to explain the processes that, to them, seem very logical and obvious.
The Temptation
Of course this isn’t a bad thing—it simply reaffirms the need for business analysts and project managers who know how to communicate with clients. But have you ever tried to translate tech-speak to a client? A lot of times it has…less than desirable results. Sometimes, greater transparency causes only more frustration for the client and we are tempted by the thought that it would have much been better had we simply delivered the product and limited the customer’s perspective. The client, the company, and the developers would all be satisfied.
The Reality
But really things don’t work out so nicely. And a fixed presentation at one point may lead into some tough questions later on.
Agile software development methodology puts the Product Owner in the metaphorical driver’s seat of the project. He calls the ultimate shots on the project because, well, he’s paying for it. It makes sense. The problem we incur, however, is that most product owners are non-technical people, and their understanding of development processes and the limitations of computer programming are almost slim-to-none.
While there is an element of truth to this, most clients are not completely oblivious to the challenges of producing a high-quality product within a given budget, and they’re fully capable of understanding the hiccups that happen along the way. Being transparent really isn’t so bad after all!
The Benefits
When the client is actively involved in the product-building process, they see in almost-real-time the development of any possible holes, bottlenecks, and problems that might incur with the way the software is being developed. Instead of having to wait for the end of a sprint to see the problem, they can immediately bring it to the attention of the project manager, and so a resolution process can begin.
Just as developers often have difficulty communicating ideas to non-technical people, clients don’t always understand the implications of the requests that they make. The client, for example may retain certain necessary bits of information that they deem unimportant or that, in their mind, will not affect the outcome of the product. But increased transparency and regular communication will bring these issues to light substantially sooner and help avoid redundant development. Talking things through helps trigger ideas about the way the entire software package fits together and prompts various parties to raise more questions: resulting in clarity.
Developers will benefit as well: complete transparency doesn’t simply mean “transparency to the customer.” Transparency also applies to code, so that at any given time, anyone involved in the project can see what the individual is working on. When all members of the team understand who’s working on what, they can offer their insight to help solve problems together and greatly increase the efficiency of development. An experienced developer may be able to solve a problem in a few minutes, whereas a junior developer may have been struggling with it for several days.
Managers benefit from transparency because of their role as the bi-directional channel of communication between developers and clients. They are a messenger to both parties, often bearing bad news…so they need as much information as possible. Managers bridge the technical and non-technical worlds in order to facilitate the best possible solutions for all stakeholders. The more the manager understands both sides, the better he can communicate needs and anticipate (and subsequently neutralize) potential bottlenecks while mitigating problems.
So if Everybody Benefits, Why is it Still so Tough?
Because we don’t like to do it all the way. Drawing back on the temptation described above, we want to be somewhat transparent, but we’re also tempted to try and hide certain information and smooth the process without letting the client worry about it (and ultimately complain about it).
In a similar vein, at the end of the day, clients, managers, and developers are all different stakeholders—and each one has their own interests. Sometimes those interests conflict (i.e. the client wants to save money, the vendor wants to make money), but transparency helps every party compromise.
Transparency Means Transparency
If we implement complete transparency in a project, then it puts the client in the driver’s seat and sets the vendor as the advisor. This is good for everyone: when the client has more control, then they are ready and aware to take total responsibility for the project—for good or for bad.
In the advisor role, the vendor is free to offer as many possible solutions as necessary and even their recommendations, but it is ultimately the decision of the client to take that advice. Understanding specific roles is an entirely different story, but one thing is for sure: the more everyone knows about the project, the better the final product will be.