The Importance of the Transparency Value in Agile

Transparency is one of the core values of Agile.  Transparency is critical to the success of organizations and groups adopting Agile.  In Scrum, we use burndown and/or burnup charts to report the progress of the team throughout the Sprint.  In Scrum, we also have “ceremonies” or meetings that help with transparency, which include the Daily Standup, Sprint Planning, Sprint Review, and Retrospective meetings. These all give the team and product owner a chance to raise issues and be honest about things like the team’s progress. We can also implement a 5 whys root cause analysis process in the agile team to identify the main problem solution. The meetings also give the team a chance to adapt and improve. Get to know more about agile vs traditional project management.

Why is transparency important to Agile?

Transparency in Agile Software Development cannot be overstated. In some organizations it is not easy to be transparent and open.  There are lots of pressures to say what the business wants to hear.  But I believe in the long-run a lack of transparency hurts an Agile team, the project, the organization, and ultimately the company.

I have seen firsthand organizations that claim they want “openness” but then, I can say that true transparency is not easy. Transparency is critical to the success of Software Development using Agile Methodology  and it is well worth the effort.

Without full transparency there are lots of bad things that happen, including:

• Lack of trust with the Product Owner
• Team has to get caught-up in politics instead of focusing on what needs to be delivered
• Team morale can suffer
• Measuring future work is more difficult
• The team’s true velocity is not known

 How teams can be more transparent with a Product Owner

There are several steps a team can take to prevent the issues raised in the previous section.  In this section, we will cover some of those steps.

Use burndown charts to be honest about how the team is performing in a given Sprint. A burndown chart tells the true story of how the team is performing. Some teams also use a burnup chart for this purpose. If you cliff-dive at the end of the Sprint, that's not the greatest, but at least you are being honest to the Product Owner in terms of what happened.

If you are not going to make the Sprint commitment, at least that will be more obvious during the Sprint (i.e. the burndown will show that the team is not closing enough points each day and is at risk of either cliff-diving or not meeting the commitment). The point is that the team is being completely transparent.  The velocity is what it is.  The product owner knows what the team is capable of delivering.

Using the raw data and not hiding anything from the business frees an Agile team. I believe it is Kent Beck that has an excellent quote in one of his presentations about what he calls “schedule chicken.” He tells a story about people around the table during a typical project meeting and the project manager is going around asking each team how things are going. Everyone wants to put on a good face and says “umm, yeah we are on schedule” even when they are not. Now they have to sit there and know that they might be caught in a lie later.

Better to just be honest and say “Well, we are about 2 Sprints behind.” Done.  Now there is nothing to hide and you can move on and deal with the reality of the situation you are faced with.
There are a couple things that happen when the team is honest with the Product Owner.  The first, as mentioned previously, is the relationship between the Product Owner’s trust in a team and the team’s transparency.  Figure 1 below shows this relationship.

But there is another benefit we get from being transparent: the team’s velocity becomes more accurate.  This can be seen in Figure 2 below.

What Product Owners Should Ask

If you are a Product Owner what are some of the signs that a Scrum team is not being 100% transparent? This section will focus on some of the red flags or “smells” that may indicate a team is not being truthful and transparent.

If a team does not want to share their burndown and/or burnup charts, that is an obvious red flag and is simply not acceptable.

If the velocity of a team is very static, that may also indicate issues. This may indicate that the team has a fixed amount of points they will always commit to for a Sprint, regardless of their actual capacity.  More on this in the section below on case studies.

Another possible red flag is when most User Stories have the same point value. It could indicate that the team is using a “one size fits all” for their estimates. The Product Owner should not be afraid to press the team if they feel the team is not accurately estimating User Stories. But you need to ask in a way that is not accusatory.

Become a project management expert with our PMP online training courses. Enhance your career and confidently lead successful projects.

 Case studies

In one Scrum team I saw a real lack of transparency and it really was not a good experience. Soon after joining this Scrum team, I attended my first Sprint Planning meeting on this team. In the meeting I noticed something odd. Their true velocity was let's say, 40 points, but they would only commit to around 30 points. They would then find a few more stories and put them in the next Sprint. These additional stories were what they would call “a stretch goal”. But they knew their velocity was much higher than what they were committing to. This seemed very wrong to me. It was a total lack of transparency and honesty.

Not surprisingly, the team would typically finish the stories in the current Sprint and then work on a few more stories from the next Sprint that they had put aside. For the most part, this was a management decision because they did not trust the team to meet their velocity in a consistent fashion. This led to a lack of transparency with the business, and normal tools like burndown charts could not be trusted. Also, it did not make the team feel very good because they knew they were not being honest with the business.

Instead of using this "stretch goal" approach, use the velocity of the team to measure how much work can be done in a given Sprint. Then, based on capacity, commit to what you know your team can complete that Sprint.

Be honest about the team’s velocity and don't give into political games about trying “to look good” on some presentation slide. This type of misrepresentation does not benefit anyone in the long run.

Conclusion

The bottom line is to let the quality of the team’s work speak for itself. Have a consistent velocity, deliver software without defects, deliver business value, and adapt to what the business needs. This will lead to more trust with the Product Owner and will make the team feel better since they are being 100% honest not having to play any games. This lets the team focus on what truly matters: delivering quality software that adds value.