Scrum vs Kanban: identical yet miles apart!
Introduction
Any IT product, application or software development effort is made up of stakeholders who are invested in the success of the product. These stakeholders typical comprise customers or users, executives, development team comprising architects, product owners, analysts, Ux/ UI developers, software developers, testers, etc.
In conventional waterfall projects, the teams above form strict structures and protocols for delivery of the desired work. Waterfall stresses on strict Finish to Start approach where end of a stage is prerequisite for subsequent stages to start. In Agile approach, the same structures are loosely defined and followed, while protocols are generally flexible and come with only ‘recommended’ status. Further, Agile is typically defined by iterative, small pieces of functionality delivered rapidly and in close collaboration with the customers and / or end users. Agile doesn’t follow Finish to start approach rather stressing on parallel tracks of work which can be finished separately or together.
In Agile projects, Product owner or product manager is responsible for maintaining the details of what is being built. The amount of work to be done in a project is recorded in what’s knows as a product backlog. Product backlog is a list of features and user stories required to complete the work in a typical Agile development. It is the product owner’s responsibility to work with Development team to organize the product backlog in to a list of prioritized features and user stories which dev teams then use to pull sprint backlog and deliver useful, working increments iteratively. Product backlogs features and user stories are continually revised, updated and modified as project proceeds along and as more clarity is achieved through a collaborative approach.
Image Credit: Internet
Scrum vs Kanban
Scrum and Kanban are two of the most popular approaches. Both the approaches have lot in common, yet both have points of divergence as well. Many experts consider Kanban as the methodology closest to the spirit of Agile principles. It is often contended that while Scrum does contain vital benefits, like continuous feedback loop and the ability for teams to self-organize independently, these benefits are effectively absorbed by the self-arrangement features of Kanban.
In Scrum and Kanban both, the focus is on efficiencies and transparency. Both the approaches are Agile and Lean, and favor using clear, most obstruction free path. Scrum and Kanban both target to deliver usable software early, efficiently and as seamlessly as possible, through breaking features into easily manageable pieces of work. Further, both Scrum and Kanban feature self-organizing, learning teams which evolve with time.
Scrum teams work in a series of sprints. Each Sprint is characterized by certain ceremonies and artifacts. Scrum team typically means the product owner, development team and scrum master. In many cases, depending upon the composition of the team, testers, Business Analysts and in few cases, devops personnel, are considered part of development team. Before each sprint, there is a sprint kickoff meeting, which is attended by scrum master, product owner and the development team. The development teams consult with the product owner to discuss the items on the backlog to identify and prioritize the work they can deliver at the end of the sprint. The selected items become the sprint backlog. And the sprint backlog becomes the sole focus of the development team for the next two weeks. This sprint backlog is held sacrosanct and as far as possible no new items are allowed unless under exigent circumstances. There are occasions when dev team is not able to complete all the prioritized work in the sprint. In such cases the incomplete items are transferred back to the product backlog at the end of the sprint to be taken up during subsequent sprint or re-prioritized for future. During the sprint, which is typically 2 – 4 weeks in duration, daily stand up call is organized by the Scrum Master where each development team member is invited to cover three things – what was done yesterday, what will be done today and any blockers / risks / issues. It is the Scrum Master’s responsibility to record all blockers / risks / issues and seek resolution to clear development team’s path. Scrum Master is also responsible to maintain the decorum by ensuring daily stand up meeting takes place daily, that most members participate and speak up and the duration of meeting doesn’t exceed 15 minutes.
At the end of the Sprint, Sprint Review (or Sprint demo or showcase of new functionality) meeting and Sprint Retrospective are held to present what the team has delivered and what are the lessons learnt respectively to ensure that next sprint is more efficient than the last. It is generally a good practice to document these sessions, especially where customer sign-offs need to be obtained.
Image Credit: Internet
In Kanban, there are no defined Sprints and there is no defined ‘prioritized backlog’ required to build an increment of working software at the end of iteration. The development team works in a continuous manner, as per its capacity. As the dev team works on the prioritized product backlog directly, there is no separate sprint backlog. Dev team keeps pulling items from the prioritized backlog as soon as one item is finished or any capacity becomes available. The capacity of dev team in each phase determines the number of user stories or features it can pull to work upon. During each phase of development, i.e. build (coding), testing, and marking items as done, movement of backlog items frees up capacity in the preceding phase. As capacity is freed up in one phase, pressure is on the preceding phase to move work up. This ‘pull mechanism’ exerted by each subsequent phase on the previous phase results in movement of work through phases.
Kanban has no time-boxed iterations or sprints, and as such doesn’t place a hard limit for each iterative delivery or increment of working software or any improvements that are being targeted as goal. Kanban teams generally work as per the workflow, which are defined as goals. The team expects to make continual improvements in an evolutionary manner as the teams get more mature.
Image Credit: Internet
In each Kanban board, there are specified columns. Under each column is a limited set of colored notes that signify the tasks assigned to the given column as per the workflow. As studies have noted, 80% of information is gathered visually, which makes the Kanban board a powerful tool for noticing and remembering the things that must be done.
Further, under Kanban, no set roles are defined. Practically speaking, it makes sense for someone to serve as a product owner, project manager or supervisor, especially for medium to large projects which are more complex, but the roles may also theoretically evolve with the needs of the project and the environment. A Kanban team is not required to be cross-functional since Kanban workflow is intended to be used by any and all teams involved in the project. Therefore, a team of specialists and a separate team of generalists may be working on different aspects of the same Kanban project from the same board at the same time, all in order to pursue the defined goals.
Unlike Scrum, where the focus is to produce an increment of working software, in Kanban, teams strive to achieve goals (complete workflow states) and reduce the amount of time to complete the entire process. A reduction in the average timecycle may be one of the indicators of success.
Under Scrum, work in progress is limited in each iteration. The team has committed to the number of tasks or user stories and has adapted that scope as sprint backlog. This is the scope that the team is ready to accomplish during the Sprint. All the items can theoretically move to the Work-in-progress section simultaneously. In Kanban however, the limit for each stage of the workflow is defined and noted on the Kanban board clearly. Kanban limits work in progress per workflow state to this number, which is nothing but the capacity of the project teams working on the Kanban board. For example, if there are 5 developers, and each developer has committed to 1 user story or task, then number 5 is denoted on the Kanban board to indicate the maximum capacity available in that phase. Consequentially, there shouldn’t be more than 5 items in the particular phase.
Under Scrum, only the development team can edit the sprint backlog once it has been committed. In Kanban, the Kanban board may be edited by a Product Owner. According to Essential Kanban Condensed Guide, Kanban has evolutionary defined two “hats” that the team members can wear: Service Request Manager and Service Delivery Manager. The “hat” of Service Request Manager is an alternative to the Product Owner. In Kanban, there is also a culture of slack resources, or free flowing resources who can don generalized or specialized hat to help resolve bottlenecks, as and when needed. For example if a resource has completed his / her tasks, s/he is free to move to help another team member on a task which is in blocked state or on critical path. Equally well, the free resource can choose to take up a fresh task or user story from the backlog queue.
In some Kanban teams, there is an additional section on the Kanban board, an Urgency section, which is typically represented as a swim lane. This section may be used for an unpredicted urgent task from the Backlog or a bottleneck task from the board. In such an event, the urgent or bottleneck task is moved to Urgency swim lane where it becomes the first priority for the team.
Image Credit: Internet
Conclusion
Scrum and Kanban are often used interchangeably or thought to be two sides of the same coin. As both approaches are used to drive efficiency and utilize product backlog and common terms, the different nature doesn’t become apparent to a layman. In reality however, there are significant differences between these two methodologies. An often raised complaint about Scrum is the length of its time-boxed sprints and the rigidity through which time-boxed iterations are imposed, which are considered too long when employed with startups. The main criticism stems from the fact that lengthy, rigid sprints lead to infrequent releases, which can cause work teams to drag their feet or become accustomed to slow pace when responding to the needs of customers. Similarly, in case of undersized sprints, where the scope of work for each release is large, the larger features need to be broken in to smaller iterations, which are unlikely to deliver full value to a customer and might end up confusing the customers and end users. The set time-boxed lengths of Scrum were designed to offer consistency, and may not always be useful in a world where technological innovations move at a faster rate than before. Kanban tackles problems raised in Scrum with a different scheduling protocol where instead of operating with time-boxed sprints, Kanban restricts the number of things that a collective can focus on during any particular time span. Hence, the benefits of Kanban are twofold: Organizations can get more response from the marketplace, and they’re able to adjust to the demands of that input with greater agility. In that sense, Kanban is often considered the most close to Agile spirit.
Understanding these differences is key to choosing the path that will work best in a given environment.