Agile Scrum

If you work in the business world for long enough, chances are you’ll see a high-profile project unravel in front of your eyes.

Maybe you have caught sight of big project failures making the news headlines, even if you weren’t aware of it:

“$100 million over budget!”

“Estimated to be running three years behind schedule!”

What is it that separates a project disaster from a success? It turns out that the development industry might have some answers to that question.

Agile Scrum methodology has grown in stature and is no longer the buzzword that many people took it for when it first came on the scene.

In this article, we’ll explain exactly what Agile Scrum is, and help you to understand the benefits it offers.

But first, some history.

Like most innovations, Agile was borne out of frustration for everything that was wrong with the status quo.

From the 1970s through to the 1990s and beyond, most historical software developments took their build approach from physical engineering. If bright minds could build bridges and buildings, what challenge was a small piece of software?

Sadly, software development inherited a reputation that it struggled to shake off: projects running horrendously late; untested releases; and overworked, overstressed development teams working away to meet impossible deadlines.

Like all great engineers, the software community took a step back, assessed the situation, and came to the conclusion that this method for building software wasn’t working.

The traditional approach to software development was linear, also termed the “Waterfall” method.

A design team or customer would outline a set of requirements for the software. The project stakeholders would sign off on those requirements, and build work would begin.

Once a complete product was ready, a separate team would begin testing the software. Eventually, the development team would have a big set of issues and bugs returned to them to work through.

Though this model was a great fit for physical engineering that needed that end-to-end structure, in software it became a problem.

Debugging issues often caused a new set of problems to emerge and another round of testing.

Worse still, it was common for the stakeholders to ask for changes mid-way through the development or after testing, which often brought with it new issues and delays.

In 2000, a group of leading software developers met to brainstorm ways they could improve the development process and speed up software releases.

They challenged the notion of whether software development had to be linear.

Agile software methodology was the answer to emerge from that summit. A core principle of this new approach was to switch from top-down, linear, and stakeholder-led projects to a method that was collaborative, iterative, and results-driven.

Scrum is part of the Agile family, but Scrum is a specific technique and framework that operates within the principles set out by the Agile method.

Agile Scrum is about developing rapidly and delivering early.

Typically, a development team will look at a set of requirements for a product, known as the Product Backlog, and select a small subset of the most high-value features to begin working on.

This work will become the minimum viable product, which will be a stripped-down but fully working version of the product. It forms the first release for the development team.

Scrum has very unique terminology, and the time between starting the first bit of development and the first release is known as a Sprint.

Sprints are very different from a typical project plan that uses the Waterfall method. Sprints always follow a strict and uniform timeframe. The most common time frame is one month.

During the Sprint, the development team will work on that first release. This release is a testable and usable version of the end product, but with only a subset of the full features that appear in the product backlog.

The work during this period follows strict rules. Stakeholders cannot introduce changes, and no stakeholder reviews take place until the Sprint is over.

Sprints also follow a very specific structure. The development team uses a Sprint Planning Meeting to decide on the work they need to do to meet that Sprint (known as the Sprint Backlog). Unlike traditional methods, this is a collective effort by the team.

Once a Sprint comes to an end, two activities take place: a Sprint Retrospective and a Sprint Review.

The Sprint Retrospective is a chance for the development team to get together and review their work. It is also an opportunity for the team to work together to brainstorm improvements for future Sprints.

This goes back to the core principles of Agile: working collaboratively and working iteratively. There are no big surprises or major crisis points; the work delivered is exactly the work outlined during the Sprint Planning at the start of the month.

The Sprint Review is slightly different, as this is a review of the product together with the major product stakeholder. It’s a chance to look closely at the product and the overall progress of the Scrum project.

At the end of the first Sprint, the team should be able to showcase a viable product that is working and contains some high-value features. However, this is far from a finished product.

At this point, the team will repeat the Sprint, and follow the same specific structure. First, they will use the Sprint Planning meeting to decide on what work they will need to do to release the next (bigger, more feature-rich) version of the product.

