Beyond Scaling and Onto Descaling with XSCALE

Peter Merel has an impressive résumé: XP pioneer, author of the original Wikipedia wiki-engine, and founder of XSCALE Alliance. XSCALE Alliance follows de-scaling practices and values, where the goal is, among other things, to “enable [self-organizing teams] to self-manage and self-direct.” Merel takes us on a thought-provoking stroll through topics like:

• Frameworks as pattern languages
• A “damning statistic” that may have been overlooked in a recent VersionOne’s State of Agile Survey
• Throughput accounting
• YAGNI – “You aren’t going to need it”
• And – most interestingly to us – descaling in a business agility context

How can we achieve alignment between lots of these little autonomous teams to be able to build something like a self-organizing value stream, or a self-directing portfolio? That’s really our challenge.

Accenture | SolutionsIQ’s Adam Mattis hosts. To find out more about XSCALE Alliance, visit xscalealliance.org

The Agile Amped podcast is the shared voice of the Agile community, driven by compelling stories, passionate people, and innovative ideas. Together, we are advancing the impact of business agility.

Podcast library: www.agileamped.com

Connect with us on social media!

Twitter: twitter.com/AgileAmped

Facebook: facebook.com/agileamped

Instagram: instagram.com/agileamped

 

Read the full transcript

ADAM MATTIS: Welcome to Agile Amped. I’m your host, Adam Mattis. This is your one stop shop for all things Agile, all things business agility, and in general, some great conversations. Our guest today is coming to us live all the way from Australia, where it’s Friday here and it’s Saturday there, which is always kind of trippy. But our guest today is Peter Merel. Peter is Australia’s longest serving agilist and played a part in the formation of the Agile Alliance. In 2015, Peter founded his own company, XSCALE Alliance as “the Linux of the Agile world”. Peter also has three decades in delivery programs, and has authored patents in scheduling, e-currency, pattern recognition, and social ratings. Peter’s led multiple startups and open source projects, including the original Wikipedia wiki engine. Peter, I think that somehow makes you responsible for a C that I received in English class for inappropriately citing something from Wikipedia.

PETER MEREL: Well, as long as I’ve done something with all of my life, I feel gratified.

ADAM MATTIS: Peter, welcome. So give us an idea, who is Peter Merel? Wikipedia, agility, XSCALE Alliance, what’s your story?

PETER MEREL: So, I started out life as someone who was mainly focused on software delivery. As far as I was concerned, there was very little about Agile. In my purview, I was a developer, then an architect, and I got roped into this stuff in the mid 90s. I wound up running the second XP program in the world, back in ’98, and I have a credit in the first XP book. But it wasn’t what I did. About 10, 12 years ago, I was involved in a couple of transformations for ThoughtWorks, initially, and then I wound up running transformations for Australia’s second largest insurer, and its largest insurer, and then that led me to become strategist and principal coach for the transformation of Australia’s largest banking group, Commonwealth Bank Australia.

So I did that for about three years, and at the end of that, I wound up on stage with the Group CIO Michael Harte, and he said Agile is one of the five pillars of this bank’s future. And he had me talk to his direct reports for 10 minutes. And you have to understand this is a bank that had fired me for doing Agile about six years prior. So that was rather exciting.

Anyway, I realized that I had learned something about transformation, and I wanted to bring these ideas into the culture. And so I needed a vehicle to do it. I didn’t want it to be the Peter Merel show. So, after a couple of interesting false starts, we wound up with this idea of “the Linux of the Agile world.” And these days, we focus heavily on business agility first. Descaling, self-propagating transformation, and so on. But as far as I’m concerned, this is still not the Peter Merel show. I have no ambitions to be a Dean Leffingwell. I’m more of a Linus Torvalds for an ecosystem of Agile coaches.

ADAM MATTIS: It’s a great story, Peter. So, one thing you mentioned that you work in, an area you work in, and it’s an area where I spend a lot of time as well, and I’m kind of curious, in your own words: how would you define business agility? Because, I know in my own experience doing similar work, our conversations always started with Agile teams in the software space, and doing Scrum, and understanding how to deliver faster and behave as teams. And eventually the conversation expanded because it became very apparent that the way that the organizations were structured wasn’t conducive to how we expected these teams to behave. And for us, in our experience, that’s where the business agility word and philosophy really came from. But for you, for you personally, what does business agility mean?

PETER MEREL: There’s a damning statistic in last year’s Version One State of Agile survey. Although they had 98% of their respondents stand up and say “Yes! Agile is working for us at a project or a team level.” Ninety-six percent of their respondents said that Agile isn’t helping them to adapt to changing market conditions. So, from my point of view, that idea of your organization adapting continuously to changing market conditions, that’s business agility. And the fact that we’ve been going at this this long – using Agile in IT and then this lovely idea of scaling – and we still only have 4% of the market that thinks that Agile is helping them adapt to changing market conditions. That’s the crying need for business agility.

ADAM MATTIS: Certainly. And so, when you talk about descaling, I think it’s a very interesting point because we had done some preliminary conversation around what it meant to scale and kind of some of the frameworks that are out there. And I’d kind of asked you a leading question that I hope you’re willing to answer now. And-

PETER MEREL: Sure.

ADAM MATTIS: I have my own opinions and I’m happy to share those as well, but I’m very curious to hear yours. So, when we talk about descaling, and you look at all this various scaling frameworks that are out there. And we don’t have to name them all, but there are several. In your opinion, do you view those as a good interim step to a much broader conversation or a step that’s actually led us to this conversation that we’re able to have today?

PETER MEREL: I guess the real question is do scaling frameworks do more harm than good? And unfortunately, we don’t have the numbers on this. I think that every agilist out there has an opinion, one way or another, about various frameworks and some people have commercial interests that might lead them to change their opinion. From my point of view, I like the idea that we are all about benefiting the client. This is about capability uplift and primarily in a business agile sense, this is about improving business throughput, in the original Goldratt sense.

So, that’s to say, operating expense, plus net profit, minus truly variable costs. None of the words I’m using are about Agile in IT. So, the idea that we would have to begin with Agile in IT to be able to do this with our businesses, I think that that idea has hamstrung us. It’s kind of put the blinkers on and led us to go down this very narrow frame, and then go “Oh, gee, outside this frame there’s some interesting opportunities. Why don’t we pay attention to that?”

If, instead, we take a breadth first approach to this, then we can put the scaling frameworks into context. There’s nothing wrong with their content. From my point of view, a scaling framework is, or of any kind of framework, is a pattern language in the sense of Chris Alexander’s pattern language, or the design patterns book if got any familiarity in that. The idea of a pattern as a well-proven solution to a commonplace problem in specific context. That’s a really good idea. And so all of these frameworks have useful patterns, in that sense. But a lot of them also come along with cults. And so, I see that any kind of a cult is going to be bad news when it comes to introducing new capabilities to an organization.

But you also asked about descaling. There has been some lip service-

ADAM MATTIS: Before we dive into that, Peter-

PETER MEREL: Go ahead.

ADAM MATTIS: There’s two points that I’d like to unpack real quick. I love what you said about the call out for pattern from those frameworks. And I think that’s where a lot of well-intended people get lost. And, similar to your reference to patterns, I refer to a lot of them as a toolkit. And when there’s a lot of conversation around this framework or that framework is good or it’s bad or whatever else, I go back to what you said about more of that cult-like mentality following, where maybe in old way of working, I was this specific thing, and in this new way of working, I’m this specific thing, and with this framework I can continue to justify the things that I’ve been doing. And I think that it speaks to a much broader organizational issue. It’s the concept of the pattern or the tool. If you have a tool, if you have a good pattern, and you misappropriately use it, then your results are poor.

I think there’s a lot of that in business right now, and I think it ties back to, pardon me, another point that you made. And that was, we have this misconception that agility needs to start in IT. And I think what brought us here, and I’d be curious to know your thoughts, is the business case to do technology faster was much more obvious say, five or six years ago, than the business problem that we have today. So, five or six years ago it became apparent that we can no longer wait. We don’t have the luxury to deploy technology slow any more, because the markets are moving too fast. So that was the convenient conversation for traditional Agile transformation within IT.

But in the last three or four years, the entire business world’s been flipped on its head with the cool things like the access to manufacturing that we have through Alibaba, with the great desktop capabilities that you have through 3D printing, and CNC, and laser cutting. There is literally no industry, and AWS, I mean let’s be honest, you don’t need to build a computer and a server in your garage to start a tech company. For $9.99 a month, you can go out there and get all the computing capacity that you want. So I think for the first time in the history of business, a lot of these large, safe organizations, no pun intended “SAFe,” they’re to this place now where it’s not just technology.

It’s for one, we need to become a digital business, and truly understand what that means. And in order to be a digital business, that is in a position to understand our customers, and to satisfy our customers, basically on demand, we have to do business different. So I really love the point that you made about how we shouldn’t be having the agility conversation with clients today, in regard to IT. It needs to be holistic.

PETER MEREL: I think that we have to put these things into context. The fact that we have beautiful clouds where we can get a lot of NoOps services doesn’t mean that we don’t need DevOps. When it comes to business agility, if our business agility doesn’t hook on directly to what we do with DevOps, and product management, if we don’t have a holistic solution there, we’re going to be in trouble. But the problem, then, is “Wow! That sounds really fat, that sounds really heavy.” We need a very straight forward way of growing capability and there is a principle that comes from the original XP, called YAGNI – You aren’t going to need it. This was originally articulated by Ron Jeffries, and it’s kind of been dropped by the wayside outside of the IT context.

When it comes to change, we have in frameworks, an idea that you have to do it all. If instead, we go well, let’s look at the current pains and opportunities, and let’s understand our bottleneck constraints. Let’s target those with practice patterns. Let’s focus our change program on developing an uncompromised but small capability. That’s going to answer these particular specific bottlenecks and risks. And then let’s grow it. That way we can avoid the issue of, oh, well, which parts of these frameworks do we use and how do we bolt them together to be able achieve business agility. Instead, if we start with business agility, business constraints, business drivers, and then understand an epic landscape for the transformation and deal with it in little increments, use Agile to roll out Agile, focus on the things we need right now, the rest of it is all going to come. It’s not that it won’t. But it’ll come in a way that’s directed by the actual problem domain, rather than by introducing things for sake of introducing things.

ADAM MATTIS: Certainly, that’s a great point. It’s look at these frameworks as what they are, and then figure out what’s the leanest approach we can take to solve the problems that we have. We don’t need it all. I like that.

PETER MEREL: We do it agnostically. Yes.

ADAM MATTIS: Certainly. So, Peter, can you tell us more then about descaling. That’s kind of your bread and butter and the flag you’re flying right now. I’d love to learn.

PETER MEREL: All right. So, let’s begin with some simple metrics. What makes for business agility, in terms of our organizational structures. We know that self-organizing teams have an ideal size. And that size is not seven, plus or minus two. It’s six. There’s plenty of data. It’s just six. Six people can self-organize. We don’t have to worry very much about identifying some specific leadership or managerial roles. That’s fine. We can do little autonomous teams like that. Trouble is, we have to align them. So, a lot of the ideas of scaling, and a lot of the original command and control of business ideas, were about alignment. How can we achieve alignment between these lots of little autonomous teams to be able to build something that we could think of as a self-managing value stream, or a self-directing portfolio. That’s really our challenge. Bringing it back to metrics.

So we want to look at what is the maximum number of people we have to have in a room to make a decision. We also want to look at how long does a decision go unreviewed. So, we’ve got the maximum meeting size, we’ve got the minimum feedback frequency, across the entire organization. And then there’s one more metric that’s important to us. We want people to make their decisions through face-to-face sharing of learnings and collaboration. This is in the Agile Manifesto. Business and technology should be collaborating daily, not once a quarter.

So, if they’re going to do that, we also have to introduce design. We need some simple patterns that will allow us to reduce the collaboration-delegation ratio. So, if we’re making decisions face to face, collaboratively, that’s what we want. The idea we’re going to delegate decisions to some third parties or middlemen, and they’ll make the decisions for us, that’s stepping from away from the business agile capability. So, if autonomy and alignment are going to replace command and control, then we have to begin by understanding the current state in terms of these simple metrics. And then look at, really well proven practice patterns for addressing those numbers. So, let’s just say, you don’t have to say descaling and scaling are polar opposites. You can work with scaling frameworks and still introduce descaling patterns. And get enormous benefit to business agility.

ADAM MATTIS: So, Peter, that’s great, and really thank you so much for unpacking that for us. The question I have is that you’ve mentioned a lot of success in the finance and insurance sectors, which aside from health care and maybe airlines, are some of the most dug in, in how they do business and you know, they can cite compliance or regulatory, and I’m sure it’s the same in Australia as it is here, where there’s a lot of oversight. So when these businesses are highly risk-averse, and they’re very comfortable doing things the way that they do them, and they’re traditionally very hierarchical organizations – how do start this conversation with them? How do you get movement?

PETER MEREL: So that’s a really good question. And I should mention I worked in the States for seven years. I’m a dual US/Australian citizen. So, I like to think I’ve got sufficient cultural context to be able to say, “Yeah, it is very similar in both of these cultures.” Risk-aversion is natural to any organization that needs to focus on its bottom line. So part of the change is we have to change the focus to the top line. This has to be about business throughput, not operating expense. But, in terms of change model, we have to change gears as well. In my experience, the idea that we’re going to push change into a large organization is just a recipe for disruption. Where I’ve seen big wins in large financials, the approach has been about pulling the organization into the new culture or the new capability, not the other way around.

So, I first faced this problem in 2010, in the Insurance Australia group. And this, at the time, was a very siloed, conservative, command and control, Taylorist, waterfall-style organization. And they’d flirted with Agile in IT a couple of times and been badly burnt. So I didn’t have the support of the CIO for the group that I was asked to transform. This was a group of about 330. And I kept having the same conversation over and over again.

I was brought in by two senior managers, Bernard Seeto and Dave Carpenter, and they pointed me at the progressives in the business. And they said, “Okay, we want you to find the fertile ground. Where are we going to prove this Agile thing is going to work?”

And the conversation I had with these progressives was always, “I would go Agile Rah Rah Rah”, they would say “Yeah, mate, that’s what we want. That’s beautiful. One problem, those guys over there, they’re not going to do it.” And I’d go “Okay, who do I talk to over there?” They’d say something like go talk to Tom. “Tom’s good, he’ll hear you out, I’ll set up the meeting.” So, I’d go talk to Tom, and Tom would say, “Yeah mate, beautiful, love those ideas, but those guys who sent you talk to me, they’re never going to change. If they don’t change, we can’t change.” So there’s a lot of that sort of blame stuff.

So I was forced to come up with an alternative approach to this and that meant I was forced to have a hard conversation with Dave and Bernard. I sat them down on a Monday morning after a long weekend, and I said “Look, I can’t do what you’re asking me to do. But I have an idea about what we could do.” I said, “What we’re going to do is, we’re going to cherry pick the change progressives, from business, design, delivery, DevOps. Maybe a dozen people, maybe 20 people. The people you’ve been pointing me at. Or their right hands. We’re going to cherry pick them and form a new capability, a new uncompromised Agile value stream. And we’re going to prove that it works with these guys. Because they’re change champions, they’re progressives, they will change really quickly, and they will change without compromise.

