it's interesting what practices you (as Scrum Masters) use for coping with incomplete transparency of the artifacts - Product Backlog, Sprint Backlog, Increment. And what does it mean for you this quote from the Scrum Guide: "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 consider transparency to be the first step in any agile transformation. I usually set up a task or kanban board on the first day of an engagement. If there happens to be one already, I'll get the team to challenge how much is *really* in progress, how they know "done" work is done, where the impediments lie and what dependencies exist, and who determines the backlog and what the priorities are. I think it's important to do this before any attempts are made to change the client's process. The first action is just to throw a window over current practices, such that stakeholders have a shared view of their own reality.
So to address your point, as a Scrum Master I don't actually "cope" with incomplete transparency at all. Gaining an appropriate level of transparency is the most important and the most immediate challenge. Coaching stakeholders to value that transparency, and to handle the issues that are exposed, is the tricky part. Once you get that co-operation actual process improvements can begin.
Why do you cope with it instead of fixing it?
@Joshua I just quoted a Scrum Guide. It talks about "coping with incomplete transparency". I guess it's a question to Ken :)
@Ian Thumbs Up! This is just the same thing I do when approach a new team - visualizing, using Kanban/Scrum boards.
Personally I am a big fan of the concept called "total visualization". Big information radiators include Scrum boards, Impediments Board, Burndown/BurnUp Charts, Working Agreements, Team Values, Definition of Done etc.
It gives a big picture of what is going on, group memory and more engagement. There's no more place where to hide the problems.
Institutionalizing a framework is sometimes made easier by using tools. In my case I found that choosing the right set of continuous integration and reporting tools which scale well with team size and project size, training the team and promoting its use also helps in ensuring transparency
Nice, you're talking about transparency of Increment? What about Sprint Backlog and Product Backlog transparency? How do you handle it?
I understand 'coping' with incomplete transparency as something you have to do in the transition period.
Yes, you want to fix it as soon as possible, and making the three artifacts very visible is a good way, and still you will encounter that work will be done which is not in the Sprint Backlog, so more awareness and visualisation is needed, and during Sprint Planning a whole new top-priority PBI can pop-up, etc.
So everything is visual and transparent, but the world changes and then the visualisation is outdated. Making everyone aware of this and teaching them to update timely, is coping as well...
I guess that is what Ken & Jeff meant with the statement.