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. It’s primary purpose is to address complex adaptive problems and productively 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. 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.

Scrum Basics

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

Speaking about Scrum Teams, there are three roles – a Product Owner, the Development Team, and a Scrum Master. 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 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 Dev Team. Moreover, his or her 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 Dev Team member to prepare something for you, you’ll be bounced back to the Product Owner, and this is entirely correct. The Development Team is allowed to act only on what its’ Product Owner says, and not anyone else.

With the Development Team, it seems to be quite straightforward. A team of 3-9 professionals develops a product by delivering potentially releasable Increments at the end of each Sprint. As a team, 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.

However, there are two more things worth noting. 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.

The majority of people find it most confusing that the Scrum Master doesn’t manage people but the process itself.

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 the others.

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 one or two-week cycles. Throughout the duration of 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 between a week and top a month, start with 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.

Abstract Scrum Workflow
Abstract Scrum Workflow

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, the 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. Either Scrum or Kanban, high quality software is a must, and deeply rooted in our company culture.

Like this article? Please rate it!

Author

Nashat Wanli | Chief Technical Officer

Nashat fills the role of the Chief Technology Officer at CodeCoda. Nashat, with his previous roles ranging from Software Engineer, Architect, over Project Manager to CTO at a top eCommerce company, brings with him nearly 25 years of valuable industry expertise. He is a self-motivated, highly skilled and capable person, that once added to a project provides value and key expertise.
His experience in the full range of software development works as an asset to our client's software developments, which he follows through with strong attention to detail and an innovative ambition that drives key changes.