Staying Agile – Part 1/4
9 min read
9 min read
by Aleksandra Stamatović
I’ll take an educated guess and say you have an idea of how a building is constructed. You don’t need to know the details, but we need a high-level overview. It comes down to a long series of stages. First, we have an architect making a plan. At some point, construction workers start laying the foundation, then building the frame, and the sequence goes on and on until there’s a rough over the building and tenants start moving in. The process is a lot more complex than these few lines, but you get the picture – The roof can’t be worked on unless everything underneath it hasn’t been built already. This is an approach known as Waterfall, where one stage can’t begin unless the previous one has been led to completion.
In some environments, such as construction work, Waterfall checks all the boxes. But in software development, there’s a greater need for agility. A piece of software is a project that’s rarely truly finished. Even after the official release, there are individual features and updates that you have to roll out constantly.
Agile startups work in small teams, each in charge of delivering iterations and being quick on their feet. They rarely wait ten months to develop and release an all-inclusive piece of software. Instead, they release a minimum viable product and then listen closely to the users and the market to improve it feature-by-feature along the way.
That’s why Agile is a term everyone is familiar with in the software development world. And, thanks to its nimbleness and adaptability, it works outside the software development, too.
Our development team relies on the Agile mindset and SCRUM framework. Still, the exciting part is that we have also successfully implemented the SCRUM approach into our XaaS teams. This is why we have decided to launch a 4-part article series sharing our journey, which may encourage you to try it in your organization.
Here’s the layout of the article series:
In the first part, we’ll tell you about SCRUM and its body parts. Then, we will describe to you our journey. In the third part of the series, we will discuss ways to use SCRUM and how to make it work in your organization. And lastly, we’ll wrap it up with examples of how Google, Apple, Spotify, and other big players do it.
We often hear people misusing the two terms, so it’s essential to define what Agile and Scrum are before we launch ourselves into a deeper dive on the matter here.
Naturally, we’ll start with Agile. The reason why I said “Naturally,[…]” is simple. Agile is used to describe diverse approaches to software development. The term came about in 2001 as part of the Agile Manifesto. This term focuses on delivery based on increments, team collaboration, continuous planning, and continuous learning.
According to the 14th State of Agile Report, Scrum is the most popular Agile framework used in the development of complex products and systems. The term derives from the game of rugby, where scrum (short for scrummage) is a method of restarting play in rugby football that involves players packing closely together with their heads down. Just as one would in a rugby team, in Scrum, teammates work together as one. They learn through experience, self-organize, and reflect on their losses and their successes to continuously improve.
Agile is more of a mindset and a set of principles based on the Agile Manifesto. Several different frameworks are utilized to implement the Agile philosophy, and Scrum is one of the process-based frameworks implementing Agile principles.
Now that we have laid the ground with some basics, it’s time to dive deeper into the world of Scrum!
As we’ve mentioned, Scrum is a framework within which people can work on complex problems while delivering products (or services) of the highest possible value.
Scrum is a reasonably lightweight framework, and in its essence, it is far away from being complex. Scrum is indeed the opposite of an extensive collection of interwoven mandatory components.
The idea behind Scrum is to replace a programmed, algorithmic approach with one that’s heuristic. It is supposed to nourish respect for people and rely on self-organization to deal with the resolution of complex problems, covered with a veil of unpredictability.
Here you can see a graphic representation of Scrum in Action, as described by Ken Schwaber and Jeff Sutherland, the authors of Scrum, in their book Software in 30 Days depicting the process starting from the planning stage through the delivery.
In Scrum, teams are intentionally small. And the fundamental unit of Scrum is a team where every individual has a distinct role. For example, the Scrum Team consists of one Scrum Master, Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. Instead, it is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Aside from specific team roles, Scrum is based on particular events, artifacts, and values. So let’s take a closer look at those!
The idea behind these events is to nurture regularity and iteration and decrease the need for meetings that are not defined in Scrum. The events are also “time-boxed,” meaning that once a Sprint begins, its duration is fixed, and it cannot be made shorter as much as it cannot be made longer.
The Scrum Events are Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Sprints are the heartbeat of a Scrum. They are the means of turning ideas into value. Every Sprint has a fixed length, and when one sprint comes to an end, the other begins. All the events we laid out above happen within one sprint.
Sprint Planning can be seen as a ceremony of initiating a Sprint. During this event, the team is laying out the work that has to be completed during the Sprint.
Daily Scrum is an event that takes place daily, and its purpose is to check in on the progress toward the Sprint Goal and make any adjustments on the go to ensure successful sprint completion. Daily Scrum, often called a Daily Standup, is a brief meeting with a specific plan to ensure time efficiency and reduce complexity.
Sprint Review aims to inspect the outcome for the Sprint and determine future adjustments. This is where the team presents the results of their work to key stakeholders and discusses the next steps. The Sprint Review is the second-to-last event in a Sprint, and it usually results in a revised Product Backlog and items the team will use in the next Sprint.
Sprint Retrospective can be seen as a closure ceremony of a Sprint. This is where the team sits down and analyzes the learnings from this specific sprint. In addition, it is the time for them to reflect on successful practices they want to keep and those they wish to avoid moving forward.
Scrum’s artifacts exist, so there’s transparency and opportunity for analysis and adaptation. The artifacts are there specifically to maximize visibility into crucial information so that everyone in the team is on the same page.
The Scrum Artifacts are Product Backlog, Sprint Backlog, and Increment.
The Product Backlog is a list with a specific order in which something needs to be done so that the product is improved. The items in the Product Backlog that can be completed within one Sprint are usually deemed ready to be selected in a Sprint Planning event. In addition, items from the Product Backlog can be refined and broken down to further define them into smaller, more specific items where details, such as description, sizing, and time estimation, can be determined.
The Sprint Backlog is a document laying out the Sprint Goal and the set of Product Backlog items the team has selected for the ongoing sprint. In a sense, it’s a document showing a WHY (Sprint Goal), a WHAT (Product Backlog Items), and a HOW (an actionable delivery plan). The Sprint Backlog provides the team real-time insight into the work to reach the Sprint Goal.
And last but not least, there’s Increment – a concrete step toward reaching the Product Goal. A Sprint can result in the creation of one or several Increments, depending on the plan. The sum of Increments is then presented to the stakeholders during the Sprint Review event, but it can also be delivered to them before the end of the Sprint, whenever deemed ready to release by the team. There are specific requirements work has to meet to be considered part of an Increment. These requirements are known as the Definition of Done, which formally describes a state of the Increment when it aligns with the quality measures required for the product. This means that when an item from a Product Backlog meets the Definition of Done, an Increment is created.
Scrum Values were officially added to the Scrum Guide in July 2016. Still, they have always been part of Scrum and are often written about.
These values include Courage, Focus, Commitment, Respect, and Openness. A poster created by Scrum.org describes them all:
There’s value in implementing Scrum into your organization. It’s a bundle of processes to reduce complexity and maximize the quality of products and services an organization can provide. In addition, teams love Scrum for its simplicity and adaptability.
At Aryxe, we started using Scrum as part of our Software Development team long ago. However, the most exciting adventure was when we decided to implement it in other non-software development departments. So we could tailor it to our own needs and see it take shape in teams such as Digital Marketing, Social Media Marketing, Content Marketing, and Graphic Design.
In the next part of our Staying Agile series, we will share our journey and our teams’ thoughts on this transition, so stay tuned!
Resources:
