Scrum, Agile, and How to Develop Better Software

We’ve seen Scrum defined as a lightweight framework, an iterative development methodology, a project management strategy, and some other blends along the same lines. It gets even more confusing when you throw in Agile, another headline-worthy name.

Despite the buzzwordy ring of Scrum Agile, it is a well-established and widespread process used in software development. What’s more, due to its effectiveness and broad applicability, the Scrum Agile framework (or simply Scrum) has made its way into other domains outside software development, such as marketing, HR, and design.

 

Woah, Let’s Slow Down: What is Agile?

First things first: Scrum is a subdivision of the so-called Agile methodology.

The Agile methodology is an umbrella term for methods (or practices, or frameworks) used by software development teams. As the most popular of them all, Scrum tends to be used synonymously with Agile. However, it is only one of its subsets; there are many other Agile methodologies out there: Kanban, Disciplined Agile (DA), Feature-driven Development (FDD), Extreme Programming (XP), Crystal, and so on.

All of these methodologies focus on dividing the product development process into smaller builds. With agile development, you’re first putting out the simplest workable version of your application or software (or features of it) instead of straight-off aiming for the final, polished one.

The Agile development process is divided into the so-called sprints, which are continuous iterations (repetitions) of concurrent development phases (teams actively synchronize their work). The feedback given at the end of each development cycle becomes the driving force behind the next one. This happens until the product is deemed suitable for deployment.

 

Waterfall vs. Agile Methodologies (Including Scrum)

The Agile approach values adaptability, cooperation, and continuous feedback loops between stakeholders. Therefore, it differs from Waterfall development, which requires extensive research and detailed planning prior to the software developing process. Like the flow of a waterfall, each development phase follows the previous one in a linear manner. It goes more or less like this: requirement analysis – design – development – testing – deployment. Naturally, this kind of progression is more rigid, making it harder for teams to integrate unexpected, mid-development changes in product requirements.

 

But let’s put the Waterfall Methodology and the other Agile subsets aside for now. We’ll only take a look at Scrum, arguably the most popular Agile framework. Perhaps it has to do with how they borrowed the term from Rugby?

 

What Makes Scrum so Good?

As a subtype of Agile, Scrum is an iterative development method. But what exactly makes it the most widely used one? For one thing, it’s a quick-paced but remarkably flexible development methodology. Development teams use Scrum to sustain complex projects, in which mid-process changes are frequently expected. So how does it go?

With Scrum development, a product is built in a series of iterations, also called Sprints. Breaking down the product development work into small, manageable bits helps teams stay focused, synchronize, better structure their tasks, and see their efforts pay off early on. It’s widely acknowledged that sprints are overall great for teamwork.

 

As already mentioned, sprints are central to Agile methodologies in general; hence they make up the living core of Scrum. A scrum sprint may usually last between two weeks and a month. During this time, cross-functional teams (made up of software engineers, programmers, architects, QA analysts, testers, UX designers, and the like) work in parallel to deliver a certain function, feature, or even an early product version.

Teams then measure up results against pre-established requirements and then proceed with the next sprint. Let’s take a better look at this iterative process.

 

Scrum Process Basics:

 

PLANNING & BACKLOGS

Before embarking on a sprint, the goals of a given sprint are clearly set in a planning meeting. Important: this is not a brainstorming session. Sprint goals are pulled out from the existing Product Backlog. Wait, the product what…?

The Product Backlog is a list of basic and well-known requirements – at least in its inceptive form. Throughout the development process, someone called the Product Owner makes continuous amendments to the Backlog based on the team’s mid-process discoveries and other feedback loops between product stakeholders (a stakeholder is anyone directly or indirectly involved in the development process, including the client).

Thus, the backlog must be kept up-to-date, recording various events (user stories, use cases, features, upgrades, fixes, etc.) based on market and technology changes, fluctuating client demands, and other unpredictable circumstances. This is why it’s called a “live” artifact.

Now let’s go back to the sprint. First, teams pull items from the Product Backlog into the Sprint Backlog. The latter clarifies the tasks required from the development team to reach the goals of any given Sprint. Therefore, items in the Sprint Backlog are explicit, pre-planned development tasks divided between team members.

 

 

SPRINTS & INCREMENTS

Moving on. At the end of the very first sprint, you get one or more Increments – basically, an end product (like a working software feature) that is considered “done,” i.e., in a useable condition. Let’s see what the Official Scrum Guide has to say about increments:

 

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint.

The Official Scrum Guide

It’s a bit of a still explanation, but a product increment refers to the customer deliverables (Product Backlog items) produced (i.e., developed) within a sprint. Additionally, it adds up to the increments produced in previous sprints. Putting it simply, each sprint yields one or more increments, which cohesively add up until the product goal is eventually achieved.

Teams receive meaningful feedback in-between sprints on the increment they have produced. This is why the Scrum process can quickly accommodate change.

Frequent feedback is invaluable in Scrum and similar iterative methodologies. Here’s one example: each time the product owner releases a usable increment to the customer, this produces an immediate feedback loop. The customer’s response offers insights that modify the product vision (and, by extension, the product backlog as well as upcoming sprints).

 

Pocket-Sized Scrum Terminology

The Scrum process has its own concepts and practices that set it aside from other Agile methodologies. We can group those into Roles (3), Artifacts (3), and Time Boxes or Events (5) – amounting to a blasting total of 11. Let’s run through some pocket-sized definitions.

 

ROLES

Scrum Master: it sounds epic, and it is epic. In short, the Scrum Master ensures that Scrum teams follow the right processes and collaborates effectively to accomplish their goals.

Product Owner: a person that provides the product vision to the Scrum team while maintaining market and customer awareness. The Product Owner is also in charge of updating the product backlog according to feedback loops.

Development Team: these are the people getting tasks done during a Scrum sprint. They collaborate with the Product Owner to forecast how much work they can complete during each sprint. Additionally, they must be highly capable of re-organizing and improving their workflow as they progressively learn which practices work best.

 

ARTIFACTS

Product Backlog: an emergent, prioritized list of items needed to develop and improve a given product. It’s managed by the Product Owner.

Sprint Backlog: a highly transparent list containing the items to be delivered during a sprint. This task list belongs entirely to the development team.

Increment: what has been produced at the end of one or more sprints (a development period also known as a timebox).

 

EVENTS

The five events connect roles to the artifacts as to produce effective feedback loops. They are:

Sprint: a timebox (a fixed period of time) in which the scrum team delivers the Sprint goals. It shouldn’t last longer than one month.

Daily Scrum: development team members synchronize by discussing the tasks completed during the previous day. They also review what has to be done in the next 24 hours. Essentially, teams use daily scrum meetings to synch, monitor, and adapt their work to changing requirements.

Sprint Review: scrum teams and other product stakeholders review the work delivered until that moment (the increment) and how it integrates with the overall product or solution. The meeting outcome provides a feedback loop to the product backlog, sprint backlog, and decisions made during sprint planning.

The Retrospective: the team examines itself and identifies process improvements to be implemented with the following sprint.

 

Don’t Forget!

Phew, that was some introduction! The scrum methodology is as complex as it is useful, and mastering its processes is a skill in itself.

Here’s something to keep in mind regarding product (software) development in general. Each methodology has its pros and cons. None is inherently bad, and none is perfect. However, picking unsuitably can truly hinder your journey and the quality of your final product.

Before the commencement of a new project, you should measure up methodologies against the project’s particulars to figure out what might work best for it. But more on that in our next article, which plunges deeper into the wondrous world of Scrum.

Looking for a fun read until our next piece? Make sure to also check out our blog on Web design trends in 2021.