“Change is inevitable—except from a vending machine.” – Robert C. Gallagher
Change is inevitable, and it can happen at any time, both in personal life and in the workplace. In the context of Scrum, change is not an obstacle but an opportunity for inspection and adaptation. By embracing change, the Scrum Team has the chance to continuously improve the value of the Increment they deliver. Flexibility and the ability to adapt allow the team to work more effectively in facing unexpected challenges.
Commitment to Delivery
Learning from the real-life example of Thomas Edison in inventing the light bulb, we see how commitment can be the key to success. Before succeeding, Edison failed about 1,000 times in his efforts to find the right material for the filament. However, he didn’t give up; he remained committed to finding the solution and eventually invented the light bulb that changed the world. When asked about his failures, he said, “I haven’t failed 1,000 times. I’ve just found 1,000 ways that won’t work.” This is an extraordinary example of commitment to innovation despite facing repeated failures.
In Scrum, commitment is a core value. The Scrum Team commits to the Sprint Goal, which serves as a guide in delivering a valuable Increment at the end of each Sprint. When changes occur, the team must remain focused on the Sprint Goal, evaluating whether the change can be accepted without compromising the primary Sprint objectives. Commitment is not only about completing Product Backlog Items but also about dedicating oneself to continually inspect and adapt throughout the Sprint.
Scrum is designed as a lightweight framework, providing guidance without limiting the team’s creativity. If the product development process is like walking through a dark hallway towards a goal, Scrum is the flashlight that helps illuminate the path, revealing obstacles ahead. However, Scrum doesn’t provide direct solutions. The team must utilize their collective intelligence to work together to face problems, deciding whether the obstacles should be avoided or broken down to solve them. Feedback from stakeholders is also often a part of this process, helping the team to continuously inspect and adapt.
Collaboration Beyond Specialization
An example of cross-disciplinary collaboration can be seen during natural disasters, where various groups from different backgrounds work together to provide assistance. Search and Rescue teams, medical personnel, kitchen crews, and even entertainment volunteers all collaborate, despite having different expertise. The same applies in Scrum. Each member of the Scrum Team may have their specialization, but when someone is too fixated on their role without caring for others’ tasks, it can disrupt the Scrum Team’s progress. For instance, I’ve witnessed teams that are unwilling to take responsibility outside their area of expertise often fail to meet stakeholder expectations. Over time, encouraging collaboration and collective responsibility—such as rotating production support, regularly coordinating with customer support, monitoring Current Value and Time to Market metrics to decide the release strategies—has helped the Scrum Team better adapt and provide more comprehensive solutions to users.
When collaborating, the Scrum Team must be prepared to adapt and take on different roles as needed to achieve shared goals. The Scrum values encourage this flexibility and teamwork.
Adapting Through Scrum Values
One of the key outcomes of implementing Scrum is improved quality—whether in development, product, or the work environment. As a Scrum Master, I once faced a difficult situation where the team struggled due to an unstable system caused by the ongoing addition of new features without adequate stabilization processes. This led to an increase in incidents, continuous overtime, and micromanagement from leaders, which ultimately caused some team members to leave due to frustration.
In dealing with this situation, I realized that the Scrum Values—Commitment, Courage, Focus, Openness, Respect—must serve as the guiding principles to help the team adapt. Here are some lessons I learned:
- People First
My experience in implementing Scrum has shown that putting “people first” is truly the core of Scrum implementation. By creating a positive work environment where individual needs are considered, the team can work more effectively and productively. Regularly reviewing the team’s satisfaction—especially in terms of communication, collaboration, and how they overcome challenges that ultimately affect the quality of their work—is key to fostering a healthy and productive work atmosphere. When the team feels supported, they become more open, more courageous, and more focused on achieving shared goals. - Building a Trust and Caring Environment
Simon Sinek, in his book Leaders Eat Last, emphasizes the importance of creating a caring environment. An environment full of care allows people to fully engage both their “head and heart.” When team members feel trusted, they are more motivated to work well, to maintain and further earn that trust. In any collaboration with stakeholders to continue product development, trust is the foundation that must be established first by the Product Owner and Developers together so they can work effectively and build further trust from stakeholders. - Self-Organizing Teams
Trust is key in facing competition. Often, organizations that fall into a cycle of undermining each other across teams or departments ultimately fail to compete with their rivals. Performance assessments should not focus solely on how many tasks each individual in the Scrum Team completes. Instead, it’s wiser to place trust in the team’s ability to self-organize and collaborate, making that the focus of evaluation. For example, during Sprint Planning, leave schedules, checkpoints before product releases, User Acceptance Testing, and even the canary release process should all be conducted transparently. This ensures that all team members share equal responsibility for the Sprint Goal and understand what to do when issues arise during the Sprint. - Respect for Individual Growth
Every individual has their own way and pace of growing. Allowing team members the space to develop according to their abilities reflects the respect inherent in Scrum. Through openness, team members can share ideas and learn from one another, ultimately improving their overall skills. For instance, I have seen how a few hours of weekly “improvement time” can become an avenue for team members to engage in knowledge sharing, fix legacy code, and reduce technical debt, gradually enhancing the Scrum Team’s capabilities. This is evident in reduced incidents, faster Mean Time to Repair, a more stable Innovation Rate, where the average number of maintenance tickets decreases compared to building new features, and fewer user complaints as a result.
Creating High-Value Products
Often, the biggest obstacle to facing change is ourselves. An old mindset, with ingrained ways of thinking, can make us blind to new opportunities or different approaches. It takes a healthy work environment and strong facilitation processes to build a happy and productive team. Not every effort will go smoothly, but when done continuously, it will slowly increase a sense of ownership and lead to high-quality product delivery. With a team focused on product quality, the Product Owner can focus more on the needs of the users, ultimately creating a product that is both valuable and relevant in the market. What do users expect? How does this product make their lives easier or give solution? These questions become central to creating a product that the market truly wants and needs.
#annalogy 