Incomplete Transparency

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.

Hi Illya,

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

@Prabhu
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.

Cheers,
Ruud

How do we ensure that the increment is transparent; is it possible to make the increment visual in all cases?

I'm assuming you're already familiar with its meaning

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

So what exactly are you asking by "ensure that the increment is transparent"? And what do you mean by making it "visual"?

Why do you cope with it instead of fixing it?

=> @Johua: I think it is depend on the human behavior of team members, the tool and process can help but cannot fix or manage. Scrum Master have to cope with the openness everyday (learning, convincing, change) and create the safe environment of trust and facilitate for the transparency be opened.

SG: transparency doesn't occur overnight, but is a path.

@Ilia Pavlichenko in scrum guide it says ""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 am preparing for PSM 1  and I couldn't find this in the latest scrum guide. Can you help to clarify?