How do you choose between Scrum and Kanban?

Deciding between the two agile approaches can be tricky unless you know what works best in your circumstance.

As more and more people adopt an agile approach to managing their projects, they have to become better acquainted with what’s available in the market, what’s trending and more importantly, what will serve their needs and requirements best. Stephanie Tanner, who has been at Rally Software, for the last four years, transitioned from software engineering, to user experience and is now with the product team.


Stephanie Tanner









When she first started, Rally was switching over from full-on Scrum to Kanban. Having gone through both approaches, Stephanie talks about her experiences, highlights key differences between the two approaches and shares a few great tips.

How would you describe Scrum and Kanban and the environments to which they are best suited?

Stephanie : Many teams switch over from waterfall to agile in order to deliver value faster in the market. When making this decision, they’ll generally decide between Scrum and Kanban. There are benefits to both approaches: Kanban is good for teams that constantly have their priorities switched on them.  For example, Operations and Support teams have a hard time predicting what will be the most valuable work item to tackle in a week. There might be a production outage or an important defect that the team might need to swarm on. Teams like this usually adopt Kanban for their development process.

A team should not move to Kanban until they are very advanced and capable at Scrum, and even then, they might choose to avoid it.

Scrum is extremely good for beginning agile teams.  When a new team forms, or when a team is moving from traditional waterfall to agile, scrum is best suited because it inherently requires more discipline around timeboxes, planning and retroing.  If a team’s priorities don’t constantly shift, Scrum’s two week iterations provide predictability and transparency and clear timelines for getting features into market.  A team should not move to Kanban until they are very advanced and capable at Scrum, and even then, they might choose to avoid it.  Whether a team chooses Kanban or Scrum, they must continuously improve and adapt their processes to continue to be successful.

Scrum is seen by some to be a pretty prescriptive method. Would you say the same of Kanban?

Stephanie : Kanban is not as prescriptive as traditional Scrum, but I would argue that teams who are successful with Kanban tend to create as many rules and processes around Kanban.  A Kanban team should be constantly looking at improving their efficiency.  Are WIP limits accurate? Do we need to adjust them?  Is our backlog in priority order?  Are items being sized correctly? Are they all roughly the same size?  If a team is not focusing on these questions on a daily or weekly basis, they aren’t correctly practising Kanban.

Until recently, Rally’s engineering teams were mainly Kanban.  We focused on keeping our WIP low, we broke items down when we saw they were getting too big, and we planned weekly to fill up our ready-to-pull queue.  But we were not delivering value to the market quickly enough.  We had to put more rules in place and half our teams moved to Scrum while the other half stayed with Kanban. The Kanban teams still have to demo at the end of two weeks, and they have to roughly place stories into iterations so that the business can figure out when features will get to our customers. We became more rigorous with our Kanban process in order to be more transparent to our stakeholders.  New teams should follow these processes by the book.

However, as teams get better and better at the basics of Scrum and Kanban, they can afford to lighten up on the rules and start experimenting with processes that better fit the team.

Are you aware whether agile teams typically mix and match ie Scrum teams employ some Kanban practices and vice versa? Is this a good practice?

Stephanie : Whether it’s scrumban, waterscrumfall, Kanban or Scrum, it’s very common to create a process that best suits the needs for your team and your company. Waterscrumfall is a bad practice of sneakily fitting in your traditional waterfall workflows into two-week timeboxes.

Scrumban is customising your team’s workflow and maybe adding some discipline around WIP, but ensuring you plan every two weeks and every quarter.  Scrumban is probably the best of both worlds; it gives you the flexibility to mould and update your process to best fit your team.

At an organisational level, it’s okay to have some Kanban teams and some Scrum teams.  If your company has a hybrid process, there should still be some level of consistency for every team.

You don’t want to get into a situation where every team has such wildly different practices that there’s no way to track the overall status of a program or a release.  At Rally, the Kanban teams still slot work into iterations during release planning, but they break things down to be equal sizes and use counts instead of estimation.  The business cares about knowing what’s getting to our customers every two weeks.  We aren’t as concerned about story sizing. Let teams decide what process works best for them, but put in guardrails to ensure the success of your programme.

When those new to taking an agile approach are making a decision between either Scrum or Kanban, what advice can you give them about the factors they need to consider?

Stephanie : If a team is truly new to agile, I would always recommend starting with Scrum.  Scrum provides a little more guidance and discipline on how to manage and track work.  Two week iterations are pretty standard because it’s just short enough to push development teams to improve their automated testing, their deployments, and other important engineering practices.  Scrum’s prescribed estimation practices get a team used to communication and conversation around expectations on a story’s size, something a lot of waterfall teams never think about.

