alvinashcraft
shared this story
from 
Pluralsight blog.
The benefits of Agile development are clear: faster delivery, predictable development cycles, flexibility and faster bug fixes. But deciding which Agile is best for your development team isn’t quite as obvious. Two of the most popular forms of Agile are Scrum and Kanban. And while both offer flexibility, work batching and faster releases, there are significant differences that might make one or the other a better option for you. Let’s break it down.
Scrum
Scrum is a popular, customizable framework that makes it easy to define the work to be done, batch it into a “sprint” (lasting anywhere from one to four weeks), and then release the finished product at the end of the sprint and start again.
Compared to traditional waterfall development, Scrum’s fast and flexible nature gives development teams a remarkable amount of latitude to tweak both the work and the processes your team uses to fit your organization’s culture. But for some teams, the strict time limits of each sprint can be restricting. All specs are defined before the sprint begins and they can’t be reset until the sprint finishes.
Kanban
Kanban is similar to Scrum, with a bit more flexibility. Its workflow methodology allows for reprioritizing work as business needs change. Work is limited in each state and managed as it flows through the system. As work moves from one state to another, more can be added — as long as the flow remains steady. The team collaborates to improve the flow of work through the system. Because Kanban isn’t limited to defined sprints, it offers a lot of flexibility for development teams.
Scrum requires defining stories and daily standup meetings where teams report on their progress. But Kanban doesn’t have those requirements. Teams are free to adopt these practices if it helps the workflow, or to ignore them if they get in the way.
Scrum vs. Kanban: the biggest difference
Scrum’s workflow is defined by the time intervals. Projects (stories) are agreed upon and strict limits are placed on the amount of work in progress. Kanban, on the other hand, defines its workflow by single items, so additional work items can be added to each phase of the development process as long as there is room (that is, as long as it won’t cause a bottleneck and slow anything else down). This is both a strength and a weakness. While Kanban’s flexibility makes it easy to add or remove work, it’s also extremely prone to abuse by those who want development to move faster, so it needs to be monitored and controlled accordingly.
Takeaway: The form of Agile that’s best for you
Scrum and Kanban both work well. The one you choose should depend on your business and development goals.
If your team is new to Agile or focused on new project development where priorities rarely change on a daily basis, Scrum is a good choice. The regular cadence of sprint planning and releases makes it a good option for teams transitioning from waterfall to Agile, and those whose priority changes fit well into a one to four week cycle.
If your team’s priorities change more rapidly than the standard Scrum sprint, or you need additional flexibility to move work in and out of your production schedule, Kanban may be the better choice. Kanban may also be a good choice if your team already has a mature, high-functioning process that would conflict with Scrum’s requirements.
In the end, one form of Agile isn’t “better” than another. Each is best for different situations. Choosing the right form is just like choosing any other tool; it all depends on what needs to be done.
Want to learn more?
If you’re interested in learning more about the differences between Scrum and Kanban, check out Pluralsight’s new white paper, Scrum or Kanban for Agile Development: Which is right for you?
