The Middle Child of Project Management

If you've been around the PM game for a minute, you've probably noticed most conversations about methodology tend to live in two camps: the traditional waterfall folks and the agile Scrum enthusiasts. But there's this whole middle ground that doesn't get nearly enough love. Kanban, the middle child of project management methodologies that often flies under the radar or gets overlooked altogether.

If you're a round peg struggling to fit into the bounds of the Waterfall or Scrum boxes then I urge you to give Kanban some consideration for your next project.

But before we dive deeper, let's talk about where Kanban actually came from.

A Quick History Lesson

It wasn't invented by some software consultant trying to sell the next big methodology. Kanban has its roots in Toyota's manufacturing system back in the 1940s and 50s. The word "kanban" literally means "visual signal" or "card" in Japanese.

Toyota used physical cards to signal when parts were needed on the assembly line. If a workstation was running low on components, they'd display a kanban card, and that would trigger the previous station to produce more. Simple, visual, and incredibly effective at preventing both overproduction and shortages. From a software development stand-point, everyone can see what's in progress, what's blocked, and what's coming next. No one's surprised by workload, and bottlenecks become obvious before they become problems.

David Anderson adapted this concept for knowledge work in the early 2000s, recognizing that software development teams faced similar challenges. Too much work in progress, unclear priorities, and bottlenecks that nobody could see until it was too late. He took Toyota's visual signaling system and applied it to managing the flow of work through development teams. The beauty of this approach is that it's built on decades of proven manufacturing principles, but adapted for the reality of knowledge work where tasks are less predictable and harder to estimate.

So how does this translate to modern project management? Let me paint you a picture.

Reality Check

You're managing a data pipeline maintenance project for a client. It's not a traditional waterfall project with defined phases and deliverables. But it's also not a new product development effort that is well suited for Scrum. It's somewhere in between.

It's continuous work that needs to flow efficiently without the overhead of sprint ceremonies. This is where Kanban shines. We're not always building something brand new from scratch, and we're not always following a rigid sequential process. We're managing flow, optimizing throughput, and keeping work moving to deliver value.

Where Kanban Makes Sense

Each methodology has its own sweet spot in terms of the type of project they are best suited for. I'll talk about when Kanban is not an ideal use case in a bit, but for now, here are a few specific scenarios where Kanban might actually help your projects flow better.

Operational and BAU Work:

Think support tickets, infrastructure maintenance, or ongoing data pipeline monitoring. This stuff doesn't fit neatly into sprints, but it absolutely needs structure and visibility.

Teams Transitioning from Waterfall to Agile:

If you've ever tried to take a traditional team straight to Scrum, you know it can be like diving right into the deep end with no floaties. Kanban gives you that agile mindset without the ceremony shock.

Cross-Functional Initiatives:

Initiatives where you're orchestrating work across teams that already have their own established processes. Rather than trying to convert everyone to Scrum or waterfall, Kanban acts as a coordination layer that sits on top of existing workflows, making dependencies and bottlenecks visible without disrupting how each team actually does their work.

Team Make-up:

This is a common one. You have a team made up of experienced seniors who are exceptional at what they do. They hold themselves accountable and don't need or want to be beholden to endless scrum ceremonies and artificial sprint timelines. Their leadership trusts them to get their work done and deliver in a timely manner.

Kanban gives them the autonomy to manage their own flow while still providing the visibility leadership needs. This often happens with specialized roles like data engineers, architects, or senior developers who work on complex, hard-to-estimate tasks.

Traditional PM or Scrum Master?

Okay, now to address the elephant in the room. Who should be managing a Kanban project? A traditional PM or a Scrum Master? In my opinion, I think Kanban is more PM-friendly than Scrum, and here's why.

Traditional PMs are already comfortable with managing flow, tracking metrics, and optimizing processes. We're used to being the person people come to for answers about timelines and throughput. In Scrum, you're supposed to step back and let the team self-organize. In Kanban, you're actively managing the flow and helping optimize the system. To me, that feels more natural to most traditional PMs.

