How to fight lack of transparency in your Scum implementation
Better transparency is one of the key value proposition of Scrum and one of its pillar. Several parts of the framework are designed to help it and make sure to keep stakeholders aware of the progress. More often than not, this does not work as expected and Scrum is blamed for that. It is a perfect opportunity to open this series of articles around the Scrum hoaxes. In today’s article we will discuss the black box syndrome some organizations encounter while implementing Scrum, and cover the possible causes and solutions.
Some times ago, I had a discussion with a senior product analyst about how Scrum impacted its organization. Like some people complaining here and there, he was not happy at all with the methodology. Bottom line, the issue was that since the implementation of Scrum, the teams around him were completely black boxes. No transparency at all, especially regarding what the team will work on. A common issue indeed, that may come at very different stages of Scrum adoption. It is very sad because it is usually due to a bad way to Scrum. This situation, like all the others of this series of article, is not due to Scrum but to how it is implemented.
So how a team, after implementing Scrum, can be perceived as less transparent than what it was before?
Obviously, it comes from the fact that some aspects of Scrum are missed, but it is not so trivial to see what is wrong.
I will share below the most common category of mistakes I have encountered.
Case 1: No (or ghost) Product Owner
Yes, I have met teams where the role of PO was simply not filled. The Product Owner being in charge of the product backlog, the issue is obvious and immediate.
A very similar flavor is the Product Owner is appointed but too busy to take care of the backlog, or not trained to or convinced by Scrum. At best there are a bunch of badly written stories, at worst nothing at all and the Product Owner sends an email to the Scrum master here and there to ask for things.
Without a proper and up-to-date backlog, no visibility on the product, either inside or outside of the team. You can obviously forget any notion of transparency.
To get out of this situation, the organization needs just to take the subject seriously: the role of PO is critical to a working Scrum team. He should be knowledgeable, accountable, available and invested in the product. You should have the proper skills, including technical skills.
I would love to say that this is the least frequent case, but sadly it is much more common than you think.
Case 2: No (public) demo
The sprint review meeting is the opportunity for the Scrum team to demo the proposed product increment to itself and potentially key stakeholders. It is as well the opportunity for the PO to decide to release this increment or not.
The first possibility is for this meeting not to be held or to be badly run. Relating to the previous case, if the Procut Owner does not attend this meeting it will be extremely hard to discuss with stakeholders what has arrived and what should come next.
In the situation where the PO is there, but if no stakeholders attend to this demo meeting and if there is no other way for them to see the increment and provide feedback, it naturally results in poor transparency on the Scrum team output.
Our advice here would be to invite key stakeholders to the review meetings to provide them the best visibility.
In addition, especially if the point above is not doable in your particular setup, you should put in place the means for the feedback loop to be available. It depends heavily on what comes next to “Product Increment is shippable”, i.e. the path to users after the sprint.
A solution can be a webinar (for very large audience), a platform to demo your new version, a recorded demo sent to stakeholders or even some canary testing on your production environment. We will cover more on these possibilities with articles on release management but in any case you need to put in place a feedback loop.
Case 3: Private backlog
If with the situation of secret project put aside (military or equivalent), this is astonishingly frequent: the team has a backlog that no one can see outside of the team.
You cannot expect the stakeholders to participate if they cannot see what the product owner has in mind and how their feedback is taken into account.
The solution is obviously to make sure the backlog is available to your stakeholders. The clearer the backlog is the best, so the tool selected should have a good navigability and it should be obvious how to find your backlog.
Case 4: No roadmap
With case 1, 2 and 3 covered, you have a reasonably well written backlog and a two-way communication is established between the stakeholders and the team about newly built product increments. The next source of issue is trickier: what comes beyond the current sprint.
Most organizations and actors in the field of software edition (and engineering in general) are expecting a form of roadmap. Yes, it is usually not reliable and not adaptable. It is not meant to be a commitment on the few next months, but it is valuable to give some visibility on what you hope to accomplish.
Case 5: No readability on what the stakeholders want
A backlog gets denser and denser as long as you are getting closer to the next sprint items, as you will detail more and more the content of the stories. From an external point of view, it may be very hard to find out how a suggestion or request has turned into a list of stories.
A good way to do it is to differentiate the stakeholders’ requests from the stories themselves. You can use epics, but it can get complicated for different requests fulfilled by the same stories.
The best option is to distinguish the requests from the stories of the backlog and make sure each request is updated based on the status of the stories implementing it.
Find out how this works in request management of Stenusys Scrumboard.
Case 6: Private Sprint Board
When some critical stories are under implementation, stakeholders may be interested to see if everything goes ok. It is not that they can do a lot about it in most cases but that sure means they may not appreciate to wait until the sprint demo to get news from you.
To make sure the information is available at any time, without a need to compute reports manually, it is a good idea to have a sprint board fully open and easily accessible. The best option is to have your backlog browsable in your Scrum tool: it will allow the best transparency possible.
Closing up, transparency is one the key value in a business relationship. It is required to setup the viable working environment you need to work efficiently, based on trust between the team and its stakeholders.
If well applied, Scrum is a great enabler of transparency. By following the suggestions proposed in this article you should get one brick to put in place a healthy product engineering team. More to come...