In our previous episode, we talked about the importance of visualizing your current work-in-progress to uncover bottlenecks, enhance decision-making, and provide clarity on your team's workload. Now, let's tackle what often comes next: realizing you have too much work in progress.

Why does this happen so often to development teams, and what can we do about it? In this episode, we're diving into strategies to manage and prevent this overload. We’ll cover setting WIP limits, staying responsive, and juggling organizational demands effectively.

Tune in to hear how to avoid overcommitting, the perks of prioritizing and finishing tasks before jumping into new ones, and how to use Lean principles to keep your workflow sustainable.

When the kind of work we do is invisible (like software development), it can be a challenge to keep track of what work is going on at any given time. That's where visualization can be a great tool for understanding your team's work in progress.

Building on last episode's discussion on creating workflow visualizations, in this episode, host Phil Ledgerwood explores the importance of visualizing work in progress to uncover current projects in flight and find hidden bottlenecks and inefficiencies. I discuss the pros and cons of common WIP visualizations (lists, Kanban boards, etc.) so that you can decide on a visualization that fits your unique workflow, even if it means thinking outside the box.

A lot of what we do in software development is invisible. If someone is typing furiously on their keyboard, you don't know if they're about to finish that new feature or if they're complaining to their state representative.

One of the things that tends to be invisible is the actual process of getting something from “request” to “deliverable.”

Everybody kind of knows what that process is, but they typically only know their piece of it, and they probably haven't thought critically about it in years.

Creating a visualization of this process can:

• Spotlight potential weak points
• Improve communication
• Reveal the complexities of your team's workflow
• Uncover hidden opportunities for optimization

In this episode I'm sharing practical tips for mapping out your processes, understanding team dynamics, and setting the stage for continuous improvement.

When managing a new team, it's tempting to come in guns blazing with new ideas and changes. Not only can this cause resistance, however, but you might be heading the wrong direction to begin with.

Start with Fact-Finding and Reason-Finding before Recommendation-Making. In other words, one of your first moves should be to ask a lot of questions—"why" being one of the most prominent of them.

This sets you up for success with your team because:

• You may discover there are good reasons for their current practices that are not immediately apparent to you
• It lays the foundation for future discussions, focusing on the reasons behind the practices rather than the practices themselves—making the conversation ego-agnostic.

In this episode, learn how to create a safe environment to gear up your operations for change and set you and your team up for future success.

Many of us who were thrown into management positions over development teams had to learn on the job. And when that happens, it can be easy to fall into the role of what you THINK a manager should do—be the rule enforcer and hold the team accountable.

But as a dev team manager, your primary role should be to enable your team to deliver value effectively and efficiently.

In other words, get out of your team's way and empower them to do their best work. How does this actually play out, though?

In this episode, I'm sharing the lessons I've learned and things I wish I had understood when I first started managing dev teams. Whether you're a new manager or a seasoned veteran, this episode provides practical tips for keeping you and your team on the same side working towards a common goal.

If you're a CTO, manager, or team lead looking to develop software faster, this episode is for you!

If someone has told you that you shouldn't -want- to shorten time to delivery, this episode is also for you. Because they're wrong.

Wanting speed isn't a bad thing—assuming you are building the right thing (which is the main problem Agile addresses).

As teams do grow in their agility, they do tend to become faster for all kinds of reasons—but it's not directly because of Agile. Speed isn't the goal of Agile. Making sure the right software comes out the door is.

But there are definitely process improvements you can make that can also increase your speed of delivery, and you should want that.

In our most click-baity titled episode yet, I talk about the actual things that are influencing your rate of delivery and how to deal with them.

Have you stopped and asked yourself and your organization, “Why are we doing this?”

You may or may not be surprised to find out that a lot of organizations make decisions, choose frameworks, and prioritize projects simply because of inertia and not because there's a real reason behind it.

Why would you put time and resources into maintaining structures whose reasons have been lost to antiquity or never existed in the first place? It seems like common sense to individuals, but that often doesn't translate on the organizational level.

This episode delves into the importance of understanding the reasons behind technical decisions and the pitfalls of following practices or working on projects without understanding their original purpose or questioning their current relevance.

Defining the ‘why’ helps ensure that actions are not only based on historical momentum but are relevant, justified, and beneficial in their current context.

Hey managers, let's talk straight: Is Agile a scam? In your context, it just might be.

Agile has become the default for teams, but do you truly understand WHY you're using it or if you even need it?

In this episode, we're stripping away the Agile buzzwords, getting back to basics, and exploring the essence of Agile from a manager's perspective.

Forget sprints and user stories—Agile is all about responsiveness to change. By starting with this fundamental principle, you can avoid getting tangled in specific practices or frameworks that don't fit your organization.