Agile Bites

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!

So you like the idea of a Kanban board and you want to set one up. But how do you know how many columns you need? Or what to label each column? These questions can be answered by mapping out your team's value stream: the series of transformations an item has to go through to be converted from its raw form into a deliverable valuable form.

In this episode, go beyond “to-do, doing, and done” and learn about the value behind having the right columns on your board so you can optimize your team's flow.

The cornerstone of any relationship—at work or elsewhere—is trust. But unfortunately, it's something that many software teams lack, causing a whole slew of problems including dysfunction and inefficiency.

In this episode, we let you in the two biggest ways we build and maintain trust at our organization and how you can do it in yours too.

Ever get the feeling that the traditional “project” paradigm for software isn't quite fitting with agility? That trying to estimate the cost of the project versus the value of the project is just not ever working out the way you thought? Us too. And that's why we're proposing a different way to look at software projects—in a flow paradigm, where software is delivered in a stream, not a box.

In this episode, learn what we mean by a “flow paradigm” and how it can change the way you plan, monitor, and fund your software efforts.

We know we're supposed to be dividing our work into small, deliverable chunks and reflecting that on our boards. But what should we do with the occasional tasks that don't exactly have a tangible deliverable at the end of them (e.g. research, proof of concept)? 

In this episode, we're helping you build a policy for when spikes and research stories come along so you can stop trying to retrofit abstract tasks into user stories and keep your board flowing with deliverable value.

As soon as work begins, the clock starts ticking and work items start aging. But when work sits longer than it needs to, it throws off your flow of value and increases the chances for the work to change.

In this episode, learn why should we care about work item age and what you can do about it so that your team delivers a consistent stream of value.

We'll spare you any more suspense after reading this click-bait title—in this episode, we're talking about throughput. Throughput reveals chaos happening on your team, helps you plan, and can show you where to improve. That's why this is one metric you need to track if you aren't already.

Learn how you can easily start tracking your team's throughput and how you can use it to make your team better at getting valuable software out the door.

Building software requires a lot of bringing lots of different pieces together. But when some of those pieces depend on others outside your team, there's more opportunity for bottlenecks and inefficiencies. But while dependencies are unavoidable, there are ways to avoid it becoming a bigger problem.

In this episode, we're going over two ways to handle cross-team efficiencies—even when the dependency isn't significant enough to justify adding a new person to the team.

Agile Coaching as a professional seems to be going through a shift right now. Recent headlines show large companies laying off large numbers of Agile positions. Some Agile coaches are rebranding what they do. It all raises the question: What is the value of an Agile coach and are we as coaches delivering on it?

In this episode, we're giving our two cents what we see causing this shift and how Agile coaches can stay ahead of it by proving and owning real value for their clients.

If you're implementing any new practice (and that includes Agile practices), you're likely to come up against some obstacles.

At first, the practice might not work out the way you imagined it to. But an obstacle doesn't mean it's the wrong thing to be doing. In fact, obstacles are often the mechanisms by which we ultimately find success. They can be the signs that help us find what the right direction is

In this episode, we're talking about how to approach and not just overcome, but USE obstacles to your advantage in finding and implementing the best solutions for your situation.

Does your sprint planning include sprint goals? Sprint goals are a “newer” addition to the Scrum Guide (if 2013 counts as newer), yet many Scrum Masters seem unfamiliar with them. Broken down, the sprint goal is an explanation to stakeholders of why this sprint is valuable. It's what guides the decisions on what a team will work on for the next sprint.

In this episode, discover how to create good sprint goals that can positively impact your process, get everyone on your team on the same page, and increase the buy-in of stakeholders.

Budgeting in an Agile world is difficult. We request money upfront but don’t know what the project contents will be or how it will turn out. This makes it hard for both internal budgeting processes and firms to quote prices. Throughput accounting is a great solution, but not every organization is ready to make that switch. But there is a way to start the transition from big batch, cost-based funding to more value-stream-based funding—using MVPs to budget.

In this episode, we're giving you an inside look into how some of our clients have taken this different approach to project budgeting that keeps one foot in the “traditional accounting world” while the other is in the “incremental delivery of value” world.

Why do we try to size user stories in software development? And how are we supposed to accurately make guesses about how long our work is going to take?

In this episode, we're breaking down a couple of popular approaches to sizing user stories and then talking about how we can forecast projects without doing any sizing at all.

What are user stories supposed to be? And who should write them? Product Owners? BAs? Devs? Users? ChatGPT?

Despite the ways many people have convoluted and complicated user stories, the answer is in the name. They are stories that users tell you about the things they need to get done and why it’s important to do them

In this episode, we're sharing with you the no-nonsense way to approach user stories so you get the information you need and users get what they need out of the product.

If your demo has become a meeting just to check off a box and cross your fingers hoping no significant changes get brought up, you're missing out on a lot of value. In this episode, we're sharing with you why we see demos as a time to gather better requirements and build trust with users.

Building software requires a balance of solid planning but also the availability to pivot and adapt. So how far should you be planning ahead for your projects?

To answer this question for your team, you have to ask yourself 1) how likely your plan is to come out wrong, and 2) how quickly your team completes work. Because the time you're using to make a plan that's likely to change anyway could be time better spent doing what needs to be done now, giving you the right information for your next move.

What does it even mean when someone says they "do Agile"? And why does "doing Agile" automatically mean using Scrum (apparently)?

There's a lot of conflation when it comes to the terms "Agile" and "Scrum." And in this episode, we're clarifying the difference between the two and how using them synonymously can limit the potential of Agility.

People often say a focus on process means you don’t care about people. But it's actually the opposite—Agile done well is really about caring for people.

When you improve processes, you are improving the lives of people. You empower them to reach their potential and feel fulfilled in working with dignity rather than dysfunction.

It's caring for people that makes us passionate about processes. That's why we work the way we work at our own software development company, and it's also why we made our #1 core value "love."

Join us for this holiday episode of Agile Bites as we spread the love of our fellow human beings through improved processes.

Imagine being able to predict with a high degree of accuracy when your team is going to complete a project. How would knowing that information change what you're doing right now?

By running Monte Carlo simulations, using completion rates from your team's past, you can peek ahead at your project's risk and the probability of possible completion dates—helping you make better decisions while you still have the chance to affect the future.

If you're not already running Monte Carlo simulations for your team, you will after listening to this episode. What are you waiting for—all the cool kids are doing it!

As an organization grows in its agility and gets rid of old models, what happens to the role of traditional project management? What do you do with the skill set, knowledge base and rich experience that our project managers bring to projects?

Before you go making your project managers into Scrum masters, we're telling you the ways that project managers bring their own value to the table within a team pursuing agility.

If you're on LinkedIn at all, you've seen the classic "Efficiency vs. Value" dichotomy. While stating that teams should focus on delivering value and not efficiency makes for a punchy post, elevating one while ignoring the other doesn't make sense.

Caring about efficiency doesn't mean you don't care about value. If you care about producing value (which you should), one of the best ways you can do this is by increasing your efficiency, thus getting things into the hands of users more quickly and getting their feedback quickly.

So if the false "efficiency vs. value" dichotomy ever makes you feel like caring about efficiency comes at the expense of delivering value, this episode is here to tell you that you CAN and actually MUST successfully care about both.

Despite how "limiting" limits on work in progress sound, they're actually an excellent tool for improving your team's flow and speed. WIP limits optimize your team for FINISHING rather than starting. And that cuts down the time work spent in progress, getting features in the hands of users faster and you receiving feedback sooner.

In this episode, we're showing you the value of WIP limits (whether you're using Scrum or Kanban) and sharing approaches and tips to get the most benefit out of them.

So you've got an idea that you think will make your team's lives easier, but the only way it will be implemented successfully is if they all get on board. So how do you convince those involved to accept, and better yet, support the vision?

In this episode, we're breaking down strategies for getting buy-in. And *spoiler alert* — it's not always about it being your idea.

Happy, Halloween, Agile Spooks and Ghouls! In this special episode, we're sharing three truly chilling Agile horror stories about the Middle Management Slasher, a shadowy project with no owner, and the treacherous Pit of WIP.

So gather around, grab your emotional-support sticky note pads, and get ready to hear some bone-chilling software tales of Agile terror.

Despite the coder stereotype, programming is not best done alone in a dark room. Building software is a team sport, and features are best tackled by tackling them as a group (aka swarming).

Swarming is one of the most powerful and effective ways to increase your team's throughput. But so many teams struggle to execute it. Find out how simple swarming really can be for your team and how it can not only increase efficiency but also morale.