Every Scrum master's nightmare is their team wanting to switch to Kanban. It's easy to look at a shiny new framework and think that it's going to solve all your problems. 

And while we do think that Scrum is not the best fit for most software teams, there are both good and bad reasons to consider before jumping into another framework.

In this episode, get ready to think about some hard truths (like, is the problem your framework, or is it something going on in your team?). And also hear about some good reasons to make the switch to Kanban.

True or false: For Kanban, Monte Carlo, and Little's Law to work, your work items have to be a similar size. 

When we think about forecasting work, it's easy to think that the best way is to add up the total amount of time it takes to complete something and use that to predict the future. But that's actually not the case.

In this episode, learn how you can let go of worrying about making all your cards the same size in order to get accurate forecasting.

Regardless of what Agile strategy or framework a team is using, at the end of the day, one of the biggest questions teams are trying to answer is, “What can we get done in a certain timeframe?” 

And some choose to address this by using velocity: adding up the number of story points delivered in a sprint and using that to determine how much can get done in a future sprint. But does that really make sense with how story points work? And more importantly, is it even accurate at predicting future work?

In this episode, find out why we think velocity is actually meaningless and learn about better alternatives you can use to predict your team's output.

So you've found your constraint—what now? (or maybe you haven't found your constraint yet. In that case, scroll back a few episodes and listen to “Finding the Constraint” first!)

Your constraint is basically what's controlling the pace of your whole system. So now that you've found it, you need to optimize it so it's working continuously and effectively (notice that we didn't say to get rid of the constraint!) 

In this episode, we're giving you practical tips to optimize your constraint so that you're putting your efforts to improve your team's flow in the right place. 

Just because the “Q” in “QA” stands for “Quality” doesn't mean that this role should be the only one who's responsible for making sure features are up to standards. 

Unfortunately, too many QAs spend their limited time just making sure that features WORK, let alone finding edge cases and addressing actual bugs. And then they have to pull the developer back in to fix the feature after the developer has already moved on to the next one. Talk about a bottleneck! 

Quality can't only be QA's job—it needs to be everyone's job. Spending the time building in quality up front will prevent overhead involved in re-work, keeping your system flowing and allowing QA to do what they're best at. 

In this episode, you'll learn three actionable steps to start making quality a team sport for your software development team.

When Daniel was learning Karate in The Karate Kid, Mr. Miyagi had him start by doing tasks over and over without explanation so he could master the basics before actually using the martial art on his own. And this method of mastering a skill is something we see across many disciplines outside martial arts—sometimes it's even applied to learning agility.

But is following and mastering “the rules” before venturing off and making your own improvements the best way to start to increase your agility? We say no, because getting good at executing a framework is missing the point of being Agile. 

In this episode, we hope to encourage you to look at your team's unique goals and desired outcomes and feel free to step outside of “the rules” so you can focus on what's working and leave behind what's not.

Hopefully, you know by now that limiting your work in progress is the solution to a lot of delivery problems. Both Scrum and Kanban have their own ways of limiting WIP, but there's another way you might not have heard of: Drum-Buffer-Rope scheduling.

In this episode, learn what Drum-Buffer-Rope scheduling is and how it can align the activities of your team and reduce bottlenecks in your flow.

One of the benefits we can get out of Agile and Lean processes is the ability to forecast work based on a team’s metrics. But if you’ve just started tracking your cycle time and running Monte Carlo simulations, and your results are all over the map, this podcast is for you.

We’re sharing with you what things need to be in place so that when you do run forecasts or look at your cycle time scatterplots, you’ll see results that are meaningful, useful, and actionable.

Every system, no matter how optimized, has a constraint—the point in the system that has the lowest throughput. But do you know where yours is? And what are you doing about it? 

Knowing your constraint means knowing where you can make meaningful improvements to your system. Because if you make improvements to the wrong part of the system, you could actually make your flow worse (*cough, cough* hiring more developers when they're not the actual source of the bottleneck).

In this episode, learn why you should know where your system's constraint is, how you can find it, and what options you have with what to do with it.

The whole concept behind using the word “flow” in “workflow” is that work keeps moving forward. Sounds nice, right? But we all know it's a little ambiguous in practice. What about those times when cards seem to need to move backward on the board? Like when QA finds a bug—should the card move back to Dev? 

To answer that question, we first have to remember why the columns on the Kanban board exist in the first place: to be stages of transformation—not roles or specific activities, per se. And with that teaser, you can probably guess what our answer is. If not (or even if you have), listen to this episode to find out!