Join Murray Robinson and Shane Gibson as they talk with veteran developer, Jonathan Crossland about Ammerse, a value based decision making guide for products and teams. Ammerse is a mnemonic for agile, minimal, maintainable, environmental, reachable and solvable. Jonathan walks us through how to use these ideas to understand what we value now and what we should place more value on based on our context. It will be easier to understand this podcast if you look at the diagrams on the ammerse.org website, while we’re talking

Read along you will

Murray: In this episode, we talk to veteran developer, Jonathan Crosland about Ammerse, a value based decision making guide for products and teams. Ammerse is a memnomic for agile, minimal, maintainable, environmental, reachable and solvable. Jonathan walks us through how to use these ideas to understand what we value now and what we should place more value on based on our context. It will be easier to understand this podcast if you look at the diagrams on the Ammerse dot org website, while we’re talking. 

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

Murray: And I’m Murray robinson. 

Jonathan: And I am Jonathan Crossland.

Murray: Hi, Jonathan. Thanks for coming on today.

Jonathan: Hi guys. Thank you for having me.

Murray: So we want to talk to you about Ammerse, which is your decision making guide. Could you kick us off by telling us about who you are and what your background and experience is? 

Jonathan: Sure. I’ve been coding for about 30 years diving into all sorts of things. Manufacturing industry, financial, all sorts of things. Jumping in and outta teams, doing contracting. I’ve also started my own businesses software house running various teams growing and shrinking depending on the economy, building different stuff for different people, and that ranged from tax systems all the way down to e-learning course players, things like that. Personally I’m amateur musician, chess player, drummer, Bonsai artist. So I get my kicks from all sorts of things, but ultimately I’m a programmer and written a couple of books on programming.

Murray: What sort of books have you written? 

Jonathan: Oh, just reference guides, beginning VB. Net professional, VB. Net pro Windows dna, that sort of thing. All Rocks Wiley things. Lot of effort for no reward.

Murray: And you were telling me before that you’ve been working with blockchain. What have you been doing there? 

Jonathan: Yeah, so cryptocurrency is nonsense. However, there’s a nugget of truth. Deep down in blockchain this idea of something being immutable, is the core thing, the differentiator from a typical database. A developer can’t go into that node and make a change without consensus. And so we utilize that in commercial property. I’m consulting CTO for Singer VL. We’re in London, we’re now going worldwide. There’s a huge legal framework for selling property. Know your customer and anti money laundering, you know how it is. Regulations, regulations, different territories, different regulations. And it’s important for agents to have their audit trail. This is what I did, this is who I did it with. This is who approached me. This is how I prove their identity. And so on. We take that information we store in the blockchain and I can hold my hand up and say, I’m a developer. I didn’t touch the database, and everyone believes me because it’s in blockchain and nobody touched it. And so we have this verification processes where you click a little button, it goes off to the blockchain, looks at all the transactions, compares it with the database, compares it with their certificate file that contains all their audit trail information, compares it and says nobody’s tampered with any of these three things.

So therefore contracts exchanged is done within the blockchain in a secure, transparent manner. You can see it on the blockchain and it’s secure. And so we use it in that sense. So none of the crypto, none of the N F t, although, you have to use that lingo a little bit. We tokenize this property. It’s non fungible. We put it in the blockchain. So we’ve got an element of that, but we don’t promote the crypto side. We’re not promoting this heavy blockchain thing. What we are promoting is audit trails, regulatory stuff. Selling properties quickly. We’re just using blockchain. It’s a tool like anything and we try and use it where it’s needed.

Murray: Okay. Tell us about Ammerse. What is Ammerse? 

Jonathan: So ammerse is a memnomic. It means agile, minimal, maintainable, environmental, reachable, solvable, extensible. So when you first start a business the first thing you do is you solve a problem and you need to do it in an reachable budget, a time constraint, something. If you don’t reach the goal, then you don’t have a product, you don’t have a solution. So reachable and solvable are the most primary two basic values that you need in anything, in any endeavor. You want a new feature. What are we trying to solve? How do we reach it? Very simple. 

