While researching and analyzing the best scrum practices to follow and improve our ability to achieve scrum goals, a few of my present and previous team members were discussing the practices I used as the scrum master and the motivating forces behind them. I kept reminding them of the agile mindset when it came to manifestos, scrum guide, and empiricism. I wrote this post after taking in a great number of more fantastic ideas from two more books that prompted me to write about the strategy and empirical thinking underlying scrum in general. The post that follows is a mash-up of the first few chapters of these books. The books are Simon Reindl and Stephanie Ockerman's Mastering Professional Scrum and Fred Heath's The Professional Scrum Master (PSM I) Guide.

Ken Schwaber's foreword: "I established Scrum to improve the way I and others produce software. Over the previous 27 years, Scrum has been enhanced primarily through the creation, publishing, and gentle refinement of the Scrum Guide. Scrum, as stated in the Scrum Guide, was shared online by Jeff Sutherland and myself so that others might offer changes. We've developed Scrum over time in response to these suggestions, making it easier to use and comprehend."

The benefits of Scrum-based agility in a nutshell

We live in a world where the only certainty is that nothing is certain. Before we have an opportunity to respond, new consumers and rivals may arrive, evolve, and vanish. We accept the truth that we cannot anticipate the future in reaction to this ambiguity. We can only do our best by acting deliberately, taking tiny steps forward, embracing uncertainty, embracing empiricism, and learning through feedback. Planning in small increments, delivering a working product increment, inspecting the result, and adapting repeatedly and transparently, is at the heart of agility and the foundation of Scrum. However, for agility to be effective, it must be pursued with professionalism.

It is essential to note that Scrum is a framework for processes, not a process in and of itself. It establishes a set of rules, milestones, and checkpoints that must be followed independently of the underlying development method. According to the organization's working habits, the Scrum framework may be used to encompass a variety of popular development approaches, processes, or techniques. Scrum does not teach us how to conduct our activities; it just provides a container in which to accomplish them. Within Scrum, we may use whichever development methodologies, design processes, productivity, quality, and release procedures we choose. It is perfectly okay to do so as long as the Agile and Scrum principles are followed.

What is Agile software development?

Anyone who has worked in software development for some years has most likely heard of the word "Agile". People often talk about doing Agile or being Agile, but what exactly does Agile entail? To address that question, we must first examine the history of Agile software development.

In the late 90s, many top software engineers and industry experts were already experimenting with more flexible and responsive methodologies and approaches, fed up with the rigid and static software development procedures that were popular at the time. In the years 2000 and 2001, when I was just an 18-year-old student at Colombo Royal College and experiencing the sky for the first time since meeting my current wife, my first love😊. At the time, a small group of influential individuals got together to discuss these strategies and tactics. The goal of this initiative was to be able to quickly deliver working software to end customers and gain rapid feedback on the product's effects and scope. Agile became the umbrella name for approaches created under this principle in the following years. The Agile attitudes are best captured in the Agile Manifesto (2001), which states four values and twelve principles. They've established ideas that stress constant delivery, regular feedback, one-on-one interactions, and more. Okay now, let's take a deeper look at the Scrum framework with these things in mind.

What exactly is Scrum?

As said earlier, in the late 90s, numerous visionaries were experimenting with flexible and adaptable software development methods. Ken Schwaber and Jeff Sutherland were two of these visionaries. They developed Scrum, an agile framework based on the scientific technique of empiricism rather than rigorously adhering to a pre-determined plan. Scrum values are actively developed from Agile principles, not only because they were formed by two of the individuals engaged in the production of the Agile Manifesto. Scrum doesn't teach us how to do our job; it just creates a container in which we may accomplish it. Within Scrum, we may use whichever development methodology, design, or release procedures we like. It is perfectly okay to do so as long as the Agile and Scrum principles are followed. Scrum pushes us to adopt values like respect for others, transparency, and commitment to help us deal with uncertainty and solve complicated challenges. It encourages the formation of self-organizing, cross-functional teams capable of delivering workable software independently and in the face of constantly changing external demands and conditions.
The Scrum framework is made up of three parts:

• The Scrum Team is a self-organizing, cross-functional group of individuals who are responsible for delivering workable software.
• Scrum Events are a set of time-boxed activities that assist in establishing regularity, offering feedback, encouraging self-adjustment, and supporting an iterative and incremental lifecycle.
• Scrum artifacts are items that reflect work or add value and give visibility into the team's progress and accomplishments. Artifacts also serve as a foundation for inspection and adaptation.

Every team, regardless of its level of expertise, may increase its capacity to inspect and adapt in order to create valuable product increments. Customers are always changing, and their requirements are changing as well. Competitors are also constantly growing and adapting. Similarly, technology is always evolving, allowing for new possibilities but also posing new obstacles. New team members provide new abilities and perspectives, but they may alter the team's dynamics. To meet these difficulties, the Scrum team must not only master the delivery of outstanding products via empiricism, but also inspect, adapt, and improve their capabilities.

Scrum Theory and Principles

You could be wondering at this point: why should you worry about theory if Scrum is a practical, agile method for software development? Scrum isn't a step-by-step procedure, as the simplistic response implies. Scrum is a methodological framework. It informs us what we should value and what is essential, establishes certain rules, and instructs us on how to use these principles to attain our goals. It's difficult to follow Scrum's instructions without understanding the underlying idea and principles. With that in mind, the philosophy of Scrum, the empirical method it is built on, its values, and its principles are discussed in this chapter. We'll focus on the following subjects in particular: The Scrum's fundamentals, Empiricism's pillars, Scrum's values and The House of Scrum.

**The Scrum's fundamentals: **Scrum is based on empiricism or the empirical process theory of knowledge. The name "empiricism" comes from the Greek word "empeiria," which means "experience". According to this view, all knowledge should be founded on and supported by experience. Learning is built on our perceptions, observations, and practised experience. Rationalism, another paradigm of knowing that views reason as the primary source and standard of knowledge, is sometimes compared with empiricism.

The Empiricism's pillars: Empiricism is at the heart of Scrum. Transparency, inspection, and adaptability are enhanced when empiricism is embraced. For a Scrum team to increase its capacity to create valuable product increments, it is critical to understand these three pillars of Scrum Theory for any empirical process. The Scrum Framework includes a set of simple guidelines that can assist a scrum team in achieving a minimum degree of empiricism: Scrum teams may use time-boxes to help them construct empirical feedback. A Scrum team may promote transparency by generating a "Done" increment at least once throughout a sprint, allowing them to confirm their value assumptions. Scrum teams must expand the quantity and quality of their empiricism to properly realize the advantages of Scrum. Consider the following situation:

• They may find improvements in their processes, tools, and relationships by enhancing transparency in how they conduct their business.
• They receive deeper insights into how they can enhance the product by improving transparency into the value that customers realize from using it.
• By increasing their frequency of collaboration during the day, beyond just the daily scrum, they can identify and resolve issues sooner, thereby improving their flow of work.
• They can enhance the speed at which they can develop the product by collaborating with the product owner while the job is being done.

Scrum practitioners should inspect Scrum artifacts as they are created, according to the Scrum Guide. The Inspections should be comprehensive and honest, but they should not take precedence over or block development efforts. Attending activities like the Daily Scrum, the Sprint Review, and the Sprint Retrospective encourages frequent review of artifacts.

Adaptation is a natural consequence of inspection. Inspection cannot exist without adaptation. During the inspection, we learned a lot. We figure out what we did correctly and poorly, how conditions or requirements have changed, why some things succeeded and others didn't. Adaptation is the process of adapting to new information. It's about making adjustments so that things that failed the first time around may succeed the second time around, as well as so that things that went well can get even better. These changes don't necessarily have to be technical, such as switching to new technology. They might be personal, such as committing to more honesty and transparency, or they might be environmental, such as asking a break-out place, etc.

**Note: **one of the Agile Manifesto's four values is the ability to respond to change. The application of this value is referred to as adaptation. Scrum Events that stimulate introspection also promote adaptability. The Sprint Review provides us with the opportunity to make corrections and establish plans. Scrum does not instruct us on how to take action or make plans. It's up to the team to decide. Scrum is a framework, not a procedure. It just establishes the ground principles and provides an opportunity for inspection and adaptation. It's up to us to do the rest.

We must be able to easily observe what we do and comprehend how and why we do it to inspect and modify it. To do so, we must open up our events, artifacts, and the team itself to inspection. This is what transparency is all about: showing our team and stakeholders how we operate, what we do, and what we believe. All three Scrum components must be transparent: the team, events, and artifacts.

Scrum's values: the most recent modification in the Scrum Guide version of November 2020 was the addition of a section on Scrum values. Commitment, courage, focus, openness, and respect are among the ethical values covered in this section. Inspection, adaptation, and transparency will only become powerful enough to support and safeguard the team and the development process if everyone on the team believes in them. Scrum can only succeed if people put these ideas into practice and refine them regularly.

• Commitment refers to our dedication to the team and the Sprint Goal. It suggests we're willing to assist the team in achieving the objective, even if we don't agree with the aim or the decisions made to achieve it. After the team has agreed on the tasks to be performed in a sprint, we commit to completing them. Commitment does not imply that we accept any choice made by others without inquiry and follow it blindly; it does imply, however, that once our questions have been addressed and our reservations have been expressed to the team, we dedicate ourselves to the chosen commitment and goals.

• Courage implies that we can accept when we are mistaken or when our opinion differs from that of the team. Nobody is perfect; we all make errors, and it takes a bold person to accept their weaknesses. Courage also implies that we are willing to engage in difficult discussions if necessary. Courage does not include dismissing other people's viewpoints, being argumentative, or pushing back against the consensus.

• Keeping specific things in mind as high-importance objects and finishing what we start are both examples of focus. In the short term, we should concentrate on meeting the sprint goal. In the long run, we should concentrate on providing the product that our clients require while adhering to the Scrum values and supporting the Scrum pillars.

• Being straightforward and honest about what we do is what openness entails. We all face problems and obstacles that prohibit us from finishing our work. We let the team know about them when we were open. The team should be aware of such issues early on rather than wait for the client to learn about them afterwards. Rather than keeping new ideas to ourselves, we should present them to the team and discuss them. When we offer a concept or design, openness also entails discussing its disadvantages as well as advantages. Openness does not imply that we constantly remind others of our accomplishments or boast about our abilities.

• Respect is more about how you treat people. Respect entails considering other people's ideas and suggestions and, if we disagree, providing constructive criticism and reasoned explanations rather than discarding them dismissively. Respect recognizes that various people have varied skillsets; some people will be better than us at something, while others will be poorer. It entails acknowledging that people come from various backgrounds and will approach the same subject from different angles than we do. Last but not least, we must remember that we are all human beings who make mistakes, have terrible days, and do wonderful things. Recognizing and accepting this simple fact is what respect is all about.

**Note: **As Scrum Masters, we foster commitment by prohibiting mid-sprint revisions that do not adhere to a sprint goal and eliminating any barriers to the team's committing to a task or goal. We must not be courageous when other stakeholders attempt to redirect the team's focus away from the sprint goal or undermine Scrum processes or principles. Encourage full team focus in daily Scrum meetings and assist the team in defining and adhering to the definition of "Done." Encourage team members to be open about any challenges they're having, and make sure all team members have access to constructive feedback from stakeholders. Instead of rejecting new ideas, cultivate respect through promoting conversation. Instead of criticizing, promote constructive comments. Instead of personal judgment and negativity, we must encourage collaborative team effort to solve problems.

**The House of Scrum: **Scrum can be easily visualized as a home. Scrum's foundation is empiricism, which he uses to build his house. Adaptation, inspection, and transparency are the three pillars that sustain the home. Bricks built from Scrum values are used to build the walls. This may be seen as follows:

If the foundation is removed, the home will collapse, just like any other structure. The roof will collapse if the pillars collapse. The home will be exposed to the environment if the walls are broken. The previous image helps us understand Scrum's theoretical foundations as well as the need to make Scrum a complete and useful process framework.

Continuously enhancing your scrum practice

Please visit the LinkedIn link for the full article