3 Pillars of Scrum: Transparency

If you’ve spent any amount of time immersed in the world of Agile project management, you’ve likely heard of empirical process control. Rather than relying too heavily on detailed, upfront planning, empirical process control attempts to “expect the unexpected,” allowing practitioners to react dynamically to the changing conditions around them.

In Scrum, this takes the form of an iterative, experimental feedback loop, providing built-in mechanisms for improving the way a team approaches project management and product development. In order to properly execute an empirical process, however, it’s important to understand the 3 pillars of Scrum that uphold this technique— transparency, inspection, and adaptation.

Never miss a post.

Sign up now and receive updates when we post new content.

I will never give away, trade or sell your email address. You can unsubscribe at any time.

Here, we’ll break down the first crucial principle and dive into what it means to be a transparent organization.

What is Transparency?

Transparency allows every member of a Scrum team to remain on the same page with the same facts, keeping them informed and aligned throughout the duration of a Sprint. By enabling a transparent flow of information, Scrum allows team members to gain a better understanding of their collective progress, making the sources of their successes and obstacles far easier to identify.

Transparency is through formal Scrum events — Sprint Planning, Sprint Review, Sprint Retrospective, and Daily Scrum— as well as through visual means, like burndown charts or the Scrum board. The Sprint Backlog, Product Backlog, and Definition of Done also produce necessary transparency.

For example, let’s say a member of our Development Team is struggling with a particular engineering task. They know there are several options to solve their problem, but the approaches they are most familiar with tend to be meticulous and time-consuming. As a result, it seems likely they’ll be late in delivering their contribution, which could potentially snowball into subsequent delays throughout their product roadmap.

By openly voicing these concerns during the Daily Scrum, however, this individual can make their struggles more transparent, offering their team members a golden opportunity to help out. Maybe someone else on the team knows better tooling or a more efficient development approach.

Without transparency, these solutions may never surface, and progress could remain stalled as your team member continues down the path of most resistance. That’s why it’s important to voice your concerns, discuss challenges, and not be afraid to admit you need help. A Scrum Team is a force for continued growth and improvement.

The Tools of Transparency

Nearly every Event and Artifact in Scrum creates transparency, fostering collaboration and communication throughout the development process. And although adapting to more transparent ways of working can be challenging, there are many tools that help guide your team.

Scrum Values

The Scrum Values are foundational to transparency. Focus, Openness, Commitment, Courage and Respect, when embraced by Scrum Teams and organizations, establish a culture of transparency. Without these values, teams will lack transparency and struggle to improve and deliver consistently.

Product Backlog

When it comes to the complexity of modern business environments, it’s become increasingly important that teams remain aligned and informed. The Product Backlog is the ultimate source of information transparency, serving as the most tangible visualization of which solutions add the most value.

This allows all stakeholders to better understand where their own priorities fit into the overarching context of the product, and helps Product Owners and Scrum team members have more meaningful conversations about how the roadmap can be optimized and implemented.

Burndown Charts (a complimentary practice)

It’s not easy to predict how much work will be accomplished over any period of time. Throughout the duration of a Sprint— no matter how short or long— it is likely a team will encounter a variety of unexpected obstacles. For this reason, it’s important for a Scrum team to stay cognizant of their overall progress at any given moment.

While not officially part of Scrum, burndown charts are a great complementary practice commonly used with Scrum. Burndown charts enable the total transparency of the group’s collective efforts, allowing them to consider how these hurdles will affect their product release timelines and adjust accordingly.

Definition of Done

How do you define releasability? How do you know when something is safe to put into production? How do you make the quality of the new version of your product transparent? This is where the Definition of Done comes in.

The Definition of Done makes transparent the quality expected before a new version of the product can be released. If the development organization has not created a global standard it is up to the development teams to create and maintain one.

Ideally, the Definition of Done is a binary checklist leaving no room for subjectivity. Its either Performance tested, or its not. This might be an item on your Definition of Done.

Sprint Retrospective

Retrospectives are crucial periods for the growth of a Scrum team. This routine touchpoint is designed to stir thoughtful reflections about how team members might better cooperate and work together.

This process, by its very nature, requires openness which produces transparency from contributors. Without openness and transparency, attendees may not be willing to voice their frustrations or concerns and the team will continue to suffer. Every individual should take this opportunity to improve their processes and practices, making every development cycle more efficient and enjoyable.

Sprint Review

While the majority of the Artifacts and Events we’ve discussed involve only the core members of the Scrum team, Sprint Reviews involve the full spectrum of stakeholders. This event, time-boxed to a four-hour period for a one-month Sprint, is intended to be a collaborative discussion about the product’s progress and challenges faced.

In this event, the Development team is transparent about what they’ve accomplished, whether there were any issues, and collaborates with Product Owner and stakeholders about future priorities. This also provides management the opportunity to inspect timelines, budgets, and trends in the external marketplace that may impact the direction of the project.

A Guide to Scrum

All three pillars of empiricism found in Scrum are foundational for an Agile organization. It’s important to recognize that, without first instituting transparency, it’s impossible to move forward in effecting any sort of meaningful change. By fostering a culture of transparency and honesty at every level, teams will find it far easier to inspect and adapt, giving them the tools they need to transform their company into a truly Agile organization.

Still, organizational change is a complex process, with best practices and subtle details that vary sharply from product to product. For this reason, it’s important for organizations to have an experienced guide. By aligning themselves with a partner that is well-versed in the process of Scrum adoption, leaders can help smooth their team’s transition to long-term Agile success.

Responsive Advisors can be that partner. With a crew of qualified industry professionals, a diverse catalog of training offerings, and a unique perspective on project management best practices, their team can help walk you through every step of Scrum implementation. Whether you’re just beginning to explore the world of Agile project management, or you’re seeking out quality training programs to help boost your existing Scrum initiatives, Responsive Advisors is perfectly positioned to help you activate and accelerate your team’s delivery of business value.

Robert Pieper

Robert Pieper has been a licensed Scrum.org Professional Scrum Trainer since 2014 and National Public Speaker since 2013. Robb holds an MBA from Marquette University and an Electrical Engineering Degree from Milwaukee School of Engineering. Robb has 15 years of professional software development experience with a passion for making Scrum work delivering real products and services
Filed Under:
Tagged with: