Scrum Vs Kanban

Scrum Vs Kanban

Scrum in a nutshell

Scrum is an iterative or incremental process framework to build complex products of the highest possible value. In Scrum, the team always works on the highest priority items first. The work is performed in short, time-boxed iterations. Each iteration begins when the team aligns on a subset of the highest priority items that it can complete in that iteration. Each iteration ends when the team has delivered a potentially shippable product increment of the product. The team delivers value to the customer at the end of each iteration or a time-boxed cycle.

There are three defined roles – Product Owner, Scrum Master, and the Development Team. A Product Owner decides what needs to be built and in what order. A Scrum Master acts as a servant leader and coaches the team to follow Agile Scrum principles. A Development Team is a group of self-organizing individuals who develop a high-quality product.

Scrum requires the below ceremonies to be conducted regularly:

  • Product Backlog Refinement
  • Sprint Planning
  • Daily Stand-Up
  • Sprint Review
  • Sprint Retrospective

Scrum is most suited for complex projects where things are more unpredictable than they are predictable. In complex domains, there is a need to collaborate with others, have an innovative mindset to investigate, experiment with different ideas, and adapt based on the learnings.

To learn more about Scrum, you may read my bestselling book, The Basics Of Scrum – A Simple Handbook to the Most Popular Agile Scrum Framework. 

Kanban in a nutshell

Kanban works best for teams that have a continuous flow of incoming requests with different priorities. In Kanban, each request or work item is represented by a Kanban card that flows from one stage of the workflow to another until it’s complete.

Kanban is very flexible in nature. New work items can be added to the backlog at any time. Even the workflow can change anytime. If team capacity changes, WIP limits get recalibrated.

In Kanban, there is a significant focus on improving time to market and eliminating waste.

To learn more about Kanban, you may read my other book, The Basics Of Kanban - A Popular Lean Framework

 

Let's analyze the core differences between Scrum and Kanban.

Scrum: Formed for complex product development to mitigate the limitations with the Waterfall method

Kanban: Originated to manage work and control inventory at Toyota with just-in-time and lean principles

 

Scrum: Time-boxed and fixed length sprints

Kanban: Continuous flow

 

Scrum: Can release at the end of every sprint or on-demand

Kanban: Continuous delivery or at the team's discretion

 

Scrum: Required roles - Product Owner, Scrum Master, Development Team

Kanban: No specific roles required

 

Scrum: The smallest piece of business value that a team delivers is a User Story.

Kanban: Each work item is represented as a Kanban card.

 

Scrum: Best suited for complex and unpredictable efforts

Kanban: Best suited for both simple and complicated efforts where things are more predictable than they are unpredictable

 

Scrum: Sprint Retrospective is conducted at the end of every sprint to inspect and adapt the existing process.

Kanban: Service Delivery Review is conducted on a monthly or quarterly basis to review cycle time, flow efficiency, etc.

 

Scrum: Requires user stories to be estimated in terms of story points.

Kanban: Does not require items or cards to be estimated. In Kanban, estimation is optional. Some teams choose to estimate their cards to have more predictability while others prefer to split their stories such that each of the cards is of the same size.

 

Scrum: Sprint Burndown and Velocity are the key charts.

Kanban: Cycle time and Throughput are the key metrics.

 

Scrum: Less flexible

Kanban: More flexible

 

Scrum:  Ceremonies are conducted on a regular cadence.

Kanban: Meetings are held as needed.

 

Scrum: Additional stories should not be added to the active/ongoing sprint. 

Kanban: Additional work items can be added anytime, assuming it’s within WIP limits.

 

Scrum: A Scrum board or the sprint backlog is reset after every sprint.

Kanban: A Kanban board is continuously used.

 

Scrum: Requires a bigger shift with roles, ceremonies, estimations, and iterations.

Kanban: Nothing needs to change significantly to get started with Kanban.

 

Now that you understand the differences between the two frameworks, you can decide which approach works best for your team. For more on Agile, Lean, Scrum, or Kanban, you may read below books:

Please follow and like us:

Agile and Lean

Agile and Lean

Agile and Lean

People often debate whether Agile and Lean are the same or different. Sometimes, people ask me which one is the best methodology for their business. This article presents some similarities and differences between the two methodologies.

Similarities in Agile and Lean 

Some of the core similarities between Agile and Lean are listed as follows:

Development approach

Lean development encourages to reduce the batch size and limit work-in-progress (WIP). Agile methodology, too, promotes prioritization of work items and incremental development of working software within short, time-boxed iterations.

Continuous Improvement

Lean development is very focused on Kaizen or continuous improvement. Agile development also signifies the importance of the inspect and adapt activities such as product demo and retrospectives that promote continuous improvement. 

Collaboration

Teamwork is one of the core values defined in Toyota Way 2001. Lean methodology encourages collaboration between team members. Agile development, too, has a strong focus on people interactions and collaboration with product stakeholders. The below two values stated in the Agile Manifesto reflect the same.

  • Individuals and interactions over processes and tools
  • Customer collaboration over contract negotiation

Moreover, the 4th Agile principle, ‘Business people and developers must work together daily throughout the project.’ is also focused on collaboration.

Customer-centric approach

Lean is a customer-centric methodology that focuses to deliver the best quality and value in shortest sustainable lead time. Agile methodology is customer-centric as well. The 1st Agile principle, ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.’ is customer-focused.

Just-in-Time approach

