Incomplete transparency and practices for coping with it
Hi
A section on artifact transparency from the scrum guide caught my attention and has created a desire to understand it better.
There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.
I have a couple of questions and would appreciate your help
- What are the examples of incomplete transparency?
- Which appropriate practices is the Scrum Guide referring to?
Thanks
What are the examples of incomplete transparency?
Lack of input during retrospective, work left not done at the end of the sprint, teammembers staying silent during Daily Scrum, PO deciding for the team some PBI is refined enough to be deemed ready (if there is a DoR)... it can be a million things
Which appropriate practices is the Scrum Guide referring to?
In general, coaching techniques to surface the problem and help the team to address them, and a thorough understanding of Scrum and explaining the WHY behind the the things you do
What are the examples of incomplete transparency?
For instance, any artifact or item, which is visible, but not understandable can be deemed as demonstrating incomplete transparency. As an example, DoD, prepared by Dev Team, should be understandable to PO to consider if a backlog item is done. Scrum Guide mentions "everyone must understand what "Done" means."
Which appropriate practices is the Scrum Guide referring to?
As Scrum is a framework, it does not prescribe to any specific practice; and leave it to the Scrum Team to find an appropriate practice for a given context. Scrum Master just needs to ensure that there is complete transparency. And that practice for a given context is also to be demonstrating transparency, so the team can inspect if it has enhanced transparency.
Thank you Xander Ladage for answering it with such simplistic explanation
A section on artifact transparency from the scrum guide caught my attention and has created a desire to understand it better.
It's sometimes said that the best way to achieve transparency is to deliver increments that are genuinely finished and of release quality. Can you see why that perspective might be a useful one?