Agile Methods: Kanban vs Scrum
On its own, agile is more of a mindset, and there are several established frameworks that one can adopt to achieve agility.
The two most popular methods to achieve agile principles are Kanban and Scrum. Kanban (Japanese: 看板) is used to to manage a continous queue of work items, which was originally developed by Taiichi Ohno at Toyota for lean manufacturing. Adopted from the Toyota production system, core ideas of the Kanban method include:
- Limit amount of work in progress so that there are only pending issues that the team can sustainably handle.
- Identify and remove bottlenecks in your workflow via root cause analysis.
- Pull work from queue on-demand, instead of blindly pushing work
The main advantage of the Kanban method is it being lightweight: it’s easy to adopt/get started with Kanban without team restructuring. Taiichi Ohno said that the idea behind the Toyota Production System was inspired from US retail supermarkets, where supply and demand are matched by ordering when the inventory is low (i.e. a pull system a.k.a. just-in-time). The kanban system implements this pull method and controls the flow of work. Examples of kanban systems include food ordering queue at a restaurant (food is only prepared upon receiving an order), ticketing system at a sporting arena (to control the flow of spectators), etc.
Note: the Toyota production model is actually implementing the principles of lean manufacturing, which is very similar to agile. The agile manifesto was first conceived in 2001 in the context of software development but share many commonalities with the lean principles.
Scrum is a framework for developing and sustaining complex products in projects with some degree of uncertainty. The main idea behind scrum is to start with a vision and incrementally build features through several iterations. After each iteration, the features on their own should be usable and desirable (i.e. help to achieve the vision). Feedbacks upon every iteration are used to adapt the vision to market changes and improve existing feature/add new features at the next iteration. Through several iterations, the product with all its features should resemble the vision more closely.
In scrum’s speak, every iteration is called a sprint, and the product that results from a sprint is called an increment. A sprint is typically a period of two weeks to work on an increment, but should be adapted to the needs of the team (longer sprint length may be necessary when the increment is harder and shorter sprint length can allow for better adaptation).
The scrum framework defines three components/parts:
- Artifacts (e.g. backlogs, boards, reports, etc.)
- Roles (e.g. product owner, scrum master, developers, stakeholders, etc.)
- Events (e.g. sprint, daily standups, sprint meetings, spring reviews, etc.)
Besides enabling collaboration, scrum artifacts also play a role in providing project transparency because anyone can evaluate the status of the project (as well as the history and future planning) by looking at the artifacts. These include the product backlogs (e.g. features, improvements, bug fixes, and so on), sprint backlogs (i.e. list of issues to be completed in the sprint as well as the sprint details), spring boards, and scrum reports, among others. Usually visual reports are also prodided (such as burndown chart, velocity chart, etc.)
There are three roles in a scrum team: product owner, scrum master, and the development team. The stakeholders are not part of the scrum team but still play a part in the success of the project. Internal stakeholders include people within the company such as managers, executive officers, or perhaps other scrum teams. External stakeholders are typically clients, partners, investors.
The product owner is accountable to the stakeholders and should therefore interact with them on a regular basis. As part of the scrum team, the product owner is responsible for
- communicating and spearheading the vision for the product
- planning sprints such that each increment is maximized
- handling the product backlog
The scrum master promotes scrum, coaches the scrum team, and educates the stakeholders on scrum. In addition, the scrum master should be the primary point in the team to remove bottlenecks that distract the current work as well as facilitate scrum events. The scrum master is responsible for:
- championing and supporting scrum
- making sure that the team is well-informed of why and how things are done the way they are
- helping the team to stay focus on high value tasks
- keeping the project transparent to the stakeholders
That is, the job of the product owner is to maximize the product value, and the job of the scrum master is to optimize team effectiveness. On the other hand, the development team (at least 3 and not more than 9 members as per the Scrum Guide) is the one who does the real job: the team creates the increment at each sprit and collaborate as necessary to produce the sprint increments. In addition, only the dev team can estimate issues and decide how much work can be done in a sprint.
A sprint consists of (in chronological order) sprint planning, daily standups, sprint review, and sprint debrief. Any of these events are also called meetings. Scrum meetings have the following common traits:
- fixed maximum time limit (but no minimum time limit)
- mainly for collaboration (instead of status update — the status should be visible already to everyone at any point!)
The real work (i.e. actual development) occurs in between all these meetings.
