#0006 - agile scaling

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode we explore how large teams and organizations can become more agile. We share our experiences and critique common scaling methods including Water Scrum Fall Safe and the Big Bang top down approaches used by major consulting firms. We emphasize starting small and advocate for incremental growth and continuous improvement over Big Bang transformations. This episode offers valuable insights into effectively scaling agile, emphasizing a thoughtful, context sensitive approach to adoption and transformation within large scale programs.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

So today, Shane, I wanted to talk about how you help larger teams of 50 plus people to implement an agile approach. How do you scale agile?

So my experience is typically starting off with one team and then after that group has been getting some good success, everybody wants them to do more. And so the logical way of doing that is to scale, to put more people in, create different groups or a bigger group and see how they go in terms of achieving more. And that's when we hit the scaling problem. What about you? When do you tend to get involved in scaling?

It's really only been over the last five years. I was asked to do an agile transformation at a digital agency which had already implemented Agile and got very confused and was losing quite a lot of money. I redid the transformation across 90 people and was delivery general manager there. I found it quite easy and very successful. Since then I've been doing agile coaching for some very large programs. One that was over a billion dollars for an insurance company and one that was a few hundred million dollars for a telco. The insurance one was using Water Scrum Fall.

As advocated by the big consulting companies, and the telco one was using Safest.

So when I was able to do it myself, it was pretty straightforward and I think it worked well. But these other approaches I thought were pretty awful.

Okay, so my opinion is we have a group of people, let's call them a pod, that have adopted the agile mindset. They're going on their journey, they're seeing some success, and the organization wants to achieve more by adding more people. So my view is we should treat it as an experiment. So we've got say a pot of five, we should add another pot of five and we should experiment until running two pods together is successful. And then once that's working, we can then decide what we want to do next? Do we want to put another two pods in and go to four? How do we want to expand it out like an aneba and just keep breaking off and growing bigger and bigger?

Yeah, I like that approach Shane.

Yeah, because we are testing it and we're changing the things we do when they don't work. And as we scale, some of the things that used to work probably won't work. But what I see is this idea of we're doing okay, so why don't we add 10 squads and just replicate what squad one's doing nine times? How about you?

Yeah, everybody wants to do Agile now, at least in name. So whenever any big project or program is set up, it's just assumed that it's going to be agile. So you have this billion dollar insurance company program. Everybody just said it had to be agile obviously, but nobody who said that seemed to know what agile was and they just did water scrum fall because somehow they thought that's what agile was or it was easier to do. The other ones I've come into have already been set up and I was coming in to help. So there were already quite large numbers of people in them.

And did they start with a large number of people? Was it a standing start from zero to 200?

Yeah, that's what they tend to do. It's even bigger than that. Shane. So there's a number of major banks and telcos that are going through these business agility transformations where you've got the big three management consulting firms, McKinsey, Bain and BCG coming in and saying you're going to be able to cut out a lot of people and save a lot of money by doing this agile transformation. It's worked for Spotify, it's worked for ing, so it's going to work for you. And so there's this huge top down thing happening quite often.

Yeah, I hate the word transformation. I think it's bullshit. Think about how a butterfly happens. It goes into its cocoon, it hides from everybody and works on itself and then eventually comes out from the cocoon transformed. But it's completely isolated, it's a one off event. When we become agile, we transition consistently, continuously changing.

I agree. It's about continuous improvement and experimentation and tailoring for your situation. That's a much better way to go. I'm really against big bang transformations. They're very suitable for consulting companies because they can make a lot of money, do a lot of pacts and then leave.

Yeah, digital transformation is when the business removes all funding from it and gives it to an external party.

You can see if you're the external party that you'd be advocating that.

Yeah. And then you definitely want to advocate 500 people from a standing start because you've got a starting problem on day one there you have to pay to solve.

Let's talk about what people actually do to solve these kind of scaling problems. So I like your approach, which is start small and get one team working and then double it and then double it again. Using your experience, I would really strongly recommend that if organizations are prepared to do it, it's a great way to experiment and see what works and improve. It's a process of continuous change and improvement on how you're organized. So I like that approach. But what if for various business reasons they want to do 100 people?

So my answer is don't. So I don't believe standing start with a hundred people trying to figure out how they're going to work in the future and reinvent all that stuff will ever have success.

But there are many products, Shane, that are much bigger than a five person team. Like Spotify has 5,000 people now and there's bigger companies that have applications or products that actually do require hundreds of people to build them. Let's say that you want to build AWS inside your telco. You can't do that with five people. What I've seen, Shane, is that in big organizations you need to use your political capital to get funding and support and generally it's such an expense to get over that hurdle that you need to do something pretty big.

Yeah, I look at companies like Basecamp and I say, actually, do organizations really need to be massive? And I don't think they do, but let's take that off the table. So if we look at organizations that end up having lots of squads, lots of groups of people, then yes, that can work. But they still get there incrementally. They still continuously change how they're working as they grow into that. So if you say that actually to deliver your vision you are going to need a hundred teams, then the question should be how do we start with one team and then scale out as fast as possible but safely, Rather than saying a standing start of 500 people was a good idea, and I suppose that's my philosophy.

What would you do though, if you came in to consult on a program that had 10 squads and each squad had nine or 10 people in it? Let's say they're doing water scrum, fall or safes or something like that and you had to help them, what would you do?

My approach wouldn't change. I would spend the beginning observing, seeing what's working and what's not. Then I'd encourage their conversations to identify the things that are working they should keep doing and identify the things that are not and what they're going to do to fix that. What wouldn't I do? I wouldn't go and find a framework on the Internet and come in and say that solves the problem. I would go and look at those things and say, do any of the patterns from those frameworks seem to be able to solve our problem? We've talked before about the concept of three Amigos. So if one of the problems is each of the groups are working in complete isolation, but they have dependencies across each other and it's the dependencies that are causing the problem. There may be a Scrum or maybe a three Amigos. I've done a little bit of research around things like Less and I like some of the patterns and mindset that it seems to be doing. So I would look at those things and say, okay, if we experiment with these as a group, will it solve that particular problem?

Yeah, I like that approach as well. I find though that organizations that they've been sold a framework, they've been sold safe or they've been told that they're doing agile, but really what they've been sold is water Scrum for it's helpful to understand what these frameworks are so that you can identify them and maybe help them move away from them. What I like in terms of scaling frameworks is Scrum Nexus. The Nexus is a coordination and integration team. So you might have six to 10 scrum teams and you have a team in the middle which is integration, coordination and planning. And it's made up of a combination of leaders from each of the Scrum teams and maybe a couple of permanent people. And they run a kind of Less type of environment, which is a single product manager, single product backlog with all the teams. Nexus and Less seem very similar to me. Less is the same thing. It's single product manager, single product backlog, several teams and the teams take items off the product backlog as required and as makes sense. It's all about relatively autonomous, self managing teams that can work pretty independently off a single product backlog. There's something else called Scrum at scale. It's all based around Scrum of Scrums and the three Amigos. So you've got your Scrum Master, you've got your product manager and you're a technical person.

Yeah. The idea of having somebody who's experienced in doing the work brings a voice of experience around estimation. So they can go, yeah, that's all good. But this one looks like it's massive and this one looks like it's smaller. So they're doing some early guessing on the size of the work. It's an important voice into the conversation.

Yeah, I definitely think you're right about that. But I would like to bring a fourth voice in, which is the user experience design. I think they get short shrift in a lot of products and it's absolutely critical and they do the same sort of thing as a technical leader but in a different domain. In the domain of the user experience.

I don't see a lot of UX skills or behaviors in the data world. And in my startup we've got an awesome UX person, so probably have a little bit more experience over the last year or so based on that. And I can see the value. The question would be then what part of the conversation are they in?

All of the non technical parts and any of the technical parts they want to be in.

Right?

I would say, yeah.

So in the data world there's a whole new theme coming out, I think called data mesh, which unfortunately lots of data technologists think is a piece of technology, but it's not. What it's describing is typically an operating model. And so if you look at that and you look at some of the way other organizations have scale, I think you end up with two patterns. You end up with a pattern where each of the groups or squads have complete autonomy and then you are centralizing conversations or pattern slash control where you have to help scale to remove some conflict or some mismatches. So I think that's pattern one. I think the other pattern for scaling is everything's controlled from the center and then the bits that can be devolved are devolved out to each of the groups of the squads to execute, which is my view of what SAFE is saying. And so I'm a great fan of autonomy at the edges and centralized communication, centralized collaboration, centralized planning, centralized patterns where it makes sense, where it adds value. And so yeah, that's why I think when I read things like less, I naturally like it because it fits more within my mindset.

If you think about it, autonomous teams are like loosely coupled services. Shane. And we can also think of leadership as a service as well.

So if you think about defense force in the heat of the battle, autonomy is devolved at that time because that's important up until that. There's still a lot of central planning because that's important.

Yeah. So if you're in an army, you want to use the air power to bomb your enemies, but you don't want them to bomb you. That used to happen a lot. And the solution is to have a integrated command structure that has air, army, tanks and infantry all combined together. It's called combined warfare. And the more you can devolve it down to the lower level, the better it works. And it's the same thing with teams. If you have teams that are able to do everything they need to do, have all the skills and capabilities to deliver value from beginning to end, then they're going to be much more effective because they have a lot less dependencies. So I think actually dependencies is the key thing with scaling, Shane, I think that's worth talking about. How do you deal with dependencies?

So that's a good point. If you had a way of breaking the work down into completely isolated pieces of work that had no dependency on another group of people, then you probably won't have a scaling problem. So it's the fact that actually we end up touching something else that somebody else is touching or we're reliant on them doing a piece because it seems to make sense that we hit the problem.

So in my experience, when you scale, what happens is that you start to get all of the dependencies on other teams. And as you said, there's two ways of dealing with. So let's say that you have a team that's building some application to be used by a retail store and it needs to get data from some backend systems. So it's going to go two ways. And your organization has set up a middleware team and that middleware team has to make a whole lot of changes for you in order for you to do what you're going to do. But they're not on your timetable. They don't have your priorities. They are not actually really interested in what you're doing at all. You could find yourself very quickly blocked by them. And the solution that I would advocate is to get one person from that middleware team and put them in your team and empower them to do the work so they don't need to go back to their team all the time. So you're removing the dependencies between teams by making the team fully cross functional. And I would advocate that approach with all of the other dependencies. So if you're doing marketing and you're constantly being blocked by legal People who have a six week cycle for giving an opinion on any communications. Then get the legal person and put them in your product team.

I think that's the key is focus on the edges of your groups and the dependencies they have at those edges on somebody or something else. And that's what you have to manage in a scaling.

Yeah, and this is what DevOps is about. DevOps is not about having an ops team using Kubernetes and calling themselves DevOps and blocking everybody from delivering anything until it goes through them. That's not DevOps. DevOps is having the dev team be responsible for their own operations. There's no DevOps team.

So make a decision on whether you're going to centrally control and push out is the model you're going to use the mindset or you're going to have autonomy at all the edges and then centralize the communications or collaboration or practices and processes where it makes sense. That's the first decision. And then the second decision is are you going to be a factory or are you going to be product focused? So the example of the factory, it's almost like that lean money you talked about is you do a piece of the work and then you got to hand that off to another station, another group of people and they are dependent on you pushing that to them at the right time. And so we focus about that flow through those stations. The idea of just in time, so where's the latest? I can give it to you without blocking you and how do I manage that to happen? So that's one way of approaching it. The other approach is that end to end skilled team and that boundary starts to become the concept of a product.

I think the factory model just doesn't work at all for product or software development. But the factory model is what nearly everyone uses because the factory model works well for doing the same thing over and over again at low cost, efficiently and effectively. But products and software development has far too much uncertainty and far too much learning and change required for the factory model to work. So I'd say just take that out completely and stop doing it. You need to remove dependencies as much possible by having cross functional teams and you also need to coordinate between those teams. So there are sometimes capabilities that you only need a bit of. So you can't really afford from an economic point of view to have a full time highly skilled person in your team. Not every team needs a data scientist, but your product might need a data scientist. So there is a need for some coordinating and integrating group.

I think so if we say that every squad is autonomous and that the ability to use machine learning as part of whatever they're building is important, then.

They should have a data scientist in every team. Yeah.

Because as soon as we share, we introduce a dependency. And so what we're trying to say is end to end, full autonomy is our goal and then we manage everything else as an exception.

I would say in that situation, then every team needs to learn how to do data science. And if they don't have the skills now, then we're going to find somebody in the team who's interested in doing it and we're going to skill them up. And your lead technical leader, whoever that is, is going to mentor and coach all those people.

Yeah, I think that's a good distinction. We talk about skills, not roles.

Yeah. And that person doesn't have to necessarily be called a data scientist, although they might end up specializing in it. Let's say that you have.

Eight or 10 teams that cross functional. There's still a place for the three amigos or the four amigos. There's still a place for a technical leader or an architect or something like that somewhere. You need to be able to work on the bigger picture. And you also need to provide coaching and training and support to individuals in teams.

Yeah. There are times where we want each of the autonomous groups to communicate with each other because that communication has value. And there's ways of doing that. We've seen ones where each group will publish a blog every week as like a mini demo of what they worked on as a way of communicating. Obviously demo days is another way of communicating if people are interested. So I think that's important. As we get more and more, we probably need to communicate across those autonomous groups. I think the second one is collaboration, where there is actually going to be some form of dependency across the autonomous groups and they need to collaborate. How are we going to do that? So that can be scrum of scrums or three amigos. There's a bunch of patterns out there that you could experiment with. There is, then control. There are times where we want to control something across all those autonomous groups. We want them to be non autonomous for that. And that's typically where the architect has to come in. And the old way of working, which is these are the rules and you can't break them.

I agree with you that there needs to be some control. If I look at it from the product manager's point of view or from the business point of view, typically you've got a certain amount of time and money that you need to achieve some sort of outcome, otherwise it's just not worth doing. And so you need to make sure that everybody's aligned. There's not. There would be a big problem. There's a big problem with autonomous teams if they're going in different directions and they're not aligned.

So how do we align them? And the way I think works best is something called objectives and key results. Rather than setting a detailed scope, what you do is you define your scope in terms of your objectives and how you're going to measure success and then you talk to the teams and you agree how is each team going to contribute to achieve this objective? And maybe they'll do it by achieving sub objectives. So team one will achieve this objective that contributes overall and team two will be a second objective and team three will be your third objective. And together they'll achieve the big objectives and each one will have their own sub objective measures. So you end up getting like a hierarchy of objectives leading to your main goal. I think that's a good way of doing it.

Yeah, I like the objective part. I'm not such a great fan of the key result part.

It's about measuring whether you're achieving your objective.

And so I don't agree with that. I think it's about communicating a shared goal, combined objectives. When we talk about backlog grooming, the massive amount of value I see out of that is not the estimation they come up with, it's the conversation they have together before they start the work. And okrs. I see the conversations we have where people are. Setting objectives for each group of people is where the real value is. We're having a conversation about the organization's objectives and then the autonomous group's objectives. And as humans we will try and naturally align them.

Shane if you had 100 people working on a product and that product had a clear architecture where it had different components that do different things. Maybe there's a component that gets a lot of data from backend systems and then there's a component that deals with retail and there's a component that deals with your customer service people and so on. So you can break up your product solution into an architecture. Would you align the teams with the architecture or would you try and have everybody do everything?

So my current theory is I would break it up where I could reduce the dependencies as much as possible. So for our product I think we would experiment with what I believe Spotify did to reduce the dependencies. So search is a product within Spotify and there is a team that do search, there is the one that does the COVID up. And so they only worry where there's a dependency across those. And that's how I do it for a digital product like ours, but haven't done it yet, so can't tell if it's going to work or not.

Yeah, I like that approach too. And I think it's also probably worth experimenting with different team structure models.

So let's take it outside technology, let's put it into a bank or an insurance company because then what we're saying is actually we want vertical product groups. A product which is savings and a product which is loans. And in theory, with autonomy, they can run completely independent systems and only share data where there needs to be dependencies, which would be customer.

Right. I definitely think a product view of the world and product organization structure is much better. But there is perhaps a need for a matrix structure here because if you are operating a bank, there's going to be a time when you're building things and there's going to be a time when they're built and you just want to do them as efficiently as possible. And so when you are trying to do something as efficiently as possible, I think that's when the factory model does work, if you try and do the same thing over and over again. So I think there is a case for some shared services across product teams. But I would like the product teams to be the ones who decide whether those shared services are valuable and working for them or not. And I would like those shared services to be embedded as much as possible.

What Spotify talked about from memory was they allowed every squad to be completely autonomous right down to the technology. One was using jira, one was using Trello, one was using something else. But what they found was over time, as new squad stood up, they'd go, we need a place to store our board. What's everybody else using? And then they go, we don't care enough to go get our own. We'll just use what squad B is doing. And then over time they became critical mass. So enough of the squad said, actually we're spending too much time internally each maintaining jira. Let's have a squad that serves us by maintaining jira. For us, we're the customer they and they're providing us a product.

This is the idea of internal products for internal customers. And I think that makes a lot of sense. Why on earth is every product team building their own CRM? Why not have a single CRM so you can have a single customer view. And in order to do that you would set up a CRM product team and their customers are internal to the organization.

So I think that sounds like a control approach. Remember I said these two approaches. So that is we think it's more efficient, therefore we're going to mandate it.

I wasn't meaning it quite that way. I was thinking about your scenario. People start to build their own CRMs and somebody's done quite a good one. And so the others say, okay, let's use that. I was working for a large telecommunications company that had decided to build AWS type services. They had eight different initiatives to do this, each which was given a large amount of money. And it was mainly because of empires within the organization. It became an important strategic initiative. Every executive director wanted to have one and so they poured money into eight of them. And then after a while it went down to four and then two and then one, which is sensible, but it took them five years and maybe billion dollars before they got it down to one.

But do you think that if they started with 500 people using SAFE, all supposedly working together, they would have spent less time and less money to achieve the same outcome?

Not if they were using safe, Shane. Because SAFE is pretty awful in practice from a scaling point of view.

So while that sounds inefficient, I'm not convinced it is. I think there's also an anti pattern to it. I remember when I was working for some large American vendors and pre sales systems engineer or sales engineer, whatever it's called now, there was a kind of behavior that I believe came out of General Electric and it was this kind of hunger game. So the way it worked was every salesperson had a quota and at the end of the year you had measured against your quota. But unfortunately, even if you made your quota and you were in the bottom 20% of salespeople across the organization, you got fired even if you were successful because the organization was based on that hunger that win at all costs bring in new blood. So I think with UTILCO example, there was always a risk that eight groups fighting each other to win at all costs is a bad behavior. So I think we've got to be a little bit careful about that. But I'm not convinced that it was the least efficient way of achieving their outcome.

The most efficient way would have been to start 15 years ago or 20 years ago when AWS was starting and to start with a small team and then scale it up in an evolutionary and experimental way.

I remember when my previous company we started using AWS and I remember the AWS console with the services as you logged on and tick the box for the services you want to use, there weren't that many boxes and now I hop onto AWS and I'm like, oh my God, there are so many things. And that didn't happen overnight. It wasn't the organization bringing on 50,000 people on day one to build out all these things. It was done incrementally and continuously.

What happened was the organization didn't do anything for a long time, even though lots of people were complaining about it and told them they should do it internally. They didn't do anything for a long time until it became such a serious threat that they had to do something. So they had to play catch up, which is Borders and Amazon. You ignore the problem for a long time and you've got to do a big catch up. So you do need to spend a lot of money quickly.

Do they catch up? Are they winning?

I think that they are actually successful in building the service for internal users and it seems quite strong, quite robust and quite good from my point of view. Whether they'll be able to commercialize it and make money out of it, I'm not sure.

So maybe the answer then is if you've had inaction for 15 years and your business is in massive trouble, you have no choice but to try and scale from zero to a thousand people on day one to fix your lack of foresight, leadership and inaction. But actually it's not a good idea. The best idea is start small scale where it makes sense and as you learn and become an efficient organization at scale because you've grown to be good at it.

Yeah, I think that's definitely a much better approach. Shane. I think we agree there, there's some research on this. So Standish Group has this chaos report which they've been doing for 20 years, which is on all sorts of success factors with projects, waterfall versus agile and a whole lot of other things. And they have shown that small projects are much more successful than big projects, no matter what methodology. The Project Management Institute also has found the same thing. And then agile projects are more successful than waterfall projects. So if you have a small agile project, it's many more times more likely to be successful than a big waterfall project. Big waterfall projects have only 2 or 3% success rate with something like 20 or 30% of them or more failing. And the rest are seriously challenged.

I'm going to make a prediction in two or three years we're going to be reading the white papers that talk about the failure of agile transformations to achieve the organization's goals. And for me that's a scaling problem.