However, once a team understands the ‘why’ behind the scrum-level ceremonies, (why we plan every two weeks, why we estimate, etc.), Kanban is a great methodology to try.  Try focusing on keeping WIP limits low and sizing everything similarly. As long as a team can be predictable and transparent, Kanban can be successful.

Each approach has its advantages and constraints. What would you say are three of the advantages of going the Kanban route?

Stephanie :

  1. Kanban is more light-weight than Scrum. There’s more frequent but less taxing planning.  Teams plan weekly to fill up their ready-to-pull queue, and no more. This allows teams to focus on a week’s worth of work at a time instead of two weeks.
  2. Kanban focuses on improving flow and removing bottlenecks. Items are sized to the smallest amount a team can take on so that it flows through the development cycle quickly.  A lot of research has been done around how to improve efficiency, and if everything is the same size, the work flows much faster.
  3. Kanban focuses on continuous delivery.  When you have a two week timebox, you generally release every two weeks.  When you have a Kanban process, there’s a lot more focus on delivering continuously.  Maybe you’ll finally get to a point where you’re delivering once a day or even once an hour.

What are three advantages of using Scrum instead?

Stephanie :

  1. There’s more discipline and rigour around ceremonies.  When a team is just learning about agile, it helps to have more focus on when to demo, when to retro and when to plan.
  2. Scrum offers better transparency between engineering and business.   Because Scrum teams plan on a quarterly cadence and again every two weeks, it’s very easy to communicate to the business what’s going to make it for the quarter and what’s not. Furthermore, with two week iteration planning, it’s much easier to steer a team if an important defect or a high priority customer request comes up. Yes, you can do that with Kanban, but with Scrum, you’re less likely to completely run over quarterly team commitments.
  3. Scrum provides teams with a sustainable pace for long-term development.  With five  two-week iterations and an ‘ip’ iteration, a team can get used to a rhythm. IP stands for innovation and planning in the Scaled Agile Framework. There’s always some breathing room at the end of a release.

Can you name one particular limitation of Kanban and how you have addressed this when applying Kanban?

Stephanie : I’ve seen some organisations struggle with the implementation of Kanban. Specifically, if Kanban is adopted by a development team, the first thing to go is often predictability and transparency with the business.  When Rally adopted Kanban, we also removed ‘commitments’.

However, once a team understands the ‘why’ behind the scrum-level ceremonies, (why we plan every two weeks, why we estimate, etc.), Kanban is a great methodology to try.

This impacted how and when our sales teams and customers would learn about new features out to market. We fixed this by re-introducing quarterly planning or ‘big room planning’.  This was an opportunity for the product team to communicate our business goals to the engineers and for the the engineers to commit to what they could deliver in that timebox.  Even the Kanban teams go through this, and it has helped us retain those important customer commits.

Are there any notable trends in Agile that you’d like to draw attention to and why so?

Stephanie : Scaled Agile Framework (SAFe) is a very notable trend. We are seeing many large companies adopt SAFe because it provides a framework to Scale Agile from the team all the way up to the portfolio.  Many large companies have seen that adopting agile at the team-level empowers the team but sometimes loses the connection to the business. Agile at Scale brings that back to the organisation.

Sign up to our newsletter for free





SAFe shows that adding a light-weight Kanban process at the portfolio helps prioritise the big business initiatives. Those initiatives can be broken down to smaller items that can be completed by a team in one quarter.  This is very important to improve value delivery to the market.  Big room planning brings all development teams in a room together where they can discuss risks and dependencies, and communicate back to the business what they can actually deliver. This conversation brings a dose of reality into the business and reduces planning waste for teams. It’s crucial to continue the cycle of talking about what actually can get done versus what’s requested by the executives.  Adopting an agile process higher than the team is critical for any company looking to beat their competitors to market.

Stephanie Tanner is passionate about delivering great products to customers.  As a developer, a user experience designer, product owner and currently a product manager, she’s experienced the full Agile product lifecycle.  She graduated from St. Olaf College with a B.A. in Computer Science and has been at Rally for four years.  Contact Stephanie on LinkedIn | Twitter or read her posts.


Desk image by MConners@morguefiles.

There are no comments

Add yours

This site uses Akismet to reduce spam. Learn how your comment data is processed.

freshmail.com powered your email marketing