Crystal clear — how increasing your transparency will super-charge your agile process
The first principle in the Scrum Guide is Transparency. Whilst it is easy to nod your head and agree — it’s obvious we should be transparent, isn’t it? — the Scrum Guide is silent on what this means in practice. How do we become more transparent, and why should we care about it?
Often people think they are protecting the team, but they are actually reducing transparency.
If the whole team don’t know what work is being undertaken and the current progress, it limits the ability to collaborate effectively and prioritise the work. This is one of the key cultural shifts of using Scrum. Here are some examples of things members of the Scrum team might say that limit transparency:
- “I won’t tell the team to protect them and let them concentrate.”
- “I will take this away and come back with an ordered backlog.”
- “Its unclear how much is left to do on this task, so I’ll wait to update until I know more.”
- “I cant estimate because I don’t have all the details yet about the ticket and don’t know the full estimate.”
All of these are trying to do right by the team. But critically, all restrict transparency. Here are some key actions that Scrum Masters should encourage to prevent the above comments and encourage transparency.
Everything the team works on is shown on the Kanban board
This applies particularly for new teams. There is a tendency to have the items on the Kanban board that apply to the product direction, and not all the other work the team has to do. A key principle is that everything should be on the board. This means team members understand what everyone else is working on. Over time, the team can focus on shedding tasks that are not contributing to the Product Goal and become more focussed. Secondly, building the muscle of new work equals a new story or task on the board is important, including bugs and issues that are found.
The Product Owner explains his prioritisation and can be challenged
The product Owner is accountable for prioritising the backlog by working with stakeholders. However, this shouldn’t give them an ivory tower from which they can simply dictate what needs to be done. The Product Owner should be able to explain why we are working on these items, and what the priority means. He should be open to challenges from the team too, if they offer new information that may impact his decision. This requires an open culture where challenge is treated as constructive and in no way personal.
Mandate live demonstrations in Sprint Reviews
Sprint Reviews are a critical part of the Scrum process. They make it transparent what the state of the increment currently is. But often, there is a tendency to say “we are almost there” or explain the current state. These are both examples of status updates. A quick way to resolve this is to mandate that everyone gives a live demo — they share their screen and live demo the work they have done. This quickly greatly improves the transparency of what has been done and helps stakeholders understand the work done.
Utilise checklists to better understand the status of stories
Checklists can make it quickly visible as to how a task is currently progressing towards a quality bar set by the team. The three main examples I have used for this is:
- Definition of Ready — use a checklist in the ticket to check progress towards the definition of ready. This makes it transparent what remains to be done for the ticket to be ready.
- Definition of Done — the checklist makes it transparent what needs to be done in order for the story to be completed. This helps both the developers, Scrum Master and Product Owner have a shared understanding of the current state.
- Deployment checklist — often there are a number of steps that need to be done in order to push to Production. A checklist makes it explicit what work needs to be done, and makes it clear to everyone the current status of deployment.
Enhancing transparency is an important function of the Scrum Master, and should be taken seriously. Take actionable steps to help the whole Scrum team better understand the work, decisions associated with prioritisation and its current progress.
