SCRUM is a process framework that has been used since the early 90’s to manage complex product development. It’s not a process or a technique to develop a product, because in reality it actually is a framework in which several processes and techniques are employed. SCRUM makes the product management and development management efficiency visible, allowing improvements to be implemented.
Although simplistic and easy to use, it allows to deliver, in short periods of time, software modules that really work. This fact, along with the sense of control given by short daily meetings, encourage teams to immediately want to embrace this methodology, without knowing if they are really prepared for it.
It just isn't enough to teach the team how the methodology works, having a certified Scrum Master and respect the SCRUM choreography. It's fundamental that the team stays committed to three different factors: adaptation, verification and transparency.
(Ken Schwaber, Agile Software Development with Scrum)
Scrum enforces transparency inside and outside the team. Transparency is vital to the Scrum process, as it allows everyone to see and understand what is really happening in each sprint, achieving a bigger and better communication and trust on the team and in this methodology. With scrum there are no priorities within the sprint nor hidden work being done. By using the Product Backlog, the team can predict future tasks for the upcoming sprints. This shows that the team understands their course and goals.
At the Scrum Board, the team shows it's feedback for the actual sprints' planned tasks, allowing everyone to understand at a given moment the actual state of each task. There should exist some detail on this board, although it must remain as simple as possible, allowing it to be quick and easy to read.
The existence of a multidisciplinary team allows a great deal of information sharing and better understanding by each team members' capacities and constraints, pushing the team to learn how to better communicate. With anticipated feedback about each story and tasks, given by the team and the users, it's possible to identify and avoid constraints. This feedback can and should be given at any point of the development cycle.
At the sprint review, done in the final of each sprint, it's considered fundamental that each team member openly talks about all the positive and negative aspects of the current sprint, proposing also improvements that should be important to the team. The objective of this is to honestly face every difficulty/problem and get to a consensus as how these can be surpassed.
Although the transparency on the teams' day-by-day is important, some members may suspect and even lack motivation to embrace a process that has transparency as a fundamental pillar. One of the most usual reasons for this to happen comes from the (lack of) capacity of each member to admit its own mistakes. Errors are inevitable, and each team must be motivated to see this as a premise and as a base point in which everyone learns with the mistakes that occur, always backed up by the Scrum Master and the other team members.
In my opinion, if the team is afraid to admit their mistakes, the process will never be transparent. However, it's never too late to achieve the desired transparency, if the team leaders show comprehension with the occurred mistakes and react in a more adequate way when they occur. Transparency helps organizations to anticipate and eliminate undesired surprises and problems, and Scrum makes the teams' work visible and even allows it to be demonstrated at the end of each sprint. Short work cycles help to generate a pattern and make each sprint quite predictable over time. When new tasks are originated, from new necessities or planed requirements, we just need to add them to the Product Backlog with the adequate priority over the project.