Join Murray Robinson and Shane Gibson in a no-nonsense agile discussion. In this podcast, we talk about evolutionary design and the problem with a narrow focus, planning at different time horizons, big blocks and small blocks and the importance of having flexible roadmaps that change as we learn. We also talk about centralised teams vs experts in teams, how the role of the coach is to build the team’s capability and how a coach should be a sports coach, not a therapist.

Read along you will

Murray: In this episode, Shane and I talk about evolutionary design and agile architecture. How doing all of the design upfront leads to a huge amount of waste while focusing on the next two weeks leads to very fragmented design . We talk about how the team need to understand the big picture of where they’re heading before diving into detailed design.

We discuss the problem with centralized design and architecture teams and the benefits of distributing those skills to support the teams throughout the product development life cycle. We discussed the role of the expert and that the key focus should be both building the capability of the team and getting results. 

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

Murray: And I’m Murray Robinson.

Shane: Hey, Murray. Good to see you again. We’ve decided today we are gonna talk about evolutionary or evolving design and which I call agile architecture.

Murray: Yeah. Let’s talk about evolutionary design. 

Shane: Why don’t you start off from your domain And then I’ll jump in from, my data and analytics architecture view.

Murray: Sure. So, I first got into agile in 2004 through XP. And in XP explained Kent Beck talks about the rule of three and you ain’t going to need it. Which is the idea that you just code a solution for the immediate small feature that you’re working on and you don’t worry about reuse. You just focus on now because there’s an enormous amount of waste in designing things for a future that may never happen. 

Later on, you might find that you’re making changes to that code module to add new rules or functionality. And then if you find you’re doing it again, a third time. Then, you know it’s worth restructuring to make it modular and more abstract from an architecture point of view. So the idea is to avoid any big architectural design decisions on the basis that its probably not needed. Or you don’t really know what it is and so you’ll probably get it wrong.

Scrum has a similar short term focus since scrum and XP both came from the same place. So there’s this idea in SCRUM that you just focus on the current iteration, usually the next two weeks. We groom the backlog. And maybe there’s a bit of a discussion about how you might solve something in order to estimate it. But you generally try to avoid design conversations when you’re grooming the product backlog. 

So I’ve seen a lot of really fragmented user experience design, which comes out of this constant very short term focus. Because it makes you take a microscopic focus around buttons and small code modules. And UX designers and UI designers complain about it a lot because they work at the level of user experience, user flows, user journeys and pages, not buttons. They’ll argue that you can’t design buttons are part of a form for a page unless you know what the whole page is, and you can’t design the page unless you know what the user journey and the user flow is. And I think they’re right. I’ve seen bad design cover in this total focus on the micro decisions. 

But on the other hand, I’ve run waterfall projects in which there was three months of requirements, three months of architecture. Months of design and months of technical design before you ever build anything. And a lot of that stuff ends up being wrong and wasted and has to be fixed or redone later. 

So you always miss a lot of things and you only find them out during development. Because there’s always quite a lot of uncertainty about the requirements and the solution in software development and product development. So I think there’s a place for evolutionary design, but it needs, is it somewhere in the middle? 

I’ve got to have a big picture, a medium term and a short term. You don’t want the big picture to be detailed. You just want it to block out what you’re going to. Do so you know what context you’re working in when you’re making micro decisions during a sprint? What’s your view on it? 

Shane: I started off on that same journey as you different book. But the idea that we could build the airplane while we’re flying. We didn’t go in and do any architecture design at the beginning. We were starting from nowhere and trying to design the architecture at the same time as implement it and build it. In the data world, that seemed to cause us a major problem. In the AppDev world there are a bunch of patterns. There are a bunch of architectures or design that, work together. Whereas in the data and analytics world, we are still not at that level of maturity. We’ve got 101 different choices, all giving us massive consequences. So I recommend what I call agile techture which is the idea of, using time horizons. So at the beginning, we should take a piece of paper and we should draw some big rocks. And they should be the big influential decisions that will have a massive impact if we change our mind. They don’t have a lot of detail in them yet. And then as we’re building things out, if we’re starting to make a change that looks like one of those rocks is going to change, then we, should be aware that there’s probably a whole lot of change impact in some other spaces. And therefore the cost and time of making that change will be bigger than we expected. 