You’ll be amazed how many people forget those two simple values when discussing things in daily Scrum meetings, or feature or planning or whatever. What are we trying to solve? Let’s break it down. Oh, we don’t need to solve these other things. Those are edge cases. How does it align to our customer? What do they really want? Can we do it within this week or next month? How long is it gonna take? How much is it gonna cost me? This is reachable and solvable. So the values of reachable and solvable can cut right to the chase and ask the right questions. 

So I’ve got loads of interns that have come in, walked through my software house, and I teach them Ammerse first and the change that it makes in them. Reachable and solvable are the first two things I want you to consider beyond anything else. Oh, but I don’t know how to No, I don’t care. Oh, but I don’t know what if we need this? I don’t care. Reachable, solvable. Let’s take it one step at a time.

So the first reachable and solvable is obvious. It seems obvious. There’s much more to it, by the way, but it seems obvious. And that’s the beauty of Ammerse is that it’s straightforward. Once you hear it. 

Murray: So reachables the same as achievable? 

Jonathan: You can think of it as achievable. Yes. When you come with reachable, it’s a bit more abstract, so I can use it across different domains. So for example, if I want to reach a goal, or can I divide it into reachable sections? Do I have the capabilities to reach it? Do we have the resources to reach it? Do I have a budget to reach it? How can I reach X and then reach y? So there’s a lot of language around reachable that one can learn but basically it’s how you achieve things and can you achieve things? That’s the same way of thinking about it.

Murray: All right. What are the other parts of Ammerse? 

Jonathan: So level one is reachable and solvable. This is like red green, refactor. Red and green is reachable and solvable. What are you gonna do? You’re gonna write a test to solve a problem. You’re gonna try and reach it and you’ve done, then you refactor it. What happens on refactor? That’s level two. That is environmental, maintainable and minimal.

What are you gonna do now? You’re gonna try and minimize the code. You’re gonna make it more succinct. You’re gonna take off the clutter. Oh, I had that commented out section, and this other function could be over here, and I’m gonna shuffle this around. I’m gonna make it cleaner. Oh, I’m gonna rename these things cuz, make it more understandable. I’m gonna make it more maintainable by putting it in this other library over here for higher cohesion. 

In the same way these levels pertain to everything we do. And that’s why I know it’s an axiom. It forms basic truths. So level two is you’re concerned with the environmental things, sustainability, maintainability, minimizing things. And then you go up to the next level and that’s agile. Now you need to continuously improve what you’ve just done.

You can’t jump into Agile if you haven’t got something that’s maintainable. And so the levels make sense as well within Ammerse. After Agile though, is one higher thing. And this is where I feel the industry is just missing it. And that’s extensibility. 

The Slacks, the miro, things like that. What do they build? Plug-in ecosystems. Because that is where you need to get to for true agility, and that’s why extensibility is better than agility.

You have to go up these scales. You first start with solving a real problem, you reach your goal, then you add minimal maintainable, and environmental. And now you’ve got this basis that you can then extend with agile. And once you’ve achieved that, you go extensively. And so the value system is divided up into these levels and it helps you think about the right things at the right time.

Murray: Okay, so let me give an example and see if I understand what you’re saying. So I want to build a power tools company. All right. So first of all, is there a problem? Yes, there’s a problem with the way power tools are available to me at the moment. They’re too expensive. They break too much. They use too much power. They’re not portable. So I found a problem that I can solve. I get some people together and we come up with some prototypes. So the problem is solvable. We show customers they like it.

So I’m considering then reachable, which is can I build this? Can I take it to market? So I’ve gotta break up my solution into a series of achievable steps. First, build a prototype, then start selling it, then find people to build it for me and scale up and so on. So now I’ve got a product in the market.