The team repeats these sprints until they have completed the final product and released it to the customer or stakeholder.

If the team releases the product in increments after intense bursts of work, at what point does the software get tested?

The answer is that testing happens continuously and in parallel to the development work. The testing team is a core part of the Scrum team and they will feedback issues to the developers as they find them.

Two well-known features of Scrum often sound alien to outsiders but are highly effective components of the framework.

The first is the Scrum Master. Unlike traditional managerial roles within project environments, a Scrum Master is best described as a coach.

They monitor the progress of the Sprints to check how quickly the team is ticking items off the Sprint Backlog, but in terms of their relationship with the team, they are predominantly there to support and lead, rather than to manage.

The second notable feature is the Daily Scrum. This is a strict 15-minute meeting between the development team where each member talks through what they have done and any problems holding them back.

When compared to a more traditional linear model, it is easy to see how the flexible, fast, and iterative framework of Agile got its name. Here are some of the key benefits of using Agile Scrum for a website or mobile app development:

Businesses around the world have adopted Scrum because it has proven to be a faster method of getting a complete, tested, and fully working product to market.

The iterative approach means issues and bugs are discovered far earlier in the development and addressed before the software gets too big and complex to fix.

One of the main reasons corporations love Scrum is that they get a useable product far earlier in the lifecycle of software development. This is great for businesses who invest in software and want a quick return on their investment.

This is one of the key reasons why Scrum emphasizes delivering high-value features early on, so that end users can begin to get the benefits straight away, whilst the team continues with smaller and less urgent features.

It’s easy to walk down the wrong path and keep on going, especially if you don’t look up and see what is around you. This is true for software development too.

When Agile was outlined at the turn of this century, the architects emphasized creating developer communities who could continuously strive for improvements in their work, their development methods, and product quality.

Each Sprint Retrospective allows the team to do this. In development, there are always smarter and better ways of working. Innovations are waiting to happen and Scrum allows the team to discover these along the way.

The collaborative aspect of Scrum allows development teams and customers to feel connected. Teams take ownership of the work during the planning stages. They set the priorities and decide on the pace of the development.

This close working relationship that emphasizes strong teamwork to complete a Sprint goal helps a team relationship blossom.

Teams also have a high amount of accountability in Scrum development. Many of the features of Scrum, such as the Daily Scrum and Sprint Retrospective, empower team members to review their work, find flaws and focus on improvements.

Technology is fast-paced, highly competitive, and rapidly changing. For industries working in the fields of software, apps, or the web, the ability to keep up with this speed is essential.

Scrum is the perfect fit for this type of rapid development environment. A new business with an innovative product can get their website or app to market quickly and start growing a user base, even while much of the development is still taking place.

In a traditional project, change to software is costly and time-consuming. It often arrives late in the project, sometimes after the full end product has been tested, and the alterations can cause a string of unintended consequences.

Though Scrum does not invite change from the Stakeholder within a Sprint, it is possible to make changes to the product between Sprints, and this is a useful benefit when it comes to pivoting with a product once it has been released into the market.

Timescales in Scrum are far easier to predict, due to the fixed length of each Sprint. It avoids the sense of lateness and failure that often happens with a traditional project when it becomes large, complex, and months overdue.

Instead of an ever-expanding workload and impending deadline, Sprint Planning meetings take a snapshot of part of the product and fit a realistic delivery within a single month.

Scrum may have started life as the innovation of the development community, but many industries around the world have started to recognize the benefits of this framework for their projects.

Industries that currently use Scrum include:

As Agile Scrum becomes more widely known and more professionals are trained in the framework, this methodology could be adopted by an ever-growing, wide-ranging list of industries in the future.

The Agile Scrum framework is a big step forward for many organizations. Whilst it is a cultural shift the first time a business adopts the method, the ability to get a new website or app launched quickly and successful is an attractive proposition.

We adopted the Agile framework at EB Pearls because we recognized how well it could support our clients’ goals.

If you are looking to build an app or website, contact our team and let’s have a chat about how our approach can help you successfully launch your website or mobile app.