I find that drawing that picture, doing that wireframe architecture helps the entire team understand what the future state might be. The picture seems to get the message across We are building out this app at the moment and we had to decide what we’re gonna build the front end in, and what we were gonna build the backend in. And we actually changed it quite a bit. I phoned a whole lot of friends and, worked out that I could go down the React or Flutter path. And then that design decision impacts the people we hire. If we went react, we have to hire specialists. And then we actually started off experimenting with Flutter. As we experimented with it, we worked out, it wasn’t quite a level of maturity we needed to do what we want. It was a little bit too early in it’s lifecycle to be safe for us. So we then ended up moving on a front end technology called Svelt which again was early in its lifecycle but was a little bit more mature. And that’s what we’ve gone with. Now, that’s a big rock, if I decide to go from Svelt to React, there’s a massive amount of cost and change that I’ve gotta incur cuz I have to potentially retrain my whole front end team or find another one. I have to rebuild ALL my components or port them. So if we do decide to change it, then the cost and consequences of that change are quite large. So it has to be a really well thought out decision. Whereas if we decided to bring in one of the CSS kits that were Svelt compatible to make us a little bit faster when we’re building some of the widgets, then that’s fine. It’s a small change within the rock and that’s okay. 

Murray: I agree with you. You’ve got some technology choices that you need to make early on, and they’re going to have a big impact on the direction you’re going on. So what I would be doing is prioritizing those very early for exploration so you can understand the risk and understand the doability of the technology. we covered that during the, initiation piece we talked about last week. The purpose of that first two weeks or so has gotta be to understand the platforms and components that you’re gonna use and explore them to see if they’re going to work. I’d want to have the technical leaders in the team exploring those and trying to do some point to point integrations to see, which one is gonna be best. How far did you get before you switched over? 

Shane: It was pretty quick because our, app is designed primarily to work on a large device, it’s not designed for a cell phone. And as we started to experiment with it, we worked out that Flutter was designed to build native apps and not built to be on a browser, on a desktop or a laptop. So at that stage, we knew it wasn’t gonna meet our need. It wasn’t, focused on the things that we thought were important. And so that’s when we decided to switch.

Murray: But had you put much effort into it 

Shane: No

Murray: Okay. So that’s good. So did you do that deliberately? Did you deliberately focus on exploring the potential issues with flooded before you went far with it? 

Shane: yeah, we did. We were also lucky that for a whole bunch of reasons. We weren’t executing as fast as we wanted. Whereas with Svelt, we pretty much started straight away using it in anger. And if we got, a couple weeks down the track and worked out it wasn’t the right thing, then we would’ve to go and take another, look at our roadmap or our blueprint and go, okay, we’re gonna have to go change. How do we figure out what the next change is. 

Murray: That is the big advantage of an evolutionary design approach. If I was doing a waterfall project, we would’ve spent months and maybe a million dollars assuming that it was gonna be flutter, and then everything would’ve been designed with flutter in mind. We would’ve only discovered after the development team started that it didn’t give us what we wanted. So you’d be well into development before you realized you had to change, and then it would be a really big problem at that point.

Shane: I think the other thing as well is that we have always designed with our architectural rocks being loosely coupled. We’re designing as much as possible that we could remove one of those rocks and replace it with something else. In that scenario, our backend didn’t need to change. And from a data and analytics point of view, we try and do the same thing. So we figure out how we are gonna store the data, into which type of technology, which modeling technique we want to use. And if we take those scenario, it’s always possible to change our technology we are storing the data in without changing our modeling technique. That loosely coupled architecture is really important when you’re using a iterative development process.

Murray: Sure. So how are you getting a loosely coupled architecture. 

