The Scrum room: how to improve transparency within your team.

Scrum is a framework that many companies are increasingly incorporating more frequently in their work projects with the aim of improving team motivation, the relationship with the customer and product quality from the planning stages to the end. It is a good bet for companies that believe in agile methodologies and in the advantages they have on productivity.

One of the bases of Scrum is empiricism, which is based on three pillars: inspection, adaptation and transparency. Scrum uses these three pillars as a basis to function.

Inspection and adaptation always work in tandem in Scrum. There are many times when the team (or part of it) inspects part of the work and adapts it accordingly.

For example, during the Daily Scrum, the Development Team inspects the Sprint Backlog and adapts it the next day to reach the goal of Sprint.

Another example occurs during the Sprint Review, where the Scrum team inspects together with different stakeholders the state of the product that is being developed ahead of adapting the next Sprint.

Inspection and adaptation is something that many teams use and that works for them. Today we are going to talk about the third part of the equation: transparency.

This factor is necessary for the inspection to be made in due course, so that knowledge is shared and expectations can be managed. Transparency is a key part of the process and without it, we cannot benefit from the full set of advantages Scrum can offer us as a team.

To the one who questions: What should be transparent? The answer is: everything that is related to the result. No more no less. In this post we will see some ideas coming from a peer group who applies this transparency in a project for Mediaset.

This team working for Mediaset has an empty office they are using as a meeting place for different Scrum events. Since it is a place they have available daily, they use it to gather all the relevant information for the project.

The first thing we found on the wall was their own Team Manifest.

In this manifesto, they have shaped the main ideas about what must be made within that team. We see ideas like: "Analyse from the point of view of the user". These rules are constantly in motion as the team updates them according to their needs, so it is a highly recommended practice.

Having their own manifesto is also greatly helpful for new people joining the team, as it facilitates their understanding of the values that hover above all that ecosystem that has been generated.

The second part that we can appreciate is that it is Product Owner oriented.

This role also belongs to the team, but has other functions and responsibilities, and therefore has its own area. In this space, two important things were defined: how to write user stories and "Definition of Ready".

User stories are work items that the team should develop. The same approach has to be mutually agreed between Product Owner and Development Team. Sharing a common jargon and a defined communication mechanism will reduce incidents and misunderstandings, which will eventually lead to improving trust.

The "Definition of Ready" is a very good practice to apply in Agile. This definition includes everything that an "item" of work must meet to be able to begin developing. In the case of our peers, they need prototyping, verification by someone on the team and the entry requirements and use cases file.

Thus, if a task includes this, it may be included in the following work Sprint. The person seeking this "definition of ready" should be the Product Owner, because it suits him to know what must be given to the team in order not to reject an item.

The central area of the room is the Sprint Backlog, an artefact that belongs to the Development Team and is the means used by the development team to create a plan to meet the current Sprint. In this case, this team has opted for a physical version regarding online Tools.

In this way and with a quick eye glance, the team knows the status of the project.

[caption id="" align="aligncenter" width="804"]

Sprint Backlog[/caption]

For this Sprint Backlog the team generated several columns directed at self-review to ensure that the completed tasks have attained the desired quality.

This Sprint Backlog has received the addition of the Definition of Done, another essential concept that we must consider if we want our team to be of the highest quality.

In this picture, we see how it is necessary to go through Sonar and rely on a validation made by a partner, in order to consider that a task is completed. It is a good way to make sure that everything that is finished has quality and will not fail in the future.

Another one of the tools we have is the Retrospective Backlog. This backlog contains all those tasks and commitments the team has made in retrospectives and that they wish to keep on special monitoring. It is good that these tasks are present and that they are highlighted in some way since they are actions that will make the team improve and gain productivity.

Finally, they use the board room to remember specific things that should be considered. Moreover, they have painted the questions they must answer in Daily Scrum at the top to remember how to do it properly.

All these panels, messages, posters and rules are essential for teams. How many of us have kept these rules in mind, but we did not have them written down? This is a great example of transparency that requires our teams to question themselves if we are all on the same page.

In the case of discrepancy, we can always talk during a retrospective on how to improve. Transparency is something we must internalize in our teams, it will always generate confidence and will help to understand why certain things happen, why somethings work and other things do not. Trying to hide mistakes and hiding them will not make us any better.