How does increased transparency reduce risk in software development projects?
By Nathan Donaldson in Agile on October 17, 2013
Why is lack of transparency a problem?
Lack of transparency leads to poor quality, which has a strong negative impact on organisation’s brands and revenue.
Customers delay sales, and you lose revenue because of poor quality Releasing poor quality software builds the expectation that initial releases will be buggy. If a release date slips several times, new and potential customers may assume there is a problem with quality and will be reluctant to buy when the software is finally released. Even a single sub-par release can sow the seeds of doubt. Once doubt creeps into the minds of existing customers, they may delay purchasing new releases, preferring to allow other early adopters to work through the problems, or worse, they may decide not to buy.
Identifying the Cost of Poor Quality, Seapine Software.
What is transparency?
Transparency, as used in science, engineering, business, the humanities and in a social context more generally, implies openness, communication, and accountability. Transparency is operating in such a way that it is easy for others to see what actions are performed.
Looking at software development in particular, transparency is about making obvious: the reasons we are doing the work, the way we are doing the work, the quality of the work and functionality of the work.
When we talk about transparency it is very easy to see it in only one dimension. Often we will focus on the dimension that is most relevant or pressing in our role. For example as a manager I may see transparency as knowing the status of the work. To a developer transparency may be about seeing the work in progress in a tool or on a task board. Increasing transparency in all aspects of the work we do delivers the highest benefit and reduces risk across the project.
Why is transparency important?
Transparency enables us to make good decisions. A simple example is the Scrum task-board. The board shows, to anyone who walks past, what’s being worked on this sprint, what’s complete, what’s in progress and what remains to be started.
This transparency enables the team to see, at a glance, whether they are on track to meet their sprint goal, have too much work in progress or are blocked on one or more stories.
The team can use this information to change the way they are working. If the team sees that too much work is in progress, they can decide to focus on the most important story until it is complete, before moving on to the next story.
Without transparency around the processes and the output the team is unable to make these decisions.
How does increased transparency reduce risk?
The sooner we know, the sooner we can respond to info from both the team and the market. Transparency enables us to react to changing circumstances quickly.
We cannot have high quality without high transparency. High quality is key to reducing risk. The cost of low quality in dollars, reputation and brand damage is very high.
Increased transparency leads to higher levels of trust and respect. Higher levels of trust lead to higher transparency. It is a virtuous circle. Increasing trust and transparency continue to reinforce each other in an upwards spiral.
Don’t shoot the messenger
As transparency increases in your organisation you will encounter and uncover issues that were not previously visible. It may appear that transparency has ’caused’ the problems and is therefore problematic in it’s own right.
A team’s productivity, for example, is more transparent when using Scrum. The productivity may not be any lower than before they used Scrum (usually it is higher), but it is very visible. The organisation around the team may conclude that the productivity has dropped, before productivity was not as visible and so the organisation assumed it was highly productive. The conclusion that the organisation draws is that Scrum causes a drop in productivity, rather than the more obvious Scrum is more transparent about productivity.
This post is an excerpt from the chapter on transparency in my book Mananging Project Risk with Agile.