Shane: So there are proven paths of technology components or architecture components that naturally work together in a decoupled way. You still need to test it. You still need to be aware that something might be different than what you are doing. But when you’re introducing something that’s unknown where you can’t find anything that reference it being used regularly in that way , within your architecture or you can’t really get any confidence that other people have done it that way, then you know you’ve got risk, and that’s when, you’ve gotta go and do research spikes. You spend time to explore, whether it’s safe carrying on that way or not, and then make the change. So I’m a big fan of blueprints that other people have done that are proven. Reusing those patterns, I think is a good technique when you’re starting from scratch .

Murray: Yeah. I do too. I think that there’s a lot of patterns out there that you can use. User experience, designers do that. They go to websites like Dribble and other places where they can see examples of other people’s work. And most of it from a UX point of view is just trying to work out what the best practice is and applying it. So they’ll go and look at competitor websites and user flows, and then they’ll map things out. 

There is a big advantage in mapping things out in the big block level to provide context for everything else you’re doing. So I would say map it out at the big block level, maybe a 12 month view, and then pick the first component you’re gonna work on map that out in a bit more detail. Maybe a three month view. We’re not talking about writing big documents or anything. I’m just talking about whiteboard stuff, and if you need to record it, you take a picture of it and put pictures of it up around the team room so people can refer to it so that when they’re making their decisions within a sprint, they know what the bigger picture is.

There’s constant small decisions all the time that the team are making both with their, technical solution and their user experience solution. And if they don’t understand the bigger picture and the direction that you are going in, they could easily go off in another direction, which solves the short term solution, but causes a lot of problems in the longer term. That’s what I’m a bit worried about with Scrum, that people do just seem to talk about taking a very short term focus all of the time. I’ve had pushback on this from scrum trainers who say no, no, that’s not right, because there’s a product backlog and the product backlog contains everything that you wanna do. And it has its big rocks for things that are far away, and small rocks for things that are close up. But I really think that there’s a lot of discouragement of any design work being done at all during product backlog grooming . It’s really all just about trying to identify what the feature is and what it might mean to a user so you can prioritize it from a business point of view. There’s seems to be a strong discouragement of any design more than say, one sprint ahead , except for the idea of technical spikes but because they don’t deliver immediate business value, it better be for something we’re gonna be building next sprint. 

Shane: I often see a, pattern, which is called the three Amigos. So we have the product owner, some form of BA skillset, some form of technical lead experience, so an expert or a coach level within those skills. And those skills work together slightly ahead of the scrum team, doing very light mapping of some stuff to be able to walk into the backlog grooming with more sureity. They’re identifying the proven paths where they know things should be relatively safe and the areas where there’s a high level of uncertainty.

Murray: Yeah, but there’s nothing about that in the scrum guide. 

Shane: I help teams, I coach adopt a lot of scrum patterns cuz I think they have value but they also adopt a lot of patterns from other agile approaches that have value as well. I’m not a scrum purist. So I’m very opinionated on some words like best practice cuz I call bullshit on best practice. I believe there’s a thing called good practice. Which is in a known context with a known problem. There is a bunch of things other people have done, and if you adopt them, it’s gonna make you faster, they’re good practices. Just do them unless there’s a reason not to. But best practice is you know, those consulting firms trying to say really there is one way to do it.

Murray: I agree with you. I retract best practice and I substitute it with good practice. 

Shane: So we’ll use good practice from now on and we’ll call bullshit on each other if one of us regresses. so Three Amigos is not outta the Scrum Guide. But I’m okay with that. The danger of three Amigos is we start to regress back into pipeline and waterfall behavior. We start overworking that early work. We spend too much time on it. We start defining too much stuff in detail outside of the team rather than giving them a quick start. Some guide rails. 

Murray: But aren’t those three amigos part of the team though?

