Episode 13 – Value not just content
/
RSS Feed
Lean focusses on the end to end flow of value. If we are to be effective at delivering value to customers, we must look at the whole organization. If we understand from the process map how the business functions, we can extend from the development flow of work to looking at the flow of value across the organization. Local optimisation of one part of the overall process will not generate agility while there are bottlenecks in the other parts. Business agility requires us to step back and look at the delivery of value through the whole business. The integration of multiple business areas as a cross-functional whole is a key part of making agility effective.
This podcast is AI-generated based on material from the “Agile Plays” website and book.
Transcript
Hey, everyone, and welcome back to the Deep Dive. Today, we are going really deep on something. Oh, I love deep dives. I know. Right?
It's gonna be a good one. I'm excited. So today, we're focusing on how development teams can make sure they are truly delivering value. It's such a key concept. It really is.
And we've got a whole stack of sources here, agile guides, some case studies, even some historical context on how we got to where we are today. It's fascinating to see how much things have changed. Oh, yeah. For sure. And we're gonna try to pull out the most useful insights for you from all this material.
What do you say we jump right in? Let's do it. Okay. So one of our sources, an agile playbook for scale up organizations, dives right into this idea of scalability. Right.
But they don't just mean the usual tech definition, like handling more users or data or whatever. It's a broader concept. Yeah. They're talking about building a company that can grow and adapt without, you know, falling apart. So it's kind of like having a flexible skeleton.
Exactly. Instead of one that just snaps under pressure. Which is really relevant in today's fast paced world. It really is. Things change so quickly.
Right. And speaking of adapting, that's where agile principles come in. Agile is all about that, isn't it? Yeah. And this playbook ties scalability directly to agile, things like scrum, the agile manifesto.
Those are great starting points. For sure. But they're not meant to be, like, rigid rules. More like models you adapt to your own situation. Precisely.
Okay. So we're building this adaptable, scalable organization. But There's a big but there. Always a but. The question is, how do we make sure we're building the right things, you know, the things that actually deliver value?
We don't wanna just be building efficiently. We wanna build the right things efficiently. Exactly. And that's where constant feedback comes in. Feedback.
Such a crucial element. Absolutely. This playbook talks about feedback as being like a compass. It's constantly guiding the development team toward delivering real value. It's such a shift from that old school mindset.
You mean the waterfall method? Yeah. That rigid preset plan approach. Instead, we're embracing the unknown, reacting to feedback and adjusting course as we go. So more like navigating by the stars instead of a rigid map.
I love that analogy. Okay. So we've got our compass. We're adaptable. We're getting feedback.
But how do we make sure everyone's on the same page, you know, rolling in the same direction? Yes. Alignment is key, and how to achieve it? That's where our agile playbook introduces this idea of value stream management. Now we're talking.
One of my favorite topics. Mine too. Okay. So imagine your development process as a river k. I'm picturing it.
Flowing from that initial spark of an idea The headwaters. Right all the way to delivering a finished product to your customer. That's the mouth of the river where it meets the ocean. Exactly. Value stream management helps you see that entire flow, spot any bottlenecks or log jams.
And make sure everyone is pedaling towards the same destination. Exactly. And within that river, we have these things called features. They're like little boats carrying customer value. More than just big user stories though.
Right. The group related work together, making that big picture flow clearer. But here's the thing Hit me with it. Not all work is created equal. Some tasks directly deliver that customer value.
Uh-huh. Others, they're important, but they don't contribute directly to that end product. And that is where prioritization becomes absolutely essential. Couldn't agree more. And our agile playbook really stresses aligning development efforts with customer value above all else.
The customer should always be top of mind. Always. They even have this great example in here about hair. The appliance company? Yeah.
The giant one. They restructured their entire company Wow. I know. To empower teams that were specifically focused on customer needs. So they moved away from those traditional hierarchies.
They did. Created smaller, more agile teams that really had ownership over meeting those customer needs. That's a fantastic example of walking the walk, not just talking the talk. It really is. So practically speaking.
How do we make sure we're working on the right things, the things that matter most to the customer? That's where a well maintained backlog comes in. The trusty backlog, it's more than just a to do list. Oh, for sure. When it's done right, it's a living document, a prioritized road map that keeps the team focused on what's most important.
And it needs constant attention Absolutely. Using techniques like the definition of ready to make sure each task is fully fleshed out before anyone even starts working on it. So no more jumping into things half cocked. Exactly. We're taking the time to understand what needs to be built before we build it.
Makes total sense. But there's another concept here that I think can easily get overlooked. Oh, do tell. It's the idea of waste from a lean thinking perspective. Ah, yes.
Identifying and eliminating anything that doesn't directly contribute to delivering value. You'd be surprised how much time and effort goes into activities that don't actually move the needle. So much wasted effort. It's like decluttering your workspace, but for your entire development process. Love that.
Okay. Speaking of clutter What about it? One thing that can really muddy the waters is poor communication between, well, everyone. The development team and Yeah. And everyone else, stakeholders, product owners, you name it.
Silos are the enemy. The Agile manifesto actually states that this collaboration should be a daily activity. Daily. Wow. I know.
Right? So we need to build those bridges, break down those silos between the people who understand the business needs and the people who are actually building the product. A shared language, common goals, and that constant flow of information. All essential. Okay.
So we've got our value stream, our backlog, our focus on customer needs. But how do we make sure the customer is truly at the heart of it all? Not just a concept, but a driving force. Exactly. And our agile playbook gives us a couple of really practical techniques.
Plei mommy. 1 is embedding product owners within the development teams. So they're right there in the trenches. They are. Their s solely focus is representing the voice of the customer.
Love it. So the customer always has a dedicated advocate. Exactly. Another technique they mentioned is the Moscow method for prioritization. Have you heard of that?
Moscow rings a bell. It stands for must have, should have, could have, and won't have. Right. A framework for making tough choices. You got it.
It forces you to categorize features based on how important they are to the customer. That's a great way to avoid that dreaded feature creep. Oh, I hate that. It can really bog down development and dilute the value you're delivering. Totally.
So no more trying to be everything to everyone. Right. We're choosing our battles and focusing on what truly matters. Starting to get a clear picture of how to build a value driven development machine, aren't we? We are.
But we've only just scratched the surface. Welcome back to the deep dive. Before the break, we were talking about prioritizing work based on customer value And making sure the customer is truly at the heart of it all. Now let's shift gears a bit and talk about measuring our success. Metrics.
Because what gets measured gets managed right. Exactly. But it's not just about tracking numbers for the sake of it. It's about choosing the right metrics, ones that actually reflect what matters to the customer. Okay.
I like that. So how do we do that? How do we measure value in a way that doesn't just lead to, you know, ticking boxes, but actually shows if we're succeeding. That's where our agile playbook comes in handy again. They warn against using what they call gameable metrics.
Gameable. What's that? It's those metrics that look good on paper. You know? They make you feel like you're making progress Right.
But they don't actually tell you if you're delivering real value to the customer. Oh, I see. So they could be manipulated. Exactly. They can be easily twisted to make things look better than they really are.
Okay. So we wanna avoid those. Yeah. What should we focus on instead? Metrics that are directly tied to outcomes.
Things that can't be easily gained. Our source suggests focusing on 3 key areas. Okay. Let's hear them. Flow, quality, and value.
Alright. Break those down for me. Sure. Right. Let's start with flow.
This is all about how smoothly work is moving through our development process. Okay. Makes sense. How do we measure that? Metrics like cycle time, that's the average time it takes to complete a task Right.
Or lead time, which is the time from when you start a task to when you actually deliver it to the customer. So we're looking for bottlenecks. Any points where things are getting stuck or slowing down that flow of value to the customer. You got it. It's about identifying those friction points and figuring out how to streamline the process.
Makes sense. But doesn't focusing on speed risk sacrificing quality, you know, rushing things out the door? That's a great point. And that's why we need to balance those flow metrics with quality metrics. So what would some quality metrics be?
Things like escape frequency. That's how often defects make it into production. Oh, right. So we wanna keep that number low. As low as possible.
And then there's mean time to failure, how long a feature works before it encounters problem. Right. So it's all about making sure we're building things that are robust and reliable. Exactly. We're building a multidimensional dashboard, so to speak.
Right. Getting a complete picture of how our development process is performing. I like that analogy. But what about the value part? How do we actually measure the value itself?
The $1,000,000 question. How do we know if we're building things that customers actually want? And that they're willing to pay for. Right? Absolutely.
This is where things get a bit trickier. But we can start by tracking how much time we're spending on value work versus waste. Value work versus waste. Okay. Explain that one.
Value work is any activity that directly contributes to customer value. So things like developing new features, fixing bugs, those kinds of things. Right. Waste is any activity that's necessary. You know?
We have to do it. But it doesn't actually add value to the end product. Exactly. Things like unnecessary meetings, rework due to poor communication, all that stuff. Makes sense.
So by increasing the proportion of time we're spending on value work, we can be more confident that we're using our resources effectively. You got it. But measuring value can also involve getting direct feedback from customers. Right. Like surveys and user testing.
Exactly. And tracking things like customer satisfaction and engagement. So it's a mix of quantitative and qualitative data. Absolutely. It's about getting a holistic view of how well we're meeting customer needs.
Okay. This is all great stuff, but I can imagine some development teams pushing back against all these metrics. You know, it can feel like big brother is watching. I get it. Like, their work is being micromanaged.
Right. So how do we get buy in from the people who are actually doing the work? Transparency and communication are key. You have to involve the team in choosing the metrics. So it's not just being dictated from above.
No way. Explain why these metrics are important and how the data is gonna be used to improve the process. So it's about helping them, not punishing them. Exactly. It's about using data to work smarter, not harder.
Our agile playbook actually highlights a case study where a company did this really well. Oh, yeah. The weapon. They transformed their entire development process by focusing on flow, quality, and value. And what were the results?
They saw massive improvements in productivity, customer satisfaction, and even team morale. Wow. That's impressive. And what's really interesting is they didn't just focus on one metric. They tracked a whole bunch of them across all three areas.
So they got that holistic few we were talking about. Exactly. And that allowed them to make informed decisions and continuously adapt their approach. This is all really inspiring. But I know for someone just starting out with agile, it can feel pretty overwhelming.
Oh, for sure. It's a lot to take in. So where do they begin? What's that first step towards building a more value driven culture? Start small.
Don't try to boil the ocean. Pick 1 or 2 key areas. Get comfortable with the concepts. And then gradually expand from there. So it's a journey, not a destination.
Exactly. And remember, involve the team, get their buy in, create that culture of continuous learning. Great advice. Okay. So we talked about agile principles, value stream management, prioritizing work, the power of metrics.
It's all connected. It is. But before we wrap up this part What's the key takeaway here? Yeah. Let's circle back to that core theme delivering value.
What's the ultimate message for our listeners? Delivering value is so much more than just churning out code and shipping features. It's bigger than that. It's about building a system, a culture, even a mindset that prioritizes customer needs, a mindset that embraces change and constantly strives for improvement. It's about finding what works best for your specific team and your specific organization.
Exactly. And that brings us to the technical side of things, which we'll explore next. We'll dig into technical excellence, talk about the dangers of hero culture, and how to avoid getting bogged down by technical debt. All important stuff. Stay tuned, folks.
Welcome back, everyone. So we spent the last two parts talking about building a development process that's really focused on delivering value. Making sure we're building the right things in the right way. Right. But what about the actual code itself?
Yes. The foundation of it all. Exactly. How do we make sure that our technical foundation is, you know, rock solid Yeah. That it can support this whole value driven approach.
That's where technical excellence comes in. Our agile playbook really stresses this. They talk about good design, continuous improvement, and, of course Tackling that technical debt. Yes. Technical debt.
Always lurking in the shadows. I love how they call it debt. It's such a good analogy. Isn't it? It's like you're taking a shortcut now.
But you know you'll have to pay for it later. Exactly. Like those tempting credit card purchases. Purchases. Come back to bite you?
Ouch. Yeah. And just like financial debt, technical debt can really pile up. It becomes this huge burden. That makes everything harder.
Absolutely. A code base that's riddled with technical debt is harder to maintain. It's more prone to errors. It slows down development. It's like trying to run a marathon with a backpack full of rocks.
Great analogy. So how do we even know if we're starting to accumulate too much of this technical debt? What are the warning signs? Yeah. What should we be looking out for?
Well, if you start noticing that development times are getting longer or you're seeing more and more bugs popping up It's never a good sign. It's not. And if the team is starting to feel really frustrated Yeah. That's a red flag for sure. So let's say we are seeing those warning signs.
What do we do about it? How do we start paying down that technical debt? Our playbook recommends a proactive approach. It's kinda like, you know, setting aside time for regular maintenance on your car. Oh, I like that.
You need to allocate resources specifically for tackling technical debt. So it's an investment in the long term health of our product. Exactly. You're preventing those small issues from snowballing into big, nasty problems down the road. Makes total sense.
Mhmm. But I feel like there's always this pressure, you know, to ship new features, to go faster and faster. How do we balance that need for speed with the need for quality and maintainability? That's where we have to watch out for the dangers of hero culture. Hero culture.
Tell me more about that. It's that mentality where individual developers are celebrated for, you know, pulling all nighters and single handedly saving the day. Oh, I've seen them. Even if it means sacrificing their own well-being Right. And creating more technical debt in the process.
So it's a short term gain, but a long term pain. Exactly. It's not sustainable. So how do we break free from that hero culture? How do we create a more sustainable pace?
Yeah. What's the antidote? Empowerment is key. Trusting your team, giving them the autonomy to make decisions. Giving them ownership.
Exactly. And creating an environment where they feel supported and valued, it's moving away from that command and control style of management. There was a more collaborative self organizing model. You got it. And our agile playbook has this great comparison.
They compare management to venture capitalists. Venture capitalists. That's an interesting analogy. It is. They're saying that good managers, they provide the resources and the support, but they trust the team to make the right decisions and build the best product possible.
So it's about setting the stage, but then stepping back and letting the team do their thing. Exactly. But empowerment alone isn't enough. We also need to really embrace continuous improvement. Oh, that sounds familiar.
Takes us back to that agile mindset, doesn't it? It does. It's about embracing change, iterating quickly, and always looking for ways to improve the process and the product. So delivering value isn't just a one time event. Nope.
It's an ongoing process of learning and adapting. And refining our approach. It's about being open to feedback, experimenting with new ideas, and never settling for good enough. So true. As we wrap up this deep dive into delivering value.
What's the main message you want our listeners to walk away with? It's about so much more than just writing code and shipping features. Right? So much more. It's about building a system, a culture, a mindset that prioritizes customer needs, that embraces change, and that strives for excellence in every single aspect of development.
It's a journey, not a destination. And remember, there's no one right way to do it. Experiment, adapt, find what works best for your team. And never stop learning. The world of agile is constantly changing and evolving.
Always new challenges to tackle. Couldn't have said it better myself. Well, thanks for joining us on this deep dive, everyone. We hope you found it helpful and inspiring. And until next time, happy deep diving.
Leave a Reply