Episode 1 – What are Plays?

Agile Plays
Agile Plays
Episode 1 - What are Plays?
Loading
/

I do not believe that there is any single recipe for scaling which can be applied across all organizations.  If such a recipe existed, I would sell the solution (and some people do try to do exactly that as pre-defined frameworks).  Trying to apply a set of fixed rules to transform a complex organization is likely to get poor results. 

In sports, especially US sports, each successful sports team compiles a set of strategies or “Plays”.  These choices give the team potential solutions to different match situations.  In a match, the team chooses Plays as appropriate to gain advantage.

I’m reusing this terminology here. A Playbook is the team’s collection of strategies. On this site, you can collect Plays into your own personalised Playbook for reference.


This podcast is AI-generated based on material from the “Agile Plays” website and book.


Transcript


Welcome back everyone to the deep dive. This time, we're taking a look at this book, an agile playbook for scale up organizations. It really grabbed my attention because instead of, you know, another one of those rigid agile transformations, this book offers a more flexible approach to building your own, you know, agile approach. Yeah. I see what you mean.

It's interesting how the book presents this agile playbook idea, which is basically a bunch of optional strategies or plays. It's like having a toolbox full of different tools to choose from, and you just pick whichever one fits your, you know, specific need or challenge. That's a good way to put it. It's very different from a lot of agile implementations I've seen that have that rip and replace mentality. Exactly.

This seems much more adaptable. Why do you think they went with a playbook idea instead of, like, a strict transformation? Well, I think it's because transformations often fail. Oh, yeah. I can see that.

It's almost like trying to force a square peg into a round hole. A lot of companies try to adopt these agile practices that just don't fit their culture or structure. You know? And it ends up creating more problems than it solves. So instead of going through this painful one size fits all overhaul, it's more like, hey.

Here's a menu of agile options. Take your pick. Right. And the playbook recognizes that organizations are constantly evolving. Like how we all had those awkward growth spurts as teenagers.

Like, exactly. And you suddenly realize your old clothes don't fit, and you need a whole new approach to, like, everything. And that's where Griner's model of organizational growth comes in. Right? Yeah.

It talks about how organizations go through these periods of stability, and then eventually, they hit those crisis points, and their old ways of doing things just don't work anymore. Like those growing pains. Yeah. Exactly. And this book is saying that having a playbook with these, you know, adaptable strategies is especially helpful during those turbulent phases when an organization is scaling up.

Makes sense. So the playbook is all about adapting to those growth phases and having options instead of just one rigid system. Right. But what about scalability itself? Like, that seems like a big challenge for companies that are trying to grow while staying agile.

Oh, absolutely. The book really stresses how important it is to build scalability into your agile approach right from the beginning. Like those successful tech companies we see, they started small, but they were built to grow. Exactly. Think of, like, the apps that we use every day.

They have to handle millions of users, right, not just a few 1,000. It's like they have that built to grow mindset. Yeah. And the book argues that organizations need to have that same mindset when they're implementing agile. So it's not just about doing agile today.

It's about creating a system that can support your growth in the future. So you're not just sprinting to keep up. You're building a system for the marathon. That's a good way to put it. And one way the book suggests you can do that is by using a rugby approach to product development.

A rugby approach. That sounds interesting. What's that like? Well, it contrasts the traditional sequential model of development, you know, where each team kind of works in isolation, and then they pass the ball to the next team. Instead, it's more like a rugby team where everyone's moving down the field together as a unit.

They're constantly communicating and adjusting their strategy, you know, as they go. Oh, so instead of handing off tasks and hoping for the best, it's about having a more fluid movement and open communication. Right. And making sure everyone's on the same page about the end goal. It's definitely a different way to think about development.

So it's less like a relay race and more like a team sport where everyone's playing at the same time. That's a great way to put it. It really gets at the collaborative spirit of agile. So we've got this playbook idea where you pick the agile strategies that work for you. We've got Griner's model that explains those growing pains that companies go through.

And then we've got this rugby approach to working together. That's a really good summary of the key ideas. And with that foundation, we can start looking at some of the specific plays from the book, you know, the ones that can actually help you build a truly scalable, agile approach. So one of the most important plays the book talks about is empowering self organizing teams. It's all about moving away from that traditional top down management style.

So instead of having managers dictating every single step, it's more about giving teams the freedom to kinda own their work. Exactly. When you trust your teams to make decisions and, you know, figure things out on their own, you create a sense of ownership. You encourage them to take initiative, and it can really help speed up decision making too. That makes sense.

But what about managers? What happens to them in this kind of setup? Do they just disappear? Well, their role changes quite a bit. Instead of being directors, they become more like coaches or facilitators.

Okay. They're there to, you know, provide guidance and remove any obstacles that are in the team's way, but they're not there to micromanage. So it's less about giving orders and more about creating environment where teams can thrive. Yeah. Exactly.

The book actually uses this term that I really like, management as a service. Management as a service. I like that. It kinda changes the whole idea of what leadership looks like in an agile organization. So you're empowering teams, but what about all the work that needs to get done?

How do you keep things from getting out of control? Well, that's where another important play comes in, minimizing work in progress. It's about focusing on finishing what you've already started before taking on new things. No more juggling a 1000000 things at once. Finish one task and then move on to the next.

Right. It's a key principle in lean thinking, and it's really all about reducing waste and being more efficient. When you're juggling too many projects at this on time, you end up context switching all the time. Which can really kill your productivity. Exactly.

It's like when you try to read 3 books at once. You might feel like you're getting a lot done, but you're not really absorbing much. Right. And when you limit your work in progress, it allows your teams to focus and really get things done quickly. So we've empowered our teams.

We've streamlined the workflow. What's the next play in this agile playbook? Well, the book talks about prioritizing value streams. Yeah. So it's basically identifying the most important steps in getting your product from the idea phase to the delivery phase and then making sure those steps are, you know, as efficient as possible.

Yeah. And then making sure those steps are, you know, as efficient as possible. So understanding the whole journey of the product Mhmm. From the first spark of an idea all the way to when a customer actually experiences it and making sure that flow is smooth. That's a perfect way to put it.

By focusing on those value streams, you ensure that everyone's working on the stuff that really makes a difference. So nobody gets bogged down with busy work that doesn't actually contribute to the big picture. Exactly. Especially as a company grows, it's really easy to lose sight of what really matters, which is delivering value to your customers. Right.

So prioritizing value streams helps you stay focused on the things that really matter. Now the book also talks a lot about continuous improvement, but that feels like one of those business buzzwords. You know? Like, everyone talks about it, but what does it actually mean in an Agile context? It's about creating a culture where your teams are always learning and adapting and improving their processes.

So it's not about setting a rigid plan and then just sticking to it no matter what? No. Exactly. Being flexible and responding to change is really important. But how do you actually build that into a company's DNA?

Well, it starts with having regular feedback loops and retrospectives. Teams need to, you know, regularly step back and look at what's working and what's not and then make adjustments based on that. So it's that constant cycle of trying things out, getting feedback, and then tweaking your approach. Exactly. It's about being open to learning new things and, you know, realizing that there's always room for improvement no matter how good you think you are.

So it's not about achieving perfection. It's more about just always striving to get better. But a lot of companies, especially big ones, they're gonna get stuck in their ways. It's hard to change the culture once it's established. That's true.

And the book actually addresses that head on. It talks about how organizations often need to evolve their management style in order to stay agile as they grow. So it's not enough to just implement agile practices. Mhmm. You need the right leadership style to back them up.

Exactly. The book talks about the importance of leaders becoming enablers and facilitators, not the traditional command and control type managers. Right. Like that management as a service idea we were talking about earlier. Exactly.

It's about shifting from a culture of do what I tell you to do to a culture of figure things out on your own, which is a big shift for a lot of organizations. It sounds like a crucial one though if you wanna stay agile as you grow. Yeah. Now I remember the the book also mentioned this thing called technical debt. It feels like one of those unavoidable things in software development.

