Agile Scaling
Podcast 005 - Scaling
Sun, 7/25 5:10 PM • 58:50
SUMMARY
Join Murray Robinson and Shane Gibson in a no-nonsense agile discussion. In this podcast, Murray and Shane discuss how to scale agile. We discuss the problems with a big bang top-down agile transformation and the benefits of starting small and experimenting to find a scaling approach that works for you. We talk about the factory model of organisation vs autonomous product teams. And we contrast agile change management with waterfall change management.
Shane Gibson
Welcome to the no-nonsense Agile podcast. I'm Shane Gibson.
Murray Robinson
And I'm Murray Robinson.
Murray Robinson
We want to talk about doing Agile in big organisations at scale today.
Shane Gibson
Let's put a background on where I typically have the scaling problem. I will typically be brought in by an organisation that has one team that are starting their Agile journey. I will typically get bought in at the beginning, which is ideal, where they say, Hey, we want to do this. We see value in coaching to help us get there faster and safer. The other model is they've had a go for a while and they haven't been getting the benefit's they were expecting they bring me in to help coach the team. My experience is typically starting off with one team, then after the group got good results, everybody wants to do more. The logical way of doing that is to scale. To put more people in the team or to create different groups or a bigger group and see how they go. That's when we hit the scaling problem. What about you, when do you tend to get involved in this beautiful thing called scaling?
Murray Robinson
It's been over the last five years. I was asked to do an Agile transformation at a digital agency that had implemented Agile, got very confused and was losing a lot of money. I redid the transformation across 60 people as delivery general manager. I found it quite easy and very successful. Since then I have coached management and teams on a billion-dollar digital program for an insurance company and a $200 million dollar Telco program. The insurance company was scaling with WaterScrumFall and the Telco was scaling with Safe. Both of these approaches were pretty awful.
Shane Gibson
My experience is that we have a group of people, let's call them a pod, that have adopted the Agile mindset and are going on the journey. When management sees their success they want to accelerate that success by adding more people. My view is that we should treat scaling as an experiment. If we've got a pod of five that is working well then we should experiment with another pod until running two pods together is successful. Then once it's working, we can then decide what we want to do next. Do we want to put on another two pods and go to four? How can we expand that out like an amoeba and keep breaking off and growing bigger and bigger?
Murray Robinson
I like that approach.
Shane Gibson
We're testing and changing the things we do to see if they work as we scale. The problem I see is that organisations want to go from one squad to 10 squads that replicate what squad one is doing. Because why wouldn't that work? How about you?
Murray Robinson
Everybody wants to do Agile now, at least in Name. Whenever any big project or programme is set up, it's assumed that it's going to be Agile. You had this billion-dollar insurance company programme that everybody said had to be Agile but nobody seemed to know what Agile was. So they did Water Scrum Fall because somehow they thought that's Agile and it was easy to do. The programs I've come into help have already been set up with large numbers of people in them.
Shane Gibson
And did they start with a large number of people? Was that a standing start from zero to 200?
Murray Robinson
That's what they tend to do even if it's bigger than that. There's a number of major banks and telcos that are going through business agility transformations with the big three management consulting firms, which are McKinsey, Bain and BCG. These consulting firms are saying that Agile has worked for Spotify and it's worked for ING it's going to work for you. You're going to be able to cut out a lot of people and save a lot of money by doing an Agile transformation. It's done as this huge top-down thing.
Shane Gibson
We had that conversation about how much I hated the word project previously, I also hate the word transformation. When people use the term about how a butterfly goes into its cocoon, hides from everybody and works on itself
Murray Robinson
It dissolves into cells and rebuilds itself from the ground up,
Shane Gibson
And then eventually comes out from the cocoon transformed. But it's completely isolated. It's a one-off event. It's not Agile. When we do Agile we continuously change.
Murray Robinson
Yes, I agree. It's about continuous improvement and experimentation and tailoring for your situation. That's a much better way to go. I'm against Big Bang change transformations. They're very suitable for big consulting companies because they can do a lot of slide packs, make a lot of money and then leave.
Shane Gibson
I was listening to podcasts the other day and I heard the best definition of digital transformation that I've heard before. Digital transformation is when the business removes all funding from IT and gives it to an external party.
Murray Robinson
That's funny. You can see if you're the external party that you'd want to be advocating that.
Shane Gibson
Then you definitely want to educate 500 people from a standing start, because you've got a scaling problem on day one that you have to pay to solve.
Murray Robinson
I like your approach, which is to start small and get one team working, and then double it, and then double it again using your experience. I strongly recommend that approach if organisations 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 organizational improvement which takes account of all these different teams. But what if, for various business reasons, you can't do that, there are already 100 people in a program?
Shane Gibson
My answer is don't. I don't believe that you will ever have success if you start with 100 people and try to figure out how they are going to work in the future and reinvent all that stuff.
Murray Robinson
But there are many products that are much bigger than a five-person team. Spotify has 5000 plus people now and there are other big companies that have applications, or products that require hundreds of people to build them. Let's say that you want to build your own version of AWS inside a Telco as a theoretical example. You can't do that with five people. Maybe you could start the way you've said. In big organisations, you need to use your political capital to get funding and support. It's such an expense to get over that approval hurdle that you need to do something pretty big to make it worthwhile.
Shane Gibson
I suppose at companies like Basecamp. Organisations don't need to be massive. But let's take that off the table. Organisations that have lots of teams can be Agile but they need to get there incrementally. They need to continuously change how they're working as they grow. If you're going to need 100 teams to deliver your vision, then the question should be how do we start with one team and then scale out safely as fast as possible. I don’t think a standing start of 500 people is a good idea. I suppose that's my philosophy.
Murray Robinson
Well, this is going to be a short conversation if we stick with that. What would you do, though, if you came in to consult on a programme that had 8 to 10 squads, and each squad had 9 or 10 people in them. Let's say they are in trouble and they're doing Water Scrum fall or SAFE or something like that, and you had to help them? What would you do?
Shane Gibson
My approach wouldn't change. I would spend the beginning observing. Seeing what's working and what's not. Then I would encourage conversations to identify the things that are working that they should keep doing and identify the things that are not and help work out how to fix them. I wouldn't go and find a process framework on the internet and say that solves the problem. I would ask if any of the patterns from those frameworks are helpful. We've talked before about the concept of three amigos. If teams have dependencies across each other that are causing a problem then Scrum of Scrums or the three amigos pattern might help. I like the patterns and mindset in LESS. I would ask if we experiment with those patterns as a group would it solve that particular problem?
Murray Robinson
I like that approach as well but I find that these organisations have always been sold a framework. Often it's SAFe or WaterScrumFall. It's helpful to understand what these frameworks are so that you can help people move away from them. I like lightweight scaling frameworks like LESS and Scrum Nexus. Scrum Nexus is a coordination and integration team. If you have six to 10 Scrum teams working on a product then you have a Nexus team in the middle that does integration, coordination and more advanced planning. It's made up of a combination of leaders from each of the Scrum teams, and a couple of permanent people. They have a single Product Manager and a single Product Backlog for all the teams. LESS is the same thing. It's a single Product Manager and a single product backlog with several teams taking items off the one product backlog as makes sense. Usually what happens is that teams focus on particular parts of the problem. In these lightweight scaling frameworks it's all relatively autonomous, self-managing teams that work pretty independently off a single product backlog. There's something else called Scrum at Scale, which is Jeff Sutherland's thing. Scrum at Scale is quite interesting. It's all based around Scrum of Scrums and the Three Amigos. You've got your Agile coach or Scrum Master you've got your product manager who's the other amigo?
Shane Gibson
Normally the key technical person
Murray Robinson
Scrum at Scale doesn't recognise a technical leader as far as I can tell. It scales up around the Scrum Master and the Product Manager.
Shane Gibson
In the data world, at least, it's important to have somebody who's doing the work to bring experience for estimation. To say this feature looks massive and this one looks smaller. They're guessing early on the size of the work which brings an important third voice into the conversation.
Murray Robinson
I definitely think you're right about that. But I would like to bring the fourth voice in for user experience design. Designers get short shrift in a lot of products, and it's absolutely critical they do the same thing as a technical leader, but in a different domain, the domain of the user's experience.
Shane Gibson
We don't see a lot of UX skills or behaviours in the data world. In my startup, we've got an awesome UX person. So I have more experience over the last year and I can see the value. The question would be then, what part of the conversation are they in?
Murray Robinson
They are in all of the non-technical parts of the conversation and any technical parts they want to be in.
Shane Gibson
I'm a great fan of that. One of the key things is autonomy. In the data world, there's a whole new theme coming out called data mesh, which lots of data technologists think is a piece of technology, but it's not. It’s describing an autonomous operating model. If you look at the way organisations have scaled you end up with two patterns. You get one pattern where each of the groups has complete autonomy and you have central conversations and patterns to remove conflict and mismatches. The other pattern for scaling is everything's controlled from the centre and bits are devolved out to each group to execute which is the way SAFe scales. I'm a great fan of autonomy at the edges coordinated by centralised communication, centralised collaborations, centralised planning and centralised patterns where it makes sense and where it adds value. That's why I like LESS because it fits more with my mindset.
Murray Robinson
This has an analogy with technical architecture patterns. Because if you think about it, autonomous teams are like loosely coupled services. We can think of leadership as a service.
Shane Gibson
If you think about our Defence Forces, in the heat of battle autonomy is devolved. Up until then, there's a lot of central planning. Those patterns need to be applied at the right time.
Murray Robinson
If you're in an army you want your air force to bomb your enemies before you get to them but you don't want them to bomb you. The solution is to have an integrated command structure that has the airforce, army, tanks, and infantry combined together. It's called combined warfare. The more you can devolve it down to the lower level the better it works. It's the same thing with teams. If you have teams that 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 fewer dependencies. Dependencies are the key problem with scaling.
Shane Gibson
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 won't have a scaling problem. When we touch something that somebody else is touching, or we're reliant on them doing a piece of work for us then we hit the problem.
Murray Robinson
I agree.
Shane Gibson
Defence is an example. Microservices are an example of loosely coupled technologies. Do you have any other examples of scaling that's outside of the world of Agile?
Murray Robinson
In lean manufacturing, there's this idea of operational cells, where you take a section of the assembly line, let's say you have 12 steps on six machines, and you organise them into a circle. So five operators will work in a circle together to work out how to do their part of the build, and they'll move from station to station as required. I haven't seen it in practice, but it's part of the Lean process. It's an interesting one.
Shane Gibson
I assume that if we think about it, afterwards, there'll be a bunch of other examples from ecology or elsewhere.
Murray Robinson
When you scale you get dependencies on other teams. Let's say that you have a team that's building an eCommerce application for a retailer that needs to get inventory data from warehouse systems in near real-time. Most organisations will set up a middleware team to integrate data and provide it to other systems. The problem is that this team will block you because they are on a different timetable, with different priorities. The solution is to get one person from that middleware team assigned to work in your team. This removes the dependencies between teams by making the product team fully cross-functional. I advocate this approach with all of the other dependencies. If you're doing marketing, and you're constantly being blocked by legal people who have a six-week cycle for approving communications, then get the legal person and put them in your product team.
Shane Gibson
The key is to focus on the edges of your groups and the dependencies they have at those edges on somebody or something else. That's what you have to manage in scaling.
Murray Robinson
This is what DevOps is about. DevOps is not an Ops team using Kubernetes that blocks everybody from delivering 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 because Dev and Ops are combined in one team. DevOps was developed to solve the dependency problem.
Shane Gibson
Your first decision should be whether you're going to centrally control a function and push it out or if you're going to have autonomy at the edges and centralise the collaboration practices and processes where it makes sense. The second decision is, are you going to be a factory or are you going to be product-focused? In a factory, you do a piece of the work and then hand it off to another group of people. They are dependent on you pushing it to them at the right time. In a factory, we focus on alignment in flow through stations. In just in time manufacturing we ask what is the latest I can give you something without blocking you, and how do I manage that to happen. That's one way of approaching it. The other approach is to have a skilled team that produces a product from end to end in one team. I think we should have a product team for software development.
Murray Robinson
Everyone uses the factory model because it's the most cost-effective way to do the same thing over and over again. But product and software development is different every time. There is far too much uncertainty, learning and change in product development for the factory model to work. People need to stop developing software in a factory model. When you're developing products you need to remove dependencies on other groups by having cross-functional teams. You may need to coordinate between those teams so that you can make use of capabilities that are too expensive for one team. Your product might need a data scientist but you don't need one in every team. So there is a need for a coordinating and integrating group.
Shane Gibson
You've mixed your models which I hate. If we apply constraints we have to move to a hybrid model. If machine learning is an important part of the product then every team should have a data scientist. We should minimise dependencies on a central team as much as possible. As soon as we introduce a dependency then we lose full end to end autonomy.
Murray Robinson
If every team needs data science then they should learn how to do it. 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. Your technical leader is going to mentor and coach all those people so they can do it themselves.
Shane Gibson
That's a good distinction. We should talk about skills not roles.
Murray Robinson
That person in each team doesn't have to be called a data scientist, although they might end up specialising in it.
Shane Gibson
A few years ago we called them a data miner and 30 years ago we called them a statistician. Five years from now we'll have a fancy new name for the same old stuff,
Murray Robinson
We will probably call them AI researchers because that's the magic wand now.
Shane Gibson
That's when the machine will be doing it for us.
Murray Robinson
I still think there is a place for the three amigos if you have eight or 10 cross-functional teams. There is still a place for a technical leader, or an architect to work on the bigger picture and provide coaching, training and support to individuals in teams.
Shane Gibson
There are times where we want each of the autonomous groups to communicate with each other. I've seen organisations where each group published a blog every week to show what they worked on. Demo days are another way of communicating with people who are interested. As we get more teams we need to communicate more. The second thing is collaboration. Where there are dependencies across autonomous groups then they need to collaborate. They can experiment with Scrum of Scrums or three amigos and a bunch of other collaboration patterns. There are also times where we want to control something across autonomous groups. We may need an architect who sets architecture rules that control the dependencies across multiple groups. I like common Objectives for a team of teams but I'm not such a great fan of key results.
Murray Robinson
I agree that there needs to be some control. Businesses have a limited amount of time and money to achieve an outcome. Otherwise, it's not worth doing. You need to make sure that everybody is aligned or there will be a big problem. If autonomous teams are going in different directions then they're not aligned. The best way to align them is through objectives and key results. Rather than setting a detailed scope, you define your scope in terms of your objectives and how you're going to measure success. Then you agree on how each team is going to contribute to achieving the objective. Maybe they'll do it by achieving sub-objectives. Team one will have a sub-objective that contributes to the overall goal, team two will have a second objective and team three will have a third objective. Together they'll achieve the big objective. You end up with a hierarchy of objectives leading to your main goal. That's a good way of doing it. It's about measuring whether you're achieving your objective.
Shane Gibson
I don't agree with that. It's about communicating a shared goal with combined objectives. The value of backlog grooming is not the estimation, it's the conversation we have before we start the work. The value of OKRs is not the success measures, it's the conversations we have with people when we're setting objectives. When each autonomous group knows where the real value is they will naturally align their objectives to them.
Murray Robinson
If you had 100 people working on a product, and that product had a clear architecture where it had different components that did different things would you have everybody do everything or would you align the teams with the architecture? For instance, would you have a team that builds the CRM for customer service, a team that builds the eCommerce website and a third team that implements the warehouse system?
Shane Gibson
I've been thinking about how to scale our startup. My current theory is that I would break up the work where I could reduce the dependencies as much as possible. I would experiment with the model Spotify used. The Spotify app is divided up into different zones or products within the larger product. Spotify treats search and album art as different products with different teams. They only worry when there's a dependency across those two products. That's how I'd do a digital product like ours but I haven't done it yet. I can't tell if it's going to work or not.
Murray Robinson
I like that approach too. It's worth experimenting with different team structure models.
Shane Gibson
Let's take this model outside technology. In a bank or an insurance company, we would have vertical groups that ran the savings and loans products autonomously with independent systems that only shared data where there needs to be a dependency such as a customer.
Murray Robinson
I think a product view or the world and product organisation structure is much better. But there may be a need for a matrix structure. In a bank, there will be times when you're building things and a time when they're built and you want to operate them as efficiently as possible. The factory model is a very efficient way to deliver the same service over and over again. There is also a case for shared services across product teams but only if the product teams can decide whether to use them or not. I would like shared services to be embedded in the product teams as much as possible.
Shane Gibson
I think that Spotify allowed every squad to be completely autonomous down to the technology. One team used JIRA, another team used Trello and a third-team used something else. But what they found was that new squads found it easier to use the same tools as everyone else. Then they got to a critical mass where it became easier to have one squad manage a tool for everyone rather than doing it themselves. And that squad provided the tool as a product to other teams which were their customers.
Murray Robinson
This idea of internal products for internal customers makes a lot of sense. This is how you should treat your shared services. It would be better to have a single team provide a single CRM for everyone than to have each product team build their own. Then you can have a single view of each customer. You could set up a CRM product team whose customers are internal to the organisation.
Shane Gibson
That sounds like a control approach that we're going to mandate because we think it's more efficient.
Murray Robinson
I wasn't meaning it that way. If different product groups need a CRM and somebody has a good one then other groups can choose to use it. I worked for a large telecommunications company that decided that it was critical to building cloud infrastructure for their products and services. Every executive wanted their own cloud infrastructure because it was strategically important. As a result, eight different divisions started building their own clouds at enormous expense. Over five years this company spent a billion dollars on these initiatives slowly consolidating them down into one common infrastructure initiative.
Shane Gibson
Do you think that if they started with 500 people using SAFe that they would have spent less time or less money to achieve the same outcome?
Murray Robinson
Not if they were using SAFe because SAFe is pretty awful in practice.
Shane Gibson
While that sounds inefficient, I'm not convinced that it's an anti-pattern. When I was working for large American vendors as a sales engineer they had this hunger games behaviour that came out of General Electric. At the end of each year if you were in the bottom 20% of sales you were fired even if you made your quota. It was a win at all costs hunger games system to bring in new blood each year. In your telco example, there is a risk that 8 groups fighting each other to win at all costs will cause bad behaviour. We've got to be careful about that but I'm not convinced that it is the least efficient way of achieving your outcome.
Murray Robinson
Well, the most efficient way to build your own cloud infrastructure would have been to start 15 or 20 years ago with a small team and scale it up in an evolutionary and experimental way as Amazon did.
Shane Gibson
When you log onto the AWS console you tick the box for the services you want to use. When I started using AWS there weren't that many boxes and now there are so many things. That didn't happen overnight. AWS didn't bring on 50,000 people on day one to build out all these things. That was done incrementally, and continuously.
Murray Robinson
This Telco didn't do anything for a long time even though a lot of people had been complaining about their infrastructure for decades. They didn’t do anything until cloud services became such a serious threat that they had to do something. Then they had to play catch up, like Borders and Amazon. If you ignore a problem for a long time you need to spend a lot of money to catch up quickly.
Shane Gibson
Did they catch up? Are they winning?
Murray Robinson
They were successful in building cloud infrastructure services for internal users. It seems quite strong, robust and flexible. I don't know if they will be able to commercialise it and make money out of it but they can use it to accelerate the products and services they build on top of it.
Shane Gibson
Maybe if your business is in massive trouble because you didn't make progress on an important issue for 15 years then you have no choice but to try and scale from zero to 1000 people on day one to fix your lack of foresight, leadership and inaction. But it's not a good idea. The best idea is to start small, scale where it makes sense, as you learn and become an efficient organisation at scale because you've grown and to be good at it.
Murray Robinson
That's definitely a much better approach. Also, there's research on this. The Standish Group produces the CHAOs report on success factors with projects. They have shown that small projects are much more successful than big projects and Agile projects are more successful than Waterfall projects. The Project Management Institute found the same thing. Small Agile projects are far more likely to succeed than big waterfall projects. Big waterfall projects have only a 2% or 3% success rate with 20% to 30% failing, and the rest are seriously challenged.
Shane Gibson
I'm going to make a prediction that in two or three years, we're going to be reading white papers that talk about the failure of Agile transformations to achieve the organization's goals. For me, that's a scaling problem with a massive scale.
Murray Robinson
I agree with you, the reason is that it's being done in a very non Agile way. They're using a waterfall approach to change the organisation into an Agile one. You get the big consultancies in. They lock themselves away in secret rooms with executives and come up with a new “Agile” organisational structure that has fewer people in it. They train people in the basics and then tell them to apply for a new job in the new structure. It's a very big centralised, top-down redesign which is very unagile. What we need is an Agile change management process, which is iterative, incremental, exploratory, highly collaborative and open and honest. Not a big bang where you restructure the organisation and make everybody apply for their jobs again.
Shane Gibson
Agile change should start small and scale-out to a large organisation over time.
Murray Robinson
I would call it Agile change management, as opposed to Big Bang change management.
Shane Gibson
I hate the word change management. Managing change is important but 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.
Murray Robinson
Well, it's not collaborative at all. That's a problem from an Agile point of view. We should talk about Agile leadership rather than Agile change management, because it's continuous, not one-off.
Shane Gibson
I'd love to have a conversation around business agility. The behaviours of being a servant leader versus command control, and all the baggage that comes with a command control organisation, like annual budgets. But we're running out of time. Final thoughts on how to scale?
Murray Robinson
You should start small, with one team and then expand out from that area with an evolutionary pattern like cellular division. You don't know what the scaling solution is going to be for your organisation. Every organisation is different. You should try lightweight scaling frameworks like LESS, Scrum Nexus and Scrum at Scale. There's plenty of good tools in the SAFe framework which you could try, but it's important to experiment with them and try them in your situations. I would try these methods on small teams first. If you are going to do something big then make that big thing out 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.
Shane Gibson
The only way of successfully scaling is to start small and get bigger. If you're in trouble because you've waited 15 years for your competitor to take you out, then start small and focus on how fast you can scale. Focus on your dependencies and how you're going to manage them. New problems will turn up as you go through exponential growth. Fix those problems quickly, at scale and speed. We should focus on Scale at speed. Go look at all the patterns in Nexus, LESS and those ideas because they have stuff that makes it easier and may work for you.
Murray Robinson
There are lots of good patterns where people have solved the problem before. You should try them out. Don't do a massive Big Bang agility transformation from the top down because a partner at a big management consulting firm said that's Agile. They don't know what they're talking about.
Shane Gibson
Agile transformation is not the goal. Our goal is to achieve the organisation goals in a more effective way by being Agile. Agile is not the outcome. It's the thing that helps us get the outcome.
Murray Robinson
I agree that we need to focus on the business outcome we want. If we're doing it in an evolutionary way we can see whether the changes we're making are contributing to the outcome. If they're not, we can try different things. If you do a billion-dollar three-year transformation programme the results will only emerge at the end. It's only then that you will find out that it didn't do anything.
Shane Gibson
Imagine if the people doing the transformation stayed after it and wore the cost and consequences of what they did, like developers operating their own code. Transformation Ops, that's the new thing.
Murray Robinson
I recommended having people focused on the business side of change embedded in teams or the Scrum of Scrums rather than operating independently.
Shane Gibson
Change management skills are treated as a role and not a set of skills. If our teams don't have those skills we need a change coach to help them upgrade their skills as a team to manage that change for the organisation. Skills, not roles.
Murray Robinson
Are we asking an application development team to design the new organisational structure? It would be empowering for them but they wouldn't have any idea of what they were doing to start with.
Shane Gibson
I remember reading Valves' manifesto. The founder of Valve has been in New Zealand for the last 12 to 18 months because he got stuck during COVID. Now he's become a New Zealand citizen. Valve talks about holacracy and no organisational structure. Why does the organisation structure need to be centrally controlled at all?
Murray Robinson
It's so that people can build their empire, Shane.
Shane Gibson
Well, that's done otherwise we'll be here for a few more hours. good to catch up as always. We'll catch you next time.
Murray Robinson
That was the no-nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with Agile contact Murray at evolve, co thats evolve with a zero. Thanks for listening.