Why Kanban could be your answer to project management chaos

If you’ve tried different project management methods, you know that finding the right approach can feel like a never-ending experiment. The problem with most methods is that they either provide too much structure or not enough.

Let’s take a look at what’s out there and why they might not be giving you the results you need. By the end of this article, you’ll have a better understanding of what it takes to keep your team on track and deliver great results, without all the headache and hassle. We’ll also discuss why we ultimately decided to opt for Kanban as our main framework.

Waterfall

Waterfall is the classic method of project management. It’s been around forever, since the dawn of software development. Its linear, sequential approach breaks down projects into distinct phases, each one having its own set of deliverables and milestones.

Sounds great in theory - you move from one phase to the next, until the project is complete. But in practice, it’s not really flexible. The method assumes you know everything upfront. You’re expected to define all the requirements, design, the entire system, and plan out every last detail before you write a single line of code.

The reality with modern development is that things change fast. Markets shift and new technologies emerge. By the time you’ve completed your carefully planned phases, the original requirements might be obsolete. This is more ideal for projects with very stable requirements.

Agile

At its core, Agile is all about embracing change, collaborating closely with stakeholders, and delivering working software early and often. Rather than planning out every detail upfront, Agile teams work in short iterations, called sprints that last anywhere from one to four weeks.

With each sprint, the team is focused on delivering a small but functional piece of the overall product. They start with the product backlog, which is basically just a prioritized to-do list of all the features and requirements for the project. The team then selects a subset of items that they think they can realistically complete during the sprint.

Once the sprint is underway, the team has daily stand-up meetings, usually no more than 15 minutes and each team member answers three key questions: What did I do yesterday? What will I do today? Are there any obstacles in my way? It sounds like a lot but the idea is to keep everyone on the same page.

There are a ton of different Agile frameworks out there, including Scrum, Extreme Programming (XP), and Kanban.

Scrum

So, along comes Scrum. It shares many of the same principles and practices as Agile, but they’re not exactly the same. Think of Agile as a philosophy and Scrum as a specific way of putting that philosophy into practice.

Three key roles define this method:

• Product Owner: Prioritizes the product backlog and represents stakeholder interests.
• Scrum Master: Facilitates Scrum practices, removes obstacles, and ensures team productivity.
• Development Team: Builds the software and collaborates to deliver working increments each sprint.

There’s also a set of tools to help teams stay on track.

• Product Backlog: A list of all features and requirements for the project, listed by priority.
• Sprint Backlog: A subset of tasks from the selected Product Backlog for the current sprint.
• Burndown Chart: A visual of the remaining tasks and time left in the sprint.

Its strength lies in its structured approach, while allowing for regular feedback and adjustments. Teams know exactly what they’re delivering every few weeks, and stakeholders get frequent opportunities to provide input.

However, Scrum comes with its own set of rules and ceremonies. Daily standups, sprint planning, sprint reviews, and retrospectives - these eat up valuable time. Many teams find themselves spending hours in meetings instead of doing actual work. Plus, the rigid structure can become its own form of waterfall when urgent work disrupts sprint plans or tasks don’t fit neatly into two-week boxes.

Extreme Programming (XP)

A more extreme Agile framework is Extreme Programming, or XP for short. You might call it the perfectionist’s take on Agile. The emphasis is on technical excellence and producing high quality software through collaboration, rapid feedback, and continuous testing.

It’s highly prescriptive and its practices include:

Pair Programming: This is when two developers work together on one computer. One programmer (the driver) writes the code while the other (the navigator) reviews each line as it’s typed. It seems inefficient but research shows that it can actually improve code quality by up to 15% and reduce defects significantly. This is because both programmers are sharing knowledge and solving problems in real-time.

Test-Driven Development: Instead of writing code and then testing it, developers write a failing test that defines a desired improvement. They write the minimum amount of code to make the test pass. They then refactor the code to remove duplication and improve the design. This red-green-refactor cycle ensures every feature is testable and verified.

Continuous Integration and Deployment: Instead of waiting for days or weeks to merge code changes, XP teams integrate their work several times per day. Each integration is then checked by an automated build and test process. This helps catch problems early on when they’re easier to fix.

Small Releases: XP teams release working software early and often, sometimes even daily. Each release is as small as possible while still adding business value. This approach reduces risk because the changes are incremental. It also gives opportunities for customers to provide feedback, making the software even better as it goes.

This method might be overkill for simple projects, but it’s more ideal for complex ones that have evolving requirements. The disciplined approach means teams can deliver high-quality software consistently.

Why Kanban makes the most sense

After exploring other project management methods, we’ve discovered Kanban to be the most suitable. Unlike other methodologies, Kanban adapts to how your team actually works.

With this method, work is visible, and the flow is more manageable. Unlike Scrum's rigid sprint structure or XP's intensive practices, Kanban allows teams to visualize their work, limit the tasks in progress, and optimize their workflow.

Teams use a board (physical or digital) to represent work items as they move through different stages of development. The visualization makes it easy to spot bottlenecks and opportunities for improvement.

No need to reorganize your team or create artificial time boxes. Simply start with the current process and gradually improve it instead of doing a complete overhaul like you would with methods like Scrum or XP. This makes it ideal for teams that are transitioning from old methods.

Perhaps the most powerful feature of Kanban is the concept of WIP (work in progress) limit. By limiting the number of items that are being worked on at any given stage, teams avoid the productivity-killing effects of context switching and overburden.

How Kanban ultimately works for us

Kanban really shines in environments where priorities can shift quickly and work items can vary in size and complexity. Instead of forcing all tasks into fixed sprint cycles, Kanban lets you add urgent work without disrupting the entire system. This flexibility allows teams to respond nimbly to changing demands.

You can quickly spot areas where work is getting stuck or piling up and take corrective action. Kanban also helps you scale work based on your actual capacity. This ongoing flow allows for faster feedback cycles and more opportunities to iterate and improve.

By monitoring flow, teams can accurately forecast completion times for different types of work. This means you can plan more reliably and provide better expectations to stakeholders.

References

https://www.pmi.org/learning/library/quick-history-project-management-8919

https://scrumguides.org/scrum-guide.html#sprints

https://www.researchgate.net/publication/2333697_The_Costs_and_Benefits_of_Pair_Programming

https://www.scrum.org/resources/kanban-guide-scrum-teams

https://www.planview.com/resources/guide/introduction-to-kanban/what-is-kanban-board/

http://www.extremeprogramming.org/