Do you find yourself asking which agile framework to use? Do you think Kanban and/or Scrum sound like some kind of strange dessert? Well you’ve arrived at the right place! Crema employs both of these agile frameworks, and sometimes even a mixture of them to produce the best results for our clients. Within this post you’ll find the definition of Kanban, Scrum, pros and cons of each, mixtures of the two frameworks and even suggestions on which to use for your next project. Plus, a video at the end that sums everything up!
What is Kanban?
The largest visual differentiator between Kanban and Scrum is the lack of sprints. Typically, Kanban boards are organized into columns and the work flows from left to right. The left most column is typically work to be done and the right most column is the work that has been completed, or sometimes, blocked. It’s important to note that there’s no right or wrong way to setup a Kanban board and that it greatly depends on a variety of factors such as the type of work being done, restrictions imposed by process, the inclusion of epics, etc.
While Kanban has become popular with software development, it’s also becoming more and more popular with other business aspects such as recruitment, marketing projects, and leadership initiatives.
The primary metric used within Kanban to determine process effectiveness is cycle time, though, that metric isn’t used by all.
What is Scrum?
The base level definition of scrum is very similar to Kanban. Scrum, in its simplest form, is a way to manage work, but in a time boxed manner. The time boxes are most commonly referred to as sprints.
Typically, sprints are two weeks long, but can be up to a month long. Each day, there’s a daily scrum that’s also sometimes referred to as standup. This daily meeting lasts no longer than 15 minutes and is a time to check-in on sprint progress. Each standup answers three questions:
- What did you do yesterday?
- What are you working on today?
- Do you have anything impeding your progress?
This agile framework is used so that the product team (a.k.a. scrum team) can work as a group to meet a goal that’s valuable to the business. The framework is also widely used and accepted in product development because rather than planning out all requirements upfront, they are created along the way. This allows for shifts to happen much more easily and quickly, giving the team a chance to adapt to new requirements, changes in target and new technology.
Additionally, this particular framework allows for the measurement of velocity, which is the average amount of story points a product team can accomplish within any given sprint. This allows for accurate projections to be made regarding releases.
Scrum has a lot more process behind it than Kanban does that we could write a whole article on, but we’ll just focus on the base level definition so that we can continue to compare Kanban vs Scrum.
Pros & Cons of Kanban and Scrum
Middle Ground Options
Scrum and Kanban are both viable and successful frameworks to use in product development. However, you should never be afraid to go beyond what is outlined as ‘standard.’ This is why we call them frameworks, because they are inherently flexible.
The beauty of Agile is that it was created to serve the individual team, and it’s not necessarily seen as ‘one size fits all’ when it comes to the framework used as an implementation method. Rarely will you come across a business or product that has been developed within a single silo of Scrum or Kanban - it’s just not all that common today.
It’s important to use a framework that works best for your team and your product goals. You may find that as you begin a creating product, you start with the goal of implementing via one framework, but utilizing components of other frameworks along the way.
For example: If you first decide to approach a product with the Kanban method, but would also like to implement a daily standup (or “Scrum” meetings) to ensure alignment throughout the team, you should feel confident in this decision.
There are documented approaches for overlaps within Scrum and Kanban (such as Scrumban and Kanplan), but ensure that whatever method you choose to take, you don’t limit yourself or your team, just for the sake of following structure.
What does Crema use and why?
Crema uses all of these frameworks! We more commonly use the Scrum framework on our heavy product development work, but use Kanban more commonly with our design and prototyping engagements. Sometimes, we even use the middle ground options listed above. Frankly, we use whatever framework or combination of frameworks that make the most sense for the engagement. Our Product Management team analyzes each and every engagement that comes through our doors to determine the best method to produce the greatest results.
We tend to use the Scrum framework most heavily for our product development work, because it allows us to plan out work more effectively and deliver quicker results. Scrum also allows us to pivot if, or when, necessary, so that our clients still get something at the end of the engagement. While it may not be what they thought they were going to get at the beginning of the engagements, it better aligns with their business needs.
One of the main reasons Scrum allows us to plan work out more effectively is that our engagements are centered around a product team for a duration anywhere from three months to over a year. Since the teams remain largely the same throughout those engagements, it allows us to calculate a team velocity within the first two or three sprints. That velocity metric is a way for us to measure how much work we can get done within any given sprint, using story points, and then allows us to plan out the remaining work and estimate how long it will take to complete.
With all of this said, It’s important to call out that each of our product teams can run a little differently at times - depending on the need of the client, product, and individuals working towards the solution. Each time that you embark on the journey of building out a new product, it’s really important to understand that flexibility is key to not only the success of the overall solution being built, but also for the individual team members working towards their common goal. We love to use Scrum, and we love to use Kanban, but we are never afraid to flex in different areas (regardless of the core method that we’ve chosen) to allow for the team to grow, and deliver the very best possible product.
What tools do we like the most for each and why?
- Asana doesn’t really have a good way to use it for Scrum, but, it does work GREAT for Kanban style projects. As a product agency, we’ve used Asana for years and only recently had to begin to transition projects out that are prescribed a more Scrum style framework. You can learn more about how we use Asana in this blog post.
- Jira is king for both Scrum and Kanban projects (and even projects beyond that). They’re the leading product development software used throughout the globe and there’s a reason for that. It’s incredibly robust and can handle pretty much any type of project you throw at it. That robustness does come at a cost though. Jira can be a lot to manage for newbies, but they’re doing a lot to fix that, including releasing an entirely new UI. I think we’ll see great things to come from Jira in the coming months and years.
- Ora is a new player in the realm of digital product management, but they’ve really impressed us with their flexibility in nature. By default, Ora is set to manage projects within Kanban boards. However, their suite of options and features allow for teams with different preferences or goals to run their projects without restriction or prescription.
We hope you enjoyed this article about Kanban vs Scrum and hopefully come away with some clarity around the topic. If there’s one thing to take away, it would be that flexibility is key. Do what you need to do for your team to produce the best results and you’ll be set! As a bonus, here's a video we made that goes into even more details: