#0070 - Al Shalloway - Pattern Libraries for knowledge work

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

In this episode we talk to EL Shalloway about AMPLIO and the movement backed pattern libraries in knowledge work. As Lean and Agile have become commercialized, they've become rigid bureaucratic frameworks that disempower teams and prevent us from improving. Pattern libraries set us free. When we learn patterns like the concept of bottlenecks, we're able to see things in our world that we couldn't see before.

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

And I'm Murray Robinson.

And I'm Al Shalloway.

Hey Al, thanks for coming back and talking to us again.

Thanks for having me.

We want to talk to you about amplio, which is the new framework you're working on. But for people who didn't hear the last podcast, maybe you could remind people what your background and experience is.

Sure. So I've been in software since like 1970 when I started college. I formed a company called Net Objectives from 99 to 2019. I was mostly at that time doing design pattern training cause I was very experienced in IT and I'd Learned patterns in 97. I sold my IP to the PMI in 2019 and I left about a year and a half ago in form success engineering. The last 20 years or so I've been mostly doing Lean theory, Constraints Flow. I was an SBCT for Safe sai, the first non SAI person to teach safe. So I'm very familiar with it. I know a lot about it. I also started Lean Kanban University with David Anderson. I was the Lean guy, he was the Kanban guy. So I'm very heavily technically oriented, but I haven't done much in the last 15 years or so. On the technical side, I'm mostly doing how businesses can get better at creating and delivering value to their stakeholders inside and outside the organization.

What is amplio then?

It consists right now of two different pattern languages. A pattern language at the team level and a pattern language at the scale level. So it's basically an approach to achieve business agility based on flow, lean and the theory of constraints. It's not a framework because framework means it's static, it's structured, it's limiting, it's like a cage. Now think of the words like agile, dynamic, sprightly, flexible. An agile framework is an oxymoronic statement. I wanted to come up with Something that really didn't have any limits as long as it was good.

What's the problem that you're trying to solve?

Great question. So I started doing XP in 99 Scrum in 2000. Around 2004, 2005 we ran into Agile at Scale, which in those days was three teams. We couldn't quite get them to work. But scrumos Scrum didn't really work. I had some really senior consultants at Net Objectives who really knew how to help large organizations and our success rate was very high. But outside of us and a few other people, it seemed it was hit or miss. In fact, it still is hit or miss. That was what was so tough. So around 2005, 2006, my purpose was is there a way we could see what you needed to do to be effective at scale? I'm saying agile at scale, not scaling agile. I don't believe in starting at the team and scaling it up. There are a lot of reasons that's not a good idea. But how do you do it across the organization? And there was one other thing that bothered me. So I was actually working on these two problems at the same time. The problem was how can we make companies more effective? How do you know what to do and how can you do it in a cost effective way across an organization where a company can control it, not have to pay what I consider to be exorbitant fees by bringing in outside people? So those are the two drivers for me?

Yeah, those are the drivers for you. But what's the drivers for the market or the customers or users? Is it cost?

Cost and effectiveness? Much lower cost in order magnitude of better effectiveness. But to train better, you've got to know what to train them in. So I see people using Safe over and over and over again and it doesn't work. Sometimes it does. Why does Safe sometimes work and sometimes don't? See people deny that SAFE works sometimes. Why Scrum works sometimes? Why? I wanted to know why and I wanted to know how to replicate it. So there are billions of dollars being spent, but we're not very effective. It fails most of the time. That was the problem. How do you make Agile improvements not fail so much? How do you make them work 80% of the time, 90% of the time at Net Objectives, we had about a 90% success rate in the work we did that was pretty good.

