When people say they want to start increasing their agility or do more Agile software development, they almost automatically start with Scrum. But the problem is that they're not asking whether Scrum is actually the right framework to use for their specific scenario.

In this episode, host Phil Ledgerwood goes over the indicators that tell you if Scrum can be helpful for your team, or if it's time to experiment with some other Agile frameworks that might be a better fit.

We all know keeping our WIP limited is a good thing—Scrum does it with a Goal and timebox, and Kanban does it with a stated limit.

But are you paying attention to your arrival rate and departure rate? In other words, are you starting new items at the same frequency that you’re finishing them? 

In this episode learn why you should care about and control how often we start new things—because it has a whole lot to do with how often you finish things.

Everyone says they have a software development team, but do you really? Or is it just a group of individuals who kind of work together?

Software development is a team sport. We want to be operating as a team—not a group of many silos. And as more and more software teams are no longer co-locating, having intentional and real team dynamics is even more important now than ever.

In this episode, Host Phil Ledgerwood shares indicators that you do or do not have a true team dynamic in your software development team and what you can do to change that.

There are a lot of different metrics out there for keeping track of your team's workflow. But in this episode, we're sharing the three metrics that we find valuable to keep an eye on and some ideas on how to use them for your own team—not just for planning purposes but also for good discussion on how your team can improve.

What outcome are you expecting from Agility?

This is the most important question for organizations and teams to be asked when it comes to using Agile methods, but it's also commonly overlooked. And, of course, that leads to missed expectations—like a team increasing their responsiveness when all they really wanted to do was go faster.

To know you're using the right method, you have to make sure you're addressing the right problem—and sometimes the typical understanding of “Agility” isn't the solution a team is looking for.

Everyone has had their own path that introduced them to agility, and that path shapes the way we see and interact with the concept in our roles today.

In this episode, Host Phil Ledgerwood takes a brief walk down memory lane and shares how his path led him to his mindset on agile. His biggest takeaway? Whatever you’re sold on today, be ready to leave it for something better—that's what agility is all about.

Story points—some teams find them useful for having discussions to align their understanding of what a story entails. But the points are not actual quantities of anything. So why are so many teams still using story point velocity to forecast how much they can get done within a sprint? And why are so many people on LinkedIn so adamant about it? We're still trying to figure that out.

But in this episode, for once and for all, host Phil Ledgerwood is breaking down why story points are, at best, complicating your planning, and at worst, misleading you into thinking your timeline plan is accurate.

While test-driven development (TDD) might seem like a technical topic, it has a profound impact on the agility of software development.

This episode explores how TDD integrates testing throughout the development process, minimizes rework, lowers risk, and fosters a shared understanding of project goals among team members—ultimately creating better software for the user.

Whether you're a technical role or not, this episode will give you the tools you need to understand the basics of TDD and its the positive effects it can have on the software development process.

Conway's Law says that any organization's system design reflects its communication structure. But is it really a law, or is it more of an observation?

Conway's Law is often misused by consultants attempting to create a mechanistic relationship between organizational and software structures (i.e. if one side changes, the other side will change too). But even though Conway's Law has “law” in the name, that's not quite how it works. But that doesn't mean it's not important to know about.

Whether you're new to Conway's Law or a seasoned professional, this episode will challenge your thinking and provide valuable insights into how to navigate the intricate relationship between organizational structure and software architecture

There are a lot of people claiming to be authorities and thought leaders in the agile community sharing their take on agile practices. So what is their value and how much should we be listening to them?

Agile thought leaders have their place. But in this episode, we hope you know the value of your knowledge of your own unique set of circumstances and feel empowered to experiment and find what works for your team.