Is Agile just Scrum?

Most of us are already familiar with Scrum and have a knowledge of Agile methods in general, so we know how they contrast with the more traditional methods such as the waterfall method or RUP. What is best for a specific context, agile methods or not, depends on many factors. If you believe that an agile approach is the most appropriate for your context, there are different variations to choose from.

Which should you choose and why? Far too many switch too quickly from Waterfall to Agile without much though forethought, even if perhaps the new approach is not the most practical for their circumstances.

It is obvious that things have not been well thought if someone started using Scrum without even knowing the alternatives that are available to them.

In this blog post, I will present some other agile methods and try to find out what makes them different from each other.

This is not an in-depth description of each method but rather an introduction to show just a few of the options available. Exactly which method fits your context best is impossible to say without knowing the precise needs that you have, what it is you do and who you are. But one thing is for sure – Agile is not just pure Scrum!

What do the agile methods have in common?

What’s common to all the different methods in general is that they all attempt to organize and control the system development process, which also applies to agile methods, in their own way. Even though the various agile methods differ slightly, they are all built on the same basic foundation which is recorded in the Agile Manifesto. Common to the agile methods is that they:

• are easily adaptable to change

• the goal is a working product

• they propagate continuous communication and interaction

In practical terms, this means that:

• By being adaptable to change, you have an open approach to emerging and / or changing requirements. It is simply assumed that the requirements will change and more can and will be added over time, and that it is only natural that this happens. When the changes come, the environment is positive instead of reminiscent of defeat.

• The goal of a working product, or the ‘qualitative aim’, means that agile methods emphasize that the product and the code itself should be of the highest importance compared to careful documentation when the end result is evaluated.

• Team members and stakeholders outside the team have to talk to each other on a regular basis. Developers, testers and other roles will need to meet with representatives from the business side but it is also true that team members thrive on continuous communication with each other!

Common agile methods besides from Scrum are DSDM (Dynamic Systems Development Method), XP  (eXtreme Programming) and Kanban. DSDM and XP were much more common a few years ago than they are today, but they remain popular in some contexts and referred to often, so it is worthwhile to include them in this walkthrough. Kanban has become much more common in recent years, so is also worth a mention in this blog post.

DSDM

DSDM is an approach that consists of three sequential phases with a total of seven steps. The approach begins with a “pre-project” to identify candidate projects, set budgets and ensure that there is agreement on what should be done. This is followed by a phase that includes a feasibility study, a study that focuses on business value (“business needs” in the terminology of DSDM), prototyping, design / development and an implementation phase. In particular the prototype and the development steps include steps that are iterated. The method ends with a “post-project” to ensure that the system is effective in production.

The purpose of the initial phases is to investigate who the stakeholders are, what their needs are and what the high-level requirements are. A technique that is used heavily in DSDM is the MoSCoW scale – prioritization of categories according to Must Have, Should Have, Could Have, and Won’t Have.

The project could in theory go through the different phases and then be closed. In the event that things do not run flawlessly, the project can go from some steps to others so as to repeat them.

Prototyping, which is heavily advocated within DSDM, helps all stakeholders to have a clear picture of all aspects of the system, how the system works, and that the design is good.

XP

eXtreme Programming (XP) is an iterative approach that lacks a separate requirements management phase. The work is distributed over the following steps (called the planning and feedback loop):

1. Release planning that covers months
2. Iteration planning that covers two weeks of work
3. Acceptance testing
4. Stand-up meetings for each single day
5. Pair negotiations
6. Unit testing
7. Pair programming
8. Regular code reviews

An important part is the feedback between steps so that the operation and the product gets better and better. The feedback happens almost all the time and it is direct.

XP is frequently combined with the development methodology Test Driven Development, TDD. In TDD developer first creates one, often automated, unit test, and then creates enough code to pass the test case. In this way, only what is really needed is being coded, and we know from an early stage that the code, since it has passed the test, meets the specified requirements.

XP is certainly an agile method, but it has a very clear programmer focus. This makes it a bit tricky as a method in situations when the team also includes other roles, as teams often do in reality. Many of the techniques that were developed within XP, such as pair programming and stand-up meetings, have today become common elements in most agile methodologies but also in many other contexts.

Kanban

In this context one should also mention Kanban, a method that is taken from Toyota’s Lean concept and then remodeled to a development process. Lean means that you should only work with the most important, and eliminate everything that is unnecessary, everything that does not somehow add value. This may involve deleting meetings that are not necessary or documentation that does not have an obvious advantage.

Kanban follows a continuous flow (as opposed to one with sprints), where you are always working with the most important but never with too much at once. It therefore has a fixed maximum number of activities to work with in one step. If the limit is reached, it means that you can not add more work to the step. In Kanban, the expectation is that all who that can help solve the bottleneck participate so that tasks can continue to flow through the process again.

Now you might think – “but Kanban’s not an agile method if it comes from Lean!” If the only difference between “traditional agile methods” and Kanban is that the latter does not advocate an approach divided into short iterations or sprints, I think the whole thing starts to look like a false dichotomy.

Occasionally you might hear the word Scrum-ban which stands for a version of Agile that makes use of the daily stand-up meetings and other useful information from the scrum, (for example the typical team roles) – but ignores iterations and instead uses a Kanban board.

What method or variant to choose?

What you quickly notice when you dig deeper into the subject is that there are many different methods – and the few that I have chosen to talk about here are merely scratching the surface. These methods are quite complicated to get into and they also are relatively similar to each other, which does not make things easier.

So what are the advantages and disadvantages of these methods, including Scrum?

In Scrum, the requirements are very agile, which of course is something that can be both good and bad. In some contexts, it may be worth to decide on some high-level requirements at a very early stage.

If your organization is interested in agile practices, but is then afraid that the requirements may suffer from it, it might be worth reading more about DSDM.

If the requirements are evolving, and / or constantly changing, Scrum might be better for you. Have you ever felt that the sprints are too long, too short, or why not both? Maybe then Kanban with an Agile mindset, or Scrum-ban, may be something to investigate!

Is the name of the method you use really so important? No, probably not.

Most likely you will not follow it to the letter anyway.

Take a look at the Agile Manifesto principles, as probably it is possible to put together something that works for your organization. Just be clear with your co-workers so that everyone follows the same approach.

 

Read more Articles on the subject of Agile, Lean and Scrum in the blog:

• You can’t work Agile without automated testing
• How to avoid runaway regression with Agile test automation
• Is the test leader needed in the Agile world?
• 7 Changes Scrum Made To The Tester’s Role – A guest post of mine on The Testing Planet
• Lean’ and requirements management and testing

 An edit of this article originally appeared on Konsultbolag1