Why documentation is not enough to reach transparency in Scrum
The three pillars of Scrum are transparency, inspection, and adaption. However, using documentation as the main way of achieving transparency is perhaps not as good an idea as it may seem. In this article, find out some of the reasons why documentation may still be propping up barriers between different departments and how to break down silos.
Transparency is one of the three Scrum pillars, alongside Inspection and Adaption. The motivation behind the transparency principle is to show the current status of a project – no matter how well or badly it’s going – so that any necessary adjustments can be made in time. In the Scrum Guide, Ken Schwaber and Jeff Sutherland present transparency as the following:
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
Ken Schwaber and Jeff Sutherland
Scrum events, like Sprints and Dailys, play a crucial role in transparency, especially within the group working directly on the concerned project. But outside this group, meetings are more irregular and sometimes much further away from the core activity. Other groups in the company, for instance customer service or sales, still need to know the project’s status or restrictions to plan their own initiatives accordingly.
Using documentation as the main way of transporting transparency to these people is not a good idea. It tends to have the dangerous consequence of affecting the approach to transparency within the project team.
Nevertheless, at first glance documenting the details of a project, on an internal online platform accessible to everyone, for instance, seems to bring the needed transparency. The information given is opened to any department or team at any time. But this is not transparency.
SEE ALSO: The four myths of shift left testing
Transparency is risky and therefore needs a deep trust climate. That’s why Ken Schwaber and Jeff Sutherland evoke “critical transparency”. Indeed, creating a transparent mindset means questioning, inspecting and, to a certain extent, challenging to make sure that all meaningful aspects have been clarified so far.
This is an active and interactive approach that leads to opening up on possible issues. However, documentation is built on one-way thinking, even when online platforms allow us to ask questions. It works almost as a knowledge waterfall. Someone has information they share with someone else who is looking for this knowledge. From this point of view documentation is not the most appropriate path to build transparency.
Furthermore, because of its openness towards issues, transparency is meant to take action in order to adapt projects, depending on what’s found. But documenting is done to delimit a static and comprehensive situation. That’s why documentation may even paralyze people or teams. It often overwhelms employees with information of unclear relevance.
Worse, it may lead to cases where detailed documentation hides the really problematic aspects. In reality, even when people are documenting a project in good faith, real-time documentation remains a challenge. The risk is clear: producing a dangerous amount of outdated information that is used to implement sub-projects. So even when documentation leads to actions, you need to have rules and controls to be sure that the shared knowledge is useful and not counterproductive.
An additional issue with documentation is when you write information down, you usually don’t see who will read the information. So you document what you judge is important. But what is essential for a product owner – technical dependencies, for example – might not be relevant for someone who works in customer service. They have a completely different focus, and consequently other needs.
Transparency is the path, not the goal
We naturally tend to document for ourselves, using documentation as a reminder tool, rather than for the others whose demand for information is high but seems also vague. We don’t always know how other departments work. Documentation gives the illusion that it breaks down structural silos, but it doesn’t replace a common company culture. Transparency may be an essential pillar with the condition that its deep meaning is shared and understood by everyone.
These problematic situations in which documentation is confused with transparency usually happen when transparency becomes the goal, and not the path (toward efficiency). Several contexts influence this switch. The company grows and proper documentation seems effective to inform every department about what is going on. Silos between departments are big, each one has its own culture. Some teams follow the Scrum way, whereas others don’t know what it is.
Independently from why documentation sometimes reaches more priority than transparency itself, this sort of deviance has to be limited. To do so , it is crucial that the company encourages leading a deep reflection on transparency.
Transparency as a project
Why is transparency important, what is the final goal of transparency, and how do we define and implement it? Answering these questions is in itself a project.
That’s why, as Dave West, CEO at Scrum.org, recommends:
You need to treat transparency like everything else and measure its success and change when you learn that things are not working. (…) It is important to be agile in your transparency approach.
In this process, views between teams and departments must cross. What is useful transparency for a project team is probably useless for employees directly in contact with end-users. Rethinking transparency helps reconsider the information workflows, but also the role of each team or department in relation to the other. In a working environment where virtual teams become common, the results may be particularly insightful and productive.