By now you’ve likely heard of Agile development and building products in small incremental pieces, so you can get real feedback along the way. In fact, you may even be considering using Agile on your team's next project. But where do you start? Agile can take a lot of forms, with Scrum or Kanban being two of the most popular. Each form has advantages and disadvantages, but both will help your employees get the right feedback they need to build great products.

So which one is right for your teams? Let’s find out.

Meet Scrum

Scrum is one of the most popular Agile methodologies in use today. We call Scrum a “process framework” because it describes a lightweight project management framework in which you can fit your daily development practices. In fact, Scrum doesn’t actually specify any development practices of its own, but rather leaves it up to you to add the practices that make the most sense for your team.

Teams using Scrum batch their work into fixed timeboxes called “sprints.” Sprints are commonly two weeks long, but can last anywhere from 1-4 weeks.

Where Scrum works well and where it doesn't

Because Scrum provides a turnkey project management framework, it can be a great first step for teams who want to try Agile but are unsure where to start. In addition, Scrum’s lightweight and flexible nature means you have a surprising amount of latitude to tweak the process to fit the unique qualities of your teams and organizational culture.

However, Scrum is not without its drawbacks. One drawback stems from the fact that Scrum discourages changing the team’s direction once a sprint has begun. This means teams have to wait at least two weeks before they can shift their focus and priorities. But, two weeks is magnitudes quicker than many non-Agile teams can respond, and this delay can be useful as a “cooling off” period before reacting to an unexpected event and redirecting the team. Many changes that seem critical the moment they happen seem less so after a good night’s sleep.

For product development teams who are working against a relatively stable release plan, a two-week delay before a change may not be an issue. However, for support or operations teams, whose priorities can change daily, two weeks is out of the question. For these types of teams, we need another option.

Meet Kanban

As simple as Scrum is, Kanban is even simpler. Kanban is a flow-based methodology which allows the constant reprioritization of upcoming work, allowing the team to respond to new changes much more quickly.

How Kanban differs from Scrum

Right away, you’ve probably spotted a few differences between Scrum and Kanban. For example, while Scrum attempts to group work into small batches with a regular cadence, Kanban attempts to achieve a more regular flow. As a result, because Kanban teams don’t work in regularly planned sprints, they are free to pull new work into progress as soon as it becomes available—provided they are limiting their work in progress by completing the work that was already in progress.

But more subtle differences also emerge from Kanban’s less prescriptive nature. For example, unlike with Scrum, Kanban teams don’t necessarily need to be cross-functional. It’s not uncommon for Kanban teams to be made of smaller, specialized teams, such as an engineering team, a testing team, and an operations team—each of which are responsible for different portions of the Kanban board. Also, unlike Scrum, Kanban doesn’t require stories to be estimated before a team begins works on them. Just because it’s not required doesn’t mean we don’t do it.

Just because Kanban doesn’t require as many practices as Scrum doesn’t mean that they’re not good ideas. Don’t confuse the lack of prescriptions with indicators that you shouldn’t follow these practices; instead understand that Kanban simply leaves it up to you to decide if it's right for you and your employees.

For example, although Kanban doesn’t explicitly prescribe daily stand-up meetings as part of its process, many teams still continue this practice after adopting Kanban. Why? Because they’ve proven to be useful and many teams still find value in them.

Where Kanban works well and where it doesn’t

The biggest advantage Kanban has is its simplicity, as it’s incredibly easy to understand and to get started with. Its flexible nature also makes it easy to integrate into existing processes that are looking for the lowest friction way possible to move into an agile workflow.

Kanban’s lack of prescribed sprints can also be a huge advantage if a team's priorities change rapidly. In these cases, Kanban allows a team to react quicker than Scrum would.

Interestingly enough, the same quality of Kanban that is its biggest advantage is also its biggest disadvantage. Kanban’ssimplicity and flexibility make it extremely prone to abuse, and the ability to change priorities at a moment’s notice can lead to thrashing on teams, and thus should be handled with care.  

In addition, while Scrum provides a turnkey project management framework in which you can insert your own engineering practices, Kanban is nearly blank slate from which to start. This can make getting started with Kanban challenging for teams who don’t already have a process in place or are unsure of where they’re going. Teams entirely new to Agile may not know where to start with Kanban.

Which is right for your teams?

Scrum can be a good fit if your teams are just transitioning to an Agile workflow, but would like some guidance on structuring the process so it's most effective—for example, how to break down releases or what roles should be on each team.

Scrum works very well for teams focused on new product development; though priorities can still change quickly, it’s unusual for them to change on a daily basis. The 1-4 week sprint length of Scrum tends to be more than enough for the team to respond as needed to priority changes.  Plus, the regular cadence of sprint planning and review makes it easier for organizations that still want to do some level of future planning, even if it’s only to better define upcoming releases.

On the other hand, Kanban may be good if your teams find priorities are changing more rapidly than the duration of a normal sprint. Kanban allows for flexibility to respond to these changes more quickly than with Scrum.

Kanban is also a good choice if your teams already have a mature, highly functioning process that would create friction if melded with Scrum. If your teams are already functioning well with their own processes but you’re simply looking for a new way to handle your workflow, then Kanban may be worth a look.

Finding what works for you

Agile takes a lot of forms, and Scrum and Kanban are only two. But regardless of which Agile form a team starts with, few stay with a “pure Scrum” or “pure Kanban” approach.  Instead, teams tend to bring elements from other Agile methods into their starting methodology to create a method that works best for their culture and organization.

Think of it like this, which is the better tool: a hammer or screwdriver?  There isn’t one single answer; the right answer depends on your situation and what you’re trying to accomplish.  In some cases a hammer works better, in others a screwdriver. For some larger projects, you may need both.  

Agile works the same way. Instead of choosing one method and striving to work only within it, educate yourself on all the options and then create the process that works the best for you and your employees.

Give your teams the skills to work smarter.