Shane: yep. Ideally, but sometimes we’ll see three Scrum pods and one set of three Amigos. Those three amigos become really busy cuz now they’re trying to keep ahead of three pods of people that are Scrum, teams that are working. One of the things I like about the scrum guide is it provides some good practice stuff that you can read and understand. And then when we start talking about patterns like the three amigos, there’s more literature about, good practice when using that technique. 

Murray: I think that from a design point of view, you need somebody who’s looking at the bigger picture of the user experience, somebody who’s looking at the bigger picture of the technical architecture, somebody who’s looking at the bigger picture of the product, and somebody who’s looking at the bigger picture of the business processes. And it’d be unusual to have everybody in the team being able to do that. These tend to be, more senior people with a more advanced skills and ability to look at the bigger picture. 

Shane: Yeah and I’ve been crafting the words I use around that for a while now. So I talk about four levels of literacy. So I talk about a novice, a practitioner an expert, and a coach. I’m trying not to use the word lead because that infers a hierarchy, not a literacy. Somebody that’s technically competent at an expert or a coaching level, that’s the level of literacy you need. You need those experienced people. 

I think the other thing that we wanna talk about is in an enterprise organization, especially in the data and analytics space, we end up with a team of architects. So where do they fit in? And one of the other podcasts I listen to they have this saying they use on a regular basis, which is the brakes on your car aren’t there to slow you down. The brakes on the car are there to allow you to go faster, safely. And so that’s the theme I use for architects. You’re not there to slow the team down. If you wait for the team to give you something and you are reviewing it because you’re outside the team, you are slowing them down. What you should be doing is setting principles and practices and patterns that they have to use unless they’re gonna come and have a conversation with you and that allows em to go faster.

Yeah. long as they’re within those boundaries then they don’t need to talk to you. You’re all good cuz you’ve done the hard work and said these good practices make sense, please use them. Visualizing your work on a kanban board makes sense. So if you’re not gonna do it, let’s have a conversation cuz it just seems like a good idea.

Murray: Sure. So I’ve worked for, a big telco and some other places that had enterprise architecture teams. And there was a lot of good people in those teams. I had a lot of respect for their skills, but quite a few of them had stopped coding some time ago, and it all become quite theoretical. The ones I had the most time for were the ones who could do POCs And, would still get their hands dirty. I think that makes a big difference. 

Shane: So you’re talking to somebody who can’t code, or won’t code, but I do have a technical background. But my view actually is the world’s changed and the architecture practice should change. And if you think about the idea that you’re creating these practices and these policies that make people go faster, then actually the way you behave changes, and the way I describe it now is a really good architect actually goes and observes all the teams that are working and doing cool shit. And then they harvest that knowledge and then they provide that knowledge back to all the other teams in a way they can use. So rather than inventing it, we’re copying what’s good from all the stuff that’s happened and then describing it in a way that somebody can read it and go, oh, that makes sense. I think I’ll do that because it’s easy and it looks good, and why would I invent something 

Murray: Yeah, I agree. So that makes a lot of sense to me. I have a big problem with the architect who does some work and then disappears and then it comes back at the end and says, no, it’s all wrong, cuz you didn’t do exactly what I said. And that’s why you’ve got all these problems and they just don’t take responsibility cuz they’re not involved anymore.

Shane: Yeah. And if you’re a consulting architect where you’re on contract, that’s a great way of getting another bite of the apple. I think ideally we want those architecture skills embedded in the squads, in the teams, but that’s hard sometimes. We have a separate architecture team, so it comes back to the way the two groups engage. The architects should be coming along and constantly looking in. Should be attending demo days, they should be potentially coming along to a couple of the standups just to have a listen what’s going on, or just checking in with the team at the right time about anything they should worry about. The team should be pinging the architects, when they know there’s a decision that needs to be made that, is outside the good practices they have been suggested. It’s no different than a product owner. A product owner is involved with the team as much as they need to be. In my view, a product owner should be at least 50% of their time dedicated to the team to help make decisions quickly. the architect should be engaged as often as needed to allow the team to accelerate.

Murray: Yeah, so I agree with the idea of having somebody who’s an expert working at a more abstracted level across a few teams, as long as they’re still involved in supporting the team. If I was doing a project plan with resource allocation, Shane, I would allocate an architect to the team, some percentage of their time, all the way through, either that or not have an architect just make the technical leader, the architect. 

Shane: In an agile world, the teams doing the work is actually the customer of the architect. The architect’s job is to make those customers be able to go faster, safely. An architect should be involved with those teams because they can add value, they can identify things that the team may or may not be able to identify because the architect may have more literacy, more experience in that domain, or just that ability to step back and look at it from a higher level and not be down in the weeds. Not being in their ivory towers but actually being, somebody who enables those teams as their customer to be more effective.

Murray: Most organizations are set up like factories where you have specialized teams doing specialized things, because that’s supposed to be more efficient and effective. So you have these centralized UX teams, centralized architecture teams, centralized deployment teams and so on. It’s a very much a waterfall concept and it just doesn’t work very well. It creates a lot of dependencies and creates a lot of handover problems.

The agile way is to distribute that expertise amongst the teams and then still have them getting together and still talking and sharing information. 

Shane: Yeah. And I think, the more you decentralize and let the teams be self-sufficient, the less you should control or provide standardization across those teams. There are some areas of organizational behavior that are hard to change and adapt when you’re taking an agile way of working. And the architecture part of an organization is one of those.

Murray: Yeah, It’s the same with the user experience design group. They tend to be very precious, very controlling, very much into empire building in larger organizations. That’s what I’ve seen. I’m sure they don’t have to be like that, but it does tend to be that way. 

Shane: If I take it back to our startup I am one of the worst product owners in the world in terms of being able to clearly articulate what I want. And so therefore, for me, doing a whole lot of work upfront on the flow across our application from the beginning to the end didn’t make any sense because there are whole chunks in there where I don’t know how it’s gonna work. I know what I need to achieve but I actually have no idea cause I don’t have the experience of what I want. We approached it at the beginning with a very ad hoc ungroomed requirement or approach. We’ve started to evolve that a little bit where we’re drawing lots of big rocks on a big piece of paper. And then when we get to the rock, we deal with what’s in that rock. But if any of those rocks change then from a uX point of view, we know, there’s rework, because we’re assuming each of those rocks is a thing that will actually happen. So design a little bit upfront because you need to have that vision and that shared language, and then you dive a bit deeper as you get into it, and everything can change. But there’s a cost and a consequence when you change some of those big rocks.

Murray: Yeah. You’ve gotta have a 30,000 foot view, a 10,000 foot view and then a 10 feet view. 

All right. What about the idea that we need to have an expert architect available to every team. And then that person sets the direction for the team. Cause they’re the ones who understands the big picture. It’s what I would call the surgeon model. There’s this idea in hospitals that the surgeon is the one making all the important decisions, and everybody around them supports them. 

I was talking to somebody the other day who was railing against incompetent developers and talking about how important it is to have an expert to make these decisions. Cuz otherwise you could go down some bad paths. 

Shane: So there’s my perfect example of non-agile architecture thinking. If the team had low level of literacy, and they were really struggling then that’s a big problem. How the hell do you pass that knowledge on? Because it’s knowledge you’ve gained over many years and it’s not something you can just read about. But what I heard you say is, these people are not worthy and they need to come to me because I’m the expert in the room. And that hero mentality is one of the problems we have. 

When I’m starting off with a team we identify the skills we need to be successful. In the data space there are things like, how do we understand the data requirements? How do we write tests? How do we model the data? How do we write the Extract, load, and transform code. How do we take data outta something like Salesforce, drop it into a database like Snowflake or BigQuery, and then write some code that changes it in the database to do what we want? How do we deploy that code? So there’s a whole bunch of skills which relates to the work that needs to be done. We then get each of the team members to rate themselves for each of those skills based on novice practitioner, expert and coach,

So once the team have mapped out the skills they have we look for gaps. We look for skills where nobody in the team has an expert or a coach level. Cause we know we have a risk. We also look for areas where those skills are really only held by one person because if that person’s off for a week on holiday, the team really are in trouble because nobody can pick that work up. So once we identify those gaps, then we have to work out what are we gonna do to increase the literacy of those team members over time to fill those gaps. And that’s what a good architect should do. They should look and say, cool, actually you are really light on data modeling. I’m gonna go and help you become practitioners and data modeling. I’m gonna be there when you need me through the initial parts of your work because we know you are light and I can help you. But my goal is to make yourself sufficient, not be the gatekeeper that told you did it wrong.

Murray: Yeah, I like that approach. I agree with that approach too. I’m quite worried about the hero model. But there is this concept that you just need to get a group of experts together and they’ll just do it.

Shane: So what do you name a group of architects, and it’s called an argument of architects, we ever get in the room together, we argue semantics. If you took the best soccer players from every team in the world and put them into a team, they’re not gonna perform as well as a team of players who, have been playing together for a long time and still have good skills. Because it’s the team that makes ’em efficient. And a team of experts doesn’t mean you’re actually gonna get there faster or safer. 

Murray: I think that the expert needs to do coaching, training, mentoring, capability building. But they also need to be able to paint out the big picture because the team just may not have the awareness , or understanding or experience of, a range of different possible solutions. I would want an architect, to help me map out the big picture as well as capability building.

Shane: Let’s look at what good looks like. An architect sitting with that team going, have you thought about? Is a really good way of them engaging with the, team to help the team understand they probably missed something. An architect saying, there is a pattern that looks like this. Do you think if you applied in that situation it’ll solve that problem? 

Murray: You could be working with a group of people who just don’t understand the patterns. People build up their experience over time, as you said before they go from novice to, what were the stages you had? 

Shane: Novice, practitioner, expert, and coach. 

Murray: This is a bit like the Shu Ha Ri model from Alastair Coburn and martial arts. I think a lot of practitioner developers might understand the current framework they’re working with moderately well, but they just don’t understand other frameworks and other patterns.

Shane: I think going from expert to coach is really hard because it requires you to take your expertise and articulate it in a way that you can coach somebody else to do what you do. And that’s hard, to take things that you have unconsciously done for years and then be able to articulate it. 

I’ll give you an example. When we’re doing this app development, we started down the path of design systems. And it took me ages to find somebody that could explain what a design system was. I started off pinging on my mates going, Hey, we are doing some app development. Can we grab a copy of your design system? Cause I wanna apply it. And they just laughed at me and I was like, what the hell is it? And then they’d say some words and I’d go, I don’t get it. What the hell is it? And it took me ages to figure out what I think a design system is for a ux. 

Murray: Yeah I think that experts need to think of themselves as consultants who have coaching as one of their approaches. I say that because I’ve been encountering quite a few coaches who will ask Socratic questions or engage in a therapeutic approach. Some of those people don’t have the experience to contribute and that’s why they’re taking that approach. If I engage an agile architect or an agile user experience designer, I want somebody who has a whole lot of different things that they can do. Yes, they can ask Socratic questions and they can, mentor people individually, but they can also do the work if that’s needed. Or they can teach, they can train, they can mentor. Difference between mentoring and coaching is that mentors offer possible solutions based on their experience, whereas coaches don’t offer solutions according to the International Coaching Federation. I want somebody to take a bit of a broader approach where their expertise is available as well. 

Shane: Did you just say that the definition of a coach from that organization is you don’t provide solutions?

Murray: Yes, cuz that’s mentoring and there’s a big difference between coaching and mentoring. 

Shane: Wow. So I’m going to become an Agile mentor then. The number of times I’ll work with a team and the team will ask the scrum master something in the scrum master will reply with, depends, and that does mine nut. So they shouldn’t dictate what next, but they should at least provide some guidance and options. That coaching thing’s really interesting. If I think about the coach of the All blacks, the world’s best rugby team, I don’t get the impression that the coach of the All Blacks is not providing any guidance. 