So I've had a fairly similar journey, but in the data analytics space. So I started a consulting company that did data analyst consulting, grew it to 10 to 20 consultants go and start early with the customer, get into where they're trying to define what the problem is, the strategy, figure out the roadmap of how we can help, then land the team in and help them build out some stuff and make money that way. And I had the same problem as you, and that would do a project and it would rock. The stars aligned, we delivered value, it was a great outcome for everybody. And then we'd have other ones where we delivered the outcome, but it wasn't fun, it just didn't gel. And then we had other ones which were just clusters. And there were key people that if they were working on it, somehow it seemed to work. So then I went on the journey of, okay, I need a methodology, I need a framework, I need some templates, I need the steps. And again, that never worked. When we started to get the people who were good at what they're doing to follow the framework, they, they failed. And then when we got everybody else to try and follow it, it never worked. And so that's when I started moving into the agile world and I got to the same concept of you, which is there's a set of patterns. Those patterns have value in a certain context. And the trick is being able to describe those patterns, figure out when to apply them, when not to, and how to daisy chain them. It's like Lego blocks. These ones in this context might actually work and have value. So I think I'm hearing you say the same kind of thing.

That's fair. I think it was around 2007, I realized I'd go into a company, I'd do a few days assessment, I'd work with them, we'd figure out what they should do. And what I noticed is every time I wrote the write up, I used 80% of what I'd written up before. There were some differences, but the target state was very similar. And the differences were due to how I get there rather than where I was going. 80% of the companies had about 80% of the same place to go. And if you had hardware or regulations, you just had to add those as extra requirements. Like I discovered early on, you better have an intake process. If you can't see your work, if you don't know where it's coming from or how it is, it ain't gonna work. So there were about two, three dozen things that you had to attend to. It's like an intake process. It's a solution to a recurring problem in a context and there are any number of ways of doing it, but it was always about finding the most value, the smallest thing that could be delivered quickly, attending to transaction costs. The reason the PMI had bought me was I'd built the system called Flex, which is the heart of the disciplined Agile Value Stream consultant that lays this out. But what I'm doing now with Amplio is just taking that to a next level. So, yes, very similar to what we're doing.

Christopher Alexander wrote the book around architectural patterns for houses. And we talked briefly before we started about what a great book that is in terms of giving us this patent for patterns. And one of the things that he talks about is the patterns of different sizes. You have patterns for a shape of a house, patterns for rooms, patterns for things in a room, patterns for furnishings. Have you come up with that same concept, that same pattern for patterns where there are small patterns, large patterns, patterns that go together, patterns that don't go together, and there's a natural flow for it or not?

Yes and no. So when I first read the book and he talked about a pattern language, he talks about, some things are in the context of the others, and in the physical world, these seem to be reasonably stable. There's a definite order to that. My next project blew that because I had a different ordering in this other project. And then I realized, oh, software is different in the physical world, size matters. In software, it's different. So a design pattern is a solution to a recurring problem in a context. But actually, there are three things Alexander talks about with patterns. And the big thing is if you have all these patterns, you can use them to decompose systems where everything then fits in the context of everything else. You can say, well, I got a city, and here's my city center. And then what's around the city center? And then how do I relate the two together? The key is this. Patterns give you a way of decomposing systems where you can not only see the parts, but you can see the relationships between the parts. And this is the key, is that Alexander's approach is you design from the whole and it gives you a method of decomposing. But you don't just deal with the pieces that doesn't work. You cannot decompose a system into small pieces because it's how they interact. Russ Akoff talks about this. You could take a car, take the best parts of the best cars, put them together, you got a pile of junk. So Alexander is not talking about decomposition into pieces. He's talking about the relationships between the pieces. So you can see how anything works in the bigger picture. So those are the three levels of patterns, how do I decompose, how do I keep the relationships? And then once I've got this local little thing, what are the different ways to implement it in a context? See now, patterns as solutions in a context. But as Alexander says, the patterns aren't important, the forces is important. Like in planning, what are the issues I'm dealing with, the people I have, the work I'm working on, the timeframe, how I'm gonna take it and give it to people. That's what a pattern does. It tells you what to look at in this context, how to solve it. And a pattern language is just a collection of this. If you think of patterns as words in a regular language, but these patterns state objectives, they have a name, so you know how to talk about it. They issue these forces and the beauty of it is they're flexible. You can add patterns to the language, you can take away patterns from the language. You don't need to have all the options, just one or two of them. Patterns are the future of Agile instead of frameworks, because they're flexible. And there are ways to make them just as easy to use as frameworks, as they take more time to build, but if you set it up right, doesn't take any more time to use.

