What Is Scrum?

Scrum is an iterative, ritualized, process-driven agile software product development framework created by Ken Schwaber and Jeff Sutherland. Their official guide can be found at http://www.scrumguides.org/. Scrum organizes software product development around three foundational pillars; artifacts, roles, and meetings, that control the flow of work through the Scrum framework.

Scrum Artifacts

The Scrum artifacts are the product backlog, the sprint backlog, and the product/software increment. The product backlog is composed of prioritized product backlog items (epics, user stories, and bugs). The sprint backlog is composed of those estimated product backlog items that have been selected for development in the current sprint based on their priority (i.e., their location at the top of the product backlog). The product increment is the potentially releasable version of the software that is delivered at the end of the sprint.

Scrum Roles

The Scrum roles are the product owner, the scrum master, and the developer. The product owner is responsible for prioritizing and maintaining the product backlog, writing user stories and acting as the bridge between business stakeholders and the development team. The scrum master is responsible for ensuring that the scrum team adheres to the principles and precepts of scrum, maintaining the sprint backlog, resolving impediments to development, and instilling and coaching agile values in the Scrum team. Developers, collectively known as the development team, are responsible for creating the features detailed by the product owner.

Scrum Events

The Scrum events are meetings (i.e., rituals) that give scrum its cadence. The sprint is the time-boxed container for all other scrum events and is one, two, three, or four weeks long. Sprints run back to back and should always be the same length. The sprint planning meeting is used to groom the product backlog and plan the next sprint. The daily scrum is the 15-minute development team huddle at the beginning of every day to inspect the previous day’s work and raise any impediments to ongoing development. The sprint review is the meeting in which the scrum team, led by the product owner, demonstrate to business stakeholders the completed functionality created during the last sprint. The sprint retrospective is the meeting in which the scrum team reviews its performance during the last sprint and makes adjustments to their practice of Scrum to increase their performance.

Summary

Because of the defined artifacts, roles and events in scrum, it is highly ritualized and process oriented and can often be seen as too complex to those who are not familiar with it. Scrum also requires that Scrum teams be fully cross-functional (having few to no dependencies on outside resources), often collocated in the same office, and autonomous enough to create and prioritize their own work based on close interaction with business stakeholders.

Pros of Scrum

• Iterative and incremental
• Adaptable to changing priorities from sprint to sprint
• Enhanced communication and collaboration
• Teams become more productive over time

Cons of Scrum

• The more experienced and disciplined the Scrum team, the better the performance
• Accurate Scrum estimation is quite difficult
• Lots of ritualized meetings
• Unexpected complications and team-external dependencies can cause a sprint to fail or partially fail
• The rolling backlog can be quite chaotic if not managed by an experienced and disciplined Scrum product owner

What is Kanban?

Kanban was created in post-WWII Japan by Toyota as a visual scheduling system for just-in-time manufacturing. It was later applied to software development sometime after the year 2000 with David Anderson’s 2010 book Kanban seen as the seminal work on adopting Kanban in the field of software development.

Visualize the Workflow

Firstly, Kanban requires the visualization of the existing workflow. Secondly, each piece of work is visually represented by a card, called a kanban card. The card is then pulled through each phase of the workflow in turn and monitored. Wherever cards pile up too quickly in one area, that work phase becomes a system constraint.

Optimize the Workflow

Work in Progress Limits (WIP Limits) are then applied to the previous work phase – not to the constraint! – to prevent production backlogs. This subordinates the entire workflow to the identified system constraint(s) and reduces the batch size of development efforts. Optimization continues until each phase of the workflow has an assigned WIP limit that allows cards to flow freely through the system without creating any backlogs.

Another method for determining WIP Limits is to measure both the lead time (i.e., the total time to delivery for one card) for a card and the cycle time (the total time to produce) for each work phase. Those numbers can then be used to optimize the entire workflow by balancing the work phase cycle times against the lead time, with the overall goal being to make the lead time as small and predictable as possible.

Alternatively, in development environments, more resources can be added to a constraint, thus increasing capacity (i.e., the WIP Limit) in that work phase, allowing the entire workflow to achieve higher levels of production. However, the important point is that the system is brought into balance for a stable, predictable workflow.

Summary

Kanban is a visual pull system that focuses on the smooth and steady flow of work through the production system. Small batch size coupled with tight monitoring of cycle and lead times lends itself to a stable, normalized and predictable workflow. Kanban is often used in software development for maintenance or bugfix teams where roadmaps and carefully planned and managed releases are less important. Kanban teams often develop specialized skillsets that allow them to work efficiently on specialized functionality or feature sets.

Pros of Kanban

• It is visual
• Focuses on optimizing the entire production chain (workflow)
• Visually identifies system constraints and limits work input into those constraints (WIP limits)
• Increases quality by never passing defective products or features on to the next work phase
• Reduces waste by never producing work without a corresponding request for work (i.e., a pull system)
• Very suitable for software maintenance work streams and organizations that have achieved Continuous Integration/Continuous Delivery (CICD) environments
• Allows for team specialization

Cons of Kanban

• Does not lend itself well to formalized and feature rich software releases
• Is not iterative in nature
• Does not account for production impediments or interruptions at all
• Does not account well for differently-sized work flowing through the system (e.g., work of the same size flows more predictably through the system)