Focus on Transparency
Transparency demonstrates openness and honesty. It shows that we are continually growing and open to feedback. A lack of transparency breeds mistrust and suspicion and appears unassertive. A reluctance to be transparent suggests the presence of fear.
However, not everyone needs to know everything all of the time. Let’s look at how to get the balance right.
In A Nutshell
Transparency can take two forms: transparency of the process we are adopting and transparency of the progress we are making.
Transparency of process is being open about the steps that will be taken to achieve something. In agile terms, that’s being obvious and visual with our roadmap, our backlog, our user stories, our planning (and assumptions) and items on the board.
Transparency in terms of progress is being obvious and visual with what’s on track, blocked or challenging.
Not all stakeholders need the same level of transparency in these areas. For example, some stakeholders might be much more interested in the progress you are making than the process you are following. Others will be more keen to know that you are managing to follow a particular process. The key is being able to be transparent with both and then discuss with your stakeholders what they need to know and how this can be best demonstrated.
Adoption of disciplines such as backlog refinement, sprint planning, and stand ups all play a part in supporting transparency. Our rigorous application to these disciplines is also essential. For example, being open when something is blocked in the daily standups allows us to tackle the issue. Hiding a blockage means we are gambling with people’s trust. In stakeholder reviews, being transparent about progress and what is working and not working for the product is key to building productive relationships with our stakeholders. In retrospectives, we need to find ways of having transparent conversations focused on the continuous improvement of the processes we are using and the progress we are making.
Practices
Blameless Post-Mortems are adopted as part Google’s Site Reliability Engineering framework. The concept has existed for sometime as part of traditional Service Operations. Its use within SRE shows its adoption in "DevOps” too. In this context, post-mortems are used to analyse the causes of operational failures and to decide how to improve the situation.
The Sprint Retrospective is a Scrum event. Its purpose is to allow the team to inspect and adapt its way of working, the functioning of the team, the working context and all other factors which may impact the team’s ability to deliver its goals. Some factors the team have direct control over, other factors will require external influence to change.
Practices
Visualise the process
Visualising work is a practice that reflects the agile values of openness and transparency. But what are the pitfalls we can fall into if we attach too much importance to the visualisation?