So Ivar Jacobson has been doing a lot of work on pattern languages with essence. How does what you're talking about relate to essence?

It's totally consistent, but it's different. And I love what Ivar is doing. A lot of frameworks are working with him now. Scrum Safe on bond. It's brilliant. I came at it from how do I conceptualize the work I'm doing? He came at it. Let's conceptualize the work that needs to happen. In other words, he came at it abstractly, I came at it from actually doing it. And then seeing the abstractions in what I was doing. He lays essence on top of other people's work. Amplio is built with this in it, it's integrated in it, which is why I've never worked with Ivar on this. I admire it. But methods like Scrum, Safe, Kanban, they don't have it baked in. They're applying ESSENCE on top of their stuff, which is great. If you're using one of these, you should go and check out essence. All too often, frameworks have one way to do something, and now he's talking about the abstraction. And this gives you options. This means if you've used to doing planning one way and you have the essence of planning, you've got five different ways of doing planning now. You can plug play, you can make it like Lego box. Because he's created this language of patterns that fit together and he lets other people's stuff pull in. I might actually join because it would be an easy thing for me to do. I've already abstracted everything out. I just have to find what he calls it, lay it on top of my stuff. That might be a good idea. I've just been really busy. So it's one of those, yeah, when I get time, I'll do it, which may mean I never will, but it's good stuff. I like Ivar's work. He's a very smart guy.

So you're describing a language for describing patterns.

I wouldn't say I've got the language for describing patterns, but it is a language for solving the problem in knowledge work of how do you increase learning what the value you need to create is? Increase the ability to create the value and to talk to people about why you're doing what you're doing? This is something that's been forgotten in this industry. People are coming up with all these methods and they're ignoring, how do I convey that to people? If you're talking about product management, what are all the concepts or distinctions? What are the things you have to look at like size, value, cost, who has to be involved in it? All these little issues, the forces and the patterns, you have to know this stuff. Just as important is how to convey it, because you might have the answer, but if you can't explain it, doesn't mean anything. I've written a book called Amplio Development the Path to Effectively in Agile Teams. But it's got a companion book called Being a Professional Coach was how to explain these concepts and how do you convey that information.

All right, so what's the structure of Amplio? What's in it?

Okay, so Amplio starts with the summary, starts with some basic principles. It starts with guidance on how to use those principles. And then it's the pattern language, about 25 things or so in six categories with an affinity mapping of those six things. How do you track what you want to do? And then what are the capabilities or patterns for managing the workflow? What are the capabilities or patterns for attending to the quality of the product, the effective value creation, team structure? What about patterns for learning? Single double loop and triple loop learning, and then finally the roles. And then the companion guide is a way to convey these. And then there's also a different training mechanism. I believe in Incremental training, not like a two or half day training thing.

How many principles are there?

There are about six or seven that I use.

Let's spell them out for the audience.

There is a mindset like we're creating value, that we can understand what's going on. We can complete smaller things faster than larger ones. Local improvements don't necessarily result in global improvements. We can't manage what we don't see. Delays in workflow, in getting feedback and in taking advantage of lessons learned causes waste. We only see what we think and talk about. People working beyond capacity causes delays, creates additional work to be done. Handoffs cause a loss of knowledge and information. And people doing the work have more insights in how the work should be done than those managing them. Those are the basic principles I drive from now. From that I come up with 10 factors for effective value streams and I can read those out too if you want me to.

Yeah, let's concern them.

Okay. Are you getting value quickly? Is all work visible? Are you avoiding overloading teams? Are you getting actionable feedback? Do you understand the way you're working? Has it also been made explicit? Are you maintaining qualities that enhance flow? Are you avoiding waiting for others? Is there system management? Is there cost effective continuous improvement of the ecosystem, process and product? And are people motivated? They change a little bit as I learn and I refine them a little, yeah.

So we should learn and change and improve our methods.

