How transparent is Scrum?

The Scrum Guide states that transparency is one of the three legs underpinning Scrum, with inspection and adaption being the other two. Since adaption depends on inspection and inspection depends on transparency, one could argue that transparency is the foundation of Scrum. So I came to ask myself: How transparent is Scrum?

Why is transparency so important?

Because

• it makes inspection possible, which is needed for adaption
• it enables visibility, to observe and understand what is happening
• it leads to more communication
• it establishes trust (in the process, as well as among team members)

This is why I think transparency is at the core of every good development process.

How does Scrum create transparency?

• A visual (physical) task board is a great tool to raise the team’s visibility of the status of the current Sprint. For me the instant status report for manager type people is a mere side effect. Much more important is the constant feedback for the team — to be aware of the progress within the Sprint. Only with this knowledge can the team be truly self-organizing. This is why I am usually against all these software tools that try to replace a physical task board. Yes, there is a slight overhead to produce index cards and print out the burndown chart, but in my opinion it is minor in comparison to the raised level of transparency. Advocates of Kanban say that the typical Scrum task board with its columns for Backlog, In Progress and Done is not transparent enough. The column In Progress is a black box, hiding states like Analysis or Development. What is the right granularity for your team depends on your context, like the complexity of your development process, team size and others. My advice is to try keeping it as simple as possible without sacrificing transparency.
• Early feedback is essential to make sure you are doing the right thing and that you are doing it right. It enables the team to discover and correct any errors and misconceptions as soon as possible. Feedback cycles can be applied at every level of development: pair programming, unit tests, acceptance tests, Daily Scrums, Sprints and releases. The time frames of these cycles range from seconds to months and the feedback is coming from different sources: your colleagues, automated tests, the Product Owner and most importantly the users of your product.
• Future work seems to be predictable. This is achieved by the Product Backlog, which can be examined by anyone anytime. This creates a sense of predictability during the project. Even though most team members barely ever look at it, its existence creates the illusion of anticipation of where the project is heading.
• Cross-functional teams work together on a common task. In an ideal (software development) world there is no them only an us. More often than not there is a bit of rivalry and tension when developers, testers and DBAs are in separate teams. This is because they don’t understand each others pain points, caused by a lack of communication and transparency between teams. In big organizations they might not even sit in the same office or know each other personally. People tend to be so much more understanding and forgiving when they communicate face to face rather than via email. By putting all needed specialists within the same team, Scrum enables communication between them and makes their needs transparent to each other.

Nowhere left to hide

Even though transparency is so important and brings the above described advantages your team might be reluctant about working in a glass house process. To happily do so requires the team to be comfortable with admitting mistakes. Mistakes are inevitable and they are not necessarily a bad thing either. Making mistakes is quite possibly the best learning technique that is out there, as long as you don’t forget about the learning part.

Are you ready for the truth?

This can of course only be achieved if the people leaders of the team have the above understanding about mistakes and react appropriately on them. If your team is scared to admit mistakes, they won’t. They also won’t adopt a transparent process. So be aware that the truth might not look as nice as the filtered reports you are used to. It’s kind of a red pill — blue pill thing.

What did I miss?

• What other reasons are there why transparency is important?
• What other things make Scrum transparent?
• What makes Scrum less transparent?
• What are other processes using to create transparency?

Image by *SΛM via Flickr