It’s reachable and solvable, but the trouble is that I haven’t made it minimal maintainable and environmental yet cause I’ve just started doing it. So then the next step is, okay, how can I reduce the components in my product? How can I reduce the steps in my manufacturing cycle and my sales cycle because that will reduce cost and reduce maintenance. How can I define my process so everybody who works for me understands it and can do it repeatably. And environmental, that’s maybe the one I’m unsure of, but I guess means what’s the effect on the external environment. 

Jonathan: Also it could be, now that you’ve got a solution, can you roll it out to another environment, another country, different types of audience, different actors, right on the system. Plumbers versus woodworkers, things like that. There’s a lot of environmental things. Could be just sustainability of your product itself in its manufacture.

Murray: Okay, so then, my next question is, can I be agile? Which is, can I take what I have done and respond to changes in customer demand. Can I be responsive and flexible with my product? So I start doing that. I start changing it for different environments. Maybe Saudi Arabia needs something different from England and, so I make my system of developing my products more adaptable. That makes me agile. And then the last thing is extensible. So I have this product, can I extend it out into a range of products? Can I, for example, change the fittings? So I basically have a core engine and I can start to plug other things on the end of it. 

Jonathan: Yeah. 

What about plug and play batteries? It works across other brands, for example, 

Murray: Or I can turn it into a vacuum cleaner because I just add the vacuum cleaner attachment to my power battery and my control panel. 

Jonathan: Well, you, You’ve got it. Spot on. What you’ve done is you’ve taken a potential process for a start up and you’ve mapped it to the levels correctly, and you’ve asked the right questions. Are there more questions? Of course there. More nuances. Yes. More relationships between these values. Yes. But you’ve got it spot on. That’s the thinking. And if you think about it, this is how companies operate. This is how they move in a market. This is how they do it. And when you reached your pinnacle, you are thinking about collaborations and partnerships and extending into other brands and working together.

Just as a quick addition, is that if you take reachable, you’re thinking of reachable all the way through, so even though it’s levels you’ve really gotta consider all your values and how they relate to each other in a systems thinking sort of way.

So reachable when you’re turning something minimal, in level two, you’re still saying, can I reach this? Can I make it that minimal? Can I make it, even more minimal? And so reachable is something that plays a hand all the way through. Environmental. Can we reach this goal of going into Australia and then deploying into the uk and so on. What do we need to do to achieve it? Can we reach agility? How do we reach agility? Is do we have the budget for it? Do we have the mindset for it?

Murray: Okay. But when I’m starting off with my new product company, I shouldn’t worry about that. I should just focus on. Do I have a problem that’s worth solving? Can I solve it? What are the steps to reach some sort of solution or where I first make a sale. So I just wanna that for now and not worry about business agility or minimal business process for sales or anything comes later after I’ve got a product. 

Jonathan: So Ammerse is a weight system as well. Each of those seven values, put a little box under them and put a value between naught and one in there. And now you can reason about anything. What do I look like currently? As a business, what do we look like? What are we let’s evaluate our business. 

So if I said I value reachable over solvable, I would be a different company than if I valued solvable, over reachable. So for example, if I’m trying to work out nuclear fission and I have large budgets, obviously I wanna reach it, but it’s not as important as solving the problem.

All we need to do is get those experiments off the ground to prove this, prove that, prove this. Put all the pieces together to solve the problem. So reachable is not as important as solving the problem. 

In another situation. You’re a small startup. You’re starting your business by yourself with 10 credit cards. It’s gonna be reachable that’s more important. I only have a finite amount of funds before I have to go back and get a day job, I have to solve a problem within this reachable time. 

Can I modify that to that? No, I can’t. That’s a bit too hard. How long is it gonna take? Five months or I would’ve expected a week. Alright, so we are not that agile and you start reasoning about all things, you start questioning, you come up with these weighted values and you could mark this as our current state of affairs, a nice weighted set of seven values.

And then you can say what do we wanna become? We wanna become extensible. And you can do gap analysis and then you can determine what you need to focus on within your organization. Our stumbling block could be maintenance. We’ve got a lot of issues with maintainability. That becomes our focus.

And also any organization is gonna be a mixture of those weights. So even though we’ve painted a picture of there are levels, level 1, 2, 3, so on, and we move through it, that might be a typical scenario. But every organization is different and every organization has different contexts.

But with Ammerse, you can map it out and really reason about it.

Murray: Okay, so I might say then I’m gonna put a lower value on reachable and solvable because I have solved a problem worth solving. And now I want to try and make it a maintainable solution with a maintainable process. Cause my current way of doing things is not very maintainable. It’s all over the place. And it’s not worth me trying to become agile yet cause I haven’t currently got a maintainable way of actually delivering my product.

Jonathan: So in the IT industry we are concentrating on one thing and that’s agility. And so when I see, oh, we couldn’t convince this organization to really go agile. I was a consultant. I went in there for a year, minimal success, but I couldn’t really turn it around. Why? What are the reasons? It’s maybe they’re not ready. Maybe it’s a step-by-step process.

Murray: Yeah. I’m reflecting on a consulting engagement I had where it was quite difficult to implement Agile, and I would say that they had an important problem to solve. They had a solution for it , they’d achieved it. Was it minimal? No, it was overly complex. Was it maintainable? Sort of but, they really struggled with the complexity of what they were doing. What was the effect on the environment? Well, they were expanding into a lot of different environments. So their focus was expansion. were trying to do agile, but when I was helping them with Agile, I ended up spending a lot of time with them trying to reduce complexity, which would, come under minimal and make it a lot clearer with information sharing on what their architecture was and what their requirements would be, which I guess would fit more into solvable and maintainable. Those things were big barriers to being agile. 

Shane: I, think that’s the key though, Murray. So you’ve said there was a problem they needed to solve and they proved they could solve it.

Murray: Yes. 

Shane: They struggled with reachable because they were never on time and they were never on budget. So they weren’t at level one. Yet they started to breach into the other areas. They tried to get to level two or three. They tried to expand the environment by going to new markets. they, tried to make it. extensible by adding more shit to it they tried to adopt agile, even though they hadn’t nailed the first two values. And their core crux point was that value of minimal, because nothing was minimal. Everything was over specked and overdone and not delivered, so if you took the seven, you’re saying you haven’t achieved the first two, just solve the problem, don’t even try to go to those other things. You’re not ready to scale yet because you haven’t reached your goal, 

Murray: They had solved it, but when they were moving into new environments, new markets, new types of clients, that’s where they really struggled because they’d made everything overly complex. 

Shane: Yeah, so it wasn’t minimal and they never reached their target, ever. So therefore don’t go to the next level complexity. Don’t move up the maturity scale. Fix the problem. If they had to fix the problem of reachable, then potentially they would’ve solved the minimal problem, cuz that’s maybe how they would’ve solved it, and then they could look at the other values. So I can see how you can use it in that sense for what you just said.

Murray: Yeah, the thing is that you and I aren’t by the book management consultants. We actually have deep experience in software development and product development and organizational change. So when we come in and we see companies that are struggling with solvable and reachable, even though they’ve asked us to help them with Agile, we just go and help them with that, don’t we?

Shane: And so this just gives a good pattern, effectively to say, seven things to focus on. This is the one that’s broke, let’s go focus and fix that one. Once that’s fixed, we can talk about the others. No point talking about it yet cuz you’re just gonna spin, you’re not gonna get any value outta that work cuz you’ve got core problems you need to solve first.

If the team aren’t actually working together. Doesn’t matter what ceremonies we put in place and what points they guess at and what their velocity is. If they’re not working as a team, we’re screwed. So fix the, team, getting them working as a team and then the rest will come. I can see how these values gives us lenses. It gives us things we can point to and go, we think we are here. We think that’s where the problem is. How do we solve that problem? Solve that problem. We’ll figure out what the next problem after that is.

Murray: If I use this lens to reflect on agile consultants out there. A lot of them can’t do the lower level stuff. Let’s say you’ve got a HR manager who’s gone on an agile coaching course and has been put in charge of agile coaching for a team of a hundred people. This is a actual real world example. And that team is struggling with nobody understands the architecture and the code and they’ve got a whole lot of consultancy in who don’t understand it at all either, and that’s where their real problem is. Helping them to communicate and feel safe is not gonna solve problem that their architectures staffed and nobody understands 

Jonathan: Yeah. Quite right. There are many problems that can be solved with Ammerse. It’s a heuristic for thinking, and people don’t think enough. What happens often is you come in as a consultant and you placed somewhere within that vertical slice of an organization, and you’re told Look, downwards. Get the team sorted, get this project sorted, or this product and some of the problem happens to be above you, not only below you, but you’re coming in and you’re imposing your value system and your belief system, your worldview. If you are hired to be a batch manufacturing consultant or a process manufacturing consultant, or a scrum master or something, that is your focus because that’s your job title.

That’s what you’ve been hired to do. That might not be the correct role. An organization thinks that they need this person, I need this type of thing, and then they hire you. That might not be the case. Now, how do you say, I’m not the right fit? This is a paying gig, so often people go I’m gonna have to make this work.

How do I make it work? And you impose your value system. My value system is I want this to be agile. My role is agile coach, whatever it might be. And then you start. Is it the right thing? What’s the gap? Have you done a gap analysis? I think an organization who takes Ammerse and says in the boardroom, what are we trying to achieve? Where are we going? 

And they go we want to be extensible. We need to roll out into this territory. However, our software people are saying we are level one. You see a disconnect. That doesn’t mean that a team can’t say, look, we’re gonna use Ammerse just to help us think about software. It’s gonna help us make the right decisions. That’s it. But it’s better when the whole organization is aiming for a particular value,

Murray: So do you have a set of questions for each of these values to try and understand where you are with them? 

Jonathan: I’m trying my best to take organizational questions that are out there and applying it with the lens of Ammerse. I’m also busy on the other end where I’m categorizing the gang of four design patterns and other design patterns and slotting them into the value system for more practical guidance. If you want to build a plug-in ecosystem, what design patterns would you use? So I’m trying to map different terminologies onto Ammerse and it takes some time. It’s just a work in progress. 

Another example quickly, is the minimal viable product. What is a minimal viable product to Ammerse? Reachable? Solvable is that what MVP is reachable? Solvable? Is it reachable? Solvable with a little bit of minimal. Maybe. So now you can choose in your organization what M V P means to you. You’ll find better alignment if you know that an MVP is reachable solvable, minimal and maintainable, it’ll be a different solution to somebody building an mvp, which is just reachable and solvable. 

Murray: So, if this sounds interesting to you and you want to use it, where do you go? Is there some website or somewhere you can go and find out more about this?

Jonathan: So what I’m doing is this website.

Murray: Ammerse Dot org

Jonathan: Yeah I’m slowly putting things up. Every month I release another thing. I’ve written a paper where it all started talking about organizational values. And I’m going to launch a video really soon about what we’re talking about today on how you can build an Ammerse set to reason about anything. So if people are interested in this, they just follow the website. I’ve got a book in progress. I’ve written three chapters. I’ve got the other chapters fleshed out. Probably by the end of the year I’m going to release that book for a small marginal fee on Lean Pub or something like that. So I’m really not in it for the funds here, it’s just about getting the information out.

But it’s just me. But if anybody wants to join in and say, I like the sound of this, maybe I can think about, team topologies and how it might apply. I welcome that. Anyone can come in and send me the paper, get my review on it and see and we can put it out there and stuff like that. So I’m very open to collaboration.

Murray: Yeah. And it sounds like a lot of it’s still in your head as well. 

Jonathan: Yeah. It’s something that I could dedicate some time to, but then I would have to start charging and doing some monetary thing on it. And I’m not one of those guys to make money. It’s not one of my priorities. I’m bothered by thinking. So yeah I would invite anybody who wants to learn more, they can talk to me and I don’t mind sharing some time and chatting about it. And if I do anything, it’ll probably be finish the book and then offer some courses to people for a marginal fee. Just to get people going. 

Murray: But it sounds like what’s driving you is that you are very frustrated by vague, cloudy thinking. That people say things and they don’t do them, and it’s very hard to understand what their real values and those weights are.

Jonathan: Yeah. That is true. You’ve got that right. And I think from software point of view, when I’m building software, I see the minimal. I want a succinct design. I build that class to be reusable. I build that thing to be efficient. I want the smallest core thing. I want it to go across the departments, I don’t wanna be building the same authentication system in my department that some other department is doing. When we started in software 30 years ago everyone across the board was doing the same thing all the time. It took decades before a single sign-on existed. 

Murray: Yeah. We used to build sign on all the time.

Jonathan: Exactly. So to me, I think I’m driven by a few things. What are the axioms here? What are the core truths? What really are you talking about? 

So take fine grained versus course grained. There was a time in the software industry, we ask a developer fine grained or course grain, they’ll all go fine-Grained, fine grained. Is it really good? What do we need for fine-grained? We need machinery to lift sand. If it’s coarse grained, we need machinery to lift boulders. Two different things. Is there a benefit of having some boulders and some sand? Well, That’s how life works. So having this approach where we only pick one thing, we only say, these are the patterns we use, or this is the thing we do. I think it’s short-sighted. What is the fundamental. 

Writing software is actually easy. It’s simple. We make it difficult because we’re hiring inexperienced developers. We’re sitting on ever-changing platforms. Do you think something’s gonna go wrong? Yeah. I think we’re actually on a rollercoaster and there might be a cliff. Maybe the rollercoaster doesn’t come back again. I don’t know the state, but it just feels odd. 

Murray: There’s a real movement in the broader agile community now to say, get away from frameworks. Frameworks haven’t worked. They’re too far too restrictive. All we need is patents and patent libraries.

Jonathan: So Jim Copeland’s doing the patterns for scrum. He came up with daily standups and things like that. Okay, so what are your values? If you value a daily scrum. What’s your values? And, so if you don’t value all of those values in the same way, then you won’t value a daily scrum. But yet there are people going, oh, you don’t value a daily scrum. How can you be such an idiot?

Actually there’s a thing called asynchronous communication, and I think we get caught up in saying our values are better than those values. And then we get led by the nose, by people. And I think Ammerse is the class that sits underneath, that everything’s inheriting from. 

I think if you take a daily standup, if you express it as we value communication above anything else. Then what’s your culture gonna be? Meetings. So what does Scrum have in terms of values? It’s meeting, it’s not really thinking that people can do stuff by themselves. Although it says self-organizing, it’s really like you’ve gotta get together and you’ve always gotta discuss it. It’s very regimentry, it’s very process oriented. We’ve gotta get this all in. We’ve gotta be in sync, we’ve gotta be in lockstep. 

Murray: It’s all about teams. 

Jonathan: So, what are your values for that? If you’ve got a bunch of introverts go getters, Linus Torvalds, why do you need to do it in that way? Why can’t you follow their way? Look at what they’ve done for the world, so there must be something in between. The baseline for all of this, the axioms is Ammerse. I just think it’s about values. It might not be Ammersed per se, but it’s definitely values. I’ve just tried to aggregate it and abstract it a little bit more.

Murray: All right. We better go to summaries. Shane, do you wanna kick us off?

Shane: Yeah, so I like the fact that you’re building a shared language. I think that’s important. So you’ve got seven words and they have meaning and they have very clear meaning, and you’re obviously very passionate about what they are and they aren’t. I think that’s the start of any pattern language. Clear meaning. Words that mean something. 

I like the diagram you have on the website under the guide where you show the seven values and then you talk about the maturities at level one, level two, because that helps me visualize this idea. If I deal with solvable and reachable first then I’m at level one, I don’t need to worry about the others yet.

