The Future of Innovation
In the 90s, the software development couldn’t keep up with demand. Processes were heavy and rigid (most developers used the Waterfall methodology, a linear, sequential project management approach). So a group of developers met in Snowbird, Utah in 2001 to bring a new process to life. The result was the Agile Manifesto, a completely new way to approach project management in terms of developing software.
Despite similar ideologies, Kanban and Scrum have nuanced differences in execution you should consider before adopting either one. Let’s break them down so you can make the best decision for your development team.
Product owner — this person sets strategy. They’re responsible for mapping out the planning of the project, how tasks are prioritized and facilitating communication between the team. Another part of this role is advocating for the customer, which helps with the prioritization of work done by the development team.
In Kanban, there aren’t any structured roles. Of course, within an engineering team these roles might exist, like someone who’s responsible for customer interviews or project management. But Kanban doesn’t dictate them. It’s more of a collaborative approach.
For your team: If you already have effective team structure in place and a strong working relationship, Kanban might be better for your team. If you need to build that structure, Scrum might be the way to go.
Sprints — two-week periods designed to limit work, where specific tasks related to a project need to be completed. The product owner works with the dev team to plan these sprints, pulling tasks from a product backlog of work items and placing them into each sprint bucket based on priority. Releases are usually done at the end of each sprint or at the end of several sprints.
Retrospectives are part of each sprint — here, the team will assess their work in a sprint review, how they can better optimize, and then move onto the next sprint. Guided by velocity, the Scrum team should get better at estimating how much work can be completed in each sprint. If the team completes 25 tasks during a sprint, they wouldn’t agree to 40 on the next sprint. Here’s a template you can use for your retros!
Cards, not sprints — a Kanban board is organized by columns which the development team customizes based on their process (like “In Progress,” “Review Needed,” or “Complete”). In each column are cards (tasks) that the dev team moves though each stage of their workflow. There’s no designated timeframe to complete a certain amount of work.
Identifying process improvements — by nature, the Kanban method usually surfaces bottlenecks. If you see too many cards in the “Review Needed” column, you might need to assess your review process. Usually there’s a “WIP limit,” capping the items in your work in progress column. Teams assign a maximum number of cards that can be in each column to keep everything moving forward.
For your team: When it comes to your own team’s workflow, consider how you’re shipping projects currently. If you’re shipping cadence isn’t where you want it to be, use Scrum to help push your team to complete projects in a more timely manner. If it’s process your team needs to improve, Kanban is the method that can help identify where you can get better.
But the idea is to keep the scope of work within the sprint cemented. However, because the product owner is advocating for the customer, if they come across information that a feature or task is less valuable to the customer, the sprint’s scope might change. But generally, the idea is to maintain what’s been set out at the onset of the sprint.
Projects, workflow, tasks — Kanban hopes to improve process by recognizing these changes, allowing for continuous improvements as the project is being completed. If a task is blocked or WIP items stack up, there’s likely a reason. And your team can react based on the flexibility of the process.
For your team: If you need something a little more rigid because you’ve already established a solid cadence within your team, Scrum might be beneficial. On the other hand, Kanban helps your team remain flexible and figure out the best process needed to complete projects.
Kanban and Scrum can actually function together — Kanban to visualize the work, and Scrum to approach it incrementally (sometimes called a “Scrumban”). Of course, the process will have to be tailored to meet the demands of either Scrum or Kanban methodology (like establishing a Scrum master), but you can make one Notion board that can be tweaked to either framework.
Inside the card, you can keep all the information relevant to that task. Regardless if your engineering team is using Scrum or Kanban, bundling all the info to complete the task at hand is a way to keep your engineers running efficiently.
Inside cards, you can add whatever content helps you get the project or task done (with infinte layers as you need them). A page for code. A page for design. A page for ideas and inspiration. Most project management software doesn’t actually let you do work. You have to switch between tabs or tools to get anything done.
In Notion, you can slice the same data many ways. So you can create a view where you see only the tasks for “Sprint 1,” and a totally separate view of the same board where you see only the tasks for “Sprint 2.”