The strategy and empirical thinking underlying professional scrum??

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:

1. The Scrum Team is a self-organizing, cross-functional group of individuals who are responsible for delivering workable software.
2. 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.
3. 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 htt
• By increasing their frequency of collaboration during the day, beyond just the daily scrum, they can identify and relate with the product owner while the job is being done.
• They solve issues sooner, thereby improving their flow of work. They can enhance the speed at which they can develop the product by collaborating.

• 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

To improve your Scrum practice, concentrate on seven key areas. We've broken down the improvements into an agile mindset, empiricism, teamwork, team process, team identity, product value, and organization. The outcome is that Scrum encourages an iterative and incremental approach to software development, which is one of its biggest advantages.

An Agile mindset improves the attitudes and outlooks of Scrum team members, influencing how they view?and collaborate with one another. When we talk about an agile mentality, we refer to the Scrum values, Agile Software Development values and principles, and Lean Principles. These values and principles govern a Scrum team's actions, and they have a direct impact on the team's ability to collaborate while employing an empirical approach to create valuable product increments.?In a complicated world, there are few rules and no "best practices" that a team may use to deliver value.?Instead, an agile mentality guides team members to make decisions based on the best evidence available.

Mastering Scrum involves improving?teamwork. Scrum teams must cooperate to create useful solutions to complicated issues, then assess the results and change based on feedback to make empiricism work. A Scrum team that works well is a cross-functional team that has all of the necessary talents to achieve the goal. This decreases the danger posed by external dependencies. A self-organizing team decides what it can achieve and how team members will collaborate to achieve it. The first step is to ensure responsibility is for a team to feel ownership of the job. A self-organizing, cross-functional team must break down silos to profit from the benefits of cooperation and collective intelligence. A stable team is more than a collection of individuals; it is a whole new entity made up of people who are themselves magnificently diverse entities.

In order to improve, teams must develop their team procedures. The Scrum Team defines its working style within the constraints and guidelines given by role accountabilities, event goals, and artifact purposes in the Scrum Framework. It is up to the Scrum Team to fulfill the duties, use the artifacts, and perform the events, and here is where most team-to-team procedures become unique. It is also up to them to decide how they will develop product increments and maintain quality.

Practices, methods, and ways of working together are all part of the team process dimension. It covers a wide range of subjects, including the following:

• Engineering practices and equipment.
• Tools and methods for ensuring quality.
• Practices and tools for project/product management.
• Practices and technologies for managing product backlogs.
• Effective use of Scrum events and artifacts.
• Effective communication and collaboration.
• Identification and removal of sources of waste.
• Impediments must be identified and removed.
• Team knowledge, skills, and talents are effectively used and grown.

The type of product, its technological platform, the environment in which the product is used, the users of the product and how they use it, regulatory and legal restrictions, market trends, changing business demands, and so on will all affect the techniques and tools that a team employs. As a result, scrum teams must continue to inspect and modify what they're doing, why they're doing it, how they're doing it, and what advantages they're getting from it. New practices and tools are always being developed and shared in product development communities all over the world, so staying engaged and learning is essential. In reality, to address their particular difficulties and goals, teams may need to design new practices and tools.

A team begins as a collection of people, and every strong team has a distinct team identity. They produce a new life and breathing entity when they come together. At its most basic level, defining identity entails responding to three major questions that steer a team on its path to great performance:

Why do we exist? (Purpose), What is important to us? (Values) and What do we want? (Vision)

Organizations provide both structure and culture, and they may have a big impact on how well a team and product perform. Both of these aspects have a positive or negative influence on the teams and products that exist within the organization. The business model, or design for effectively conducting an organization, is included in the structure. This comprises the objective, strategy, assets, and services, as well as how they connect to revenue, a client base, and funding. Employees, partners, and service providers are all arranged according to their structure. Organizational procedures and policies are frequently influenced by it.

The success of Scrum Teams is greatly influenced by organizational structure and culture ??.

Scrum teams require varied skills based on the type of product they're working on and the restrictions of the company. The capabilities they require may be divided into five categories:?teaching and facilitation talents, coaching abilities, technical competence, and servant leadership.

Iterative and incremental software development

Iterative development refers to the process of creating software in little pieces over time, rather than waiting for everything to be done and then providing a huge chunk all at once. It entails breaking down the requirements to be achieved into smaller chunks and implementing them one at a time. As a result, rather than one single, big-bang software release after the project, we have a series of smaller deployments spaced out across time. Iterations are the term for these delivery intervals. A sprint is what we call an iteration in Scrum. Each iteration of incremental development builds on the software produced by prior iterations. The goal is that each iteration should provide value to the preceding one. An increment is a piece of software or functionality that each iteration adds to the system. An increment in Scrum is not created at random, but rather to achieve a specific objective, supply requested functionality, or solve a specific problem. This goal is known as a "sprint goal" since it is determined at the start of the sprint.

As demonstrated, there is no difference between development stages in an incremental and iterative development cycle. So, within the same iteration, our team may be designing one feature, developing another, and testing a third, all at the same time. This style of development allows developers to rectify any mistakes, address any issues, and inspect and adapt to changing needs at an early stage, resulting in less time and effort and a lower risk of failure or late delivery.

Three key pain points

The three key pain points of a Scrum team are circled in the above figure, and each likely reason is represented as contributing to one or more of the pain points. The Scrum team can make better-informed judgments about where to begin fixing the most essential issues now that they have seen the problems. Although there is no magic formula for addressing all possible root causes, the team will be able to uncover the best solutions for them at this moment through an iterative and incremental approach. Empiricism is used to make incremental improvements. We have generated openness and enabled inspection of that visible information by addressing difficulties and their core causes.

Endnote: Empiricism is a useful approach to software development, which we talked about. The scientific framework is founded on an empirical approach of observation and experimentation, which has resulted in the high quality of work-life and technological advancements that we have today. Similarly, in addition to helping us understand and apply Scrum, the pillars of empiricism (transparency, inspection, and adaptability) may be quite valuable in many other aspects too. Finally, for Scrum to be useful to our team, the Scrum values are essential. They assist us in understanding how to use Scrum principles and rituals in the proper spirit, treating them as opportunities for progress and communication rather than things we must do because Scrum requires them within the framework.