Transparency

Scrum isn’t a process that magically solves your problems and creates ‘hyper-productive’ teams. It isn’t even a ‘process’. It’s a framework that creates short feedback loops that dramatically increase transparency. This acts as a mirror showing the team how good they are at making a product. It also exposes problems in the team and organization. This visibility underpins empirical process control with inspect-adapt cycles that put the team, Product Owner, and organization in a continuous improvement loop.

Within the LeSS principle of Queueing Theory is an explanation of the Indirect Benefits of Reducing Batch Size and Cycle Time. Purposefully requiring a reduction in cycle time, batch sizes, and/or WIP levels to get to a shippable product also exposes hidden weaknesses. More transparency.

Without transparency, it’s hard to steer or adapt. With it, adaptive control and improvement is possible.

That’s the good news. The bad news is that reality sucks. This transparency is discomforting or even threatening, which makes adoption hard and even politically charged. Previously, mild or severe weaknesses amongst people, groups, processes, tools, environment, sites—and indeed the entire organizational design and management team—were not really clearly seen. With the introduction of LeSS, there is painful transparency.

And that’s one reason why single-team Scrum or Large-Scale Scrum is mutated into something much like the status quo, so that current weaknesses remain hidden or avoided. Or that Scrum or LeSS are derided and ejected, to be replaced with something safer to the status quo.

Ken Schwaber—the co-creator of Scrum—once summarized the “four obstacles to adopting Scrum”, which also points to the political implications of this painful transparency when Scrum or LeSS is introduced to an organization. The “four obstacles” are:

• The tyranny of the waterfall;
• The illusion of command and control;
• The belief in magic; and,
• The era of opacity.
  
  
  
  

Transparency is also strongly related to the Definition of Done. Formally defining the meaning of ‘done’ reduces variability and the likelihood of undone work and measuring progress unambiguously (‘done’ or ‘not done’) increases transparency.

Having an imperfect Definition of Done implies there is Undone Work in your system. This Undone Work also causes a lack of transparency. Risks are hidden in it. For example, if performance testing is left Undone then it delays the risk of a non-performing system until close to release—when it hurts most.