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

Tech Insights for Professionals

Tech Insights for ProfessionalsThe latest thought leadership for IT pros

Tuesday, October 1, 2019

What's the difference between Scrum and Kanban? Why aren't agile and Scrum interchangeable terms? This guide should help you decide which framework to use for which projects.

Article
  • Home
  • IT
  • Software
  • 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?

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.

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.

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.

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.

Don't be afraid to experiment

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.

There's also 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.

Comments

Join the conversation...

Back To The Top!