Agile Bites: Recent Episodes
Integrity Inspired Solutions
There is a lot of material on how a team should operate in an agile manner. There is also a lot of material for leadership as to the benefits of agility, the mindset, etc. But there is not a lot of material directed towards those folks who sit in between.
Agile Bites breaks down key Lean and Agile concepts and practices for the people who are often tasked with supporting these things. People who may have to be redefining their roles in a world of incremental delivery. Or maybe they’ve been put in the middle of an “agile transformation” and things are not going as well as promised.
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.
Should we be slicing stories vertically or horizontally? Does it even matter?
Should we organize the requirements in our user stories by architectural layers or by small units of functionality?
Both approaches divide the work up into smaller batches, but what good are pieces of software if they're not actually usable? That's what happens when we slice stories horizontally (e.g. a user story to build a non-functional screen).
Horizontal slicing brings on risks to the organization, like:
- Prematurely prescribing an implementation
- Lengthening the feedback loop
- Delaying value delivery
- Misaligning user story delivery metrics
Vertical slicing, however, allows our teams to be agile by ensuring the delivery of functional, valuable capabilities driven by user needs and feedback
Wondering what scaled Agile framework is right for your organization?
If this is your question, this episode is not going to answer it for you because we don't think that's going to bring you the most value. Instead, we're going to challenge you to take a step back and ask why you need to scale and why you're Agile in the first place.
Just because your organization is “big" and your current framework is causing friction, that does not mean finding the right scaled Agile framework is the answer (in fact, it's usually not). And implementing a scaled framework might actually cause more pain than not.
In this episode, we explore the underlying reasons and common misconceptions behind scaling, from the classic scenario of numerous teams to the allure of frameworks like SAFe. Discover how you can navigate dependencies, optimize team structures, rethink release cadences, and look at your team's framework from a different perspective to get to the Agility you're looking for.
Traditionally confined to creating hefty upfront requirements documents, BAs find themselves at a crossroads in the Agile world. However, we believe BAs hold the key to promoting agility and delivering maximum value to organizations.
In this episode, we challenge the notion that BAs are mere translators of requirements into user stories. Instead, we highlight the rich business knowledge and questioning skills that BAs possess. By delving deep into business processes and understanding the "why" behind them, BAs can unearth genuine value in user stories.
BAs also have the unique opportunity to uncover hidden needs and facilitate cross-functional dialogues that drive process improvements. By fostering collaboration and aligning business objectives with software development, BAs can contribute to the creation of software that not only meets user needs but also enhances overall organizational efficiency.
In the year and a half that the Agile Bites podcast has been around, we've covered a lot of topics—from story points to stand-ups to MVPs and a whole lot more. And we hope it's been a helpful resource in our listeners' Agile journeys.
Now, we're taking a look at the future and asking ourselves, "What's next?" Listen to this episode to hear from Host Phil Ledgerwood about the new direction of Agile Bites, and we'd love for you to be a part of it by leaving your feedback! Leave a comment on this platform or email Phil at phil@integrityinspired.com.
If we had a dollar for every piece of “authoritative Agile advice” out there, let's just say that we'd have a lot of money.
Sharing the successes, failures, and lessons learned is so valuable to all of us on an Agile journey. But it's important to keep your filter up for not only false information, but also true information that doesn't fit your situation.
In this episode, Host Phil Ledgerwood dissects some “authoritative” facts and figures about so-called “full Scrum” vs. “lightweight Scrum” to demonstrate how easy it can be to fall into the trap of misleading Agile guidance.
The lesson here? Don’t blindly accept what anyone says, no matter the source (even this podcast!). Always investigate, weigh it carefully, and experiment for yourself.
Traditionally, QA has been synonymous with manual testing and has been established as its own post-development phase. But in an agile landscape, that setup can lead to bottlenecks and silos. That's why we advocate for making QA a strategic player throughout the entire development journey—not just at the end of development.
Tune in to gain insights on reshaping QA practices and maximizing its impact on the entire value stream of software development.
We all know we should get user stories as small as they can be, but can we go too far?
Yes, user stories should be as small as we can get them, but they also need to be a valuable delivery (e.g. a user story should not just be a technical task).
Tune into this episode for actionable tips on what to do (and what not to do) to keep your user stories both small and valuable.
Have you or someone you know ever been stuck with pages of requirements notes having to turn those into user story format (As a [persona], I [want to], [so that])?
If so, first of all, we're sorry. Secondly, we want to help you know that there are other—and better—ways to dealing with this situation, and that's what this episode is all about.
User stories should be user STORIES—pigeonholing them into a one-size-fits-all format takes away from the value they were meant to provide. Tune into this episode to hear a brief history of user stories and get back to the WHY behind them so that your user stories function the way they're supposed to.
You might be wondering what this controversial subject has to do with agility, but people in the agile community are already trying to figure out how this topic works in an agile environment.
How do we reconcile with the work-from-home debate when one of the principles of the Agile Manifesto is that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation?”
Ultimately, just like anything else, this is something that is heavily dependent on context and is a decision each organization needs to make. But this episode lays out the realities of both dispersed and co-located teams and presents ways to approach this topic from an agile perspective.
When you ask how long a project is going to take, do you ever feel like your developer team is telling you what you want to hear rather than reality?
Unfortunately, this problem is all too common in software development when it comes to estimating deadlines and giving progress updates. We're not claiming it's anything nefarious—humans are just bad at predicting how long things are going to take (especially when building a huge project for the first time) and they probably just want to keep you happy.
In this episode, learn what signs to look for if you're being lied to, why teams feel like they need to lie, and how to prevent a culture that incentivizes it.
So you've defined success for your MVP. But have you thought about how you're going to measure whether it's successful or not? It sounds simple, but it's often not.
Some measurements are black-and-white and easier to extract information from. But others (like sentiment) have a lot more gray areas and can be tricky to make decisions based on.
In this last episode of our MVP series, learn about different types of measurements (financial, technical, operational, and psychological) and how to extract valuable data from even the trickiest of factors so you can make smart decisions about your product.
Next in line on MVP series, we're talking about defining success for your MVP.
The point of an MVP is not to create a small version of the product—it's to get meaningful information that will inform your decisions about the product going forward.Because of this, how you define success plays a vital role in whether your MVP reveals valuable information about your product's viability.
What things, if they turned out to be true or false, would cause you to rethink this product or would convince you that you’re on the right track?
In this episode, learn about the different success indicators that can be considered and how to define those best so you can measure the valuable information to make informed decisions about your product's future.
Next up in our MVP series, we're talking about schedule and cost—two related elements that can trigger essential pivots in your project.
In this episode, host Phil Ledgerwood shares practical insights on estimating timelines, development costs, and additional considerations such as infrastructure and promotional expenses. Learn how these factors play a pivotal role in making informed decisions about your MVP.
How do you decide which features should make it into your MVP?
When people first think about MVPs, usually this is the point they jump to (side note: if you haven't listened to our previous episodes in our MVP series yet, go back and listen to those first!)
With countless feature options and probably many strong opinions, it can be challenging to narrow down what features you should invest in for your first MVP.
In this episode, Host Phil Ledgerwood shares the framework and exercises he uses to help define MVP features with that will be valuable for future decisions about your product.
Forget about software for a second and think about what your user actually wants to accomplish. Why would they want your software in the first place? What are you helping them to get done more easily than they could without your software?
Those questions are what you should be thinking about when it comes to user journey—not screens or features. Because your users don't inherently care about those things. They just want to accomplish whatever they need to get done in a way that makes sense to them.
In this episode, Host Phil Ledgerwood explains the importance of user journeys and what you need to think about as you go about understanding how your users will best interact with your product.
Next up in our series about MVPs, we're talking about personas. To know if people are going to use your product, you first have to understand the people you would be building the product for—because no product can be built for “everyone.”
In this episode, Host Phil Ledgerwood breaks down MVP personas into three parts: identifying potential users, understanding them, and empathizing with them. When you truly understand your potential users, that knowledge helps you build a product that serves your users better—and that should be your ultimate goal.
In the next episode in our series about MVPs, we're talking about the vision: the thing that guides, outlines the scope, and captures the value of the MVP.
Everything we do in the MVP needs to be geared towards the vision—not towards your idea of the final product. If it’s extraneous to the vision, it’s extraneous to the MVP. Sticking to the vision will keep you from wasting time and money on features that aren't necessary to validate the core of your product.
After 67 episodes, it's about time we talk about the MVP—Minimum Viable Product.
There are a whole lot of conversations online about what an MVP is and what it isn't. We're not setting out to define it once and for all. Instead, we're taking you through the same process we go through with our clients in this special series about MVPs.
And this first episode is all about the “what” and the “why” behind this framework that can help you validate a product idea before putting a full investment into it.
We're covering the last assumption of Little's Law in this series, and this time we're looking at why consistent units must be used for all measures
This one seems obvious and trivial, but that doesn't always translate on a practical level when we're thinking about how we want our work items and the planning around them to look.
This assumption comes down to deciding what unit of measurement is valuable for planning and communicating, and then only using those units—not transferring them to other ways of measuring.
In this episode, dive into this thought-provoking assumption with us and learn how consistency of your measurements can make your forecasts more meaningful, stable, and reliable.
It's time to unpack another assumption of Little's Law, and this time we're looking at how and why the average age of WIP must not be meaningfully changing.
This is probably one of the most misunderstood assumptions because people think everything must be the same size. But the key to remember here is the word "average." Little’s Law needs the average age to stay level— not each individual age to stay level.
In this episode, Host Phil Ledgerwood talks through this assumption and its upsides/downsides.
We've been working our way through a series on the assumptions of Little's Law, and this episode is about the importance of keeping your WIP constant in your system as a whole.
Little’s Law doesn’t tell you the right amount of WIP—it just wants it to be stable so that you're pulling work at the same rate that work is completed. This way, your system stays flowing and is neither underworked nor overworked.
In this episode, Host Phil Ledgerwood illustrates how this assumption of Little's Law works, and how you can implement it in your team.
When a card gets pulled to work on, that should mean that the team is committing to not only starting it but also (and more importantly) finishing it.
Now, we all know that it's not always that simple. Blockers happen, new priorities come down the management pipeline, and, unfortunately, cards in progress are forgotten or pushed backward into the backlog.
But at the end of the day, your team is judged on the work they finish—not the work they start. And that's why the commitment to finishing should be the highest priority rather than the commitment to start something.
In this episode, Host Phil Ledgerwood talks about why cards get started but not finished and how to avoid ending up in this situation in the first place.
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.
If you do Scrum, you know that the sprint is the heartbeat of your process. They're what many aspects of a Scrum team are based around. But Scrum often gets criticized for seemingly arbitrary time boxes around getting work done.
While we usually do love an opportunity to criticize Scrum, we don't think it's exactly fair to criticize it from a flow-based methodology perspective. Scrum and its time-boxed Sprint method are great tools…when used in the right scenario.
In this episode, Host Phil Ledgerwood explains why sprints have their place, the utility behind them, and for which scenarios they're best suited.
There’s a prevalent idea that Scrum is a good way to introduce a team to agility. But at the same time, a lot of teams are really struggling with Scrum. So is Scrum really a great place to start for a team new to agility?
In this episode, hear from host Phil Ledgerwood why Scrum was created in the first place, what type of teams it was intended for, and why it's most likely not the right place for a team to start.
Oftentimes in organizations shifting to be more agile and focusing on team-oriented operations and production, the question inevitably arises, “How do we deal with individual performance?”
Performance happens at various levels of an organization. To only focus on individual performance (and not the performance of the systems those individuals are working in) only tells part of the story - the least important part, really.
In this episode, host Phil Ledgerwood shares ways of measuring performance at the various levels operating in an agile organization and why it's important to do so.
➡️ Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
➡️ Visit our website
The title to this episode may seem like a question with an obvious answer. But we think it's important to discuss why it's a question at all, and why somebody might even think differently about it (because there are some good reasons).
The more you understand the issues associated with this question, the better off you're going to be strategically when you try to move your own organization to greater agility.
So tune in as we unpack this loaded question and look at how speed impacts agility.
➡️ Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
➡️ Visit our website
How often does your software team do releases? And when you do, how traumatic is it?
Many software teams may be agile in their workflow but still be very slow or inflexible when it comes to the actual delivery of value.
But what if we told you that your release cycles are -key- to how agile your team can actually be?
In this episode, Host Phil Ledgerwood shares why the big batch and infrequent nature of releases might be canceling out the value you're getting out of an agile workflow and what you can do about it to improve both the technical and cultural aspects of your agility.
➡️ Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
➡️ Visit our website
So you've identified the constraint. You've optimized your constraint. You've learned to subordinate to your constraint. Assuming you haven't skipped any of these important steps (if you have, go back and listen to those episodes!), now it's time to elevate your constraint.
In this episode, host Phil Ledgerwood discusses ways to get the most efficiency out of your constraint and increase its capacity to keep work moving forward.
➡️ Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
➡️ Visit our website
When you're starting to build an application, at what point should the database be designed? (To our non-developer listeners, hang in there—this is relevant to you!)
There are a lot of opinions on this topic in the software community, and many say the database should come first. But if you're building an application in an agile manner, why would you start with a piece of the project that the user can't interact with and give feedback on?
In this episode, we're discussing why we think starting with the database can not only hold back your team's agility, but also negatively affect the quality of the application in the long run. And we'll be giving some suggestions for better places to start that will help you create a more useful app for your users.
We all know that having lots of work in process causes problems when it comes to your delivery rate.
If you're on a Scrum team, this can look like items getting carried over from sprint to sprint, nothing being ready until the very end of the sprint, no capacity to respond to emergency fixes, or every new user story taking longer and longer to complete. These can all be indicators that your Scrum team has too much WIP.
But before you start thinking you need to incorporate other techniques and frameworks that focus on limiting WIP—did you know that Scrum already had a WIP limiting mechanism built into the framework?
In this episode, learn to take advantage of the ways Scrum can guide your team to limit the amount of work they have in progress and deliver at a more consistent rate.
Can you be a good scrum master or agile coach without experience in the domain you work on?
There are several schools of thought when it comes to this controversial question. Some say yes, some say no, and some say that technical knowledge can actually make you worse at your job.
What should actually be the standard? Who's to say? But in this episode, we're going over the different perspectives we've come across and sharing our viewpoint on the matter.
The title of this episode may sound counterintuitive, but it's actually the key to optimizing your team's agility.
When we say “working less,” we're not talking about slacking off—we're talking about balancing your workflow by subordinating your work stages to your constraint.
Having every team member produce the most amount of work at all times seems like the fastest way complete projects, but it's not. And it'll actually work against you.
In this episode, learn how you can start thinking about your team as a stream of value rather than individual units cranking out as much work as possible. And in learning that, we hope you more clearly see the path to delivering value in the most efficient way possible.
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!
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.
Blockers are something that almost all of us have to deal with at some point. When, for one reason or another, a work item gets blocked in the middle of the flow, how does your team handle it?
In this episode, we're talking about what makes an item "blocked," how to effectively represent them in your workflow, and some helpful tips to create an effective policy for blocked work items in your team.
Contact us at integrityinspired.com
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.
People tend to have a lot of mixed feelings associated with metrics. They can seem intimidating and like a lot of extra work—or even an oppressive tool used by some managers. But when used properly, metrics can be the guiding star on your path to Agility.
In this episode, we're showing you the value metrics can bring (hello, better projections and team improvements!). Plus, we're giving you three simple metrics you can start using with your teams right now. And trust us—once you start, you won't ever want to go back.
Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
Visit our website
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.
Before you write this episode off as another anti-Scrum talk, hear us out—Scrum is not a bad system, but a lot of the teams using it are not who Scrum was made for.
Scrum was meant for exploratory development—the kind of development when you don't even know the next piece you'll be building—and most software development teams don't fall into that category.
So why are so many dev teams trying to fit a round peg into a square hole with Scrum when another system would be so much more valuable? And what do you do if that sounds like you? Listen to this episode to find out!
Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
Visit our website
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.
If you've been listening to our podcast, you know we're not the biggest fan of themed retrospectives (see Ep. 1 "Retrospectives That Work"). But not everyone shares the same opinion, and some find them to be a valuable tool for their team.
In the spirit of sharing valuable knowledge and continuing the longstanding debate of themed retros vs. non-themed retros, we've invited a guest with a compelling argument for spicing up those retro meetings.
Hear from Chris Stone, an Agile coach who is an advocate and creator of hundreds of themed retro templates, as he shares his perspective on the value he's seen with themed retrospectives.
Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
Visit our website
Too many stand-ups (or daily Scrums, for our Scrum friends out there) have turned into status updates, and that's hardly valuable for anyone.
Say goodbye to everyone going around the circle, proving that they've been staying busy. Use your stand-ups as an opportunity for your team to come together and come up with their plan of attack for the day to stay on track as a group and reach team goals.
Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
Visit our website
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.
100% utilization rates— we know it doesn't sound like the most exciting thing to hear about, but it could be the key factor that's slowing you down.
What if we told you that the people working on your project should not be as busy as possible?
Sounds crazy, right? But if delivery is your ultimate goal, optimizing your system for everyone to be "busy" could be working against your flow and decreasing your delivery rate.
Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
Visit our website
This episode is for all you out there who've had to spend hours breaking down a requirements document into statements that say "As a role, I want a ____ so that I can ____." We're here to help clear the misconceptions, liberate you from that kind of work, and bring the user story back to focus on what's important: the user.
Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
Visit our website
Do you know why you’re trying to increase your organization's agility? What do you want to get out of it?
Identify the specific benefits and the specific reasons that it's worth it to you to make your organization more Agile. Because if you don't know the “why,” not only will you not know whether you've succeeded—you're not going to be able to pick the best way to get there.
Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
Visit our website
Are your retrospectives producing value for your team? Have they turned into unfocused complaining sessions? Or have people stopped coming altogether? Understand what's going wrong and learn how you can bring value back to your retrospectives (hint: it doesn't have to do with incentivizing with food or popular TV show themes).
Connect with Agile Bites Host Phil Ledgerwood on LinkedIn
Visit our website