Empiricism and Transparency
Empiricism and Transparency
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. This post focuses on transparency.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
"Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation."
The pillars of inspection and adaptation will be addressed in more depth in different blog posts on the daily Scrum, the review, and the retrospective. The focus in this post is on transparency. What entails transparency in a process and why is it so important?
The Scrum Guide states that “significant aspects of the process must be visible to those responsible for the outcome.” Two questions arise: what are these significant aspects and who are those responsible?
Well, the latter question is easiest to answer. This statement revolves around the Scrum team. Simply stated, by transparency, we do not mean velocity and burndown charts for the IT manager to support his or her planning, but the aspects that are relevant to the team in their process of delivering a valuable increment.
For empiricism to work, the team must be able to make informed decisions about their progress towards their sprint goal. To make an informed decision, one must understand the variables at play. The understanding of these variables is enhanced by transparency.
In my opinion, transparency should be encouraged and facilitated in a broad sense. As much relevant information as possible should be visible to the team. The Scrum master can facilitate this, but the team should feel responsible for making all of the information available. They can best decide what information is significant to their decision-making process.
So, what information could be relevant? Of course, the Definition of Done is one guideline. All tasks needed to deliver a done increment should be visible to the team. This means that the team must at all times have insight in their work in progress. The tasks at hand must be small enough to visually track progress and their status should be accurate (i.e., a task cannot stay in the same status for a day).
When additional tasks are discovered (the Sprint backlog evolves during a Sprint) they should directly be added to the Sprint. One should avoid scope creep at story level but also in tasks. If new insights emerge, one should create a new task, and finish the former task first. This improves focus and enhances transparency.
If for some reason progress is blocked, this should be visible. In other words, impediments should be visualized and their progress must be tracked. Needless to say, impediments should best be removed immediately, but this simply is not always possible. One can only see if the team is on track if the current status of the sprint depicts reality.
Transparency also means that one should not work on tasks that are not in the Sprint backlog. It is evident that work outside the Sprint should not be performed, but in practice this may sometimes be necessary. When one can help another team with little effort, this may in some cases be desirable even though the team did not commit to this work. If this work emerges, add it to the sprint so there is no hidden work.
One artifact that is often linked to transparency is the burndown chart. Although it might provide useful insights in progress during the sprint (if there are no points burned during a certain period, there must be something wrong), a burndown chart is not the most suitable tool for gaining these insights. These should emerge earlier in the process via the above-mentioned aspects. The Burndown does not depict any information on the state of the work in progress.
For my team, it works well to frequently look at our overall progress in a different manner using a helicopter view. Do not only talk about tasks and stories but also look at the big picture. How much of the work on each story is done? What big chunks of work do we still have left, do we see dependencies arise, or are there new insights that could hinder our progress later on?
To summarize, visualize all parts of the WIP you can, including blockers and overall progress. Make sure it depicts the actual status of the work. Then and only then one can make good, informed decisions based on what is known and avoid making assumptions. Progress will become more controllable, since if something unexpected happens, you will know the consequences much faster. With true transparency, the team will be more successful achieving its goals!
Opinions expressed by DZone contributors are their own.