Agile vs Scrum vs Kanban: Which Should You Use and When?

Agile development has become one of the biggest trends of IT teams in recent years. Although the techniques used within this can be applied to a wide variety of projects for any business, it has proven to be especially useful to IT departments, and software development projects in particular.

But 'agile' is often a vaguely defined term, and within this there are a range of frameworks and methodologies that can be applied, each of which have their own strengths and weaknesses, so even once you've decided to adopt an agile way of working, there are still decisions to be made about how to implement this.

Two of the most popular agile frameworks for software development are Scrum and Kanban. But these have very different approaches to the concept and may not be equally suited to every project.

So what do you need to know about the advantages of each, and what are the right projects to apply them to?

1. Agile
   • What is it?
   • What are the advantages?
   • What are the challenges?
   • When should I use it?
2. Scrum
   • What is it?
   • What are the advantages?
   • What are the challenges?
   • When should I use it?
3. Kanban
   • What is it?
   • What are the advantages?
   • What are the challenges?
   • When should I use it?
4. Why combining Scrum and Kanban methodologies is the way forward

Agile

What is it?

Agile is an umbrella term for a variety of methods that differ from traditional waterfall development processes, of which the likes of Scrum and Kanban are specific frameworks. But what they all have in common is that they promote iterative development strategies that break projects down into a series of smaller activities. This allows work to be carried out more flexibly, and teams to respond quickly to any changing requirements.

What are the advantages?

Adopting an agile strategy promises to offer a range of benefits to businesses. For instance, Collabnet VersionOne's 13th annual State of Agile report revealed the number one reason for going down this route was to accelerate the delivery of software, named by almost three-quarters of respondents (74%).

This was followed by:

• Improved ability to manage shifting priorities (62%)
• Increased productivity (52%)
• Improved alignment between business units and IT departments (51%)

However, the potential for reducing costs is also an increasingly big driver. The number of firms citing this as a factor rose by 71% compared with the previous year, while the potential of agile to improve the morale of development teams was another factor where there was a significant increase in interest.

What are the challenges?

While Agile management offers flexibility and the potential for continuous improvement, it can lead to missed deadlines with the final product if not overseen properly. When executives buy into the concept of agile, they must ensure its ways of working trickle down to the teams putting the project into action.

Otherwise, there can be a disconnect between the expectations from above and the reality of everyday working without the necessary resources for success. It can result in teams being expected to produce work more quickly and cheaply using non-Agile methods that haven’t been updated in the new system.

When should I use it?

Waterfall approaches are structured around long development cycles and distinct development phases. If you're building a new application from scratch and have a sufficiently long lead-in time, this may work fine. It offers clarity and structure, and allows teams to set specific requirements and work towards meeting them.

But in the real world, this is now rarely the case. Agile should be used whenever the IT department has to balance competing demands from business units to deliver results quickly and cost-effectively without compromising on quality. Given most IT departments are almost always under pressure to work leaner and smarter, there are few IT projects that won't benefit from an agile approach.

Any software project that doesn't have a clear, tangible goal in mind from the outset, or is liable to be swept up in the changing whims of business units, is a good candidate for an agile approach.

Scrum

What is it?

The Scrum framework is often used interchangeably with agile, but it’s a specific subset of agile with its own methods and quirks. Key factors that separate Scrum from general agile processes include the 'sprint' format, which is a compressed cycle of work, with every cycle producing working software at the end. It calls for constant feedback from customers/end users, and is done with the oversight of a Scrum Master.

What are the advantages?

Scrum is the most popular form of agile development, with Collabnet VersionOne's report finding more than half of projects (54%) use this methodology. The fast development cycles - a typical sprint usually lasts no more than two weeks - coupled with daily meetings to review progress, means ideas can be implemented and tested quickly.

It also maximizes the amount of time devoted to development work rather than planning. If a firm has a new idea for a feature, or wants to change how an application works, they can quickly implement and test any new additions, learn what works, and roll back any changes that don't work.

Scrum has a focus on constant communication, so there’s no excuse for anyone not knowing the status of the current project or what the latest updates are. This should extend not only to the dev team, but every stakeholder, from business units to customers, with the Scrum Master acting as the facilitator through which all instructions and discussions are passed.

Having product owners and project managers deeply involved in the process means everyone should be clear on the goals, and all members of the Scrum team will have clearly defined roles that ensure everyone plays to their strengths and promotes greater collaboration.

What are the challenges?

Despite Scrum being the most common way of implementing Agile working, there are a number of issues associated with this prescriptive methodology. In fact, one of its biggest selling points can also be a significant drawback. Breaking large tasks into smaller chunks can mean they become poorly defined and employees lose direction or find themselves overlapping with other work being carried out.

Scrum methodologies are not flexible by design and tasks should be finished at the end of each sprint. These sprints are set for a predetermined amount of time - anything from between one and four weeks, but most typically two - meaning any changes must be implemented at the end of the sprint.