Murray: I agree with you. My model of a coach is the sports team coach. They’re adding a lot of value and guidance. They’re not playing the game or kicking the ball. They’re providing a lot of help and strategies and guidance so other people can do it. But there is this strong trend in the agile coaching community at the moment to say that an agile coach is not a sports coach. An agile coach is more like an executive coach, which is more like a counselor. It’s a counselor model where the important thing is to get very interested in the person and then curious about them and how they’re feeling and what they’re thinking, and to ask questions to help them, make their own choices, but you don’t provide any suggestions at all. It does my head in too. I think it’s really low value. 

Shane: I think it’s about balance. A while ago I was attending some agile meetups in New Zealand and the group started going down this whole thing of ethics for an agile coach. I dunno if you agree, but it seems a bit wild west out there in terms of who can call themselves a coach and what’s acceptable for a coach to do or not.

I could see that some coaches believe they were life coaches and some coaches believe that you should be very clear that if a person has personal issues you can’t go there because you don’t actually have that training and you could damage people if you do it badly. Bob Galen had a code of ethics that he publishes, gives us customers at the beginning of every engagement to say, as an agile coach, this is what I will do. And as an agile coach, this is what I won’t do. I think that’s important, I think the ability for say, these are my skills. And so if you come from life coaching saying, Hey, I’m more of a life coach than a domain expert, and that’s okay, as long as that’s the expectation between you and the people you are working with. But again, I see very few agile coaches that actually have that charter. We teach our teams start off with a team charter. Get agreement on what you will and won’t do and what good looks like and what’s not acceptable. But how often does an Agile coach do that with their customer or their team on day one? 

Murray: There’s this consulting model, which came from Douglas Champion, Keel and McLendon from the mid eighties which suggests that there are nine possible consulting stances that you can take depending on how much responsibility you take for the client’s result and how much responsibility you take for the client’s growth.

You could be an observer and provide feedback. You can be an advisor who answers questions. You can be a hands-on expert You could be a facilitator, a teacher, or a mentor. And the top level you can be a visionary, a coach or a partner. So I want a expert in architecture or design to be able to use all of those approaches not just the therapy approach that some people take. 

Shane: That sounds like a great framework. My takeaway is, It’s unlikely somebody has all nine of those at a level of expert or coach. So you just need to be clear what you’re good at and how you can help and where the gaps are so that everybody’s clear on the value. What you’re helping with and what you’re not helping with.

Murray: So maybe we can do a summary, Shane. We started talking about evolutionary design and the problem with a two week focus. And then we talked about looking at things at different time horizons makes a lot of sense. And you talked a lot about big blocks and small blocks, which I agree with. The importance of having roadmaps but not fixed roadmaps. They provide direction, but you change your roadmaps as you learn. And then we started talking about centralized teams and the role of the architect which I want distributed.

And then we went into quite a big discussion about the role of the expert. If you are the expert architect or the expert designer what do you do? And I think we both agree that a very big part of your job is to build the capability of the team. But I want ’em to both build the capability of the team and get results for the client. And that can mean that they’re, on the field as well, to some extent, when it’s needed. 

Shane: Yeah. I go back to the literacy model that I’m comfortable with, which is if you’re at that expert level, then you can be on the team, you can be on the field. That’s okay. When you get to the coaching level, you typically shouldn’t be because your whole focus is changing from getting the thing done to teaching other people how to do it as well as you do. We all have to sometimes do things because they just need to be done, but your focus should be coaching that team or many teams to be as, much of an expert as you are. 

Murray: I want those people to be sports coaches. doing a lot of strategy planning with the team, even not on the field. 

Shane: Yeah. Should an agile coach have played on the field of the team you are coaching? Or is it okay to come in when you’ve never played that game? I like the way you summarize this one up. Thank you for doing that,

Murray: That’s all right.

Shane: Excellent. Catch you next time.

Murray: All right, thanks. 

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.