“And once we’ve proved that it works, and that it works reliably, and that it works fast, then we’ll be ready to grow it. What we’ll do is, we’ll take that initial uncompromised capability, we’ll split it right down the middle, and we’ll hold a little open space and we’ll demonstrate the benefits we’ve been able to achieve so far. We’ll develop appetite among some people in the organization to get involved. And we’ll simply let those guys join. When they join, they’ll be learning by immersion, rather than by instruction. And we’ll be able to deliver the change in controlled increments without disrupting any of the existing value streams which means we will reduce the risk you guys are carrying.”

It took four months before the CIO piled on and agreed that this was the way she wanted to go. After 11 months, we called these streams we called them, well to begin with we chose the most inoffensive name we could come up with, which was, we called it a small changes team. But in 11 months, we went from one of these steel-thread streams is what we wound up calling them, to 16. And that was most of the group of 330. And we did it with, well just yours truly as a change agent. So, I moved from there into this role as strategist for CBA. And there, we discovered that wasn’t enough. And we came up with this idea of a T-shaped transformation.

ADAM MATTIS: All right, you’ve got me on the hook. Can you tell us more about the T-shaped transformation. You left me hanging.

PETER MEREL: Well, so this is really good way to start up an uncompromised capability. And we did this in CBA in three divisions of the bank. In treasury and risk, we set up the [inaudible 00:23:28] regulation program, the program director is a gentleman named Chris Young who’s presently a steward for XSCALE Alliance in Switzerland. He’s also president of the Swiss Agile Association. So, Chris and I didn’t know each other at the time, we got on very well, that worked. But a funny thing happened on the way to the transformation. The funny thing was, I had been running trainings for people in wealth and particularly in digital channels. And in digital channels, we had a very experimental program called ka-ching. I trained those guys, and I said, “Well, do you want me to come and coach as well?”

“No, no, no, we’re ready to do this ourselves.” Good. Off they went. It was sort of XP/BDD/CICDD, that sort of thing. After about three months, I had a call from the General Manager, Rob Webb, very unhappy with what was going on. And when I sat down with him, he said, “Look, as far as I can see, the problem is that Agile does exactly what you said. It’s going to make everything go right at the start, it’s done that, and the business is so far offside, they’re bitterly unhappy. I’m going to have to stop doing this, unless you can come up with a way to give us predictability.”

So, this led to a set of patterns that we now describe as XSCALE product management. Breadth-first product management. But that wasn’t the real problem. I thought we were getting wins. I was very happy. We spent about three months getting that part of this rolling, using the pattern I just described. The productivity went through the roof, in Agile terms, but more to the point, in the program services group, which sort of controlled all of the programs in the bank. They went green across the board. And they stayed green across the board for the next year. They started winning external product [inaudible 00:25:41]. They became the showboat for Agile in the bank. That’s kind of got me on stage with the group CIO. But the fact that we had these three areas that were all getting these big wins created a reaction in the old guard in the bank. A lot of folk who didn’t really have an interest in seeing these programs, this approach succeed, began to organize to deal with the problem.

So, we had to change tack. I and an Australian coach, Dave Bales, very very solid coach in a Scrum tradition. We came up with an approach we called the four productivity practices. And this was basically the parts of Agile that a waterfall program can get immediate benefit from without realizing it’s doing anything Agile. And so this was, we had to put it into lean language so that the waterfall guys wouldn’t push back again. But it was standard operating procedures, which is to say definitions of done, visual management boards, which were of course Kanban, huddles, which were great big fat standups, but better than not doing any standups at all, and continuous improvement meetings, which were of course were retros, PDC, Deming cycle stuff.