Yeah. Technical debt is kinda like financial debt, you know, that we all try to avoid. It is. It's the cost of taking those shortcuts or making those quick fixes that seem like a good idea at the time, but end up coming back to bite you later. It's like putting a Band Aid on a broken leg.

You know, it might hold things together for a little bit, but you really need to fix the underlying problem. Exactly. And just like with financial debt, technical debt can accumulate interest over time. The longer you ignore it, the harder and more expensive it becomes to fix it. So it's recognizing that sometimes you need to slow down to speed up.

You need to take the time to clean up your code and really address those underlying problems before they turn into major issues. Precisely. And the book really emphasizes the importance of tracking your technical debt and making it visible so you can actually factor it into your planning and decision making. So it's not about avoiding it completely because that's often not possible. It's more about managing it effectively and knowing when to invest and actually fixing things the right way.

That's a great way to put it. It's all about finding that balance between, you know, delivering new features quickly and making sure your code base is healthy and sustainable. Like preventative maintenance for your software. You know, a little effort upfront can save you a lot of pain later on. Exactly.

And it goes back to that idea of continuous improvement. Building a great product is a marathon, not a sprint. So it's not just about speed. It's about building something that's sustainable and that can last. It really seems like this agile playbook is about building this whole culture of agility.

It's not just about following specific practices. Right? It's about having that mindset and the leadership style to support it. That's a great point. And I think one of the things that really stood out to me from this book was the emphasis on trust and empowerment.

Now you can have all the processes in the world, but if you don't trust your teams to make decisions and own their work, agile is not gonna work. Yeah. That makes sense. It all goes back to that idea of management as a service where leaders are there to support their teams and not micromanage them. But how do you actually build that trust?

I mean, it seems like it takes time, right, And a willingness to let go of some control, which can be tough for some managers. It definitely requires a shift in thinking. One thing the book suggests is focusing on outcomes instead of outputs. So instead of telling people exactly how to do something, you focus on the goals, and then you trust your teams to figure out how to get there. So it's less about do this task this way and more about here's the problem.

Let's solve it together. Exactly. And when you give teams that freedom, they're not only gonna be happier and more engaged, but you're also gonna tap into their creativity and their problem solving skills. I love that quote. If you wanna build a ship, don't drum up people to gather wood, divide the work, and give orders.

Instead, teach them to yearn for the vast and endless sea. That's a great one. It really captures that sense of empowerment that's so essential to Agile. Yeah. It's about inspiring people and giving them a sense of purpose and then just trusting them to do what they do best.

Now another thing I wanted to touch on is that idea of designing for scalability that we mentioned before. Do you have any specific advice for our listeners who are, you know, thinking about how to make their agile approach more scalable as their company grows? Well, one thing that's really important is to choose tools and platforms that can handle a lot of data and large teams. You don't wanna end up with a system that can't keep up as you grow. So think about those cloud based solutions that can scale with you.

And you don't want your tools to hold you back. It's like trying to run a marathon in shoes that are 2 sizes too small. Another important thing to consider is how you structure your teams. As your company grows, you might need to move away from having those small self contained teams and go to a more federated model. So instead of having 1 giant team trying to do everything, you break it down into smaller, more focused groups.

Right. And that way, you can stay agile even as your organization becomes more complex. It's It's like having a bunch of small boats instead of 1 big ship. You can move faster and adapt to changes more easily. That's a really good way to think about it.

It's all about decentralization and letting teams make decisions at a more local level. Well, this has been an awesome deep dive into an agile playbook for scale up organizations. It's packed with useful advice for anyone who's looking to make their company more agile and responsive, especially as it grows. I definitely think it's a must read for leaders, managers, really anyone who's involved in organizational change and innovation. It's a good reminder that agility isn't just for software development.

It's something that can benefit any team, any department, any industry. Absolutely. It's all about being open to change, empowering your people, and always trying to improve. Well, thank you for joining us for this deep dive. We hope you found it helpful and insightful.

And remember, agility is a journey, not a destination. So keep learning, keep adapting, and keep evolving. We'll see you next time on the deep dive.

Leave a Reply

Your email address will not be published. Required fields are marked *