But here's where it gets interesting. With a little bit of a mindset shift, you don't really have to choose. I've started thinking of this role as a "Flow Manager". You're taking the best of both worlds: the servant leadership approach of a Scrum Master with the process optimization skills of a traditional PM.

More on what a Flow Manager is and the value they bring next.

The Reality of Being a Flow Manager

A Flow Manager is 100% focused on optimizing how work moves through the board. They actively manage work-in-progress limits, facilitating flow discussions about capacity and priorities. They are still doing the relationship management and stakeholder communication that PMs excel at, but also embracing the always-be-optimizing mentality that makes agile teams effective.

Really analyzing what's stuck, what's moving, and what's about to become a bottleneck. Not micromanaging, but using pattern recognition and sifting through details to determine the story the board is telling.

When work starts piling up in one column, that's not necessarily a failure. That's valuable information. A Flow Managers job is to make that visible and facilitate the conversation about what to do about it. Keeping a close eye on team metrics (more on this later) will help give the Flow Manager accurate data to act upon. This is agile after all, so the goal isn't to control the work, it's to optimize the flow of work by coaching the team towards continuous improvement.

When NOT to Use Kanban

Kanban isn't going to be the answer for every project. If you're working on a complex, milestone-driven project with fixed deliverables and dependencies, like a house remodel or building an office complex, stick with waterfall. The structure will be necessary.

If you're developing a new product with a defined team that can commit to sprint goals, Scrum is probably your best bet. The ceremonies and time-boxed iterations will help keep you focused.

If you're in a highly regulated environment where every step needs to be documented and approved, waterfall's your friend.

Where Kanban Can Go Wrong

Just because Kanban seems simple doesn't mean it's easy. Often teams crash and burn with Kanban just as spectacularly as they do with any other methodology.

Here are a few pitfalls to be mindful of so you can avoid altogether or course-correct early.

False Flexibility: 

This is probably the biggest one! Teams get excited about the flexibility and think because there are no sprints, there are no commitments. But your stakeholders still need predictability. Your clients still have deadlines. Just because you're using Kanban doesn't mean you get to ignore the business realities around you.

The flexibility isn't about avoiding accountability, but rather about optimizing how your team delivers on their commitments. Hint: implementing work-in-progress limits will help with understanding priority and avoid turning the board into a chaotic mess.

Measurement Avoidance:

Some teams use Kanban as an excuse to avoid metrics altogether. Accountability does not go out the window when using Kanban. A few metrics to track include: lead time, cycle time, work-in-progress, and throughput.

• Lead Time - The time it takes for the team to complete an item from request to delivery. This is your "customer experience" metric.

• Cycle Time - Measures your team's actual working efficiency from when work starts to when it's completed.

• Work-in-Progress (WIP) - Tracks how many items are actively being worked on at any given time. Crucial for managing flow and preventing bottlenecks.

  
  

• Throughput - How many items your team completes over a specific time period. This measures your delivery rate.

Stakeholder Confusion:

This is a challenging one for sure. Executives who are used to the sprint demos and milestone reports will struggle with Kanban until a rhythm of delivering value continuously is established. Keeping the Kanban board visible to leadership and religiously up to date will help with this transition.

Process Stagnation:

Teams start with a simple board and then... never evolve it. They treat their initial setup like it's set in stone. Six months later, they're still using the same three columns that made sense when they started, but their work has completely changed. Kanban boards should evolve with your team and your work.

The key is recognizing these pitfalls early before they become project killers.

That's All She Wrote

So there you have it. The beauty of Kanban is that it meets you where you are. Whether you're drowning in operational work that doesn't fit sprint boundaries, managing a team of senior engineers who thrive on autonomy, or trying to wrangle cross-functional chaos into something visible and manageable. Kanban might just be the middle ground you didn't know you needed.

Don't expect perfection from day one. Like any methodology, it takes practice, iteration, and yes, you'll probably mess up a few times. But that's where the iterative improvement comes in handy. Start simple, measure what matters, and let your board evolve with your team.

If you're feeling stuck between methodologies or dealing with work that just doesn't fit neatly into sprints or sequential phases, maybe it's time to give the middle child some love.

Happy flowing!

xx Kristi