Do You Have Trust & Transparency in Your Scrum Team? If Not, You Don’t Have a Team

The Scrum framework was founded on empiricism and lean thinking and is sustained by 3 pillars: transparency, inspection, and adaptation. This should be in the mindset of every team member, but unfortunately, it is not that common. Teams give too much attention to the Scrum events and sometimes forget about what is behind them. All – yes, all Scrum events – exist to give the opportunity for inspection. Once you perform a proper inspection, you can adapt if you need. However, a good inspection can only be conducted when a team has transparency and trust. Without transparency and trust, everything might fall apart. Without transparency and trust, you will not be able to inspect – at least not properly – and without a good inspection, you can forget about adaptation. Transparency enables inspection, and inspection enables adaptation.

Low transparency can lead to lower value and higher risks. I’m talking about transparency in terms of work and process. Transparency in terms of the 3 artifacts which Scrum proposes: Product Backlog, Sprint Backlog, and Increment. A team needs to constantly inspect progress, artifacts, their way of working, and that is where the events play a key role. Scrum provides these 5 events – Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective – to help with the inspection. If you try to inspect without transparency, it won’t work. If you inspect but don’t adapt, then inspection becomes pointless. Scrum events are designed to provoke change. Once inspection is done and a need for adaptation is found, it must be done as soon as possible.

You start your Sprint with a Sprint Planning. At that time, you are inspecting the priority of the backlog (prioritized by the Product Owner), the team goal, and the plan for the Sprint that you just started. During the Sprint, the cadence event of Scrum, you have your Daily Scrum (yes, daily means every single day) where your team inspects the progress towards the Sprint Goal and decides if any adaptation to the plan is needed. Yes, adaptation to the plan in this case might mean changing the Sprint Backlog. Lots of people state that the Sprint Backlog cannot be changed, which is completely wrong. The Scrum Guide states that the “… Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.” At the end of your Sprint, you have the Sprint Review, where your team, together with stakeholders, inspects the increment and the work achieved by the Scrum Team, providing feedback. It is a good opportunity to also inspect the Product Backlog. The last opportunity for inspection – meaning the last event of the Sprint – is the Sprint Retrospective, where the Scrum Team inspects how the team worked during the Sprint, identifying improvement actions.

Every team member should keep these thoughts in mind when entering one of the 4 Scrum events, as these are made to give room for inspection and adaptation. And the team will only be able to inspect – plan, backlog, increment, work – by having transparency.

What is your team inspecting next?

One thing the Product Owner must ensure for the Sprint Planning is that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal (commitment of Product Backlog). This is the first opportunity to show transparency and perform inspection. During the planning, team members need to understand why the Sprint is valuable, what can be done, and how the chosen work will get done. A Product Owner, or even a Scrum Team, that fails to ensure this common and shared understanding about the value and which items bringing most to the product will result in a bad inspection. And remember that inspection enables adaptation. After a discussion with the Product Owner, developers select the items to include in the current Sprint, refining them during the process. This inspection is meant to increase understanding and confidence. But to ensure that, you need transparency. I have seen many team members failing to be transparent when an item was not clear, failing to ask the Product Owner, and thus being driven by other team members who were taking the lead. This will surely mess up your inspection, as transparency is casted off.

Some teams use the Daily Scrum as a status meeting. Doing so may help facilitate the presence of transparency, but inspection and adaptation end up agonizingly forgotten. The purpose of this event is, according to the guide itself, “to inspect progress toward the Sprint Goal and adapt the Sprint Backlog.” This is clear: inspect, then adapt if you need. “Responding to change over following a plan,” according to the Manifesto for Agile Software Development, is the appropriate course of action. Skipping Daily Scrums, hosting it a few times per week, not giving space for all developers to speak, and forgetting the Sprint Goal (if you have one) are some of the pitfalls that might kill the power of inspection. And without inspecting, you cannot adapt.

The Sprint Review is not just a demo. I’ve seen many teams consider the review to be a demo (calling it sometimes the “Sprint Demo”), as an opportunity to “sell” the product to stakeholders. That is a big mistake. When doing Scrum, you are not delivering value to your stakeholders, you are also delivering with your stakeholders. During this event, we inspect the increment to see what has been done by the team. Rather than a fancy or colorful presentation (that you will probably throw out the following day), focus on demonstrating the work done – the value delivered. This is what feeds the inspection. Do it transparently and adapt with your stakeholders, collect feedback – and don’t be afraid of asking for it directly – and look at the Product Backlog to align on what is coming next and adapt accordingly.

One of the biggest mistakes made during a Sprint Retrospective, even in teams that are skipping them, is to not perform the actions taken. Or worse: not taking actions at all. If your team does not act, then there is no adaptation. Inspection without adaptation is pointless.

Next time when you go to a Scrum event as a team member, keep in mind the benefits of being transparent, and don’t forget what you aim to inspect during that time. And, of course, what needs to be adapted.