Absolutely. I've been called a serial adopter and I've been made fun of and it's because I'm always learning, I'm always changing. It's why I went from xp, Scrum, Safe, my own stuff, Flex and now amplio. Amplio means improve in Latin. And what's so great about the name is it's about people improving and me helping people improving. But it's also about amplio improving so I never have to change it again because it'll just improve. It's not a set things, I'm improving it as I go. People don't apply agile to their own method. It's really remarkable in my mind that we're talking about being agile, but the proponents of most of the agile methods are not agile at all. And how they build their frameworks.

I'd agree with you. Right? The problem with the framework is that there's a bunch of lines and the cost of changing that line is expensive. Whereas if it's a bunch of patterns, we just iterate a small pattern or we add another pattern and you can choose to use that pattern or you can exclude it, it's not in a box. There is no line for you to have to move. It's just adding or iterating. And it's easy. The cost of change is small, very.

Key because the pattern language itself will not change nearly as fast as the individual pieces of, but because the individual pieces of it fit into the entire holistic view, you can change the pattern without changing the holistic view. And that's key because it's designed to be flexible, designed to change. It's about the way this thing relates to that thing, but the way you implement it can be different.

Yeah, I think a lot of people who are new into Agile have forgotten about this idea of patterns. When I first got into Agile I learned stuff from the C2 Wiki and that was just a whole bunch of people trying to develop the pattern library.

Yep.

And then out of that emerged Scrum and XP and things like that. And then they become solidified. People who are really experienced are developing new ways of doing things themselves. But it's not that common these days.

In the early days of Agile there were a lot of early adopters and innovators. How did XP work? How did Scrum work? And there was a lot of debate even back then about what it was. Scrum came out as an idea of, I've got this cross functional team and I just need a framework for them to figure stuff out. It's really good for that. But that's not where we are now. Now we have late adopters, even laggards, they're having to use this thing. What we need is something that will embrace everybody, that will embrace the innovators and the early adopters and the early majority and the late majority. Amplio is designed to create coaches who can help work with teams. Not to tell them what to do, but to guide them so they work better based on the way they want to work. One of the cool things about a pattern language is you might have a hundred things, but you can say, well, we're starting, we only need these 12. And you know what? We want to start a particular way to make it simple. So I can pick a few easy starting points out of the Amplio pattern language. I can take this subset and you got Scrum, take this subset, you got Kanban, take this something and you have some hybrid. And then you don't teach the team all the options, they don't care. You let them pick from menus and now you have something that's fit. But as you need more, you expand. So there's all these pieces, I think I've mentioned pretty much all of them. Now, there are first principles, there is a way to teach it across time zones. There's an organization of the practices. You've got incremental earning and you have to know how to start based on the team. These six things are pretty much ignored by current methods. And any one of them missing is like a big gap in a wheel.

Yeah, I agree. We get taught that everybody starts in the same place and that's not true. And so that idea of having patents is Lego blocks. We can understand the context of the team or the organization and we say, okay, based on that context, we think you start with these three things. What do you think? Here's what they are, have a read of them, understand what they are, and then say, do you agree or do you think they're somewhere else? And then the second thing is feedback loops. The teams or the organization can grab Lego blocks and make their own shapes. Or hey, we've iterated this pattern, we found a better implementation methodology for it or way of putting it in. We think this is important. And you can have that conversation of saying, is that an iteration on a current pattern or is it a new pattern? Because they're both okay, add another Lego block or slightly change it. It's all okay. You're just iterating the work and crowdsourcing it. And again, with the methodologies and frameworks we have today, it's hard to get that iteration back in from the crowd. There's no right for them to adapt it. It's not agile. So I'm with you on that one.

Yeah, you bring up an interesting point with feedback, because when people talk about experience, it's not time based, it's the feedback, the learning. It's not the time. You learn as much in two weeks as you do in four weeks, but you learn it faster. So two week sprints over four weeks, you'll learn twice as much. So we have to shift from experience in time to experience in the number of feedback loops.

Yeah, so the number of repetitions of using a pattern is important to a learn the pattern or figure of its fits. The second thing is the number of times you take that pattern into another area that is uncertain. That's when you start finding the boundaries of the pattern with different industries, different processes, different teams, different scenarios, that's where you get the edge patterns or you actually harden the patterns where they become more applicable in various contexts.

What we want to do is make sure it's simple to be used. If I have these core sets of patterns, and I don't have the basic edge conditions or all this other stuff. That's okay. But I know when I run into it, I can go look at the DA toolkit that's got zillions of things.

Or what's the structure of one of your patterns? What are the components of a pattern?

Well, okay, so I've got the name, the objective, the why it's important how to implement it with flow, end or time boxing and the anti pattern. That's the general structure of each pattern.

I love the fact that you've added the anti pattern because often it's the anti pattern that gives you clarity on the patent.

Yeah. So I don't have a preset solution. I say, here's the general goal. Here's the problems you're having. These are potential solutions. So I work with how do you see what you want to do? How do I see when you're not doing something, for example, intake process. An intake process is things coming in one place, and I can see where they are in a let an in pattern is. I don't know what work I've got done. Nobody's tracking it. Sometimes some companies find the challenge easier to see than what they should be doing. So as a consultant, by having both of these see, am I gonna ask them what their challenges are or am I gonna show them what they should be doing and they can tell me whether they're doing it or not? Patterns aren't important. It's the forces that are important. The patterns tell you what the forces are. So this issue of time, boxing or flow, I've identified the forces and then you have, okay, how do I make a decision? And if you're wrong, it's okay, because you're learning about how does this work? I mentioned complexity a few times. This is another thing Amplio does differently. I'll go from the worst to the best. And the worst is we're embedded into the outside world. No system is closed. You cannot predict Black Swan events by definition. You also can't predict really what a customer wants. That has to emerge as well. You really don't know how people are going to react to things. You could have a pretty good idea, and a lot of times you'll be right. But there's always the risk some group is going to get command and control or don't understand and monkey wrenches. Amplio is focused on how do I improve our workflow? If you have quick feedback and if you set things up so you can pivot Quickly, you can work with the other three things as well. If I can shift my organization quickly, I actually get stronger. This is the notion of anti fragility, that I'm not just robust. I don't withstand change, I get better with change because other people aren't getting as better with change as I am. I talk to the customer every day, do small incremental change, so I focus on what I have more control. On the Manifesto for Agile Software Development, they don't say, we did discover a better way. They said we are discovering better ways. It's in the present tense. So we have to continuously learn. This is also what Lean is about. A lot of people think Lean's about eliminating waste. No, no. When you really read stuff from the people who are doing Lean and when you look at the Toyota production system, it's about learning. The number one thing about Lean is learn. Taiichi Ono said this. He told his managers, if I come back in 30 days and you're doing the same thing, you are not doing your job, you're not improving. Agile and Lean are about improvement. The frameworks just go very slow.

Yeah, you talked a bit about training and coaching as being another element to this. And I also heard you say that if an organization has three trainers, they should be able to run this. But my experience is that there are a lot of people training agile things who don't have any hands on practical experience and it's just not good. They steer people the wrong way.

Yeah, so I agree with that. But there are two things here. The structure of full day training is the worst way to train. This has been known for hundreds of years. Universities give you an hour class here, three days a week or four days a week maybe because the body can only remember about an hour's worth and you've got to focus intently on things. So full day training's 80% is gone in a matter of days. But there's even worse than that because you're not training in your workplace. See, what you really want to do is learn in the workplace. You don't want to learn in a class and then forget most of it and then try to bring it back. So I do what I call incremental flipped classroom training. It's live, but there's also recordings. You learn a little bit, then you try a little bit, then you come back, you've got your feedback, you get instruction from me or from other students, you then learn a little bit more. And we break it down over a four month period of two or three hours a Week. The learning is in the workplace. It's not go to a two day class where you have no other recourse to get help. I'm not saying this was done intentionally, but if you look at the current certification stuff because you get two days and then you're on your own. Now you got to find somebody to coach or you do it on a user group, which is not so good. Now, I'm not talking about three people who don't have hands on experience training the amplio consultant educators, and I call them consultant educators because you don't go in and just train or you don't go in and just consult. You gotta know how to do both. What I'm doing right now is I'm training aces and their role is going to be to go into a company, lead this, and then they or I train an internal ace. But amplio as a set of patterns and as a set of options is a lot more robust than saying, here, do something every couple of weeks and then figure out what's wrong. We've got guidance, we've got templates. There's also these mural boards which enable you to dump and have challenges. Like what are the challenges we're having? What can we do about it? So this lack of support in the current agile space is really dreadful. It's raising the bar for individuals to know what to do. You need checklists, you need templates, not to tell you what to do, but to remind you what you should at least consider. So this is a big part of amplos, these checklists and we use mural for the virtual collaboration.

