November 7, 2019
The Scrum Pillars at Sophilabs: Transparency
We strive to maintain an Agile approach to software development, and we use Scrum as a framework to organize our work. However, it's crucial that we don't practice Scrum just for the sake of following a structure by the book, lest we fall into the clutches of Zombie Scrum. 1 Instead, we must understand the underlying value of what we're doing and prioritize these valuable outcomes in the way we use Scrum.
One way to do this is to make sure the three pillars of empirical process control – transparency, inspection, and adaptation – are front and center in every sprint. Furthermore, we should sustain and strengthen these pillars with the Scrum values of commitment, courage, focus, openness, and respect. In this post, we'll look at how our team works to achieve transparency, the first pillar of Scrum.
According to the Scrum Guide, transparency means that "significant aspects of the process must be visible to those responsible for the outcome." In addition, transparency "requires those aspects be defined by a common standard so observers share a common understanding of what is being seen." 2 Transparency is a big factor in building trust between the team and stakeholders as well as within the team itself. It also plays a part in keeping the team aligned and ensuring product quality. But what exactly does transparency look like in practice here at sophilabs?
Metrics and QA Elements
This is a key area where the "common understanding" the Scrum Guide mentions is absolutely crucial. At sophilabs, our teams work with the Product Owner to define the following, which help promote transparency and contribute to building a successful product.
Clearly delineated acceptance criteria enables the team to know exactly when a user story or task is complete from a business perspective. When a team can consistently meet client and/or user needs, it builds customer trust.
Definition of Done (DOD)
This shared agreement specifies the quality and working elements the software needs in order to be released. The transparency provided by the DOD is essential to building the right thing in the right way.
These artifacts help the team break down and organize work. However, they also foster transparency, making it clear to everyone involved what still needs to be built or what the team has taken on during a sprint. The Scrum values of commitment and focus play a significant part here, as the team zeros in on the sprint goals and concentrates its energy on delivering the stories it pulls into the sprint. Our teams at sophilabs consistently use these artifacts as part of the way we practice Scrum.
The product backlog lists all the elements the product will need. However, it's also a fluid artifact and does not represent a fixed plan. It can change and adapt depending on information and feedback from the business side, which is one reason the transparency it provides is so important.
This subset of the Product Backlog lists the stories the team has committed to finishing by the end of the sprint. In addition to aligning and focusing the team's efforts, it leaves the customer with no doubt as to the working software they will receive when the iteration is complete.
The Scrum board shows how stories or tasks are flowing through the pipeline from "to do" to "done." It makes progress visible and keeps team members accountable to each other and to stakeholders.
While each Scrum ceremony has its own specific goals, when done right, the byproduct of every ceremony is effective communication and transparency. In addition, the Scrum values of courage, openness, and respect are essential to the exchange of ideas and information at any point. Our team works to achieve transparency and carry out these values through every step of the sprint.
Transparency plays an important role in sprint planning. The team must remain clear on what can feasibly be accomplished during an iteration in order to successfully deliver the increment of working software and maintain customer trust.
In this critical instance of inspection and adaptation (we'll dive deeper into these two other pillars of scrum in future posts), the team checks in to see how things are going in terms of the goals they set out to achieve. Team members openly discuss impediments and blockers, enabling the team to start brainstorming solutions. Transparency in every daily scrum helps teams overcome obstacles faster and brings everyone closer to reaching the sprint goals.
The sprint review is crucial to maintaining transparency with stakeholders. The team demonstrates what they accomplished during the sprint, and the stakeholders in turn provide feedback on this increment. Agile software development needs frequent and honest feedback in order to work effectively, as the team must validate the hypothesis that what they're doing fulfills customer needs.
At sophilabs, we've had sprint reviews driven by the Scrum team and reviews led by the Product Owner and stakeholders, depending on customer preference. Either way, the sprint review assures the customer that they are receiving value, allows the team to acquire the feedback they need, and builds mutual trust.
The retrospective is a cornerstone of the people-centric mentality characteristic of Agile and Scrum. The main goal of the retrospective is for the team to work on their tools and see how they can improve, so it's a great time to assess the quality of internal communication. An effective retrospective requires the team to openly raise issues, propose new ideas and solutions, and demonstrate respect for diverse opinions. Without real honesty and transparency, the team can't take full advantage of the opportunity for improvement that the retrospective provides. We value sprint retrospectives not only because they enable our teams to reach higher, but because they align with our broader organizational culture of continuous improvement.
Transparency contributes to customer satisfaction and helps Scrum teams thrive. At sophilabs, we strive to achieve transparency on our teams through every sprint. Stay tuned for the rest of this series, in which we'll take a closer look at how inspection and adaptation work within Scrum and how we foster these principles at sophilabs. In the meantime, if you'd like to find out more about how we work, check out our Playbook.
Christiaan Verwijs, "The Rise of Zombie Scrum: Symptoms, Causes, and What You Can Do About It," Medium, March 29, 2017. ↩