Both Agile and Lean methodologies encourage the Just-in-Time approach. One of the two pillars in the Toyota House of Lean is ‘Just-in-Time’ that encourages to produce only what is needed when it is needed, and in the quantities needed. Agile development, too, promotes ‘Just-in-Time’ planning, design, development, and documentation. Agile encourages teams to refine, design, and document only the prioritized work items. Agile concepts such as incremental development and emergent design reinforce the ‘Just-in-Time’ approach.

Waste Elimination

Though Lean is the major proponent for waste elimination, Agile methodology, too, supports this concept by delaying decisions until the last responsible moment (LRM). Thus, with LRM, possible rework, caused when working on an incorrect feature or an incorrect design, is minimized.

Differences in Agile and Lean

Let’s look at some of the core differences between Agile and Lean.

Origin

Lean management was originated in the manufacturing sector with the intention to reduce waste and improve the efficiency of the existing system, whereas Agile methodology was conceived by the software development thinkers to solve problems with the traditional software development approach.

Nature of work

Lean methodology is best suited to optimize simple, repetitive tasks that flow through different workflow states. On the contrary, Agile is best suited to build complex products that require research, experimentation, ability to adapt to change, and collaboration.

End Goal

With Lean, the end goal is to deliver a high-quality product in shortest sustainable lead time in the most economical way while eliminating redundancies and waste. With Agile, the end goal is to deliver the maximum business value, respond quickly to the changing business needs, and develop incrementally in an iterative way.

Team Size

Lean methodology is applied to improve processes in large enterprises and teams. Value stream mapping helps to visualize the end-to-end journey or steps required to deliver value to the customer. On the other hand, Agile is most effective when applied to small teams with a team size of 5-8 people.

Learn more on Agile and Lean with my short book, The Basics Of Agile and Lean

Please follow and like us:

Kanban Boards – Practical Examples

Kanban Boards - Practical Examples

Applying Kanban

What Is a Kanban Board?

A Kanban board is a visual tool for enabling Kanban to manage work for any business. The board helps the team to track each of their work items, minimize idle time, improve predictability, increase quality, and reduce time-to-market.

 

Sample Kanban Boards

Let's dive-in into a few practical examples when teams manage their work via Kanban:

 

Consider a scenario that a DevOps team receives several requests each day to automate build process in Jenkins, resolve test environment issues, onboard new applications onto the hybrid cloud, and so on. Here’s a sample Kanban board for such a scenario.

DevOps Kanban

 

Consider a scenario that an operations team receives several calls during the day from its customers and works together to analyze reported issues, provide real-time guidance, and execute fixes to a customer-facing application. Here’s a sample Kanban board for such a scenario.

 

Consider a scenario that a software development team receives new requests on a regular basis to build new capabilities and enhance existing application features. This team targets to deliver a quality code and invests time in peer code reviews and application testing. Here’s a sample Kanban board for such a scenario.

 

Consider a scenario that an organization’s legal team receives requests on a regular basis from different portfolios in the organization to review content on their sites, campaigns, offers, etc. from a legal point of view. Here’s a sample Kanban board for such a scenario.

 

Consider a scenario that a platform team receives multiple requests from different application teams every day to onboard their applications onto the new platform. Here’s a sample Kanban board for such a team.

 

Consider a scenario that you are buying a new home. In order to track the various tasks and reduce distractions, you create a personal Kanban Board with a WIP limit of 2 home viewings. Here’s a sample Kanban board for such a scenario. 

 

Consider a scenario that you need to sort your house over the weekend. You decide to organize your work and reduce task-switching by creating a personal Kanban board. Here’s a sample Kanban board for such a scenario. 

 

Please follow and like us:

Waterfall Vs Agile

Waterfall Vs Agile

Let's analyze the core differences between the plan-driven Waterfall approach and the Agile methodology.

 

Waterfall: Project development flows steadily downwards like a waterfall from one phase to another. The common phases are: Define, Analyze, Design, Build, Test, Launch, and Maintain. The preceding phase must be completed before the next phase can begin.

Agile: Work evolves in an iterative and incremental manner with an emphasis on collaboration, responding to change, and continuous improvement. Its core foundation was laid with the Agile Manifesto for Software Development in 2001. 

 

Waterfall: Encourages conformance to processes and tools

Agile: Values people interactions over processes and tools

 

Waterfall: Requires comprehensive documentation

Agile: Values working software over comprehensive documentation

 

Waterfall: Restricts new ideas

Agile: Encourages experimentation and new ideas

 

Waterfall: Promotes a process-centric environment

Agile: Promotes a people-centric environment

 

Waterfall: Dependent on contract negotiation with customers or suppliers

Agile: Encourages customer collaboration over contract negotiation

 

Waterfall: Requires conformance to a detailed project plan

Agile: Embraces change over following a plan

 

Waterfall: Demotivated team members. Requires a continuous effort to motivate the team.

Agile: Creates high performing, self-organizing, and motivated teams

 

Waterfall: Requires a huge rework to accommodate late changes

Agile: Welcomes changes even late in development with minimal rework

 

Waterfall: High cost of change

Agile: Low cost of change

 

Waterfall: Upfront planning

Agile: Just-in-time planning

 

Waterfall: A higher possibility of mismatch between requirements and the final product

Agile: Frequent feedback loops reduce any mismatch between expectations and results

 

Waterfall: Unhappy customers in spite of the hard work by the development team

Agile: Delighted customers due to frequent feedback and response to changes

 

Waterfall: Requires upfront decisions

Agile: Decisions wait till the last responsible moment (LRM)

 

Waterfall: Does not encourage regular interactions with customers

Agile: Promotes daily collaboration with customers

 

Learn more on Agile, Lean, Scrum, or Kanban with below reads:

Please follow and like us: