The Tao of Scrum – Transparency

Based on empirical process control, the three pillars of Scrum are transparency, inspection, and adaptation. The nature of software development is complex and hard to predict, especially when it comes to the inputs and timelines(estimates and release dates). However, the outputs(Features/Stories/Product Backlog Items) are well defined.

One way of thinking about an empirical process would to think about a heater trying to maintain a desirable temperature of a room. It’s hard for a heater to determine exactly how much heat or exactly how long to generate heat to hit a specific temperature. So, instead, when needed, the heater just makes sure that it is injecting air that is warmer than the room temperature, and it simply keeps inputting that heated air until it senses that the current temperature is the desired temperature. At this point, it turns off for a while, until that temperature needs raising again. The key to the whole process is that the heater knows exactly what the current and desired temperatures are, and it keeps inspecting and adapting (turn heat on, turn heat off) its inputs until it reaches the desired temperature. The reason the heater is able to operate in this manner is that it has a transparent view into the current temperature. If you remove that transparent view, the heater does not know how to adjust itself to meet the desired temperature. In fact, that heater would probably never be able to keep a room hovering near the desired temperature.

So, in the same way the heater needs a transparent view into the current and desired room temperatures, the different Scrum roles and stakeholders need a transparent view into the software development process. Said another way, transparency allows the Scrum Team and its stakeholders to inspect and adapt the software that is delivered by the Scrum Team. This cyclical process is commonly referred to as a “feedback loop.”

Scrum bakes in numerous feedback loops. Let’s modify that just a bit. Let’s say that Scrum bakes in numerous “collaboration loops.” Each Scrum collaboration loop has a primary audience that is responsible for optimizing the given process. For instance, the Sprint Review’s primary audience is the external stakeholders. The external stakeholders give feedback and collaborate on the new software so that the Scrum Team may “tweak” or “improve” their ability to deliver Product Backlog Items. Another example is the Sprint Backlog and Sprint Burndown, whose primary audience is the development team. The development team members give feedback and collaborate with each other to help optimize work efficiency. There are several other “collaboration loops” in Scrum as well.

Bringing it back home a bit, the best transparency leads to the best collaboration loops. Investigating a bit further, we realize that the best transparency often requires some minimal data collection. Think of a football team. They’re so focused on playing the game to the best of their abilities that it’s often hard for them to remember everything they did on the field so that they can improve. A simple piece of data collection, a video recording of the game, increases transparency exponentially, and allows the team to learn from their experiences and improve. In Scrum, maximizing transparency often involves some simple data collection. So long as that data collection and presentation is being used according to the Scrum Guide, the Scrum Team and those new to Scrum should not fear it.

In conclusion, transparency is an absolutely essential pillar of Scrum, and that pillar works hand in hand with the other two pillars of Scrum, inspection and adaptation.


2 Responses

  1. Nice post Charles. I see teams get themselves in trouble time and time again because they aren’t completely transparent. Most of these teams do a fair job of estimating going into the iteration, but they fail to account for slippage. If everything followed their estimations, they be fine. But then tasks take longer than estimated, and additional work – in the forms of scope creep and urgent maintenance – are injected into the iteration. The scrum team doesn’t properly account for the underestimated work and the scope creep. The PO wonders why the team keeps failing to meet their commitments. The team often works extra hours to meet those commitments. If only the team accounted properly, then inspection would reveal what was going on and the team could adapt without getting business pressure to work harder. It seems like nearly every new Scrum team has to learn this lesson.

    • I agree. The key, in my mind, to identifying most of the intra Sprint troubles you describe, is to analyze the Sprint Burndown with an “ideal burndown” line. (I don’t like the “ideal burndown” terminology, but so long as people know what the “ideal” line means and is, I’m ok with it.)

      In my upcoming article, Sprint Tasking Tips, I talk about how to use the Sprint Burndown in combination with a Capacity Burndown (my name for the “ideal burndown line”) to make slippage type problems more transparent.

      The exact type of unpredictability you describe is why Scrum is based on Empirical Process Control theory, and the key to any Empirical Process Control system is transparency, inspection, and adaptation. If you don’t have the transparency, it makes it very difficult to inspect and adapt.

      Did I mention that I agree? 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: