Episode 22 – Lean, waste and bananas
/
RSS Feed
We all know that “waste” is bad. We use the term “waste” for all sorts of really bad things. Toxic waste, hazardous waste, nuclear waste. But when I start talking about the Lean concept of “Waste” I find it causes a lot of tension in organisations. Lean asks some hard questions of any organisation and one of the key ones is about value, and what we mean by value.
Lean focusses on the flow of value to the customer. Everything which the product produces which aligns with the customer need is considered “Value”. The customer will pay for this because the product is addressing the customer need. In general in software development this aligns with product features.
This podcast is AI-generated based on material from the “Agile Plays” website and book .
Transcript
Alright. So, let's deep dive into this whole waste thing in lean software development. You've sent over some really interesting stuff, including, bits from an agile playbook for scaling up. It seems like you're really keen on, making your development process as efficient and valuable as possible, and that's exactly where this idea waste comes in. Yeah.
It's absolutely crucial, especially as organizations grow. The concept of waste in lean software actually comes from lean manufacturing, which really revolutionized industries like car manufacturing. Right. And it's fascinating how these manufacturing principles can be applied to something as abstract as software. So help me understand this.
What exactly is waste in the context of software development? That's a great question. You see, waste isn't just about tasks that are completely pointless. It's anything that doesn't directly contribute to delivering value to your customer. It's about looking at your process with a critical eye and asking, does this actually move the needle for the user?
So it's about being laser focused on what truly matters. Cutting out the fluff? I can see how that could be a real game changer. Absolutely. Now Mary Poppendieck, a true pioneer in lean software, adapted the seven wastes of lean manufacturing to the software world.
These wastes give us a really practical framework for identifying and eliminating inefficiencies in our development process. Okay. Let's unpack these seven wastes. I'm curious to see how they manifest in software development. What's the first one?
The first one is partially done work. Imagine a car factory with a thousand half built cars just sitting around. That's a lot of tied up resources that aren't delivering any value. That's a powerful image. I can definitely see how that applies to software.
We've all been in situations where we have too many things in progress, leading to delays and context switching. It's like a mental juggling act that nobody enjoys. Exactly. That's why minimizing partially done work is so crucial. Now the second waste is extra processes.
We all know how bureaucracy can bog things down. But it's not just about eliminating processes altogether. It's about ensuring that every process serves a clear purpose and adds value. So it's about streamlining things and making sure that we're not just spinning our wheels. Okay.
What about extra features? How can a feature be considered waste? Well, a feature is waste if it doesn't actually solve a real problem for the user. It's easy to get caught up in adding bells and whistles that sound cool but don't actually deliver value. A classic example is that one complex feature that took months to develop but was barely used by anyone Coach that it's close to home.
So how do we avoid falling into that trap? By being ruthlessly focused on what the customer truly needs and values. This is where techniques like user story mapping and impact mapping come into play. They help us to prioritize features based on their potential impact and ensure that we're building the right thing. That makes a lot of sense.
So we've covered partially done work, extra processes, and extra features. What's next on the list? The fourth waste is task switching. You know how frustrating it is to be constantly interrupted when you're trying to focus on a task? Well, it turns out that our brains aren't designed for multitasking.
Every time we switch between tasks, there's a mental cost involved in reorienting ourselves. It's like trying to read a book, watch TV, and have a conversation all at the same time. Nothing gets done well. Exactly. And that's why minimizing task switching is so important for productivity.
Encourage your team to focus on one task at a time and create an environment that minimizes distractions. That's great advice. Yeah. What about the fifth waste, waiting? Mhmm.
I have a feeling we've all experienced this one. Oh, absolutely. Waiting is anytime that work is stalled for reasons outside the team's control. It could be waiting for approvals, waiting for information from other departments, or even waiting for the right tools or resources. It's like being stuck in traffic.
Yeah. It's frustrating, and it completely throws off your momentum. Precisely. And it can be a huge drain on productivity and morale. So identifying and addressing these bottlenecks is crucial.
Okay. So that's waiting. What's next? The sixth waste is motion. Now this might seem a bit strange in the context of software development, but it refers to any unnecessary movement or activity within the development process.
So we're not talking about literal physical motion? Not necessarily. It could be things like searching for files, searching for files, navigating complex systems, or even just excessive communication that doesn't add value. It's about streamlining things and removing any unnecessary steps or handoffs. Okay.
I'm starting to see how that fits in. So we've covered six wastes so far. Partially done work, extra processes, extra features, task switching, waiting, and motion. What's the final one? The seventh and final waste is defects.
I think we can all agree that defects are a major source of frustration and wasted effort. They represent rework, which means we're essentially doing the same work twice. It's like having to go back and fix a leaky faucet that you thought you'd already repaired. It's annoying, and it takes time away from other important tasks. Exactly.
And defects can have a ripple effect throughout the development process, leading to delays, increased costs, and even damage to your reputation. So those are the seven wastes of lean software development adapted from lean manufacturing by Mary Poppendieck. It's a pretty comprehensive list. And I can see how addressing each of these wastes could significantly improve efficiency and value delivery. Absolutely.
But it's not just about eliminating waste in isolation. We also need to understand the relationship between waste and value and how to optimize the flow of value through the entire system. That sounds interesting. Can you elaborate on that? Of course.
Think of it this way. The goal of lean software development is to maximize the value we deliver to our customers while minimizing the resources And to do that, we need to ensure that value is flowing smoothly through the entire development process from idea to delivered product. Like a river flowing unimpeded towards the ocean. That's a great analogy. And just like a river can be blocked by dams or debris, our value stream can be obstructed by various forms of waste.
So identifying and eliminating those obstacles is key to achieving a smooth and efficient flow of value. Precisely. And there's a really insightful analogy that Shigeo Shingo, a key figure in the Toyota production system, used to describe waste. He called it the banana skin analogy. Okay.
I'm intrigued. Tell me more about this banana skin analogy. Well, imagine you're buying a banana. You're You're buying it for the fruit. Right?
Not the peel. The peel is necessary to protect the fruit, but it doesn't provide the core value. Right. You wouldn't eat the peel. Exactly.
And in software development, there are many things that are necessary, but not the main event. Things like excessive documentation, unnecessary meetings, or complicated handoffs between teams. These are our banana skins. So they're necessary to some extent, but we need to be mindful of their impact on the overall value we're trying to deliver. We don't wanna get bogged down in the peels and lose sight of the fruit.
Precisely. And that's a key takeaway from lean thinking. Constantly challenge your assumptions. Look for ways to simplify and streamline your processes, and always keep the customer's perspective in mind. This is starting to make a lot of sense.
But how do we actually put these ideas into practice? Where do we start? Well, the first step is awareness. We need to start seeing our development process through the lens of waste and value. Once we can identify the banana skins, we can start peeling them away and streamlining our flow.
That's a great point. And I'm sure the agile playbook you mentioned provides some concrete strategies for doing just that, which we'll get into after a quick so we've identified some of those pesky banana skins. What are some practical ways to start peeling them away and actually optimize our development process? That's where the real magic of lean comes in. It's not just about theory.
It's about putting these principles into action. And one of the most powerful tools we have is the concept of a sustainable pace. I love that idea. It resonates with me so much. Building a process that allows us to deliver consistently without burning out is the opposite of those dreaded crunch times.
Exactly. And a key part of achieving a sustainable pace is having a well managed backlog. Remember the playbook talked a lot about that? Right. It's like the fuel that keeps the development engine running smoothly.
If it's cluttered and disorganized, the whole system sputters. That's a fantastic analogy. It emphasizes the importance of treating the backlog as a valuable asset, not just a random to do list. So how do we transform that to do list into a well oiled machine? It's about constant refinement, breaking down those large intimidating pieces of work into smaller, more manageable chunks.
Think of it like chopping a giant log into kindling so it can actually fuel the fire. And I remember the playbook also mentioning something called the definition of ready. Sounded like a checklist to make sure work is truly ready for the team to tackle. Yes. That's a crucial step to prevent wasted time and effort.
It's about making sure that every work item is well defined with clear acceptance criteria so the team can hit the ground running without any ambiguity. Like having a clear blueprint before starting construction. Exactly. And speaking of hitting the ground running, there's the idea of time boxing, which is a core principle in scrum and other agile frameworks. Yes.
Time boxing. Yeah. I've heard of it, but never really understood the practical application. It's all about working in short focused iterations, typically one to four weeks long. It forces us to prioritize and deliver value in manageable increments rather than trying to boil the ocean all at once.
That makes a lot of sense. Breaking down those massive tasks into bite sized pieces. Precisely. And this leads us to the concept of velocity, which is a way of measuring how much work a team can realistically complete in a given time box. So it's like gauging the team's speed, but in a sustainable way.
Exactly. Velocity is a valuable tool for planning and forecasting, but it's important to remember that it's a measure of capacity, not a target to be maximized at all costs. That's a crucial point. The playbook actually warned against using velocity as a key performance indicator because it can lead to unhealthy behaviors and burnout. Absolutely.
We wanna focus on delivering value sustainably, not just churning through work as quickly as possible. It's about finding that sweet spot between speed and quality. So we've got a well managed backlog, clear definitions of ready, time boxing, and a healthy understanding of velocity. What about the human element in all of this? The playbook emphasized the importance of high performing self managing teams.
That's where the real magic happens, when we move away from the traditional hierarchical model of management and empower teams to make decisions and take ownership of their work. The playbook actually used the phrase management as a service, which I thought was a really interesting way of framing it. It is. It shifts the focus from managers as controllers to managers as enablers. They're there to provide support guidance and resources, but, ultimately, the team is responsible for figuring out how to best achieve their goals.
It's like the difference between a director and a coach. The director tells people exactly what to do while the coach empowers them to find their own solutions. That's a perfect analogy. And this approach is particularly important in complex software development environments where things are constantly changing and there's no one size fits all solution. So we're moving away from rigid hierarchies, empowering teams, and embracing a more collaborative and adaptive approach to management.
But how do we ensure that all of this work is actually contributing to the overall business goals? That's where the concept of value streams comes back into play. We need to be able to trace the flow of value from the initial idea all the way to the delivered product and identify any bottlenecks or areas of waste along the way. It's like mapping out the entire supply chain from raw materials to the finished product, seeing where things get stuck. Exactly.
And in software development, that means understanding how each piece of work contributes to the overall value stream. It requires close collaboration between the business side and the development team to ensure everyone is aligned on what delivers the most value. It's like making sure all the gears are turning smoothly in the same direction. Perfect analogy. And the playbook talked about the importance of having a designated product owner, who can act as a bridge between the business and the development team.
Right. Someone who has a clear vision of the product and can guide the team towards that vision. The product owner is crucial for prioritizing the backlog, defining acceptance criteria, and ensuring that the team is always working on the most valuable things. And then there's the idea of tracking the work visually using agile boards or other tools so everyone can see the progress and identify any roadblocks. Visualizing the workflow is essential for transparency and communication.
It allows everyone to see what's in progress, what's blocked, and where bottlenecks are occurring. It's like having a giant map of the entire development process so everyone knows where they are and where they're going. Exactly. And speaking of knowing where we're going, going, how do we measure our success in this lean journey? What are the right metrics to focus on?
That's a great question. It's easy to get caught up in vanity metrics that don't actually reflect real progress. You're absolutely right. That's where we need to choose our key performance indicators carefully. Focusing on metrics that are truly aligned with business value and don't incentivize unhealthy behaviors.
So what are some examples of these meaningful metrics? Well, the playbook suggested a few, like cycle time, escape frequency, and strategic focus. Okay. Break those down for me. Cycle time tells us how long it takes to complete a piece of work from start to finish.
Escape frequency measures how often defects slip through to production. And strategic focus tracks how much of our time is spent on activities that directly contribute to customer value. So we're measuring the flow, the quality, and the value of our work, and using that data to continuously improve our process. Precisely. And that's the essence of lean software development.
It's a journey of continuous improvement focused on delivering maximum value to our customers. It sounds like a powerful approach, but I have to admit, it all seems a bit overwhelming. Where do we even begin to implement all of these ideas? Feels like a lot to take in. Well, the good news is you don't have to do everything at once.
Remember, the playbook emphasized that it's a journey, not a destination. So we can take it one step at a time. Exactly. Start small. Yeah.
Focus on one area at a time and gradually build those lean muscles. That's a relief. It's like any new skill. We need to practice and iterate to get better. And the key is to keep learning and experimenting.
There's no one right way to do lean software development. We need to find what works best for our team and our organization. That's a great reminder. It's about adapting these principles to our own unique context. Exactly.
Now before we move on, there's one more point from the playbook I'd like to bring up. It ties back to our discussion of waste and value. Okay. I'm all ears. Remember Shigeo Shingo's analogy of the banana skins?
Oh, yes. The banana skins. Such a vivid image. It really drives home the point that we need to be mindful of the things that are necessary, but don't directly contribute to customer value. Exactly.
It's a great reminder to constantly challenge our assumptions and look for ways to eliminate waste, even in the seemingly insignificant details. So as we think about implementing these lean principles What? We need to keep asking ourselves, what are the banana skins in our process? That's a powerful question to keep in mind. And remember, the banana skins can be different for every team and every organization.
It's about finding what works best for us and continuously striving to improve. This has been an incredibly insightful conversation. I'm already starting to see how these lean principles can really transform our software development process. I'm glad to hear that. And remember, it's not just about efficiency.
It's about creating a culture of continuous improvement, collaboration, and customer focus. That's a fantastic point. It's about building a better way of working, not just squeezing out a few more lines of code. Exactly. And that's what makes lean software development so powerful.
It's a holistic approach that can benefit everyone involved, from the developers to the customers. Well, I think we've covered a lot of ground here. Mhmm. But before we wrap up this deep dive, I wanted to touch on one more point from the playbook that really resonated with me. Oh, and what's that?
The concept of rightsizing. It sounds intriguing, but I'm not entirely sure what it means in practice. Rightsizing is all about making sure the work items in our backlog are the right size for the team to tackle efficiently. Think of it like Goldilocks and the three bears. Not too big, not too small, but just right.
Okay. I love that analogy. So if a task is too big, it needs to be broken down into smaller chunks. Exactly. If a work item is too large, it can lead to all sorts of problems.
It can be hard to estimate accurately. It can get stuck in progress for too long, and it can block other work from moving forward. It's like trying to eat a whole cake in one bite. You're gonna choke. Exactly.
And on the other hand, if a task is too small, it can create unnecessary overhead. Right. If we're constantly switching between tiny tasks, we lose the benefits of flow and focus. It's like trying to build a house with only grains of sand. Too much time spent on picking up each individual piece.
Precisely. So rightsizing is about finding that sweet spot where tasks are challenging enough to be engaging, but not so large that they become overwhelming or unwieldy. And this isn't a one time thing. Right? It's an ongoing process.
Absolutely. We need to constantly revisit our backlog and make sure the work items are the right size for our team and our current context. What might have been the right size a few weeks ago might need to be adjusted based on new information or changing priorities. That makes sense. It's all about being adaptable and responsive to the ever changing landscape of software development.
Exactly. Now along with the rightsizing, the playbook also talked about the importance of clear communication and visibility, especially as organizations scale up. Right. As teams grow and become more distributed, it's essential to have systems in place that allow everyone to see what's going on, to stay on the same page. Yes.
And the playbook mentioned using tools like agile boards and work management systems to track work visually. Those tools can be game changers. They bring transparency and help avoid those frustrating, wait, what are you working on moments. Exactly. Agile boards provide a shared understanding of what's in progress, what's blocked, and what's coming next.
It's like having a giant whiteboard where everyone can see the big picture. It's like a visual road map of the entire project. Precisely. And work management systems allow us to track work items in more detail, including estimates, dependencies, and acceptance criteria. So we have a high level view with the agile boards Mhmm.
And then we can drill down into the specifics with the work management systems. That's right. It's all about having the right information at your fingertips so you can make informed decisions and keep the project moving forward smoothly. Okay. So we've got right sized tasks, clear communication, and visual tracking systems in place.
What's the final piece of the puzzle when it comes to implementing lean principles? The final piece and perhaps the most important one is continuous improvement. Lean software development is all about constantly looking for ways to get better, to refine our processes and deliver more value. It's about embracing that growth mindset, always learning and evolving. Exactly.
It's like that saying, the only constant is change. And in a complex environment like software development, we need to be adaptable and always learning. And the playbook emphasized the importance of regular retrospectives to reflect on what's working and what could be improved. Retrospectives are crucial. They provide a safe space for teams to discuss their experiences, identify areas for improvement, and come up with actionable plans.
It's like taking a step back to assess the landscape, see what worked, what didn't, how we can do better next time. Exactly. It's about learning from our mistakes and constantly striving to do better. So we're rightsizing our work, communicating clearly, tracking visually, and continuously improving. It sounds like a recipe for success.
It is. But remember, it's a journey, not a destination. Lean software development is a mindset, a way of working sustainable and adaptable process. Exactly. Now speaking of sustainable processes, I wanted to touch on one more aspect of Lean that's particularly relevant to software development.
Oh, I'm intrigued. What is it? It's the idea of minimizing work in progress or WIP. Okay. I've heard of WIP limits, but I'm not entirely sure how they fit into the bigger picture of lean.
Well, minimizing WIP is all about reducing the number of tasks that are actively being worked on at any given time. So instead of having a hundred things in progress Yeah. We try to focus on a smaller, more manageable number. Exactly. And there are several reasons why this is so beneficial.
Okay. Tell me more. First, it helps to reduce context switching. When we have fewer things on our plates, we can dedicate more focused attention to each task. That makes sense.
It's easier to get into a flow state when you're not constantly jumping between different tasks. Right. And second, minimizing WIP helps to expose bottlenecks more quickly. When we have a lot of work in progress, it can be hard to see where things are getting stuck. So it's like clearing out the clutter so we can see the underlying structure of the workflow.
Perfect analogy. And finally, minimizing WIP can actually lead to faster delivery times. Really? I would have thought that working on more things simultaneously would lead to faster results. It might seem counterintuitive.
But when we limit WIP, we're forced to prioritize and make sure that we're always working on the most valuable things first. So it's about focusing our energy on the tasks that will have the biggest impact. Exactly. And by doing so, we can actually get things done faster and more efficiently. That's fascinating.
So how do we actually go about implementing WIP limits in our development process? There are a few different approaches. One common method is to use Kanban boards with explicit WIP limits for each column. So we would set a limit on the number of tasks that can be in progress at any given time. Exactly.
And this forces the team to finish work items before starting new ones. It's like creating a pull system where new work is only pulled in when there's capacity. That's a great way to think about it. And another approach is to simply agree as a team on a reasonable number of work items to focus on at any given time. So it's not necessarily about having a strict limit, but rather a shared understanding of what constitutes a sustainable workload.
Precisely. The key is to find what works best for your team and your context. This whole concept of minimizing WIP is really making me rethink how we approach our development process. I can see how it could lead to significant improvements in focus efficiency and overall value delivery. I'm glad to hear that.
Remember, Lean is all about continuous improvement, and minimizing WIP is just one tool in our toolbox. Okay. I think we've covered a lot of ground here. We talked about the seven wastes, the importance of value streams, and some practical strategies for implementing lean principles. What are some key takeaways that our listener can start applying today?
That's a great question. I think one of the most important takeaways is that lean software development is not a one size fits all solution. It's about finding what works best for your team and your organization. Exactly. It's a mindset, a way of thinking about work that emphasizes continuous improvement, collaboration, and customer focus.
So don't be afraid to experiment, to try different things and see what sticks. And remember, it's a journey, not a destination. There's always room for improvement. Absolutely. And I think another key takeaway is that lean is not just about efficiency.
It's also about creating a more fulfilling and enjoyable work environment. That's a great point. When we eliminate waste and streamline our processes, we free up time and energy to focus on the things that really matter. Exactly. And that can lead to increased creativity, innovation, and job satisfaction.
So it's a win win for everyone involved. Absolutely. Now before we wrap up, I wanted to leave our listener with one final thought. Okay. What is it?
Remember Shigeo Shingo's analogy of the banana skins. Keep asking yourself, what are the banana skins in our process? That's a powerful question to keep in mind. It's a reminder to constantly challenge our assumptions, to look for ways to simplify and streamline, and to always keep the customer's perspective in mind. This has been a fantastic deep dive.
I'm feeling inspired to start peeling away some banana skins and streamlining our value stream. That's great to hear. And remember, the journey of continuous improvement never truly ends. It's like a marathon, not a sprint. But with the right mindset and the right tools, we can achieve a sustainable pace that allows us to deliver value consistently without sacrificing quality or sanity.
Well said. And that's what lean software development is all about. Thanks for joining us for this deep dives into waste in lean software development. And a big thank you to our expert for sharing your insights. We hope you found this exploration valuable, and we look forward to diving into another fascinating topic with you next time.
Leave a Reply