So nothing that was going to push them too far out of their comfort zone. But the point of all of that was, we trained 1,800 staff thereabouts in this stuff. This is a 50,000 person bank, so this wasn’t the whole bank. But it was enough of the bank that when you walked in the morning, and you looked across this big open floor, you saw many people standing up. You couldn’t tell which ones were Agile, which ones weren’t. We reduced the distance between the uncompromised Agile capabilities, and the existing culture, so that it was much easier to move, and they all perceived themselves as enrolled in the change.

So, we knew that this was working when we had people coming up to our Agile coaches in the corridors, and sort of looking both ways and going “Are we doing Agile?” And after a while, that became our main vector for change in the bank. We would tell them, after they would describe what they were doing, we would say, “What are you doing?” They would say, “Ah, well, at our last continuous improvement meeting, someone said we should use user stories. Is that Agile?” And so we would say, “Well, maybe a bit, but don’t tell anyone, keep it to yourself.”

So, we though about it as a T-shaped transformation because we had these deep capabilities that we built, very hands on, very careful to grow them at the rate the organization was able to develop capability, rather than pushing. And we had this broad base of uplift that was basically injecting memes into the existing culture without trying to get it to change at all. And it then developed an appetite for it. That, plus a series of open space events, that was the biggest vector for change in a 50,000 person organization.

ADAM MATTIS: Real quick, can you tell us more about XSCALE Alliance, and where people can go to learn more about you and send the hundreds of questions that I’m sure you’re going to get.

PETER MEREL: What is XSCALE Alliance. “The Linux of the Agile world.” We’re an ecosystem of accomplished, independent coaches, each an expert in at least one of business agility, product management, and DevOps. We coach client capability uplift hands on, across the Americas, EU, UK, India, and Australasia. We have no trainers. You need actual hands-on, years of experience and scar tissue to be an effective coach. Our coaches use open content licenses to collaborate on development training collateral. And deliver it as an integrated part of coaching engagements.

We’ve got a bunch of events up coming. We have live, online training in a series in the American time zones. This is XSCALE business agility. In March, there’ll be three hour training blocks twice a week for three weeks. The idea is that this happens after hours so people don’t need to take time off work. And we don’t have to rush it. We also have classroom training tours coming up in Utah, Toronto, Washington D.C., New York, San Francisco, that’s all April and May. I’ll be co-training those with Jeff McKenna, [Masumahita 00:30:37], [Quinton 00:30:37] Brooks, Shingirai Kanhukamwe, bunch of other very experienced, very prominent Agile coaches.

Game Without Thrones, we’re running these in multiple capitals. This is a lego game for up to 150 people with no command and control. No managers, no masters, no owners. Collaborate using autonomy and alignment, instead. And we’ve been able to demonstrate this – gets a beautiful landing. We’ve done this dozens of times in the last couple of years.

And we have a ground breaking event happening in Sydney, in March. Code Without Thrones, where we’re taking that Game Without Thrones idea and extending it to a two-day hackathon format. We’ll be creating code with lego in that one.

You can find out about all of this stuff at our central site, http://xscalealliance.org and we look forward to getting you involved in any and all of this.

ADAM MATTIS: Very good conversation. So so many interesting advanced topics here, so I think a lot of us in our agility journeys … we get stuck in the basics. And I think what Peter has exposed us to here is a different way of thinking and to learn more about that, check out the XSCALE Alliance, which there’s a ton of great information out there. And let Peter know, via social media on Twitter, when we’ll link all of his accounts in the show notes, what you thought of this conversation. He brought up some very provocative topics, and I think for a lot of us, that have been in this space for a while, it’s some very good things to think about.

With that said, thank you for tuning in to another episode of Agile Amped. We really appreciate all of the listeners and feedback we get. The greatest compliment you could give us, if you enjoy our show, is to leave us a review, either in iTunes, or whatever platform that it is you’re listening to us on. Those reviews really do a lot to help us get our message to a broader audience. Thank you all for taking the time to listen, check us out on the Accenture Agile Amped website, linked in your show notes, as well as Peter. I’m Adam Mattis, thank you so much. Have a great day.