I like the use cases. When I read the bit around Red Ocean versus Blue Ocean and being able to score the values to those to say, what type of company would you be if you were going with a blue ocean or a red ocean strategy? I can see the value there. I can get it. 

So got some of it, didn’t get a lot of it. But as you said, you’re on a journey, this isn’t your day job . And there are bits in there that I got so it’s got some value. 

I, just think it’s gonna take a lot more refinement before the rest of us get it, but that’s okay. You’re not here to make money out of certification on this thing. I’m gonna pop back every now and again. Just have a look and see how you’re going. And the fact that, we could tell what Murray was talking about and go, yeah, this apply the seven values, where was that company air? That was useful to me. It was almost like a benchmarking thing. That’s what I got. Murray, what about you?

Murray: Yeah I thought it was very easy to apply the Ammerse values to hypothetical, product company that made drills. Just working through the levels. Is it reachable and solvable? Okay we have a problem. We can solve it in an achievable way. Now let’s start looking at, can we minimize complexity, make it more maintainable? Now think about the environment we’re in. Okay, that’s good. Now we’ve got that mostly working. Can we become more agile, responsive, and then can we become extensible? That’s all quite straightforward to think about. I’m looking at your diagrams and stuff on your website though, and there seems to be a lot more complexity to it than that, which I don’t understand at the moment.

But the basic idea seems good and straightforward. So yeah, I’m gonna keep it in mind and when I get a bit confused about what’s going on, I might just write down Ammerse and start thinking about how can that help me clarify the problem that I’m dealing with and the values that people around me have? I think that’s the way I’d like to use it. I think that’s kind of the way you use it too. 

Jonathan: Yeah. I’ll end with this. Ammerse is built using Ammerse. You look at the guide and the maturity level on how you read the guide follows the maturity level of Ammers. So level one is reachable and solvable, and you can use it as you’ve said now as a mnemonic. To start asking questions. You don’t need me to list out every question you need to ask. How could I do that? But if you really think about it a little bit more deeply about any problem you’re going through, you can achieve level one by yourself. You can think about the right questions for each of those values. And now you can have a checklist against all those values and you’ve just built it for yourself, and now it’s valuable to you. That’s level one. 

You’ll find level two is when you build a set and you start using it with weights, and eventually you can build your own process framework. Very quickly you have five sets that have different weights. You achieve level one, then you achieve level two, then three, then four, then five, then six. You’re deciding what they are. It’s just assign a one to each value by themselves, you would get seven sets. So the first set would be reachable, it would have a one in zeros, everything else and so on.

And now you’ve built your own development framework or your own management framework. You can define processes. And so the complexity that you’re seeing in some of those diagrams need more explanation from me and I’ll be doing that. 

So I’m going to build new use cases there. Blue ocean, red ocean. I’m going to add more and more guides on use cases. The iron triangle. What does it mean in Ammersed terms? Ammerse is a different way of thinking about the Iron triangle and so on.

So you can start off level one and you can use it straightaway. You don’t need me, you will need me for level three. That’s when you really need to understand more about the system. So that’s where I’m gonna concentrate on delivering my content and level one and two. I’m going to, you know that for anecdotes and small things that I put out.

Murray: yeah. Interesting. It’s different. That’s for sure. It’s intriguing. As we’ve been talking, we have been going through the Ammerse website. 

Which is just Ammerse a m e r s e.org. And there’s tons of stuff in there. There’s a guide, there’s use cases there’s definitions. So I think if people interested, they should have a look through that. That would be quite helpful. And then how else can people learn about this or stay in touch with what you’re doing? 

Jonathan: On the website you can subscribe to the mailing list. I have not sent a single mail out so you won’t get bombarded. Anyone who signs up there will get the draft book before it’s published for free and they can read that over and then decide if they want the polished version when I release it a few months later on Lean Pub.

Murray: All right. Very interesting. Thanks for coming

Jonathan: Sure. Thanks for having me. It’s been awesome. Yeah, thank you.

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.