Scrum can be a hard framework to adopt and requires careful implementation from the start. It’s vital that 15-minute standups don’t become hour-long discussions and that multiple meetings don’t affect productivity.

Sprint retrospectives can easily result in the mood of the team dropping, especially if they’re seen as standing in the way of goals being achieved. Without solid implementation, Scrum can in practice become an empty shell instead of a cohesive way of working.

When should I use it?

Scrum is particularly well-suited to software development processes where there’s a strong need to add new products or features and deliver them quickly. Under traditional waterfall methods for these tasks, work might be divided into chunks that can be subject to missing deadlines or feature creep.

But with Scrum, each sprint will be the same predetermined length - there's no extending them if it appears activities are taking longer than expected. This makes it good for planning and measuring progress, as it's easy to see if you're on target. However, you do need to be careful that when you're breaking down tasks into smaller chunks for these sprints, you keep the goals for each iteration well-defined, and don't change requirements mid-sprint.

If you have a complex project with vague requirements that needs to be streamlined, Scrum's clearly-defined framework and fixed progress reviews help you maintain control of every aspect of the development. If there’s a high probability that changes will be required during the development process, Scrum often offers the best solutions for managing these shifting requirements without disruption.

Kanban

What is it?

An increasingly popular option, Kanban offers a number of key differences from Scrum. Designed by an engineer at Toyota to improve efficiency, it was originally created to facilitate just-in-time manufacturing strategies, but has proven highly useful for software development as well. It's based around workflows and scheduling, with the central focus being a board that visualizes the project's workflow and shows what stage of the process every individual task is at, with each distinct task having its own card.

What are the advantages?

A key feature of Kanban is its ability to view at a glance the status of the entire project and see what has been completed, what's currently in progress, and what elements have yet to start.

It encourages teams to limit the number of tasks that are taking place simultaneously and move elements from ideation to completion swiftly. Teams should place a set limit on the number of cards that are under the 'in progress' column at any one time, which prevents overload and helps developers focus on key areas to be prioritized. This maintains a clear workflow, as each card on the board is assigned a priority, and when one card moves from in progress to complete, the next highest-priority task on the list gets moved forward.

Kanban emphasizes the importance of continuous delivery and improvement. By meeting periodically - though not necessarily on the same fixed schedule as with Scrum - teams can identify any obstacles that are holding up processes and discuss what changes need to be made, which should then be reflected on the Kanban board. This should ensure that activities are always aiming to be as streamlined as possible, but adjustments are made gradually without any sudden major shifts in how projects work.

What are the challenges?

With the Kanban board being at the heart of this methodology, there’s a risk that mishandling it could lead to wider issues. Relying on an outdated board or one that has become too convoluted can cause confusion for the team, inaccuracies in product development or miscommunication between employees.

Every member of the team must be committed to keeping the board up to date, otherwise it will quickly descend into chaos. Tasks based on inaccurate information don’t just waste time, but require extra resources to fix and can be negative for morale.

Conversely, some team members can be so enthusiastic about updating the board it becomes too busy. Clear, simple and easy-to-read boards are the most effective.

Another common complaint about Kanban is the lack of solid timeframes to stick to. While all of the columns on the board are given a phase, there’s nothing to define how long these elements will take, which can make it difficult to establish a timeline.

When should I use it?

Because of its focus on workflows and throughput, Kanban is often the best solution for projects that are likely to involve large numbers of relatively small activities, that may crop up on a more ad-hoc basis. So if work is supply-based, such as fixing issues or bugs in existing production software, Kanban is often the best option.

Projects where there’s no big backlog of work to tackle, that include discrete tasks and the long-term goal is ill-defined or has no clear definition of 'complete' may all benefit from a Kanban approach.

Roles for team members are less rigid than with Scrum, with no individual taking responsibility for any stage of the project development or being accountable for the team's performance. Instead, the team works collectively, with tasks being assigned as appropriate and recorded on the board. Therefore, it's ideal if you don't know exactly what tasks you'll be faced with.

Why combining Scrum and Kanban methodologies is the way forward

While Scrum and Kanban are the best-known and most widely-used methods of Agile, they're far from the only frameworks out there. Extreme Programming, Crystal and Feature-driven Development are some of the other options that you may wish to consider for your projects.

But what if you could take the most useful aspects of Scrum and Kanban to create a methodology that really worked for your needs? Enter Scrumban, a way of cherry-picking the techniques that will get you results without so many drawbacks.

If you’re already working with Scrum, then tweaking your practices and introducing elements of Kanban should be relatively straightforward. You may even reach the point where time-boxed events are no longer required.

Adopting scrumban allows development teams to achieve the flexibility to adapt to requirements brought in by stakeholders and other production points without disruption. At the same time it brings all the benefits of working under an agile framework.

There's nothing to stop you taking a hybrid approach, or experimenting with multiple frameworks. It's well worth taking the time to investigate all options to find one that's particularly suited to your way of working and company culture. And of course, whatever framework you choose, it’ll only be effective if you stick to it, so discipline is vital regardless of the approach you take.