Jaco Viljoen, Principal Consultant

In a previous blog, ‘Agile: Mindset before methodology’, I made the point that agile is first and foremost a mindset, and should not be thought of as a methodology that can be followed—although, of course, there are many methodologies or techniques that have been developed to help put agile into practice.

One of these agile methodologies is scrum. It’s certainly the most common, and it’s typically the one that most people begin with. The trouble is that while scrum is a great place to start, it’s no more than that, but most teams think that implementing scrum equates to implementing agile. As a result, they are often disappointed with the results they achieve. These are people one hears saying things like, “We tried agile, but it didn’t work for us.”

Well, no; they tried scrum.

Let’s first understand what scrum is. It’s a framework that enables teams that do knowledge-based work to perform better. It was pioneered by software development teams, but is being used successfully in other areas; for example sales and executive teams. An innovative Dutch school is even using it to help pupils work together in teams more effectively.

In other words, scrum is all about making teams more productive. But, as you have doubtless guessed by now, it has nothing to do with what those teams actually do.

Thus, when teams implement scrum and then continue what they have been doing all along. They simply produce software with the same deficiencies—just faster. If scrum is applied on its own, the real effect is a reduction in quality.

Sadly, nearly three-quarters (74 percent) of agile implementations are actually no more than scrum or some variation of scrum, such as scrumban (Scrum and Kanban) or scrumXP (Scrum and Extreme Programming).

As noted above, scrum is an excellent first step, but once the development team is working more effectively as a team, the essential next step is to address quality. Agile’s approach to quality is quite different from the traditional, waterfall-style approach, in which quality assurance takes place at the end of the project—just when fixing bugs will be most expensive!

By contrast, agile works in short, quick, iterative projects (or sprints, in the jargon), each including testing. There is zero tolerance for bugs, which are fixed before the next sprint begins. Agile’s ultimate aim is actually to prevent defects from occurring in the first place, but this approach ensures that, if they occur, they are caught early on.

Agile tries to find ways of automating this frequent testing to improve its efficacy and speed.

In other words, scrum used in conjunction with the agile approach to quality will deliver higher quality software more quickly. Scrum on its own, will only deliver teams that are quicker at delivering the same quality they have always delivered.

Next time, a look at a new approach that aims to close the loop by extending the benefits of agile (better team work and higher quality software) into the operational sphere.