Hello! Welcome to the third lesson in our course on people management.
In our previous lessons, we identified the limitations of the rigid Waterfall model and then explored the Agile Manifesto's philosophy, which provides a better mindset for navigating the uncertainty of a startup environment. You learned about the four core values and twelve supporting principles that prioritize adaptability, collaboration, and delivering value.
Now, we move from the "why" of Agile to the "how." The Agile philosophy is not a single method but a foundation for many practical frameworks. This lesson is designed to help you compare and contrast the two most popular Agile approaches: iterative (Scrum) and flow-based (Kanban). By understanding their mechanics, strengths, and differences, you'll gain a concrete toolkit to start thinking about which processes might best suit your team's needs and your goal of establishing a more structured workflow.
1. Two Flavors of Agile: Iteration vs. Flow
At a high level, the main difference between Scrum and Kanban lies in how they structure the flow of work.
- Iteration-Based Agile (Scrum): Work is organized into fixed-length cycles called iterations or sprints. The team commits to a batch of work at the beginning of a sprint and focuses on completing it by the end.
- Flow-Based Agile (Kanban): Work is managed as a continuous flow. The focus is on moving individual tasks through a process from start to finish as smoothly as possible, rather than working in batches.
This image provides a simple visual distinction between the two concepts.
Let's dive into each of these frameworks to understand how they work in practice.
2. A Closer Look at Scrum: The Iterative Approach
Scrum is the most popular Agile framework. According to the "State of Agile 2024" survey, it's used by 58% of agile teams. It is intentionally prescriptive, meaning it comes with a "starter kit" of roles, events, and artifacts. This structure can be very helpful for a team, like yours, that is transitioning from an informal process to a more defined one.
To get a concise overview of Scrum's mechanics, watch the following segment of this video.
Scrum vs Kanban - What's the Difference?
This video from the Development That Pays channel provides a clear, animated explanation of the core components of the Scrum framework.
Watch the section on Scrum from 01:57 to 03:33. Pay attention to the concepts of sprints, the sprint backlog, and the different meetings (ceremonies) that structure the process.
As the video explains, Scrum is built around a few key elements:
- Time-boxed Sprints: These are the heartbeat of Scrum. They are fixed-length periods, typically 1-4 weeks, during which the team works to complete a set amount of work. This directly aligns with your goal of establishing a 2-week planning cycle.
- Key Roles:
- Product Owner: Decides what the team will build, manages the product backlog, and represents stakeholders.
- Scrum Master: A servant-leader who facilitates the process, removes impediments, and helps the team adhere to Scrum principles.
- Development Team: The cross-functional group of people (in your case, analysts and developers) who do the work of building the product.
- Key Events (Ceremonies):
- Sprint Planning: The team selects work from the product backlog for the upcoming sprint.
- Daily Scrum: A short, daily meeting for the team to sync up on progress and blockers.
- Sprint Review: A demo of the completed work for stakeholders to gather feedback.
- Sprint Retrospective: A meeting for the team to reflect on their process and identify improvements.
For a more detailed breakdown that you can reference later, the following reading provides an excellent, in-depth explanation of the entire Scrum process.
A Comparison of Lean, Agile, Scrum, and Kanban
This article from Toptal gives a thorough description of Scrum, covering its team structure, workflow, and key terminology in detail.
Read the sections titled 'Scrum Overview' and 'Scrum Process'. This will give you a solid understanding of all the components and how they fit together.
3. A Closer Look at Kanban: The Flow-Based Approach
If Scrum is a structured, time-boxed approach, Kanban is its more flexible, flow-based counterpart. Used by about 15% of agile teams (with many more using hybrid models), Kanban is less about overhauling your process and more about visualizing your current process and optimizing it.
Let's return to the same video to get an overview of Kanban.
Scrum vs Kanban - What's the Difference?
This next segment explains how Kanban works, focusing on its continuous nature and the crucial concept of Work in Progress (WIP) limits.
Watch the section on Kanban from 03:33 to 04:29. Focus on how the 'pull system' works and what WIP limits are designed to achieve.
The core principles of Kanban are:
- Visualize the Workflow: The primary tool is a Kanban board, which maps out the stages of your team's work (e.g.,
To Do,Analysis,Development,Testing,Done). - Limit Work in Progress (WIP): This is the most critical and powerful concept in Kanban. By setting explicit limits on how many items can be in any given stage of the workflow, you prevent the team from being overloaded. This forces bottlenecks to become visible and encourages the team to collaborate to "unblock" work and keep it moving.
- Manage Flow: The goal is to make work flow through the system as smoothly and predictably as possible. This is done by measuring and optimizing metrics like cycle time (how long it takes to complete a task once it's started).
The idea of limiting WIP can seem counterintuitive in a high-pressure startup, but it's essential for improving focus and throughput. The following video tells a short, practical story about how a team learned this lesson.
Scrum vs. Kanban - "Kanban For The Win!"
This follow-up video from Development That Pays illustrates the real-world impact of applying a core Kanban principle—WIP limits—to a team's workflow.
Watch from 01:14 to 02:17. Notice how a simple physical constraint on the board forced a change in the team's behavior and improved their focus.
For more detail on the Kanban process, you can refer back to the Toptal article.
A Comparison of Lean, Agile, Scrum, and Kanban
This section of the Toptal article explains the Kanban process, highlighting its lightweight nature and continuous flow compared to Scrum's more regimented structure.
Read the sections 'Kanban' and 'Kanban Process'. Note the differences in roles and meetings compared to what you read about Scrum.
4. Scrum vs. Kanban: A Side-by-Side Comparison
Now that you have an understanding of both frameworks, let's directly compare them. The Toptal article you've been reading contains an excellent summary table.
A Comparison of Lean, Agile, Scrum, and Kanban
This table provides a direct, side-by-side comparison of Kanban and Scrum across several key dimensions. It is the most direct way to understand their differences.
Carefully study the table comparing Kanban and Scrum. Use it to solidify your understanding of how they differ in terms of process, focus, roles, and flexibility.
Here are the most important distinctions for you to consider for your team:
| Dimension | Scrum | Kanban |
|---|---|---|
| Cadence | Time-boxed sprints (e.g., 2 weeks). Work is planned in batches. | Continuous flow. Work is pulled one piece at a time. |
| Commitment | The team commits to a sprint backlog for the duration of the sprint. | There is no time-boxed commitment; the focus is on finishing work in progress. |
| Change | The sprint backlog is kept stable during the sprint to allow for focus. | Change can happen at any time; new items can be pulled as soon as capacity is available. |
| Roles | Prescribed roles: Product Owner, Scrum Master, Development Team. | No prescribed roles. Teams can keep their existing structure. |
| Metrics | Primary metric is Velocity (how many story points a team completes per sprint) to aid predictability. | Primary metrics are Lead Time and Cycle Time to measure and optimize flow efficiency. |
| Prescriptiveness | High. Provides a complete framework of roles and events. | Low. Provides principles to apply to an existing workflow. |
5. Which Is Right for Your Team?
The choice isn't necessarily "Scrum or Kanban." Many experienced teams create hybrid models, often called "Scrumban," that take the best of both worlds.
Here’s a pragmatic way to think about it for your situation:
- Lean towards Scrum if... your primary goal is to establish a predictable rhythm and create a reliable planning cadence. The 2-week sprint provides a natural container for your planning, and the ceremonies (planning, review, retrospective) offer a ready-made structure for your team to adopt.
- Lean towards Kanban if... your work is highly unpredictable, with frequent, urgent requests from clients that make sticking to a two-week plan difficult. Kanban's flexibility and focus on limiting WIP can help your team manage chaos and improve delivery speed for individual high-priority items.
Given your goals, a hybrid approach could be very effective. You could adopt the 2-week sprint cycle from Scrum to create a planning rhythm, but use a Kanban board with WIP limits internally to manage the flow of work and deal with unexpected tasks.
Conclusion
This lesson has moved you from Agile theory to the practical application of two major frameworks. You now have a solid basis for evaluating what kind of process might work for your team.
Key Takeaways:
- Scrum is an iterative framework that uses fixed-length sprints, prescribed roles, and ceremonies to deliver value in predictable increments.
- Kanban is a flow-based framework that uses a visual board, Work-in-Progress (WIP) limits, and flow metrics to optimize a continuous workflow.
- Scrum provides structure and predictability, while Kanban offers flexibility and workflow optimization.
- The choice is not mutually exclusive; many teams create hybrid models that combine elements of both to suit their specific context.
In our next lesson, we will synthesize what we've learned so far. We will explain how Agile principles like iterative delivery and feedback loops address common startup challenges, tying the philosophy from Lesson 2 and the frameworks from this lesson directly to the realities of your B2B startup environment.