Scrum as a methodology is very transparent, everything is done in open sunlight where everyone can view. Following the spirit of scrum, everything is open for all stake holders to watch.

• The requirements must be detailed before the sprint planning, the team can reject a product backlog item that is not complete.
• The developers have to give an official time estimate on each work item.
• The sprint burndown chart that shows the progress of the current sprint should be on the wall, next to the developers’ work space.
• The daily standup should be open to any stake holder that wants to join and listen.
• The result of the sprint is shown in public, by the developers themselves.

The high degree of transparency effectively means that nobody in a Scrum project can hide. Successes are shown, but also failures. I think that it is good with the transparency. It ensures that problems are found and handled early.

Product Owner on Display

The product owner is in charge of the product backlog. The product backlog is the foundation of the sprint planning meeting. If the product owner hasn’t done the preparations right, it is glaringly obvious at the sprint planning meeting when the developers start asking questions about the tasks at hand. In the consultancy business where I work, one or more representatives for the customer take the role of product owner.

The customer representatives often try to push the team to keep a tight dead line for the release. Unfortunately the dead line date is sometimes just about the only thing that is clear to the customer. The objectives of the projects, user stories and detailed requirements can be quite vague. Guess if it is possible to develop anything at all if the customer can’t tell what should be done?

This is where the transparency of scrum can help identify the problem. Without scrum, low quality requirements results in a mess in the development phase. With scrum, the product owner has to clearly show what should be done before the sprint, otherwise that particular task is postponed to the next sprint. There is no “almost finished detailing requirements” accepted. Either the product backlog item is properly described at the sprint planning meeting or it isn’t. If it isn’t it can’t be included in the sprint.

This is one of the reasons that I, as a developer, love scrum. It gives the developers the possibility to reject unclear requirements. Without that possibility the unclear requirements are used for development anyway and when the useless result is presented the developers are blamed.

Developers’ Time Estimation on Display

The worst question for most software developers is to be required to Estimating Times. When being new to Scrum that is probably the most scary part; to have to officially estimate time.

There is one highly mitigating factor though for time estimation in scrum projects. The developers that will do the work are the ones estimating the time. There is no manager with an unrealistic schedule pushing an estimate onto the team. The team has the freedom to make an estimation they believe in. With freedom follows responsibility. The team is held responsible for their estimates.

Developers’ Progress on Display

During the sprint, the progress is tracked by a sprint burndown chart. There are also daily standup meetings where each developer describes what was done yesterday, what is today’s agenda and if there are any impediments. The visible burndown makes it impossible to hide lost momentum. It is immediately visible to anyone watching.

That’s great, because one of the worst and also most common pitfalls for projects is when people start sliding on the truth in progress reports to make it look like the plan is followed. When the lies are revealed it is often to late to get back to the plan. With scrum, any delay is immediately visible and actions can be taken.

Developers’ Results on Display

At the end of the sprint, the developers get to show what they have accomplished. In person. In front of the customer. In my experience this is one of the most important parts of scrum. It establishes a relation and understanding between the developers and the customer. As humans, we tend to only make an extra effort if it is for someone we know. With a direct relation to the customer, the developers make that extra effort. Believe me, that extra effort can make the whole difference between a failed and greatly successful project.

Nowhere to Hide

Scrum is not for those who want to keep what they do to themselves. To the contrary, many of the habits of scrum aim to increase transparency. Thanks to the transparency everyone involved knows what’s happening. When everyone knows, everyone can help out if there is a problem in any part of the project.