Agile Bites

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.

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.