Edgar Shine said, we don't think and talk about what we see. We see what we are able to think and talk about. So by giving you a broad spectrum of things that we can talk about and think about, then we see them. Then when people are trying and struggling and they remember they've heard it talked about, then they could go, look. Have you seen that as well?

Yeah.

See, I think people know a lot more than people give them credit for. People know the laser. People know, but it's intuitive, it's in their subconscious. They haven't pulled it out.

I don't know how to conceptualize it. For example, a lot of people don't understand bottlenecks. So I find I'm explaining bottlenecks to people and then the people who get it are suddenly seeing bottlenecks everywhere and then they can start doing something about.

That's what I'm saying. That happens. Oh yeah, Murray said bottleneck. I see. I've got one, but I don't know what to do. Now you've got one. You could go look for how to do better. Another point, you do not want to limit the amount of stuff in a framework. What you want to limit is the rate at which people have to learn it. So if I can learn a little bit and get little bits more when I know, that's awesome. Look at Wikipedia. If they had twice as many entries on Wikipedia, it wouldn't be any more complicated. If they made the entry twice as long, it wouldn't be any more complicated. Why? Because I go into something when I'm interested and I read the synopsis at the front and I read more later. I'm suggesting a pattern language. I've got this basic foundation, then six affinity maps, then you go and look at the patterns and then you drill down. So like at the team level, There might be 25 things or so, but I only start with about 10 or 15 and then I go deeper as I need to.

So one of the challenges with this patent library is it's actually hard to see the picture because there's so many moving parts, there's so many Lego blocks. Big pile on the desk, on the floor and you're going, I can't handle that complexity. How do I find and visualize those relationships? How do I find the chunks that are useful to me right now without Googling and getting back 600 pages? How are you dealing with that in NPLO?

Yeah, that's a problem if you just have everything flat. Scrumplop has lots of great patterns, but they're all over the place. And this was something with dad we never got to. If you look at the development value stream in Amplio, there are maybe 30 things to attend to. That's not too many. So you look at those and you identify which ones am I having troubles with? Is it the intake process? Is it whether I'm doing flow time boxing? Is it planning? Is it the way I'm structuring my teams? In other words, there is an order, more or less, with which you make your improvement. Some things open up the doors for others. I remember years ago reading somebody talking about take the low hanging fruit and the answer is no. Because taking low hanging fruit may make it harder to do the next things. Like starting with teams is not always the right idea. So you want to look at the whole pick. What's the more important ones? Ample lays this out. These are typically more important than you do these. Are you ready to do them? Do you have a sponsor to do them, do the teams have the skills to do them? So it gives you again a template of things to check and then use your judgment. So then you drill down. So it's like every node goes out to some more nodes, which goes out to some more nodes. If you have 10 nodes and each node goes to 10 more things and you only have to go three levels down and you got thousand things. Navigating a network of ideas is a lot easier than navigating this pile of things on the floor. And this is where a pattern language works. You have a meta pattern for planning, and then these are 10 different ways to do it. So you can go out to the Scrum Blob, you can go out to the DA browser, you can go to me. I don't actually have that many solutions in my set. Why I don't need them. Go to Scrum, go to Kanban, go to da, go to Less or go to Essence and they'll tell you where it is. But AMPLIO is this thing that structures. Mostly I grab stuff from other places, but I've created about a half a dozen things that I think are pretty cool.

Have you got a process for community involvement and improvement of these patterns or are you doing it all yourself?

