Pattern Libraries for knowledge work with Al Shalloway

Join hosts Murray Robinson and Shane Gibson in a conversation with Al Shalloway, the founder of Amplio, as they discuss the re-emergence of pattern libraries in the realm of knowledge work.

In this episode:

• Al illustrates how the commercialisation of lean and agile methodologies has led to their transformation into rigid, bureaucratic frameworks that disempower teams and hinder improvement.

• We delve into the concept of pattern libraries and how they can liberate us from this rigidity, fostering a new way of thinking and working.

• Al introduces the concept of bottlenecks as a pattern, explaining how recognizing and understanding this pattern can shed new light on our work processes and enable us to identify areas for improvement.

Join us in this engaging discussion as we explore a fresh perspective on improving knowledge work through the application of pattern libraries!

Read along you will

Murray: In this episode, we talked to Al Shalloway about Amplio and the movement back to 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 are able to see things in our world that we couldn’t see before. 

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson.

Al: And I’m Al Shalloway.

Murray: Hey, Al, Thanks for coming back and talking to us again.

Al: Thanks for having me.

Murray: We wanna talk to you about Ampl, which is the new framework you are working on. But for people who didn’t hear the last Podcast maybe you could remind people what your background and experience is.

Al: 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 cuz 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 and formed Success Engineering. The last 20 years or so, I’ve been mostly doing lean, theory constraints, flow. I was an SPCT 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. 

Murray: What is Amplio then? 

Al: 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, spritely, flexible. An agile framework is an oxymoronic statement. And I wanted to come up with something that really didn’t have any limits as long as it was good.

Murray: What’s the problem that you’re trying to solve? 

Al: 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 ’em to work. Scrum of Scrums 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.

Murray: Yeah, those are the drivers for you, but what’s the drivers for the market or the customers or users? Is it cost?

Al: Cost and effectiveness. Much lower cost, in order of magnitude of better effectiveness. But to train better, you’ve gotta know what to train ’em 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 work? Sometimes Why? Scrum work 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 ’em 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. 

Shane: So I’ve had a, fairly similar journey, but in the data and analytics space. So I started a consulting company that did data analytics 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 in that we’d 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 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’ve 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 of this context might actually work and have value. So I think I’m hearing you say the same kind of thing.

Al: 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. 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 built a system called Flex, which is the heart of the discipline, 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.

Shane: Christopher Alexander wrote the book around architectural patterns for houses and we’ve talked briefly before we started about what a great book that is in terms of giving us this pattern for patterns.

And one of the things that he talks about is the patterns are 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 patents, large patterns, patents that go together, patterns that don’t go together and there’s a natural flow for it or not. 

Al: 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 and 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 ’em together, you gotta 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 are 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. 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 cuz they’re flexible. And there are ways to make them just as easy to use this frameworks as they take more time to build. But if you set it up right, doesn’t take any more time to use.

Murray: So Iva Jacobson has been doing a lot of work on patent languages with Essence . How does what you are talking about relate to essence? 

Al: 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, kanban. 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 Iva 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 and play. You can make it like Lego blocks because he’s created this language of patterns that fit together. And he lets other people’s stuff pull in. I might actually join, cuz 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 on top of my stuff and 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.

Shane: So you’re describing a language for for describing patents.

Al: I won’t say I’ve got a 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. Cuz 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 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?

Murray: All right, so what’s the structure of Amplio what’s in it? 

Al: Okay. So amplio starts with a 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 six categories with an affinity mapping of those six things.

How do you track what you wanna 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. 

Murray: How many principles are there? 

Al: They’re about six or seven that I use. 

Murray: Let’s spell them out for the audience. 

Al: 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.

Murray: Yeah, let’s go through them. 

Al: 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 ’em. a little

Murray: Yeah. we should learn and change and improve our methods. 

Al: 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 xb Scrum Safe. My own stuff. Flex and now Ampl. 

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 in how they build their frameworks. 

Shane: 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 patent and you can choose to use that patent or you can exclude it. It’s not in a box. There is no line for you to have to move. Just adding or iterating, and it’s easy. The cost of change is small.

Al: Yeah, that’s very key because the pattern language itself will not change nearly as fast as the individual pieces of it. But because the individual pieces of it fit into the entire holistic view, you can change a 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.

Murray: 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 a patent library. And then out of that emerged scrum and XP and things like that. And then they’ve become solidified. People who are really experienced are developing new ways of doing things themselves, but it’s not that common these days.

Al: 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. And 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 ’em 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 could say, well when were starting, we only need these 12. And you know what? We wanna 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 ’em 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 learning. 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.

Shane: 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 as 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 a way of putting it in, or 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. 

Al: 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 and time to experience in the number of feedback loops. 

Shane: Yeah, so the number of repetitions of using a patent is important, to A learn the patent or figure if it fits. The second thing is the number of times you take that patent into another area that is uncertain. That’s when you start finding the boundaries of the patterns 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. 

Al: What we wanna 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 there. 

Murray: What’s the structure of one of your patterns? What are the components of a pattern? 

