What is Scrum?

Business Stakeholder: I would like to have this done by tomorrow.
Developer: As we work in Scrum we can do it no sooner than in the next Sprint, sorry. And please contact our Product Owner to follow up on your request.

Often this is how the journey begins: Scrum, Sprint, Product Owner, and the set of all the other strange-sounding terminologies.

Business Stakeholder: And how come they will not do my task for tomorrow?
Product Owner: Well, they simply won’t. Here is how it all works;

Scrum is a framework—neither a method nor a methodology. Scrum is described as an agile way to manage a project. Its primary purpose is to address complex adaptive problems and deliver products of the highest possible value and standards. 

 If you pay attention to the Scrum Guide, the definitive guide to Scrum, it doesn’t say a word about software development. So you can even talk to your spouse and decide to implement Scrum at home. Instead, it’s about values, events, artifacts, and rules that bind events together. No matter which department you work in or what kind of project you manage.

Scrum is founded on empiricism, so knowledge comes from experience and decisions on what is known at every given moment in time. Scrum uses an iterative and incremental approach combined by three pillars:

• transparency, 
• inspection and 
• adoption.

This helps to increase predictability and have better control of project risk. Five principal values control risk:

• commitment,
• courage,
• focus,
• openness and
• respect. 

Each Scrum Teams’ primary objective is to build trust towards all stakeholders by implementing the three above pillars.

Now, you might be wondering where it all begin? Well, Scrum has seen a huge revolution ever since its introduction in 1995, which has led it to understand the basis of success; empiricism.

It was first introduced at the Easel Corporation. An article was published in 1986 called ‘The New New Product Development Game,’ which compared approaches of Rugby and how a whole team surrounds a ball to ensure it doesn’t go back and forth.
The article compared companies putting this same technique. Big companies like Honda, Canon, etc., have used team-based product development to generate superior results. It also talked about what role self-organized teams and management play in development. In 1993, this article became the basis of the concept called ‘Scrum.’

In 1995, ‘The Scrum Development Process’ paper was first published, which was done with the help of two new members who had joined forces with the initial three.

In 2001, 15-17 new associates got together to form the Agile Manifesto, which then became an invitation for software developers to take action to create a unique approach to building software. The implementation of the Scrum framework also begun, creating highly capable teams for organizations across the world.

In 2002, a ‘Scrum Alliance’ organization was found, which developed and launched its highly successful program called Certified Scrum Master.

In 2006, Scrum Inc. was created and continued teaching Certified Scrum Courses. In 2007, the ‘SAFe Framework’ was developed. Finally, in 2009, Scrum org. was introduced, which offered the Professional Scrum Series. 

Then after years of research, Dr. Dave Cornelius presented his Ph.D. study on the Scrum value in 2014, naming it “The Value of Scrum to Organizations.”

Finally, in 2016, the first fully scalable Scrum was formed. Scrum recognized the need for a system of teams and product owners for strategy-related discussions with the stakeholders and the Scrum team’s prioritization. 

Ever since, Scrum continues to evolve and develop into a better version of itself, providing its users with incredible teams and satisfied clients.

Speaking about Scrum Teams, three main roles make up the team – a Product Owner, the Development Team, and a Scrum Master. They run the magic behind Scrum’s very success story, and the Scrum Guide precisely describes their obligations and relations, but let’s briefly look at the roles.

The Product Owner probably will be the first contact with the Scrum world in Software Development. The PO is responsible for maximizing the product’s value and the Development Team’s work and is the only person accountable for managing the Product Backlog.
Sounds easy, peasy? It’s precisely the opposite. The Product Owner is a kind of buffer between all the stakeholders and the Development Team. Moreover, their decisions must be respected by the entire organization.
No one else has the authority to direct the Development Team and tell them to work with different sets of requirements. Yes, that’s right. If you ask a Development Team member to prepare something for you, you’ll be bounced back to the Product Owner, which is entirely correct. The Development Team is allowed to act only on what its’ Product Owner says, and not anyone else.
The reason they have so much authority is that Product Owners are representing the business. They know what is best for the client and the Scrum team, guiding the development team accordingly. 
However, with great power comes great responsibility, and similar is the case of the product owners. The PO’s have the following responsibilities;

• Managing The Scrum Backlog: As stated before, the product owner has to ensure that the development team delivers the best. And for that, the PO should know everything that is in the backlog. Since any team member can put in the backlog items, the PO has to make sure that he knows which team member added what item and communicated with the PO regarding it. 
• Releasing Management: Sprint is more like a planning cycle which means that the team can deliver anytime. However, even though it will be ideal for them to release through the Sprint allowing sprint review, continuous delivery can be difficult. Hence, Product Owners should release things when deemed necessary. 
• Stakeholder Management: PO is responsible for the communication and management of the stakeholders. PO can actively involve stakeholders in any product development, which means they can act as users, customers, or organizational leadership. Hence, PO must step in and ensure that the people working together are doing so effectively and that the development team delivers value. 

With the Development Team, it seems to be quite straightforward. A team of  3-9 professionals develop a product by delivering potentially releasable Increments at the end of each Sprint. They have all the skills necessary to create a product Increment, which makes them cross-functional and self-organizing because no one can tell the Dev Team how to turn Product Backlog into Increments.

The development team is considered a self-organized team because they are independent to make decisions regarding the work. This gives them the space and freedom to do what is needed to get the work done! However, this does not mean that the organization is being disrespected. Rather, the team working closest to the product is empowered to make decisions to fix all problems. 

The responsibilities of the development team are simple; they have to deliver through the Sprint, and they have to lead the ‘daily scrum’ meeting with complete transparency. Everything related to work, success, issues, and blockers, should be communicated during the meeting.
The development team does the work, and they are not only a team of engineers, as one might assume. Rather a team of professionals such as designers, programmers, writers, and yes, engineers too.
However, there are two more things worth noting. First, Scrum doesn’t recognize any other title in a Team other than a “Team Member” role classification. If one member is a Programmer, another a QA Engineer, and yet another UX design, they are still called a “Developer.”
Also, Scrum recognizes no sub-teams within the Development Team. To these rules, there are absolutely no exceptions.

So what is there left for a Scrum Master?

Surprisingly? A lot. The Scrum Master ensures that everything stated above is accurate and that Scrum’s daily routines are followed meticulously.
Most people find it most confusing that the Scrum Master doesn’t manage people but the process itself.
The Scrum Master is the glue that is holding everyone together, so basically, they are helping define the value to the PO, helping deliver it with the Dev Team, and ensuring that the Scrum Team only gets better. They mostly work with the PO, providing them with the necessary help. The help can be in the form of communicating value, management of the backlog, or just general help.
According to the Scrum Guide, the Scrum Master doesn’t have any superior power or rights but is equal to all other team members. This role is usually described as servant leadership. The Scrum Master serves the team in several ways, including:

• removing impediments to the progress,
• helping people outside the team understand which of their interactions with the Scrum Team are undesirable,
• coaching the Dev Team in self-organization,
• coaching the Dev Team in cross-functionality and
• facilitating meetings.

The Scrum Master also supports agile transformation in an organization and shares agile knowledge with others.
However, that is not the end of their responsibility. The Scrum Master focuses on the following;

• Transparency: The Scrum Master has to ensure that the entire team’s work is completely transparent. This is so important because it will help point out any mistakes or changes required, and it will promote efficiency. To do so, the Scrum master could take updates from the entire team and then make story maps or update the confluence pages, etc.
• Empiricism: Another important responsibility is planning the work and learning from it. So what the does Scrum Master does is break down the work, create clear outcomes, and then review them.
• Self-Organization: We mentioned before that the Dev Teams are self-organized. That doesn’t happen overnight. It takes a lot of effort on the Scrum Master’s part to encourage the team members into it. They will empower them to step out of their comfort zones, try different things, and even challenge the boundaries set on ideas. They will encourage them to be their best version.
• Values: There are five values that Scrum believes in; courage, focus, commitment, respect, and openness. These values build a safe and trustful environment. Which in turn creates more space for the team members to thrive or want to thrive. The Scrum Master ensures that this is happening. The values are being followed to create a ‘growth’ environment and that all members are encouraged into it.

Besides this, the Scrum Master is just the helper of the team. Whether it is the PO that requires help or the Dev Team, the Scrum Master is there to take over the responsibility. The scrum master ensures that every opportunity for improvement is communicated to the scrum team and that the retrospective produces a clear set of results that can be implemented.
The above is the basic role description in a Scrum Team. Further, let’s have a look at Scrum Events.

Scrum Teams work in so-called Sprints.
Somehow you can compare it to running towards a Sprint Goal at a sustainable pace. The Sprint starts right after the previous Sprint conclusion and lasts between a week and a month. Usually, it is a one or two-week cycle. Throughout a Sprint, it is not allowed to make any changes, which could endanger the goal of the Sprint. This is why any request for features needs to wait till (a least) the following Sprint.

How does a typical Scrum Sprint work?

Sprints last a week and top a month, starting with Organizing The Backlog, Sprint Planning, Daily Scrum Meetings, the actual development work, the Sprint Review, and the Sprint Retrospective. The next Sprint begins right after the conclusions of the previous one. The whole Sprint lifecycle is illustrated below.

• Organizing The Backlog: The PO must ensure that the product is developing towards its vision while keeping an eye on the market and customer. They have to maintain and update the list after taking feedback from its users and teams.
• Sprint Planning: This is where the work that needs to be done for the current Sprint is decided upon. The meeting is led by the Scrum Master, and the team decides the sprint goal, which is then implemented.
• Daily Scrum Meetings: This is a daily short-meeting where the team gathers to ensure that everyone is updated, on the same page, and following the same goals for the next 24 hours, till the next Daily Scrum meeting.
• Development Work: The team comes together to do all the work and finish the increment. It usually lasts for 2-3 weeks. 
• Sprint Review: This is an informal session where all the work done is viewed and reviewed. Feedback is taken from team members. And the decision is made on whether or not PO should release the increment.
•  Sprint Retrospective: The retrospective is a team conference to record and analyze what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even specific procedures. The goal is to establish an environment where the team can focus on what went well and what has to be fixed next time, rather than on what went wrong.

Once completed, the process moves on to the last step, the Definition of ‘Done.’

Another significant thing about working in Scrum is the Definition of “Done.” Everyone in a team must understand what “Done” means. The Definition of “Done” is used to assess when work on product Increment is complete.
As Scrum Teams mature, their Definition of ”Done” evolves and includes tighter definitions of the strict criteria of increased work quality.
Implementing only parts of Scrum is theoretically possible; however, the output won’t be Scrum and is usually referred to as a “Scrum-ish” way of working.

The roles, events, and rules of Scrum are invariable; hence Scrum exists only when entirely employed.

CodeCoda development teams work entirely based on proven ways of management of software development projects. Therefore, either Scrum or Kanban, high-quality software is a must and deeply rooted in our company culture.