Episode 6 – Plan or Compass?
/
RSS Feed
If a classical project can be split into milestones these will similarly be built around a specific scope. The environment is complicated, not complex. Therefore it is viable to deconstruct the problem to find all of the tasks and activities required to achieve the goal. If we are to work in an Agile way, we need to approach planning and tracking differently. Development is seen as a continuous process. It is not split into projects which start and stop. As part of its continuous nature, the teams are expected to be fixed and stable, not created for individual projects.
This podcast is AI-generated based on material from the “Agile Plays” website and book.
Transcript
Welcome back everybody for another deep dive. This time, we're gonna be tackling how tech companies plan and track their work and, especially in the ever changing unpredictable world of software development. Mhmm. We've got a ton of research here on on agile and lean methodologies, and, it's gonna be really interesting. It is.
Yeah. Yeah. These are really your survival guide, you know, when you're out there in that world of software development and things are changing so quickly. Yeah. Absolutely.
You know, actually, one of the articles we were going through mentioned this wild idea. Imagine you're building a car. Right? But instead of doing it, like, step by step, you start building a 1,000 cars all at the same time. Oh.
Like, all in different stages of production. Oh, wow. I mean, that sounds Yeah. Sounds like a recipe for disaster. Right.
Total chaos. Yeah. But that's kinda like what happens when teams have too much work in progress. Like, all those cars. Right?
Each unfinished piece of software, it represents resources that are tied up and delays. Oh, I see. So it's like each one is slowing all the others down. Yeah. They're all kind of competing for attention and resources and Yeah.
It's like a bottleneck. Exactly. And that's where agile and lean come in. Okay. Yeah.
So, I mean, how is that different from how projects were managed, you know, traditionally? Well, you know, traditional project management, it often relies on these really detailed plans and fixed scopes. Like, almost like having this rigid road map. But, I mean, like we were saying, with software, stuff changes all the time. Exactly.
And that road map can quickly become outdated. Right. Agile, on the other hand, it embraces these fixed time boxes Okay. But with a variable scope. So think of it as having a compass instead of a map.
So instead of trying to, like, plan everything out, you're just sort of, like, pointing in a direction Yeah. You've got the direction. And then figuring it out as you go. You adjust as you go. Okay.
You encounter those obstacles. You discover new information, and you're free to kind of, like, adjust your course along the way. Okay. I'm starting to see why that would be very helpful. Yeah.
So instead of, like, trying to, like I said, plan every single thing out, you bring it down to these smaller chunks and adapt as you go. Precisely. And those chunks, we call them sprints. Okay. And they're typically a couple weeks long.
And within each sprint, the team, they focus on delivering a set of features or a certain functionality. Okay. That makes sense. So how do you estimate and plan when, like we keep saying, the requirements are constantly changing? Yeah.
That's a great question. Yeah. And that's where techniques like relative estimation, they really come in handy. Okay. Instead of trying to predict exactly how many hours something is gonna take Which is probably impossible.
Which, yeah, often is impossible. Yeah. In these complex environments, you use these units, like story points, to represent the relative size and complexity of a task. Okay. So instead of saying this will take 8 hours, you say this is a 5.
Exactly. This is a 5 in terms of its complexity. Yeah. Okay. And this is where the magic happens.
Alright. Let's hear the magic. You track how many story points a team can complete in a sprint, and you start to get a measure of their velocity. And this can help you predict how much they can actually achieve in future sprints even with those changing requirements. So it's like, okay.
Well, we know on average, they can do this many story points, so we can kinda predict what they can get done in the next sprint. Exactly. Yeah. Even if things change. And so velocity becomes this vital planning tool.
Right? And it helps teams make more informed decisions about what they can commit to. So they're not overcommitting or undercommitting. They're kinda right in that sweet spot. It's really important to remember though that velocity is not a performance metric.
Okay. Interesting. It's simply a measure of how much work a team can handle Okay. You know, comfortably within that sprint cycle. Yeah.
You don't wanna be pushing people to, you know, move faster than they can. Exactly. Sustainable quality output. Right? Absolutely.
Sustainable pace, high quality output, that's what we're aiming for. Now speaking of teams, agile really emphasizes these cross functional and self managing teams. Okay. I've heard those terms used a lot. What does that really mean in practice?
So a cross functional team means that you have all the necessary skills within the team to actually design, build, and test a feature or product. Okay. So you've got developers. You've got designers. You've got testers, and they're all working together from start to finish.
So it's like a mini company within a larger organization. Exactly. And because they're empowered to make decisions and organize their own work, they're much more engaged, and they can respond to those changes quickly. That's the self managing part. Okay.
So instead of having, like, a manager who's dictating every single step Mhmm. The team kind of takes ownership. That's the idea. Okay. Doesn't mean there's no management at all.
Right. But it means that the managers take on more of a supportive role acting as facilitators and removing roadblocks for the team. Okay. So it's kinda like a shift from that traditional hierarchical model, like Yeah. Top down.
It is a big shift, and it requires a different approach to leadership for sure. Right. But it can be incredibly powerful in fostering this sense of ownership and accountability within the team Oh, good. Which then leads to better decision making and a more adaptable way to handle all those inevitable changes that pop up. Right.
In those complex projects. Absolutely. It's about trusting that team to kind of navigate those complexities, you know, and make the best decisions on the ground. Right. Yeah.
Because like we've been saying, things are changing all the time. Because they're the ones closest to the work. Right. Exactly. Yeah.
So okay. So they have all this autonomy. But how do you make sure that these self managing teams are still, like, aligned with the overall business goals? That's where a key role comes in, and that's the product owner. Yeah.
And they're, like, the voice of the customer, making sure that the team is building the right things Okay. In the right order. Yeah. So they bridge the gap between that big vision and the day to day development work. Exactly.
They take those business needs, and they translate them into, like, actionable items for the team's backlog. Oh, right. That prioritized list of tasks. Yeah. Exactly.
So it's not just about, like, building things fast. It's about building the right things. Yeah. That's the heart of agile, Right. Delivering that value.
Yeah. And to do that effectively, everyone needs to be on the same page. Yeah. That's for sure. So it sounds like communication is so key.
Oh, absolutely. How do you make sure that's happening? Like, especially in such a, like, fast paced environment where everything's always changing? Openness, I think, is key. Okay.
So that means, like, clear processes Oh. Accessible information Right. And just a culture of, you know, open communication. So no more, like, siloed teams or information hoarding? If you So no more, like, siloed teams or information hoarding?
If you wanna succeed, yeah. Right. No. Teams really need to see how their work fits into that bigger picture, you know, like, that flow of activities that ultimately delivers value to the customer. Yeah.
That makes a lot of sense. And so I imagine visualizing that flow is pretty important. Absolutely. That's where those agile boards come in. Oh, okay.
And those were actually inspired by the Kanban system. They basically visually represent all that work in progress Ah, okay. And its status. So it's like a shared dashboard for the team. Well, that's great.
Everyone's on the same page. Yeah. Exactly. Everyone can see what's going on. Okay.
So we've got our compass. We've got our empowered teams. We've got our visual road map. How do we measure success in this complex world? Like, what metrics really matter?
That's the tricky part. Yeah. Choosing those KPIs. Right? Right.
The ones that are really gonna drive the right behaviors, and that can't be easily manipulated. So not, like, lines of code written per day or hours worked. Those don't tell the whole story. Right? Okay.
You really wanna focus on how smoothly work is flowing through the system. Okay. The quality of the output and, of course, the value that's being delivered to your customer. So measuring outcomes, not just output? Precisely.
And one approach to do that is using something called the engineering scorecard Okay. Which uses KPIs across 3 key areas. Okay. Flow, quality, and value delivered. So break those down for you.
Like, what falls under, like, flow? Well, cycle time for instance. Okay. How long does it take for a task to go from started to done? Shorter cycle times generally mean a more efficient process.
You know? Makes sense. Things are moving smoothly. Yeah. What about quality?
What about it? Yeah. Well, escape frequency is a big one. Escape frequency. Yeah.
How often those pesky defects Oh, no. Make it into production. So it kinda shows how effective those quality assurance practices actually are. So catching those bugs before they make it to the customer. Exactly.
Yeah. That's good. And then, of course, there's value delivery. Yes. The perhaps most important Arguably?
But also maybe the hardest to measure. And the hardest to measure. Yeah. Yeah. So how do you actually quantify value?
Yeah. It really requires a good understanding of your customer's needs. Right? Right. One way to approach it is to track development time spent on features Okay.
That are directly contributing to that customer value versus time spent on, like, bug fixes or technical debt. So aligning those development efforts with the strategic goals. Precisely. And so by tracking those three things, flow, quality, and value, you start to get this holistic view of your engineering organization's performance. That makes sense.
And the goal isn't to hit some arbitrary number. Right? It's about that continuous improvement Okay. And adaptation. Always adapting.
Yeah. Yeah. That seems to be the light the theme here. It's the essence of agile. Okay.
Embracing change Yeah. Using it to your advantage. I'm really seeing now how these principles can lead to some pretty impressive benefits. Oh, absolutely. Yeah.
Yeah. Increased speed and responsiveness. Yeah. Improved quality, reduced risk. All good things.
Higher team morale. Yeah. It all leads to greater business value at the end of the day. It's like a chain reaction, it sounds like. It is.
Yeah. But I'm curious. I mean, what are some of the challenges people might face when they're trying to implement these ideas? Well, resistance to change is a big one. That's always tough.
Yeah. Yeah. People can get very attached to old ways of doing things even if they're not really effective anymore. So it's not just about imposing a new system. You have to change those mindsets.
Right. Okay. And another challenge is finding that sweet spot, that balance between structure and flexibility. Okay. Because agile isn't chaos.
Right? Right. But it is about adaptability while maintaining a certain level of predictability. The tension between the map and the company. Exactly.
Yeah. Yeah. And it's really crucial to remember that agile isn't a magic bullet. Oh, right. It's not just gonna solve all your problems?
It takes commitment and effort and a willingness to adapt and learn along the way. So not a solution, but a set of tools for those who are willing to put in the work. Exactly. Yeah. It's like, learning a new dance almost.
It is. Yeah. It takes practice, and you're gonna stumble a little bit, but then you find your rhythm. That's a great analogy. And, you can't forget about celebrating successes along the way too.
Right? Oh, absolutely. You know, recognizing and appreciating all the hard work that the team is putting in Right. That's so crucial for keeping that morale high. Yeah.
For sure. Because it reinforces that shared purpose Right. And that collective achievement, you know, that's so important in agile. It's like that sports analogy we were talking about before where everyone contributes to the win. Exactly.
Yeah. Every small victory gets you closer to that ultimate goal. Okay. Well, as we're wrapping up this deep dive, what's the one key takeaway that you want our listeners to walk away with today? I think embrace that idea of subtle control.
Subtle control. Okay. Instead of micromanaging, empower your teams Right. To make decisions. Okay.
Self organize and take ownership. So it's really about creating an environment where innovation can thrive. Precisely. And by focusing on those core principles Right. Value flow and continuous improvement, You'll be well on your way to building a really agile and successful organization.
I love that. You know, it makes me think of that quote, if you wanna build a ship, don't drum up the team to gather wood. Instead, teach them to yearn for the vast and endless sea. That's a such a perfect quote Yeah. Because it really captures what agile leadership is all about.
Yeah. Inspiring that shared vision, empowering people to explore Yeah. And trusting the team to navigate that journey. So to our listeners out there, as you're embarking on your own agile adventure, keep that compass handy, stay flexible, and never lose sight of the value that you're creating. And most importantly, I think, enjoy the ride.
I love that. That's fantastic advice. And on that note, we'll wrap up this deep dive into the world of agile. Until next time, keep exploring, keep learning, and keep striving for excellence.
Leave a Reply