In one of our previous articles, we explored the XP development process and how it moulded us into the company that we have become today.
But because every yin needs its yang, today, we’re taking a look at Scrum, an outstanding — and complementary — Agile framework with equal importance to our company.
What It Is
Essentially, Scrum is a product development strategy that aims to organise and coordinate development teams in a way that empowers them to deliver market-ready solutions, both quickly and efficiently.
Like an actual scrum in a game of rugby, in which players will literally join noggins, developers put their heads together to address a series of business problems.
A Brief History
As early as 1993, American developer Ken Schwaber made use of what eventually became known as Scrum, while Jeff Sutherland, another software engineer, worked on a similar approach at his own company. Later, in 1995, both developers formalised the first basic version of their process in a joint paper made public at the OOSPLA research conference in Texas.
In the years since then, Scrum was gradually improved upon by both Sutherland and Schwaber to reflect their combined experiences and evolving best practices. The Agile movement was officially started in early 2001, with the signing of the now-legendary Agile Manifesto, and Extreme Programming in particular spawned a wave of popularity that put Agile methodologies at the fore of public interest. This culminated in the release of Agile Software Development with Scrum, a 2001 book by Ken Schwaber and the late Mike Beedle.
As alluded to above, like Extreme Programming, Scrum is a part of the Agile development revolution, a pivotal time period when developers saw the importance of putting people and relationships before process and tools.
Consequently, it too is led by some very Agile values:
Scrum teams know well that first and foremost, they must focus on the issues at hand, without becoming swept away in other changeable peripheral concerns. As a result, they tend only to what they know now and what comes directly after.
As a highly empirical process, Scrum requires transparency. Accordingly, therefore, its team members are wholly open about their work, progress, learning and even problems, as above all, they are open to people and acknowledge their flawed humanity.
In Scrum, we also show respect for all individuals within and without the team, including their experience, personal backgrounds and diverging opinions, as we know that together, our differences can make us stronger.
Likewise, courage is also of crucial importance here, as we admit to ourselves that no teams or requirements will ever be made perfect; that even in the midst of chaos, transparency is the way to go; and that change may often be scary, but it’s just as oft-times a necessity.
And finally, Scrum teams are expected to display an unwavering sense of commitment. This should be clearly manifest in relation to the team, the quality of their products, the principle of constant learning, workplace professionalism, meeting tight deadlines and challenging the status quo.
How Scrum Works
To understand how Scrum is actually done, however, it is helpful to acquaint ourselves with the framework’s individual roles.
- The Scrum Team, as the name suggests, is the team of developers who are working together to deliver a product.
- The Scrum Master makes sure that the team follow Scrum rules. He or she also happens to be one of the players inside the Scrum team.
- The Product Owner is responsible for representing the customer. They prioritise the backlog — a list of implementable features — and coordinate the Scrum team. This role is similar to a project manager in traditional non-Agile environments.
But when it comes to development itself, its main distinguishing feature is the Sprint, or iteration. This is a two to three-week period in which development work is actually taking place.
The goal of every iteration is to deliver hand-picked requirements from the aforementioned product backlog in one perfectly tested, market-ready solution.
Each Sprint then ends with a Sprint review, after which another portion of the backlog is selected for the following iteration. This process is repeated again and again until either the deadline is reached or the budget is fully spent.
Other interesting aspects of the Scrum process include the daily Scrum, also known as the daily stand-up meeting — where team members come together to discuss what they accomplished the previous day, what they will do today and which obstacles are currently impeding progress — and the retrospective, in which everyone formally meets to determine the best ways to make future Sprints more efficient.
Scrum vs. XP
In spite of the Agile commonality, when it comes to their focus and reason for being, Scrum and XP are definitely worlds apart.
While Scrum includes a series of steps in its process, unlike XP, these are never technical in nature. Instead, in many ways, it is a fairly philosophical approach — so much so, in fact, that Scrum is not exclusive to software either! Because its main focus is productivity, it lends itself to a wide variety of businesses, including utility companies.
Extreme Programming, on the other hand, is a lot more focused on actual programming activities, and for this reason, prescribes a number of different practices like Pair Programming and Test-Driven Development.
Like Night and Day
Despite these day-night differences, both Scrum and XP are very much compatible with one another. Together, for instance, they embody the spirit of the Agile manifesto — aiming to support individuals and interactions, quickly respond to change and deliver fantastic products.
Nonetheless, this does not mean that they are perfect.
Although for now, Scrum is certainly the better option, in the future, this is very likely to change.