So in the ASUS program, which just started last month, I've got about 15 people in there right now. And it's an ongoing learning journey. So people can start anytime. Everything's been recorded and it's like a year program. It's like you sign up and then you're in it for a year. I do about three sessions a month and some people are helping me and contributing. But I do have other places. With the AMPLEO community of practice and thinkific, we have a program where you can learn for free. Cause I'm trying to create awareness. So I'm in the process of setting that up. I'm also in the process of trying to identify people who are doing coherent things, you know, like Steve Tendon, Wolfram Mueller. There are quite a few people who are taking their own approach, which I think is good because my approach is really designed for people who want to create a structure, have ability to cross train and do things. It's more structured in that way. So yeah, I'm in the process of creating that. I want to get more collaborative with other people. I don't believe in one person at the center. One thing that's awesome about working with people in the Employee Development Masterclass and the AMPLO Consultant Educators Journey is I'm always asking for people to tell me what am I doing wrong, what am I missing? So I get a lot of help that way in building things. I've got a long way to go. People berate SAFE a lot and there's good in there and there's bad and safe. I'm not a big safe fan now, but I can fix it. But I would not start somebody and say but there's something they've forgotten. There are things that drive adoptions, and one thing that drives adoptions is a lot of the internal training and HR organizations think they need consistency. Now, SAFE actually does give you consistency, but it's a straightjacket. It's not really a good thing. But the bigger thing is if you want to educate thousands of people today, you have three choices, maybe four. One choice is you can get a consultant in and pay for expensive SCRUM training or something. It's exorbitant when you talk about thousands and thousands of people. You can't hire a CST because they're making money. You can grow it yourself. High risk because chances are you don't have the people. You can bring a consultant who's not a certified person but has their own method or you can go to safe. SAFE enables you to train at the team level. Send somebody to a SAFE class, and for 50 bucks a person, you train them in their version of scrum, which isn't that bad. I'm trying to give another alternative. I'm saying let us train your people in your workspace so they know what to do and then you can train it. I have some small license fees, but not higher than saves. The HR training companies, they want consistency. The pattern language gives you consistency objectives, but now people can implement it in their own way. So you're giving them the control they really need and you're allowing for the flexibility that the teams. Now, I'm not claiming I've got this all nailed, but I'm headed there and every month I get closer to it and that's how I'm trying to get people involved.

We better go to summary. Shane, do you want to go?

Yeah. Look, this has been awesome. This is really topical given I'm trying to write a book right now on patterns and agile data and analytics. I've always struggled with what a patent is and how to articulate it, how to train it when I'm not talking or waving my hands. So often pieces of work are successful and sometimes they're not. And trying to codify why did that one be a success and why did that one not often Came down to the people doing the work. And I've seen experienced people fail in one context and succeed in the next context. And they're the same people. It's basically a bunch of patterns that they're applying given the context, and when those fit, they are successful. So how do we share that experience and knowledge with everybody else? That's where patterns come in. I liked the way you talked about software is different to the physical world. We often try and take things from the physical world and apply them to the software world or the data world. They don't fit. We need to adapt. When we start off with teams or an organization, we should listen and watch and see where they're at, get their context before we start ripping in with, giving them suggestions on how they can improve. But I hadn't thought about using patterns to decompose where they currently are. What patterns are they implementing? Oh, they're flow centric, they're iteration centric. They're struggling with this one, but they've got this pattern nailed and oh, bloody hell, they've done it in a better way I've ever seen it before. I'm going to iterate my pattern based on that. And so you bring it down to you need to see the parts, you need to see the relationships, and then you can understand the system. Murray, what do you got?