I agree with you. And the reason is that it's actually being done in a very non agile way. They're using a waterfall approach to change the organization into an agile one. So you get the big consultancies in. They lock themselves away in secret rooms with executives, they come up with a new organizational structure that has less people in it because you're using agile. And without any consultation you just say, okay, this is it, change is happening and we're going to start by training people and here's all these new jobs and you can apply for a new job, but it's very centralized, very top down, very upfront. All we need is an agile change management process which would be iterative, incremental, exploratory, and it would be highly collaborative, open and honest. Not like this big bang that's gut the organization and restructure it and make everybody apply for their jobs again.

So agile change management really is just how do we start agile small and scale out to a large organization in a good way? I do want to say it in a safe way, but I can't use that word anymore. So what are we going to call that?

I would just call it Agile change management as opposed to big bang change management.

Yeah, I hate the word change management. I think managing change is really important. I think all the baggage that comes with change management annoys me and I call bullshit on it as much as I do around the word project.

It's not collaborative normally at all. So that's a problem from an agile point of view. But we could talk about agile leadership then rather than agile change management because it's continuous, not one off.

Yeah, and at some stage I'd love to have the conversation around business agility, being serving leaders versus command and control and all the baggage that comes with a command and control organization like annual budgets. But we're running out of time. Final thoughts on how to scale I.

Think this is interesting. We both really agreed, I think that you should start small with one team and then expand out from there in a kind of evolutionary pattern like cellular division. Because you don't know what the scaling solution is going to be for your organization. And I think every organization is different. I think you should try less and nexus and scrum at scale. And there's plenty of tools in the safe framework which are good, which you could try, but it's really important to.

Experiment with them and Try them in your situation. Small teams try them and then if you are going to do something big, make that big thing made up of a bunch of small teams working cooperatively together and unified through an OKR type of approach. That's how I'd sum it up.

Yeah, I think the only way of success is starting small and getting bigger. If you are time bound. If you've waited 15 years for your competitor to stick you and you're in trouble, then actually start small. But focus on how fast you can scale. Focus on those dependencies and how you're going to manage them when new problems turn up as you double, triple, quadruple or do that exponential growth. How are you going to fix problems quickly? But definitely go look at all those other patterns out of Nexus Lex less and those ideas.

They have lots of good patterns where people have solved the problem before and you can try them out but definitely don't do a massive big bang business agility transformation from the top down. And don't do water scrum fall because your big four consulting partner said that's agile. Because I don't know what they're talking about.

Yeah, I come back to the idea of transforming away an organization works. Agile transformation is not the goal. Achieving our organization goals in a more effective way by being agile is what we try to do. The project itself is not the outcome. The thing that assists us getting the outcome.

We need to focus on the business outcome we want. And if we're doing it in an evolutionary way, we can measure and see whether the changes we're making are contributing to the outcome. And if they're not, we can try different things. But if you do like this billion dollar three year transformation program, it's only at the very end that the results are really supposed to emerge. And only then can you measure it. And only then will you find out that it didn't do anything. Which is what's usually the case.

Imagine if we had this idea of transformation ops where the people doing the transformation actually stayed after it and wore the cost and consequences of what they did. The developers actually running their own stuff.

Wow.

Imagine transformation ops.

That's the new thing I recommended having change people who focus were on the business side of change, embedded in teams or embedded in the scrum of scrums if you can't really afford to have one in each team rather than operate independently.

Jim, let's go back to that. So my view change management skills is important in every team. Unfortunately we treat it as a role, not a set of skills and therefore if our teams don't have those skills, we need some form of coach to help upgrade their skills as a team to manage that change for the organization. Skills, not roles.

You're really going to ask an application development team to contribute to design the new organizational structure? That would be empowering for them but they wouldn't have any idea what they were doing to start with.

I remember reading a manifesto about Valve. They talk about the whole idea of hierocracy and no organizational structure. So why does the organization structure need to be centrally controlled is the question.

Oh, that's a big question. I think it's so that people can build their empire. Shane.

All right, I think that's done the dash of course. We'll be here for a few more hours so good to catch up. We'll catch you next time.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help to create high value digital products and services, contact murrayvolve. Co. That's evolve with a zero. Thanks for listening.

Sam.