Al: Oh, okay. So I’ve got the name, the objective, the why it’s important. How to implement it with flow and or timeboxing and the anti pattern. That’s the general structure of each pattern. 

Shane: I love the fact that you’ve added the anto-pattern cuz it’s the anti-pain that gives you clarity on the pattern. 

Al: 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 wanna do? How do I see when you’re not doing something? 

For example, intake process. An intake processes, things come in one place and I can see where they are at. An anti-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. Let’s see. Am I gonna ask ’em 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’ve 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. And you really don’t know how people are gonna 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 gonna get command and control or don’t understand and monkey wrench it. 

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. 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. Talk to the customer every day. Do, small, incremental change. So I focus on what I have more control on. 

In 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. Tachi 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.

Murray: Yeah. You talked a bit about training and coaching as being another element to this. 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. 

Al: 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 gotta focus intently on things. So full day training’s, 80 percent’s 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 wanna do is learn in the workplace. You don’t wanna learn in a class and then forget most of it and then try to bring it back.

So I do what I call incremental flip 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 is you get two days and then you’re on your own. Now you gotta 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. I’m training the Amplio consultant educators. And I call ’em consulting 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 is 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 Miro 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 Amplio these checklists and we use Miro 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?

Murray: Yeah. 

Al: See, I think people know a lot more than people give them credit for. People know delays are bad. People know but it’s intuitive. It’s in their subconscious. They haven’t pulled it out.

Murray: They 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 it themselves. 

Al: That’s what I’m saying. That happens. Oh yeah, Murray said bottlenecks. 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 wanna limit the amount of stuff in a framework. What you wanna 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 in, 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.

Shane: So one of the challenges with this patent library is, it’s actually hard to see the picture. Cuz there’s so many moving parts, there’s so many Lego blocks, it’s a big pile on the desk or on the floor, and you’re going, ah, 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 ampliio.

Al: Yeah. That’s a problem. if you just have everything flat. Scrum plop 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, timeboxing, 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 wanna look at the whole pick what’s the more important ones. Amplio lays us 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, then you only have to go three levels down and you got a 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 plop, 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 em. 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 Ampio 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.

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

Al: So in the ACEs 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 in contributing. But I do have other places with the Amplio community of practice, in Thinkiffic. We have a program where you can learn for free cuz 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 wanna 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 centre. One thing that’s awesome about working with people in the Amplio Development Masterclass and the Amplio 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 in safe. I’m not a big safe fan now, but I can fix it, but I would not start somebody in safe. 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 in HR organizations think they need consistency. Now SAFe actually does give you consistency, but it’s a straight jacket. It’s not really good thing. But the bigger thing is if you wanna 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 C S D because they’re making money, you can grow it yourself. High risk, cuz 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 ’em 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 SAFEs. 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 do. 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.

Murray: We better go to summaries. Shane, do you wanna go?

Shane: Yeah, look, this has been awesome. This is really topical given I’m trying to write a book right now on patents 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 and 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. I’ve seen experience people fail in one context and succeed in the next context. And they’re the same people. It’s basically a bunch of patents 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 and they don’t fit. We need to adapt them. 

When we start off with teams or an organization we should listen and watch and then 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. And gonna iterate my pattern based on that. 

And so you break 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?

Murray: 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. It’s certainly been my experience when I was learning lean and reading in Eli Goldrat’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 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 patent 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 are doing patterns. The Scrum plop 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.

Al: Great. 

Murray: Anything else you wanna add, Al? Anything important that we haven’t talked about? 

Al: Yeah. I actually have something I can be pretty quick on. In the coaching book I talk about what is the characteristics 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 foreward. And then you have to take responsibility for it. How can I convey the concept to them so they’ll see it? 

And the last thing is humility. Like I said, I love Amplio. 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 that 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. 

Murray: Yeah. Okay. That’s great. All right. Now how can people learn more about Amplio? 

Al: The best way is go to Success engineering.works and look under resources. You can get the different books online. You can look for events, upcoming events, go for presentations, see pass 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 wanna just join, get some free mural boards. Have a webinar once a month that meets every other Thursday morning, 7:00 AM Pacific. And we alternate a mural board or a webinar and it’s free. That’s the Amplio community of practice. 

There’s the Amplio Development Masterclass, which is starting in February. The next one third offering. If you’re already advanced, even though I like to take people in who’ve already done the Ample Development Masterclass or the discipline Agile value Stream consultant. But if you’re in advanced coach. I waived 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 Amplio 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 or 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 dot shallow way, success engineering.works. 

Murray: Okay. That’s great. Yeah. You are commenting on LinkedIn all the time. 

Al: Yeah. I’m just helping people do stuff better. I give away a lot of stuff. 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 five 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 Agiles canned methods. 

Ample 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 Amplio as 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.

Murray: All right. That’s great. Hey, we appreciate your time. Thanks for coming on

Al: This has been so much fun. I, 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.

Murray: That was a 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 evolve.co. That’s evolve. With a zero. Thanks for listening.