Yeah, I think the most important thing is that when you understand a pattern, then you can see things that you couldn't see before. I think that's true. That's certainly been my experience when I was learning Lean and reading Eli Goldratt's book about theory of constraints. Once you've got a pattern in your head, you can understand what's going on. Now, as I'm coaching teams, my approach is generally to ask them what their problem is, ask them what their solution is, and then offer them some other patterns that they may not have thought about and explain them to them. We can start doing some trials and just see what works. I love the idea of pattern libraries. It's a very promising movement in the agile community. There's a few people doing it. I think disciplined agile delivery is a pattern library. There's a lot of groups of things to think about and then a number of options to tackle each one. And Ivar Jacobson's doing a lot of stuff on patterns. You're doing patterns. The Scrumplop has been around for a long time and it really feels like going back to the early days of agile where it was all about patterns, which is great. We've gone through this long period of commercialization over the last 15 years, particularly with SAFE, where it wasn't about having different patterns available to you, it was about the way to do it. The thing I dislike most about SAFE is it feels very bureaucratic. There's hour by hour descriptions of workshops. So it's like a super detailed set of business processes because that's what companies like, that's what bureaucracies are. But I think having options. Here's a topic like intake that you need to consider and here's some patterns for dealing with intake that's far better. So that's what I got out of it. Also quite like your approach to training, of having experiential training that happens over a period of time with templates and Miro boards. So lots of good stuff for me to look into. So I'll go and read some more about it now.

Great.

Anything else you want to add, Al? Anything important that we haven't talked about?

Yeah, I actually have something I can be pretty quick on. In the coaching book, I talk about what is the characteristic of a good coach. And I think the first thing is you see a future. You know where you are, you look for a path. Where do you want to go? Start where you are, take steps forward, and then you have to take responsibility for it. How can I convey the concept to them so they'll see it? The last thing is humility. Like I said, I love ampli. This is a labor of love. But I'm not saying it's the only way to go. In fact, I'm saying just the opposite. I integrate others. So yeah, I'm confident in myself, but I also have humility. It's not perfect, but I can work with the other people I'm working with to take advantage of what they know. See, I don't believe people should be following. In general, leaders in an organization are not followers of somebody else's framework.

Yeah, okay, that's great. All right. Now, how can people learn more about amplio?

The best way is go to successengineering.org and look under resources. You can get the different books online. You can look for events, upcoming events, go for presentations, see past one, and then all the different workshops you'll see. And I have I guess, four right now that are going on. One is a free one. Hey, you want to just join? Get some free mural boards. Have a webinar once a month that meets every other Thursday morning, 7am Pacific. And we alternate a mural board or a webinar. And it's Free. That's the Amplio Community Practice. There's the Amplified Development Masterclass, which is starting in February. The next 1/3 offering if you're already advanced. Even though I like to take people in who've already done the Amplified Masterclass or the Discipline Agile Value Stream Consultant. But if you're an advanced coach, I waive the prerequisite. Although you will. If you want to train in the things I've got, you'll have to take it eventually. There's the AMPLA Consultant Educators program, which is a lot of cutting edge stuff, things I've accumulated literally over 35 years. It's about human education, learning how people resist their address change. And basically every week, three weeks out of a month, we talk about that. So those are the best ways to learn. The books, the events, or the workshops. And if you want a personal conversation, just shoot me an email. Al shallowayuccessengineering.org okay, that's great.

Yeah. You're commenting on LinkedIn all the time.

Yeah, I'm just helping people do stuff better. I give away a lot of stuff. Yeah, I, I really don't hold anything back. I give it all away because I really think that we're operating as a community in development at about 5 to 10% of capacity. It's not gotten a lot better. It's gotten a little better. But the companies that actually are making great headways are not using Agile as can methods. Amplio is really about how can you learn what to do based on where you are, but not force you to reinvent the wheel. And I don't think you have to reinvent the wheel. I worked on this for years. Like I said, it's been 15 years and it's been a labor of love, but it's been very difficult. And I actually believe this can guide those who want to create good methods. That's why Impulse is a pattern language. It's not a framework. There's no limit to it. It just tells you what to look at. And if you have a problem that it's not talking about, you can put it into the system. So it's an open system, it's not a closed system.

All right, that's great. Hey, we appreciate your time. Thanks for coming on.

This has been so much fun. I haven't had a chance to talk about it this way, so I just so enjoy talking to you too. So thank you for having me.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like, help to build great teams that create high value digital products and services. Contact Murray at Evolve Co. That's Evolve with a zero. Thanks for listening.