Introduction
The 3 Scrum pillars allow empiricism to thrive. Let’s recall what empiricism is according to the Scrum Guide: “Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.” The examples of applications will be interconnected.
Today, I offer you brief descriptions and examples of situations that put these pillars into action, always in a well-defined context to allow for some projection. Feel free to provide feedback to make these concepts more accessible to a wider audience! #continuousimprovement #iteration
These examples are drawn from my personal experience and modified for the article. I hope to help you to understand SCRUM pillars with they examples.
Each word with an “*” will be explained at the end of the article.
The Context
We are an Agile team using the Scrum framework (multiple developers, a Scrum Master, a Product Owner). We are developing a dating application called “GeekLuv,” which is very similar to Meetic but targets a fanbase of pop culture enthusiasts! The application features prominently displayed profiles and, most importantly, allows for “matching” based on a list of shared interests and a rating system! It’s possible to bring together two fans with a 10/10 rating for Keanu Reeves.
We are in January 2020 (two months before the first lockdown), and the activity is going very well. We are delivering new features one after another and believe we can become the number one application on the various smartphone app stores.
Transparency
All team members and stakeholders have access to project-related information, including product specifications, team goals, encountered problems, and verified results of various assumptions.
Progress is shared regularly. This honest approach allows for adequate solutions to be considered for the problems encountered and prevents unnecessary fears: we will face unforeseen problems anyway, so it is better to be united and solve them together. We have the same goals together.
Transparency allows us to have all the necessary information to make the best possible decisions.
In Scrum, this is reflected most through the state of the three artifacts: the product backlog\, the sprint backlog\, and the increment\*.
As the Scrum Guide states: “Transparency allows inspection. Inspection without transparency is misleading and wasteful.”
I could summarize transparency as “collaborators know what is happening.”
Examples:
- Developers report the unavailability of a development library (a set of pre-coded functions and classes in a specific language\\): This is a big problem. The OpenSource library “EzIdentitty” that we have been using since the beginning of the project has recently been deprecated. The team behind it has been facing financial issues, and the pandemic dealt the final blow… Several online articles reveal significant security vulnerabilities! It is possible to retrieve personal data with a few JavaScript commands from the Google Chrome console… The team communicates this unforeseen issue. We need to identify the security vulnerabilities and find ways to address them. In the medium term, we will have to switch to a different library. Currently, the team does not have security experts (so maybe not the expertise), yet it could become the new priority… The product backlog\* needs to be updated to account for the additional work.
- The Product Owner explains the context to the stakeholders: The development team has identified a critical security point in our application. We will have to change the priority of certain backlog items and create new tasks to focus on the safety of our application: sensitive data could be hacked.”
Inspection
Inspection requires regular and systematic examination of the work done, tools used, and processes employed. This allows the team to detect problems, errors, or defects as early as possible.
In Scrum, it is the five events\* that facilitate inspection.
As the Scrum Guide emphasizes: “Inspection enables adaptation. Inspection without adaptation is considered ineffective. Scrum events are designed to provoke change.”
I could summarize inspection as “Observing and interpreting to improve.”
Of course, without transparency, inspection cannot be effective!
Examples:
- During the Sprint Retrospective, developers reflect on the security incident of the sprint. “Could we be proactive in such problems?” “Do we have security skills?” “How can we ensure that a library has undergone security checks?”
- During the Sprint Review, the user representative raises accessibility issues with the application. Indeed, colorblind individuals cannot view other people’s profiles, making the application unusable for this audience. A discussion takes place between developers and the user representative to find a solution.
- During the sprint, a developer notifies other developers that they are stuck due to a lack of PHP skills. Perhaps they overestimated themselves for this task.
Adaptation
Following regular inspection by the team, the product, and the processes, the team can anticipate necessary adjustments and potentially revise or change objectives and adapt priorities for the upcoming sprints. This allows for appropriate corrective measures to be taken, improves product quality, and avoids significant deviations. Adaptation is the driver of continuous improvement.
Adjusting plans and taking measures to maximize the produced value. These adjustments allow for adaptation to new information, changing needs of stakeholders, and challenges encountered in the field.
Have we improved our situation? Can we generate more value thanks to the changes?
I could summarize adaptation as “We propose a better strategy as soon as possible or as necessary.” Transparency and inspection enable adaptation.
Example:
- The Product Owner updates the Product Backlog to address security vulnerabilities.
- The developers take into account the raised accessibility issues for colorblind individuals in the application and implement the appropriate changes.
To conclude on the context
The entire context highlights the SCRUM pillars, we can ask ourselves the following questions: Could we have predicted the security breach?
Inspection Would hiding this detail from the company and “finishing” the product on time have been beneficial? Transparency Will this transparency improve the future of the product? Adaptation Will the adaptation allow the product to survive in the long term? Certainly yes.
Did a lack of transparency and adaptation prevent a potentially much bigger problem in the future? The team acts before a scandal can break out. I hope these examples will help you see things more clearly.
The working framework cannot exist without the SCRUM pillars. It is important to specify that the lack of transparency annihilates, or can even go so far as to cancel, inspection and adaptation, and therefore empiricism.
Source :
Vocabulary:
Sprint Retrospective: An event that allows the team to reflect on the completed sprint, identify what worked well, what can be improved, and implement corrective actions for future sprints.
Product Backlog: As defined by the Scrum Guide, the Product Backlog is an ordered and emergent list of what is needed to improve the product.
Sprint Backlog: As defined by the Scrum Guide, the Sprint Backlog consists of the Sprint Goal (the “why”), the set of Product Backlog items selected for the Sprint (the “what”), and a plan for delivering the Increment (the “how”).
Increment: As defined by the Scrum Guide, an Increment is a concrete step towards the Product Goal. Each Increment adds to all previous Increments and is subject to thorough verification, ensuring that all Increments work together. The increment is thus the result of the current increment + previous increments (the product’s features).