Evolutionary design & agile architecture

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.

Resources

Recommended Books

Podcast Transcript

Read along you will

 

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

Murray: And I’m Murray Robinson. 

Shane: Hey, Murray. Good. See you again. Uh, it’s another, another podcast, uh, day. So always looking forward to these days. Um, I think we’ve decided today we are gonna talk about something which you call evolutionary or evolving design and, and, which I call agile architecture.

Murray: Yeah. Well, let’s talk about, um, evolutionary design or agile design, if you wish. 

Shane: Yeah. Well, what you started from, from your domain and what you see and how you, uh, how you make it work. And then I’ll jump in from, uh, my data and analytics architecture kind of view or, or terminology. 

Murray: Sure. So, um, I was first exposed to, or first did Agile back in 2004, and, um, I read XP explained by Kent Beck, and that’s what we tried to implement.

And in there he talks a lot about you ain’t gonna need it, which is, um, one of the key rules. And the idea is, and then the other one is the rule of three, which is basically the idea is that you, um, you just code a solution for the immediate small story that you’re working on, and you don’t worry about reuse at all.

Right? You, you have, you know, automated test cases and things. I’m very concerned about that, but you just focus on the now. And the reason is because there is an enormous amount of waste supposedly. In, you know, designing things for a future that may never happen, which makes a lot of sense. But then if you find that you’re working on that code module a second time, then you might, um, you know, you, you have to change it a bit for a new, new feature or change in rules or something.

And then the third time, then you restructure it to make it, you know, modular and, you know, uh, more abstracted from an architecture point of view. So, but apart from that, the idea is that you avoid any bigger architecture or design decisions on the basis that. It, uh, is probably not needed or you don’t really know what it is, you, you’ll probably get it wrong.

So, um, this also has carried over. It’s become a very big part of Scrum, I think. Um, Scrum is really has this idea of, we just focus on the current iteration. Um, we, we design and build in the current iteration, usually two. Um, we do groom the backlog of course, and, you know, maybe there’ll be a bit of discussion about how you might solve something in order to estimate it.

But I think the idea, if you’re gonna do Scrum by the book, you try not, you try to avoid design conversations when you are grooming the product backlog. So I have, I’ve seen this actually, um, go wrong quite a lot, uh, particularly when working with UX designers because, um, it, it makes you take this kind of microscopic focus around buttons and, you know, small code modules and things like that.

And you get a, you get lost amongst the trees. Like you can’t see the forest for the trees basically. And um, I’ve seen a lot of really fragmented. User experience design, which comes out of just this constant, very short term focus and UX designers and UI designers complain about it constantly to me when I’ve had them in my teams.

Um, and, uh, because they, they work on a bigger picture level, right? They work at the level of user experience and user flows and user journeys and pages. They will argue you can’t design a button, buttons or part of a form for a page unless you know what the whole page is. And you can’t really even design the page unless you know what the user journey is and the user flow is.

And I think that they’re right actually. I’ve seen bad design come from just this total focus on the micro decisions. Um, so my, but on the other hand, I’ve, I’m saying, You know, I’ve, I’ve run projects, uh, waterfall projects in which there was three months of requirements, three months of architecture, you know, months of design and months of technical design before you ever build anything.

And then, you know, a lot of that stuff ends up being wrong and wasted and, um, you know, you really miss a lot of things. You only find them out during development. So I, I think that there’s a place for evolutionary design, but it needs to sit somewhere in the middle. So I think about a chain as, um, different time horizons.

We’ve gotta have a big picture, you know, a medium term and a short term. In the short term is the, is the sprint. And so you don’t want the big picture too detailed, but you want it kind of blocked out so that you know what context you’re working in. When you’re making micro decisions during a sprint, what do you, what’s your view on it?

Shane: Yeah, so I think, um, actually I can, I can take two lenses on this. Um, primarily, you know, the data analytics space, we’re on coaching teams, uh, in that domain, on, on how to change the way they work. Um, but also with our current startup, we’re actually doing some application development. And that’s given me an insight into some of the things that you are talking about where it’s more active than, um, data.

Um, so from a data and analytics point of view, uh, yeah, I started off on that same journey as you different book. Um, but the idea that we could do what I call build the airplane while we’re flying. Um, so, you know, we didn’t go in and do any architecture design at the beginning. We basically started off with, with the squad or the team for, to start the work and we were.

You know, starting from nowhere, uh, and trying to design the architecture at the same time as implemented and, and build it. And in the data world, that seemed to cause us a major problem. And over the last couple of years I’ve been ruminating on that. And, and what I think it comes back to is in the active world there are, uh, a bunch of, of known paths.

I call it. There are a bunch of patterns. There are a bunch of architectures or design things that, you know, work together. Um, and therefore you can pick one of those cuz you really without a lot of effort. Whereas in the data and analytics world, we are still not at that level of maturity. We’ve still got 101 different choices, all giving us massive consequences.

And, um, so what we tend to do now is I recommend. What I call agile texture, which is the idea of, like you said, using time horizons. So at the beginning, we should take a piece of paper and we should draw some big rocks, right? We should make some decisions. Um, and they should be the big influential decisions that will have a massive impact if we change our mind.

Um, and we should draw those down on the picture and say, that’s where we’re gonna start from. And then as we’re building things out, if we are changing something within one of those rocks, within one of those boxes, and that’s okay, right? Cause they’re just boxes. They don’t have a lot of detail in them yet.

So that’s fine. But if we are starting to make a change that looks like one of those rocks is going to change, then we, we should be aware that there’s probably a whole lot of change impact that’s coming in some of the other spaces. And therefore the cost and time of making that change will be bigger than we expected.

And then we need to kind of go through and reiterate that agile texture again to say, Okay, well we, we are making that change. What’s the impact? Right? Um, yep. The other thing I find is, is drawing that picture, doing that wireframe architecture helps the entire team, uh, understand what we think the future state might be.

It, it’s, it’s a picture, it’s something, you know, we can wave our hands and use the word and say words as much as we want, but as soon as we draw it in a really light way, um, it seems to get the message across better of what we’re aiming for, and then allows any of the team members to identify, um, when one of those changes is gonna be massive.

So if I compare that to, as we are building out this, this app right at the moment, um, We had to make some, some decisions from a architecture point of view for that, where, um, we had to decide what we’re gonna build the front end, you know, what we were gonna build the back end and how were gonna make those things talking.

And we actually changed it quite a bit. So I, not coming from an active background, I, uh, phoned a whole lot of friends and, you know, worked out that I could go down the React path or I could go down the, whatever the other one was. Um, and then slowly worked out that actually that design decision, that architectural decision, actually impacts the people we hire.

Yeah. Um, because we now hire, you know, if we went react, we have to hire specialists. Um, and then we actually started off experimenting with a, a front end capability and a thing called flutter. Um, and. 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 and it’s life cycle to be safe for us. So we then ended up moving on, um, a front end technology called, which again was early in its life cycle, but was a little bit more mature. And that’s what we’ve gone with. Now, that’s a big rock, right? If I decide to go from still to react, there’s a massive amount of cost and change that I’ve gotta incur there is.

So I have to actually potentially retrain my whole front end team or find another one I have to rebuild on my components or Portland. So for me, that big rock, it doesn’t mean it’s never gonna change, but if we do decide to change it, then the cost and consequences that change are quite large. So it has to be a really well thought out decision, whereas.

If we decided to bring in, um, you know, one of the CSS kits that were felt compatible to make us a little bit faster when we’re building some of the widgets, then um, that’s fine. That’s a small change within the rock and that’s okay. 

Murray: Um, so you were talking about, um, big rocks, Shane, and I agree with you. I think that, um, you’ve got some technology choices, um, that you need to make early on, and they’re going to have a big impact on to direction you’re going on.

So what I would be doing is prioritizing those very early for exploration so you can, um, uh, understand the risk and understand the doability of the technology. We actually, I think we covered that, um, during the, the initiation piece we talked about last week. I’d be, I’d be saying that the purpose of that first two weeks or so, Has gotta be from a technical architecture point of view to understand the kind of platforms and components that you’re gonna use and explore them to see if they’re going to work.

So you, you’d be saying, I think this, I think that, I think flatter or what was the other one Still? So, so I would, during the first two weeks, I’d want to have the technical leaders in the, in the team exploring those and trying to do some point to point integrations to see, you know, which one is gonna be best.

And, um, then we’d start with, with one of them. But, um, What did, how far did you get before you switched over? 

Shane: Um, from flooded to film? Yeah. Uh, it was pretty quick because our, our app is designed primarily to work on a, on a large device, right? It’s not designed for a cell phone, a smartphone. And as we started to experiment with it, we worked out that Fluter was very much designed to build native apps and not built to, to be on a browser, on a desktop or a laptop.

Um, and it was coming, you know, it was in the roadmap for that product. Um, but after, you know, a wee while it was pretty clear it wasn’t at a priority for them. Um, So at that stage, you know, we then knew it wasn’t gonna meet our need. It wasn’t, you know, um, 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 coding with No. Okay. So that’s good. So did you, did you do that deliberately? Like, did you deliberately explore, focus on exploring the, the potential issues with Flatter before you went on and too far with 

Shane: it? Yeah, we did. We were also lucky that, um, for a whole bunch of reasons we were executing as fast as, as we wanted.

So, you know, if we were actually running pretty quick, um, we would’ve had to make the decision a lot quicker. Um, so we had some natural delays that, uh, were in hindsight lucky. Yeah. Whereas was felt we pretty much started straight away using it in anger. And so, um, again, if, if we got, you know, a couple weeks down the track and worked out, it wasn’t the right.

Then we’d have to go and, uh, take another, you know, look at our roadmap or our blueprint and go, Okay, we’re gonna have to go change. Uh, how do we figure out what the next change is? 

Murray: I think that is, that is the big advantage, Shane, I think of an evolutionary design approach because if I was doing a waterfall project, you know, we would’ve spent nine months maybe with and, and maybe a million dollars going down an architecture path, assuming that it was gonna be flutter, and then everything would’ve been designed with flutter in mind.

And then when we would’ve only discovered after the development team started that it didn’t give us what we wanted. And probably they wouldn’t even tell us because they would keep trying to make it work. And so you’d be well into development before you realized you had to change. And then it would be, you know, it’d be a really big problem at that point.

Shane: I think the other thing as well is that, um, you know, we, we have always designed with our architectural rocks being loosely coupled. Yeah. We’re designing as much as possible that we could remove one of those rocks and replace it with something else and you still be a cost and a consequence. Um, but we’re always architecting so that we can do that.

So, you know, in that scenario, our backend didn’t need to change, uh, the way we, our front end talked to 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, we figure out how we are gonna store the data right into which type of technology, which modeling technique we want to use.

Um, and if we take that scenario, you know, it’s always possible to change our technology. We are storing the data and without changing our modeling technique. So’s possible to change our modeling technique without changing our technology potentially. Right. So again, that loosely coupled architecture is really, really important when you are using a intru development process.

Sure. 

Murray: So how are you, um, getting a loosely coupled architecture? 

Shane: So I think it’s primarily in the thinking when you define that architecture mm-hmm. , right? You, you’ve taken it from the principles of everything as loosely coupled, um, and then. Again, go back to proven paths, right? There are proven paths of technology components or architecture components that naturally work together in a decoupled way.

Um, and so if you’re adopting one of those is, is what I call your blueprint. At the beginning, you’re relatively safe or certain that it’s gonna be okay. Cause you know it’s been done before you’ve ever done it yourself, or you’ve talked to lots of people that give you that confidence. You still need to test it, right?

You still need to be aware that something might be different in what you are doing. Um, but when you’re introducing something that’s unknown, right, where you can’t find anything, that kind of reference of being used regularly, and that in that way within, within your arch. Um, or you can’t really get any confidence that other people have done it that way, then you know you’ve got risk, right?

And that’s when, you know, as we talked about in the initiation podcast, that’s when you’ve gotta go and do those research spikes, right? You actually have to go and spend time to explore, um, whether it’s safe carrying on that way and, uh, or not, and then make the change. So I’m a big fan of blueprints, um, and, you know, blueprints that other people have done that are proven, uh, reusing those patterns, I think’s a good technique when you’re starting from scratch as well.

Murray: Yeah, I, I do too. I think that there’s a lot of patterns out there that you can, you can use and, um, uh, like user experience, designers do that. They go to websites like Dribble and other places where there’s, they can see. Examples of other people’s work, and most of it, um, really from a UX point of view is just trying to work out what the best practice is and, and applying it.

So they’ll go and look at competitor websites and um, you know, look at user flows and then they’ll map things out. But, um, I think there is a, there is a big advantage in mapping things out in the big block level, um, to provide context for everything else you’re doing. So I would say map it out at the big block level, you know, maybe a 12 month view, and then pick like the first component you’re gonna work on.

Like map that out in a bit more detail. Maybe a three month view. You know, we’re not talking about writing big documents or anything. I’m just talking about whiteboard stuff, you know, And if you need to record it, you take a picture of it and you put it in Jira or whatever you’re using, who knows? Um, and then, you know, or you put pictures of it up around the team room or, uh, say people can refer to it at, so that when they’re making their decisions within a sprint, they know what the context is.

And I think that context is very important because there’s, there’s constant small decisions all the time that the team are making, both with their, you know, the technical solution and the user experience solution. And they, they could, if they don’t understand the context and the direction that you are, you are, you are going in, they could easily go off in another direction, which.

Maybe solves the short term, short term solution, but causes a lot of problems in the longer term. And that’s what I’m a bit worried about with, with Scrum, that um, people do just seem to talk about taking a very short term focus all of the time. Now, when I’ve had, I’ve had pushback on this from scrum trainers who say, No, no, that’s not right, because there’s a product backlog and you know, the product backlog contains everything that you wanna do.

And it has its big rocks for things that are far apart, far away, and small rocks for things that are close up. But, um, I really think that there’s a lot of discouragement of any design work being done at all during that kind of backlog. Grooming, as it’s called. It’s really all just about trying to identify what the, 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. I would say that this sprint, we can have some technical spikes, but, um, because they don’t deliver immediate business value, you know, it better be for something we’re gonna be building next sprint.

And that’s about it, 

Shane: I think. I see, uh, yeah, from a Scrum point of view, I often see a, a patent, which is called the Three Amigos. Um, so yeah, again, it’s, it’s the balance of, uh, Of how you are working. That’s important. So when I see the three amigos happen, when I see it happen, well in my view we have the product owner, some form of be type skillset, some form of technical called lee type skill.

So sorry, experienced, right? So an expert or a coach level within those skills. And those three roles work together, Those skills work together slightly ahead of the the Scrum and they’re doing very light mapping of some stuff to be able to walk into the backlog grooming with more sureity. So, You know, they’re identifying the proven paths where they know things are relatively or should be relatively safe, and the areas where there’s a high level of uncertainty and a research spike is probably a good idea.

Murray: Yeah, but it feels like that’s an addition to Scrum, though. There’s nothing about that in the Scrum guide. That’s a kind of No, 

Shane: definitely, and, and you know, I’m, I use a lot of, Sorry, I, 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. Yeah, good. Um, so, so I’m very opinionated on some words like the one that you just triggered with me a little bit before about best practice. Cause I call bullshit on best practice. , I believe there’s a thing called good practice, right? Which is in a knowing context, with a knowing problem, there is a bunch of things other people have done and if you adopt them, it’s gonna make you faster.

Right? They’re good, they’re good practices, just do them. Unless there’s a reason not to, but best practice is, is you know, those consulting firms trying to say really there is, uh, one way to do it. And, and I don’t believe that. I mean the other trigger word you use with Jira, but I won’t there, 

Murray: let me respond to your best practice.

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

Shane: Cool. Right. So we’ll use good practice from now on and we’ll call bullshit on each other. If one of us, Reg Reeses, what 

Murray: was the other thing that you, that triggered you? 

Shane: Jira, but we won’t go . 

Murray: Oh yeah. I’m a Jira administrator.

Shane, I’ll, I’ll set up your Jira for you . Yeah, 

Shane: thanks. No worries. Anyway, so, um, so yeah, so Three Amigos is not outta the scrub guide. Um, but I’m okay with that. Now, there is an anchor 

Murray: there because Scrum is not the whole of Agile. I think we should say that. No Agile. You can do Agile without doing Scrum at all, which is pretty shocking to a lot of people, including some Scrum trainers I’ve spoken to.

Shane: Yeah, I mean, I talk about adopting an agile mindset, right? That’s, and we’ll talk about what that means to an architect actually, cuz that’s a really interesting conversation. Um, when I come back to Three Amigos. Yeah. Uh, 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 and detail outside of the team rather than giving them a quick start. Some, some guide rails. But aren’t those 

Murray: three me guys part of the team though? 

Shane: Yep. Ideally. But sometimes we’ll see um, three Scrum pods and one set of three Amigos, right?

Those three amigos become really busy cuz now they’re trying to keep ahead of three pods of people that are Scrum, you know, teams that are working. So, um, again, I, I think one of the things I like about the scrum guide is it provides some good practice stuff that you can read and understand. Yeah. And then when we start talking about patterns like the three amigos.

There’s, uh, more random literature about, you know, good practice when using that technique. 

Murray: I think that might come out of xp actually. It sounds quite familiar. 

Shane: Yeah, it could do. Uh, again, I read it somewhere and I can’t remember where. Um, there’s 

Murray: a lot of, um, XP practices, um, like gives are stories, for example, that’s not in Scrum.

But I, I think that, uh, you know, there’s an argument that Scrum without XP is pretty empty. It just doesn’t work. 

Shane: So, you know, you know this bit a more than me, but peer programming came out of xp, not Scrum, right? Yeah. Um, so did, yeah. And Theban board that we use as a scrum board that came out. One of the, you know, the Kaban Lean Track didn’t, it didn’t actually, it’s not part of Scrum.

If you read the guide from Memory, 

Murray: well, Scrum. Just had backlog doing done. And the idea of setting up a CanBan board for that came out of the Yeah, out of the CanBan community. 

Shane: Yeah. But have you ever worked with a Scrum team that doesn’t visualize their work on a CanBan board? 

Murray: You know, everybody does it now and that’s cause and talk like that

Shane: So, And I think, I dunno, if you go on a two day scrum certification, do you get taught. To visualize the flow of the work on a combine board. Yeah, you’re 

Murray: right. It it is all, it is all part of it now, I think, I mean, Scrum has evolved over time, so I, I can’t, I don’t wanna go and look up the scrum guide now to see what it says about visualizing the work, but it probably does say something about it now.

But anyway, um, coming back to design and the, the, the three me guys, I, 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, bigger picture of the, the business processes.

So I think that there’s, that’s four, and it’d be unusual to have everybody in the team being able to do that. These tend to be, you know, more senior people with more advanced skills and ability to look at the bigger. Picture. 

Shane: Yeah. And, and you know, I’ve been crafting the words I use around that for a while now.

So I talk about literacy and I talk about four levels of literacy. So I talk about a novice, a practitioner, uh, an expert and a coach. And that’s only because I used to use the word master and I used to use the word journeyman. And I’ve, I’ve purposely gone and found words I’m comfortable with to remove those words outta the vocabulary.

Um, and I, I, just thinking back, I regress as I was talking about the three megos. Cause I was talking about a technical lead, and I’m purposely trying not to use the word lead because that in fears a hierarchy, not a literacy. So I should be using the words, somebody that’s technically competent at an expert or a coaching level, right?

That’s the level of literacy you need. You need those experienced people. Um, I think the other thing that, uh, we wanna talk about is, In an enterprise organization, you know, especially in the data and analytics space, we end up with a team of architects. So where do they fit in? Um, and one of the other podcasts I listen to, they, they have this saying they use on a regular basis, which is, the breaks on your car aren’t there to slow you down.

The breaks 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’re 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. So as long as they’re within those boundaries right 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. Uh, and I take it back, you know, visualizing your work on a car bar board Makes sense. Yeah. So if you’re not gonna do it, let’s have a conversation cuz it just seems like a good idea.

Yeah, 

Murray: sure. So I’ve, I’ve worked, uh, for, you know, a big telco and some other places that had enterprise architecture teams and, um, there was a lot of good people in those teams. I, I, uh, had a lot of respect for their skills, but, um, Quite a few of them had stopped coding some time ago, and it all become quite theoretical.

Um, and the ones who had I had the most time for were the ones who could do POCs and, and you know, would still get their hands dirty. I think that makes a big difference. 

Shane: Um, so you’re talking to somebody who can’t code, Right. Um, or won’t code, but I do have a technical background. Um, but my view actually is the world’s changed and the architecture practice should change and.

If you think about the idea that you are 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 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.

Sure. So rather than inventing it, we’re kind of copying what’s good from all the stuff that’s happened and then describing it in a way, like a scrum guy that somebody can read and go, Oh, that makes sense. I think I’ll just carry on doing, I’ll do that. Um, because it’s easy and it looks good, and why would I invent 

Murray: something?

Yeah, it works. Yeah, I agree. So, So that makes a lot of sense to me. I have a, 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, you are all got all these problems.

Do you know what I mean? I’ve had that situation where you there architects in a different group and they just don’t take responsibility cuz they’re not involved anymore. 

Shane: Yeah, I, I mean, you know, and if you’re a consulting architect where you’re on contract, right? That’s a great way of getting another, uh, bite of the apple.

Um, I I think ideally we want those architecture skills embedded in the squats, Right. In the teams. Yeah. But that’s hard sometimes We have a separate architecture team, so it comes back to, uh, the way the two groups engage. Um, the architect should be coming along and constantly looking in, um, should be attending demo days, right?

They should be potentially coming along to a couple of the standups just to have a listen to 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, if they are outside their team, when they know there’s a decision that needs to be made that is outside the, the good practices they have been, um, suggested.

So to me it’s no different than a product owner, right? A product owner is, is involved with the team as much as they need to be. I mean, 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, uh, the idea of having somebody who’s a, an expert, who, who’s working at a, maybe a more abstracted level across a few teams, as long as they’re still really, um, quite involved in supporting the team. So what I would do is, um, if I was doing a, a project plan with resource allocation, Shane, I would, I would allocate an architect to the team, some percentage of their time all the way through, right?

Either that, either that or not. Have an architect just make the, the mo the technical leader, the 

Shane: architect, uh, you, you’re going on wind up with today. Um, So another, Yeah. I often talk about, uh, yeah, Agile being a mindset, right? Uh, where we adopt some approaches and patterns that other people have decided have worked out a good to make us faster.

If you think about an architect, one of the mindsets that I believe in architect needs to make, uh, might change, they need to make when we’re we’re adopting an agile way of working is who their customer. And in my view in world, the teams doing the work is actually the customer of the architect architects is to make those customers be able to go faster, safely.

And when we do, We go, Well, yeah, an architect should be involved with those teams because they can add value, right? They can identify things that the team may or may not be able to identify when they’re working on that problem because the architect may have more literacy, more experience in that domain, or just that ability to be, to step back and look at it from a higher level and not be down in the we is often valuable.

So, yeah. Yeah. Where those architecture practices exist and you don’t wanna change it, then the, the way they think of themselves not being in their ivory towers, uh, but actually been. Somebody who enables those teams as their customer to be more effective. Yeah. Is really where we gotta 

Murray: go. I think, um, organizations, 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 and builds up expertise and capabilities.

So you have these centralized UX teams, centralized architecture teams, centralized up, you know, uh, I was gonna say DevOps. That’s tends to be what they call themselves now, but deployment teams and so on. Um, and I think that that’s a real anti patent, that that creates a lot of dependencies and creates a lot of problems, a lot of handover problems and so on.

So, um, when I’ve reorganized, you know, a, a larger organization, you know, with say 50 plus people, I, uh, tend to break those teams up and I allocate people to the, um, To the scrum teams or whatever you wanna call ’em, the product, I like to call ’em product teams. So I allocate the experts to the product teams as much as possible.

And I’m, but I might say, cause you are an expert in this thing, you are, you’re gonna sit with this team or, and you’re gonna be 50% supporting them, but 50% supporting everybody else and providing coaching and mentoring and training. I think that there’s a lot of problems, a lot of serious problems with the kind of architecture team, the design team.

It’s a very much a waterfall concept and, um, it, it just doesn’t work very well. I think the’s, a way of doing it is to distribute that expertise amongst the teams and then provide them with an alternative kind of matrix structure where you still have them getting together and still talking and sharing information, but it’s not a.

Um, ivory tower at all. 

Shane: Yeah. And I think, um, yeah, we, we’ll need to pick this up in another podcast around the idea of centralization versus decentralization of teams and skills. Um, because I think that those decisions have a, a massive impact. And the more you decentralize and let the teams be self-sufficient, the less you should control or provide standardization across those teams because you are trying to mix your toasties, right?

You, you need to pick some rocks and they have consequences. Um, but let’s, let’s cover that. When we go into the old, you know, cross functional teams, what does that actually mean? Centralized capability for some things versus others, And back to that factorization that you talk about, where we treat. Um, scrum teams as if they’re working in a factory.

Um, yeah, cause that’s a really interesting conversation, but I, I agree with you. I think, um, there are some areas of organizational behavior that are hard to change and adapt when you’re taking an, an agile way of working. And, uh, the architecture part of an organization is one of those. 

Murray: Yeah. It’s the same with the user experience design group.

They, they tend to be, not always, but they tend to be very precious, very controlling, very much into empire building in, in larger organizations. Anyway, that’s what I’ve seen. I’m sure they don’t have to be like that, but um, it does tend to be that way. 

Shane: Yeah. I mean, I don’t do a lot in that space in, in enterprise land.

Um, again, if I take it back to our startup, um, you know, we’ve got one person who looks after the UX design for us, with us. Um, I am one of the worst product owners in the world in terms of, um, being able to clearly articulate what I want and the acceptance criteria. Um, and so therefore, for me doing a whole lot of work upfront on the, the flow across our application from the beginning to the end didn’t make any sense because there are whole chunks.

There are big rocks in there where I don’t actually know how it’s gonna work, Right. I know what I need to achieve, but I actually have no idea cause I don’t have the experience of kind of what I want. Um, so, you know, we approached it at the beginning we’re we’ve a very ad hoc, un groomed requirement or approach.

What’s happened is we’ve started to evolve that a little bit where again, we’re, we’re. Drawing on a big pace on a piece of paper. Big piece of paper, Lots of big rocks, Yeah. Mm-hmm. . Um, and then when we get to the rock, we deal with what’s in that rock. But if any of those rocks change, um, then from a UX point of view, we know there’s a massive amount of rework, right?

Because we’re assuming each of those rocks is a thing that will actually happen. So again, I think it comes back to that, that idea of agile architectural, agile design a little bit upfront, because you need to have that vision and, 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. I like to think of it as, you know, looking at things from like a, you gotta have a 30,000 foot view, you know, a 10,000 foot view and then like a 10 feet view. And, um, but you, the thing is, you don’t wanna be really detailed in your 30,000 feet view. What about then the idea that, um, experts are critical.

Um, there’s a lot of people who can’t do design and so therefore we need to make sure that we have an expert architect available to every team. And then that, uh, person really sets the direction for the team. Cause they’re the ones who who knows how to do, you know, knows, understands the big picture. It, it’s what I would call the surgeon model.

You know, there’s this idea in hospitals that the surgeon is the one making all the important decisions and everybody around them supports them, like the nurse and their anesthetist. And so on. And I was talking to somebody the other day who, who was very much railing against incompetent developers and talking about, um, you know, how important it is to have an expert to make these decisions.

Cuz otherwise you could go down some very bad, um, paths. 

Shane: So, so there’s my perfect example of, uh, non agile architecture thinking, right? So if you had said to me, um, the problem the person had was they had a new team, the team had low level of literacy in, in some of the areas and they were really struggling on how they could coach and mentor.

Those people to come up to a level of literacy, that they become self su, self sustain, self-sufficient, then I’m like, great. Right. 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, you know, these people are not worthy and, and they need to come to me because I’m the expert of the room.

And that hero mentality I think is one of the problems we have. The, what I do with a team when I’m starting off with them is, uh, I use a technique called T skills. So we identify the skills we need within a self organizing team to be successful. Um, so, you know, in the data space there are things like, how do we understand the data requirements?

Uh, how do we write tests? How do we model the data? How do we write the ELT code that changes the data? How do we deploy that code? So there’s a whole bunch of skills, uh, which kind of relates to the work that needs to be done. We then get each of the team members to rate themselves, uh, for each of those skills, uh, based on their literacy, right?

So we get them to physically draw a line where, um, the page is broken up into four sections and they say, Novice practitioner, expert in coach. Do you wanna 

Murray: explain alt, 

Shane: uh, extract, Load and transform? So what it means is we take data outta something like Salesforce, we drop it into a database like Snowflake or big, and then we write some code that changes it in the database to do what we want.

So once the team have mapped out their T skills, right, so the skills they have and the level of literacy they have, we overlay. Right as if they’re transparent and we look for gaps, right? 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, uh, areas where we don’t have a lot of double ups, 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 and those skills in the literacy unset team, 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 architecture 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, and I’m gonna, 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. Yeah. Right. But my goal is to make yourself sufficient, not be the gatekeeper that tells you you did it wrong.

Murray: Right? Yeah. I like, I like that approach. I, I agree with that approach too. I’m a bit, I’m quite worried about the hero model. Um, but there is this, there is this concept, um, that, uh, you know, all this, all this agile stuff is about process and it’s really irrelevant because you just need to get a group of experts together and they’ll just do it, right?

Cause the expert architects will, will think 12 months and three months and, you know, 10 feet like 

Shane: sprint. Have you ever, have you ever sat in a room of expert architects tend to 

Murray: rabbit on about abstract concepts. 

Shane: So, so what we say is what is a, what do you name? A group of architects and it’s called an argument of architects, right?

if we ever get in the room together, we argue semantics. In fact, I’m doing a presentation on that thing next week. Um, so yeah, a team of experts don’t work. And there was, uh, there’s a scenario and I don’t, I read it and I use it a lot when I’m coaching, but I don’t actually know where it came from, right?

So I dunno if it’s a made up scenario. It’s actually true, but the scenario goes, if you took the best soccer players from every team in the world, if football players and put them into a team, Yeah. Um, they’re not gonna perform as well as a team of players who, um, have been playing together for a long time and still have good skills, right?

Because it’s the team forming and norming, installing, and all that good stuff that makes them efficient and a team of experts doesn’t mean you’re actually gonna get there faster or safer. And in my experience, coaching teams, Yeah, I’ve, I’ve seen that. 

Murray: I, I think that the, um, the expert, whether they’re an architect or a user experience architect or designer, um, needs to do what you said, coaching, training, mentoring, capability building.

But they also need to be able to paint, help the team paint out the big picture, because the team just may not have the awareness or understanding or experience of, you know, a range of different possible solutions. So I’d like to see them do both. I, I would, um, I would want. An architect I’m working with to, to help me map out the big picture as well as capability building.

Shane: Yeah. And so let’s, you know, let’s not beat up on architects. Let’s look at what good looks like. And for me, you know, an architect sitting with that team going, have you thought about right? Is a really good way of them engaging with the team to help the team understand they probably missed something. Um, you know, an architect saying, There is a pattern that looks like this.

Do you think if you applied in that situation, um, it’ll solve that 

Murray: problem? Well, you could. Well be working with a group of people who just don’t understand the patterns. Yeah. And it’s quite common you think you people build up their experience over time, as you said before. They go from novice to what was the, what were the stages?

You 

Shane: had a novice practitioner, expert in coach. 

Murray: Yeah, so this is a bit like the Sari model as well from Elster, Coburn from martial arts. Um, like if you’ve got a novice or even a practitioner, I, I think a lot of practitioner developers don’t really understand the frameworks. They’re, they might understand the current framework they’re working with moderately well, but they just don’t understand other frameworks and other patterns and they probably don’t, might not even understand the concept very well of patterns.

Shane: I think also, um, going from expert to coach is really hard because what it requires you to do is to take your expertise and then be able to articulate it in a way that you can coach somebody else how to do what you do. Um, and that’s hard, right? To take things that you have unconsciously done for years and you are just good at because of that experience and your skill.

And then be able to articulate it in a way, And I’ll give you an example. When we’re doing this app development, we started down the path of design systems. Mmm. Um, and it took me ages to find somebody that could actually explain what a design system was. I started off pinging on my mates going, Hey, we we’re doing some app development.

Can we, um, grab a copy of your design system? Cause I wanna apply it. And they just laughed at me and I was like, Well, 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, uh, a design system is for, uh, for a ux. Um, so again, right, that ability to take your expertise and articulate it back to other people in a way that will make them more literate is a really hard thing to do in my experience.

Murray: Yeah. I, I think that the, the experts need to think of themselves as consultants. Who have coaching as one of their, um, approaches. Right. And I say that because I’ve been encountering quite a few coaches, um, who will only, um, Asks Socratic questions or engage in a kind of therapeutic approach. And some of those people, as it turns out, don’t have the experience to contribute anymore.

And that’s kind of why they’re taking that approach. Um, but I want, uh, say if I engage in 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, they can ask Socratic questions and they can, you know, mentor people individually, but they can also do the work if that’s needed, like in a particular area.

Or they can, they can teach, they can train, they can mentor. The difference between mentoring and coaching is that, um, Mentors offer possible solutions based on their experience, whereas coaches don’t offer solutions according to the International Coaching Federation. So, um, I, I, I want somebody to take a bit of a broader approach where their expertise is available as well.

Shane: So, Sorry, 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. Um, cause I can go down a big rant about, um, the number of times I’ll work with a team and the scrum and the team will asked the scrum master something and the scrum master will reply with depends, and that does mine up.

Um, so they shouldn’t dictate what next, but they should at least provide some guidance and options that coaching thing’s really interesting. Right, because. If I think about the coach of the All Blacks, you know, the world’s best rugby team, um, I don’t get the impression that the coach of the All Blacks is, is not providing any guidance.

Right. I, I just, I. 

Murray: No, I, I agree. I agree with you. My model of a coach is the sports team coach, you know, Um, they’re, they’re adding a lot of value and guidance. They’re not playing the game or kicking the ball, but they are, um, or passing the ball with the rugby. They are, uh, but they’re, but they’re providing a lot of, you know, help and strategies and guidance as well as, um, so other people can do it.

But there is, there is this strong trend in the agile coaching community at the moment to say that a, a coach, Is very different to a sports coach. An agile coach is not a sports coach. An agile coach is more like an executive coach, which is to say 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, you know, make their own choices.

But you don’t provide any, um, any suggestions at all. And it does my head into, I think it’s just a really low value. 

Shane: I think it’s, um, about balance, right? So, uh, one of the, so I’m a great fan of, um, Bob Galen and, and, um, his podcasts. Yeah, you probably know. Um, and a while ago I was attending some meetups in New Zealand and, and we started going down, well the group started going down this whole thing of ethics for an agile coach.

Um, cuz you, you know, from, I dunno if you agree, but it seems a bit wild west out there in terms of, um, who can call themselves a coach and, and what’s acceptable for coach to do or not. Yeah. And you know, I could see that, you know, some coaches believe they were life coaches and some were coaches believe that, um, you know, you should be very clear that if, if a person has personal issues, Um, as an agile coach, you, you, you can’t go there because you don’t actually have that training, right?

You, you don’t have any of that ex training or experience. Uh, and you could, you could do bad, right? You could, you could, uh, damage people effectively if, if you do it badly. And so as a result of that, I looked around and, and Bob actually had, um, uh, a, a code of ethics that he publishes, gives his customers, um, 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. And so I think, uh, that’s important, right? Um, I think. The ability for say, these are my skills. Right? And so if you are come from more of a life coaching, uh, saying, Hey, I’m more of a life coach than a, um, domain expert, right? Um, and that’s okay, as long as that’s the expectation between you and the people you’re working with.

Um, but again, I see very few agile coaches that actually have that, that charter. You know, we teach our teams start off with a team charter, right? Um, 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, their customer or their team on day one?

Um, sure that there’s, 

Murray: there’s, um, there’s this, uh, consulting model which came from a guy. Douglas Champion and a couple of others, Champion Keel and McLendon from the mid eighties, which, which suggests that there are nine possible, um, 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.

And, um, people have rebranded this as an agile coaching stance now, but basically you could be an observer and just watch people do it and then, you know, provide feedback later on, like a, like a report on, on what you thought. You can be an advisor who answers questions. And you can be a hands on expert who’s doing it.

So those first three are, are all where you don’t take much responsibility for growth of the team, but the hands on expert, you’re actually doing it. Right. Um, going up a level, you could be a facilitator, a teacher, or a mentor, which is starting to take responsibility for their growth as the team’s growth.

And the top level you can be, uh, a visionary, a coach or a partner. So I, I want a, you know, expert in architecture or design to be able to just use all of those approaches, um, not just the, you know, kind of therapy approach that some people take. So 

Shane: I think that sounds like a great framework. I think let’s put a link to that in the show notes.

And, and I think just to close it out, yeah. 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, you know, your literacy in each one of those and what you’re good at and how you can help and where the gaps are, right. So that, uh, everybody’s clear on, on the value and what you’re, what you helping and what you’re helping.

That’s the important message. 

Murray: Now we do a little bit of a summary, Shane. We started talking about evolutionary design and the problem with just a very narrow focus, like a two week focus leads to all sorts of problems. And then I think we talked about different, 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. Um, the importance of having roadmaps but not fixed roadmaps. I think we, we very clear on that they provide you direction, but you change your roadmaps as you learn. Um, and then we started talking about, um, the kind of centralized teams and the role of the architect, uh, which I want distributed, but we can talk about that more another time.

Um, and then we went into quite a big discussion about the role of the expert. If you are, if you are the expert, architect or the expert designer, what, 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 guess my point was that I also want, um, The expert to, to help me get results for the client.

So I want ’em to do both, both build the capability of the team and get results for the client. And that can, that can mean that they’re, you know, on the field as well to some extent just when it’s needed. 

Shane: Yeah. So, so for me, that’s where I, I go back to the literacy model that I’m comfortable with, which is if you’re at that expert level, then you, you can be on the team, right?

You can be on the field. That’s okay. Yeah. When you get to the coaching level, you typically shouldn’t. Because your whole focus is changing from getting the thing done to teaching other people how to do it as well as you do. And I think that that’s a big jump, right? I mean, we all, we all have to sometimes do things, um, because they just need to be done, but your focus should be coaching that team or many teams to be as, as much of an expert as you are.

Murray: Well, if we are going to, to become those coaches, then, then I want the, those people to be sports coaches. So, um, they are, you know, doing a lot of strategy planning with the team, even if they’re not on the field. Yeah, Yeah. 

Shane: And you know, again, Park it for another podcast. But this idea of, um, if you are the product owner for a product, should you be a domain expert or can you be a professional product owner for something you have never done before?

Uh, same question for an agile coach. Should you have least have played on the field of the team you are coaching? Uh, or is it okay to come in when you’ve never played that game? Right. So some good questions when we talk about, uh, those kind of things that we, we can cover in another session. I agree with you.

Uh, we do tend to start somewhere and end up somewhere else. . I still always feel like we kind of got there in a natural way, but yeah, sure. I like the way you summarize this one up. So thank you for doing that. 

Murray: That’s so we should close by a, uh, let’s keep real. Excellent. Next time. All. Thanks. That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson.

If you’d like help with Agile contact Murray, that’s evolve with the Zero. Thanks for listening.

 

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

Murray: And I’m Murray Robinson. 

Shane: Hey, Murray. Good. See you again. Uh, it’s another, another podcast, uh, day. So always looking forward to these days. Um, I think we’ve decided today we are gonna talk about something which you call evolutionary or evolving design and, and, which I call agile architecture.

Murray: Yeah. Well, let’s talk about, um, evolutionary design or agile design, if you wish. 

Shane: Yeah. Well, what you started from, from your domain and what you see and how you, uh, how you make it work. And then I’ll jump in from, uh, my data and analytics architecture kind of view or, or terminology. 

Murray: Sure. So, um, I was first exposed to, or first did Agile back in 2004, and, um, I read XP explained by Kent Beck, and that’s what we tried to implement.

And in there he talks a lot about you ain’t gonna need it, which is, um, one of the key rules. And the idea is, and then the other one is the rule of three, which is basically the idea is that you, um, you just code a solution for the immediate small story that you’re working on, and you don’t worry about reuse at all.

Right? You, you have, you know, automated test cases and things. I’m very concerned about that, but you just focus on the now. And the reason is because there is an enormous amount of waste supposedly. In, you know, designing things for a future that may never happen, which makes a lot of sense. But then if you find that you’re working on that code module a second time, then you might, um, you know, you, you have to change it a bit for a new, new feature or change in rules or something.

And then the third time, then you restructure it to make it, you know, modular and, you know, uh, more abstracted from an architecture point of view. So, but apart from that, the idea is that you avoid any bigger architecture or design decisions on the basis that. It, uh, is probably not needed or you don’t really know what it is, you, you’ll probably get it wrong.

So, um, this also has carried over. It’s become a very big part of Scrum, I think. Um, Scrum is really has this idea of, we just focus on the current iteration. Um, we, we design and build in the current iteration, usually two. Um, we do groom the backlog of course, and, you know, maybe there’ll be a bit of discussion about how you might solve something in order to estimate it.

But I think the idea, if you’re gonna do Scrum by the book, you try not, you try to avoid design conversations when you are grooming the product backlog. So I have, I’ve seen this actually, um, go wrong quite a lot, uh, particularly when working with UX designers because, um, it, it makes you take this kind of microscopic focus around buttons and, you know, small code modules and things like that.

And you get a, you get lost amongst the trees. Like you can’t see the forest for the trees basically. And um, I’ve seen a lot of really fragmented. User experience design, which comes out of just this constant, very short term focus and UX designers and UI designers complain about it constantly to me when I’ve had them in my teams.

Um, and, uh, because they, they work on a bigger picture level, right? They work at the level of user experience and user flows and user journeys and pages. They will argue you can’t design a button, buttons or part of a form for a page unless you know what the whole page is. And you can’t really even design the page unless you know what the user journey is and the user flow is.

And I think that they’re right actually. I’ve seen bad design come from just this total focus on the micro decisions. Um, so my, but on the other hand, I’ve, I’m saying, You know, I’ve, I’ve run projects, uh, waterfall projects in which there was three months of requirements, three months of architecture, you know, months of design and months of technical design before you ever build anything.

And then, you know, a lot of that stuff ends up being wrong and wasted and, um, you know, you really miss a lot of things. You only find them out during development. So I, I think that there’s a place for evolutionary design, but it needs to sit somewhere in the middle. So I think about a chain as, um, different time horizons.

We’ve gotta have a big picture, you know, a medium term and a short term. In the short term is the, is the sprint. And so you don’t want the big picture too detailed, but you want it kind of blocked out so that you know what context you’re working in. When you’re making micro decisions during a sprint, what do you, what’s your view on it?

Shane: Yeah, so I think, um, actually I can, I can take two lenses on this. Um, primarily, you know, the data analytics space, we’re on coaching teams, uh, in that domain, on, on how to change the way they work. Um, but also with our current startup, we’re actually doing some application development. And that’s given me an insight into some of the things that you are talking about where it’s more active than, um, data.

Um, so from a data and analytics point of view, uh, yeah, I started off on that same journey as you different book. Um, but the idea that we could do what I call build the airplane while we’re flying. Um, so, you know, we didn’t go in and do any architecture design at the beginning. We basically started off with, with the squad or the team for, to start the work and we were.

You know, starting from nowhere, uh, and trying to design the architecture at the same time as implemented and, and build it. And in the data world, that seemed to cause us a major problem. And over the last couple of years I’ve been ruminating on that. And, and what I think it comes back to is in the active world there are, uh, a bunch of, of known paths.

I call it. There are a bunch of patterns. There are a bunch of architectures or design things that, you know, work together. Um, and therefore you can pick one of those cuz you really without a lot of effort. Whereas in the data and analytics world, we are still not at that level of maturity. We’ve still got 101 different choices, all giving us massive consequences.

And, um, so what we tend to do now is I recommend. What I call agile texture, which is the idea of, like you said, using time horizons. So at the beginning, we should take a piece of paper and we should draw some big rocks, right? We should make some decisions. Um, and they should be the big influential decisions that will have a massive impact if we change our mind.

Um, and we should draw those down on the picture and say, that’s where we’re gonna start from. And then as we’re building things out, if we are changing something within one of those rocks, within one of those boxes, and that’s okay, right? Cause they’re just boxes. They don’t have a lot of detail in them yet.

So that’s fine. But if we are starting to make a change that looks like one of those rocks is going to change, then we, we should be aware that there’s probably a whole lot of change impact that’s coming in some of the other spaces. And therefore the cost and time of making that change will be bigger than we expected.

And then we need to kind of go through and reiterate that agile texture again to say, Okay, well we, we are making that change. What’s the impact? Right? Um, yep. The other thing I find is, is drawing that picture, doing that wireframe architecture helps the entire team, uh, understand what we think the future state might be.

It, it’s, it’s a picture, it’s something, you know, we can wave our hands and use the word and say words as much as we want, but as soon as we draw it in a really light way, um, it seems to get the message across better of what we’re aiming for, and then allows any of the team members to identify, um, when one of those changes is gonna be massive.

So if I compare that to, as we are building out this, this app right at the moment, um, We had to make some, some decisions from a architecture point of view for that, where, um, we had to decide what we’re gonna build the front end, you know, what we were gonna build the back end and how were gonna make those things talking.

And we actually changed it quite a bit. So I, not coming from an active background, I, uh, phoned a whole lot of friends and, you know, worked out that I could go down the React path or I could go down the, whatever the other one was. Um, and then slowly worked out that actually that design decision, that architectural decision, actually impacts the people we hire.

Yeah. Um, because we now hire, you know, if we went react, we have to hire specialists. Um, and then we actually started off experimenting with a, a front end capability and a thing called flutter. Um, and. 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 and it’s life cycle to be safe for us. So we then ended up moving on, um, a front end technology called, which again was early in its life cycle, but was a little bit more mature. And that’s what we’ve gone with. Now, that’s a big rock, right? If I decide to go from still to react, there’s a massive amount of cost and change that I’ve gotta incur there is.

So I have to actually potentially retrain my whole front end team or find another one I have to rebuild on my components or Portland. So for me, that big rock, it doesn’t mean it’s never gonna change, but if we do decide to change it, then the cost and consequences that change are quite large. So it has to be a really well thought out decision, whereas.

If we decided to bring in, um, you know, one of the CSS kits that were felt compatible to make us a little bit faster when we’re building some of the widgets, then um, that’s fine. That’s a small change within the rock and that’s okay. 

Murray: Um, so you were talking about, um, big rocks, Shane, and I agree with you. I think that, um, you’ve got some technology choices, um, that you need to make early on, and they’re going to have a big impact on to direction you’re going on.

So what I would be doing is prioritizing those very early for exploration so you can, um, uh, understand the risk and understand the doability of the technology. We actually, I think we covered that, um, during the, the initiation piece we talked about last week. I’d be, I’d be saying that the purpose of that first two weeks or so, Has gotta be from a technical architecture point of view to understand the kind of platforms and components that you’re gonna use and explore them to see if they’re going to work.

So you, you’d be saying, I think this, I think that, I think flatter or what was the other one Still? So, so I would, during the first two weeks, I’d want to have the technical leaders in the, in the team exploring those and trying to do some point to point integrations to see, you know, which one is gonna be best.

And, um, then we’d start with, with one of them. But, um, What did, how far did you get before you switched over? 

Shane: Um, from flooded to film? Yeah. Uh, it was pretty quick because our, our app is designed primarily to work on a, on a large device, right? It’s not designed for a cell phone, a smartphone. And as we started to experiment with it, we worked out that Fluter was very much designed to build native apps and not built to, to be on a browser, on a desktop or a laptop.

Um, and it was coming, you know, it was in the roadmap for that product. Um, but after, you know, a wee while it was pretty clear it wasn’t at a priority for them. Um, So at that stage, you know, we then knew it wasn’t gonna meet our need. It wasn’t, you know, um, 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 coding with No. Okay. So that’s good. So did you, did you do that deliberately? Like, did you deliberately explore, focus on exploring the, the potential issues with Flatter before you went on and too far with 

Shane: it? Yeah, we did. We were also lucky that, um, for a whole bunch of reasons we were executing as fast as, as we wanted.

So, you know, if we were actually running pretty quick, um, we would’ve had to make the decision a lot quicker. Um, so we had some natural delays that, uh, were in hindsight lucky. Yeah. Whereas was felt we pretty much started straight away using it in anger. And so, um, again, if, if we got, you know, a couple weeks down the track and worked out, it wasn’t the right.

Then we’d have to go and, uh, take another, you know, look at our roadmap or our blueprint and go, Okay, we’re gonna have to go change. Uh, how do we figure out what the next change is? 

Murray: I think that is, that is the big advantage, Shane, I think of an evolutionary design approach because if I was doing a waterfall project, you know, we would’ve spent nine months maybe with and, and maybe a million dollars going down an architecture path, assuming that it was gonna be flutter, and then everything would’ve been designed with flutter in mind.

And then when we would’ve only discovered after the development team started that it didn’t give us what we wanted. And probably they wouldn’t even tell us because they would keep trying to make it work. And so you’d be well into development before you realized you had to change. And then it would be, you know, it’d be a really big problem at that point.

Shane: I think the other thing as well is that, um, you know, we, we have always designed with our architectural rocks being loosely coupled. Yeah. We’re designing as much as possible that we could remove one of those rocks and replace it with something else and you still be a cost and a consequence. Um, but we’re always architecting so that we can do that.

So, you know, in that scenario, our backend didn’t need to change, uh, the way we, our front end talked to 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, we figure out how we are gonna store the data right into which type of technology, which modeling technique we want to use.

Um, and if we take that scenario, you know, it’s always possible to change our technology. We are storing the data and without changing our modeling technique. So’s possible to change our modeling technique without changing our technology potentially. Right. So again, that loosely coupled architecture is really, really important when you are using a intru development process.

Sure. 

Murray: So how are you, um, getting a loosely coupled architecture? 

Shane: So I think it’s primarily in the thinking when you define that architecture mm-hmm. , right? You, you’ve taken it from the principles of everything as loosely coupled, um, and then. Again, go back to proven paths, right? There are proven paths of technology components or architecture components that naturally work together in a decoupled way.

Um, and so if you’re adopting one of those is, is what I call your blueprint. At the beginning, you’re relatively safe or certain that it’s gonna be okay. Cause you know it’s been done before you’ve ever done it yourself, or you’ve talked to lots of people that give you that confidence. You still need to test it, right?

You still need to be aware that something might be different in what you are doing. Um, but when you’re introducing something that’s unknown, right, where you can’t find anything, that kind of reference of being used regularly, and that in that way within, within your arch. Um, or you can’t really get any confidence that other people have done it that way, then you know you’ve got risk, right?

And that’s when, you know, as we talked about in the initiation podcast, that’s when you’ve gotta go and do those research spikes, right? You actually have to go and spend time to explore, um, whether it’s safe carrying on that way and, uh, or not, and then make the change. So I’m a big fan of blueprints, um, and, you know, blueprints that other people have done that are proven, uh, reusing those patterns, I think’s a good technique when you’re starting from scratch as well.

Murray: Yeah, I, I do too. I think that there’s a lot of patterns out there that you can, you can use and, um, uh, like user experience, designers do that. They go to websites like Dribble and other places where there’s, they can see. Examples of other people’s work, and most of it, um, really from a UX point of view is just trying to work out what the best practice is and, and applying it.

So they’ll go and look at competitor websites and um, you know, look at user flows and then they’ll map things out. But, um, I think there is a, there is a big advantage in mapping things out in the big block level, um, to provide context for everything else you’re doing. So I would say map it out at the big block level, you know, maybe a 12 month view, and then pick like the first component you’re gonna work on.

Like map that out in a bit more detail. Maybe a three month view. You know, we’re not talking about writing big documents or anything. I’m just talking about whiteboard stuff, you know, And if you need to record it, you take a picture of it and you put it in Jira or whatever you’re using, who knows? Um, and then, you know, or you put pictures of it up around the team room or, uh, say people can refer to it at, so that when they’re making their decisions within a sprint, they know what the context is.

And I think that context is very important because there’s, there’s constant small decisions all the time that the team are making, both with their, you know, the technical solution and the user experience solution. And they, they could, if they don’t understand the context and the direction that you are, you are, you are going in, they could easily go off in another direction, which.

Maybe solves the short term, short term solution, but causes a lot of problems in the longer term. And that’s what I’m a bit worried about with, with Scrum, that um, people do just seem to talk about taking a very short term focus all of the time. Now, when I’ve had, I’ve had pushback on this from scrum trainers who say, No, no, that’s not right, because there’s a product backlog and you know, the product backlog contains everything that you wanna do.

And it has its big rocks for things that are far apart, far away, and small rocks for things that are close up. But, um, I really think that there’s a lot of discouragement of any design work being done at all during that kind of backlog. Grooming, as it’s called. It’s really all just about trying to identify what the, 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. I would say that this sprint, we can have some technical spikes, but, um, because they don’t deliver immediate business value, you know, it better be for something we’re gonna be building next sprint.

And that’s about it, 

Shane: I think. I see, uh, yeah, from a Scrum point of view, I often see a, a patent, which is called the Three Amigos. Um, so yeah, again, it’s, it’s the balance of, uh, Of how you are working. That’s important. So when I see the three amigos happen, when I see it happen, well in my view we have the product owner, some form of be type skillset, some form of technical called lee type skill.

So sorry, experienced, right? So an expert or a coach level within those skills. And those three roles work together, Those skills work together slightly ahead of the the Scrum and they’re doing very light mapping of some stuff to be able to walk into the backlog grooming with more sureity. So, You know, they’re identifying the proven paths where they know things are relatively or should be relatively safe, and the areas where there’s a high level of uncertainty and a research spike is probably a good idea.

Murray: Yeah, but it feels like that’s an addition to Scrum, though. There’s nothing about that in the Scrum guide. That’s a kind of No, 

Shane: definitely, and, and you know, I’m, I use a lot of, Sorry, I, 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. Yeah, good. Um, so, so I’m very opinionated on some words like the one that you just triggered with me a little bit before about best practice. Cause I call bullshit on best practice. , I believe there’s a thing called good practice, right? Which is in a knowing context, with a knowing problem, there is a bunch of things other people have done and if you adopt them, it’s gonna make you faster.

Right? They’re good, they’re good practices, just do them. Unless there’s a reason not to, but best practice is, is you know, those consulting firms trying to say really there is, uh, one way to do it. And, and I don’t believe that. I mean the other trigger word you use with Jira, but I won’t there, 

Murray: let me respond to your best practice.

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

Shane: Cool. Right. So we’ll use good practice from now on and we’ll call bullshit on each other. If one of us, Reg Reeses, what 

Murray: was the other thing that you, that triggered you? 

Shane: Jira, but we won’t go . 

Murray: Oh yeah. I’m a Jira administrator.

Shane, I’ll, I’ll set up your Jira for you . Yeah, 

Shane: thanks. No worries. Anyway, so, um, so yeah, so Three Amigos is not outta the scrub guide. Um, but I’m okay with that. Now, there is an anchor 

Murray: there because Scrum is not the whole of Agile. I think we should say that. No Agile. You can do Agile without doing Scrum at all, which is pretty shocking to a lot of people, including some Scrum trainers I’ve spoken to.

Shane: Yeah, I mean, I talk about adopting an agile mindset, right? That’s, and we’ll talk about what that means to an architect actually, cuz that’s a really interesting conversation. Um, when I come back to Three Amigos. Yeah. Uh, 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 and detail outside of the team rather than giving them a quick start. Some, some guide rails. But aren’t those 

Murray: three me guys part of the team though? 

Shane: Yep. Ideally. But sometimes we’ll see um, three Scrum pods and one set of three Amigos, right?

Those three amigos become really busy cuz now they’re trying to keep ahead of three pods of people that are Scrum, you know, teams that are working. So, um, again, I, I think one of the things I like about the scrum guide is it provides some good practice stuff that you can read and understand. Yeah. And then when we start talking about patterns like the three amigos.

There’s, uh, more random literature about, you know, good practice when using that technique. 

Murray: I think that might come out of xp actually. It sounds quite familiar. 

Shane: Yeah, it could do. Uh, again, I read it somewhere and I can’t remember where. Um, there’s 

Murray: a lot of, um, XP practices, um, like gives are stories, for example, that’s not in Scrum.

But I, I think that, uh, you know, there’s an argument that Scrum without XP is pretty empty. It just doesn’t work. 

Shane: So, you know, you know this bit a more than me, but peer programming came out of xp, not Scrum, right? Yeah. Um, so did, yeah. And Theban board that we use as a scrum board that came out. One of the, you know, the Kaban Lean Track didn’t, it didn’t actually, it’s not part of Scrum.

If you read the guide from Memory, 

Murray: well, Scrum. Just had backlog doing done. And the idea of setting up a CanBan board for that came out of the Yeah, out of the CanBan community. 

Shane: Yeah. But have you ever worked with a Scrum team that doesn’t visualize their work on a CanBan board? 

Murray: You know, everybody does it now and that’s cause and talk like that

Shane: So, And I think, I dunno, if you go on a two day scrum certification, do you get taught. To visualize the flow of the work on a combine board. Yeah, you’re 

Murray: right. It it is all, it is all part of it now, I think, I mean, Scrum has evolved over time, so I, I can’t, I don’t wanna go and look up the scrum guide now to see what it says about visualizing the work, but it probably does say something about it now.

But anyway, um, coming back to design and the, the, the three me guys, I, 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, bigger picture of the, the business processes.

So I think that there’s, that’s four, and it’d be unusual to have everybody in the team being able to do that. These tend to be, you know, more senior people with more advanced skills and ability to look at the bigger. Picture. 

Shane: Yeah. And, and you know, I’ve been crafting the words I use around that for a while now.

So I talk about literacy and I talk about four levels of literacy. So I talk about a novice, a practitioner, uh, an expert and a coach. And that’s only because I used to use the word master and I used to use the word journeyman. And I’ve, I’ve purposely gone and found words I’m comfortable with to remove those words outta the vocabulary.

Um, and I, I, just thinking back, I regress as I was talking about the three megos. Cause I was talking about a technical lead, and I’m purposely trying not to use the word lead because that in fears a hierarchy, not a literacy. So I should be using the words, somebody that’s technically competent at an expert or a coaching level, right?

That’s the level of literacy you need. You need those experienced people. Um, I think the other thing that, uh, we wanna talk about is, In an enterprise organization, you know, especially in the data and analytics space, we end up with a team of architects. So where do they fit in? Um, and one of the other podcasts I listen to, they, they have this saying they use on a regular basis, which is, the breaks on your car aren’t there to slow you down.

The breaks 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’re 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. So as long as they’re within those boundaries right 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. Uh, and I take it back, you know, visualizing your work on a car bar board Makes sense. Yeah. So if you’re not gonna do it, let’s have a conversation cuz it just seems like a good idea.

Yeah, 

Murray: sure. So I’ve, I’ve worked, uh, for, you know, a big telco and some other places that had enterprise architecture teams and, um, there was a lot of good people in those teams. I, I, uh, had a lot of respect for their skills, but, um, Quite a few of them had stopped coding some time ago, and it all become quite theoretical.

Um, and the ones who had I had the most time for were the ones who could do POCs and, and you know, would still get their hands dirty. I think that makes a big difference. 

Shane: Um, so you’re talking to somebody who can’t code, Right. Um, or won’t code, but I do have a technical background. Um, but my view actually is the world’s changed and the architecture practice should change and.

If you think about the idea that you are 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 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.

Sure. So rather than inventing it, we’re kind of copying what’s good from all the stuff that’s happened and then describing it in a way, like a scrum guy that somebody can read and go, Oh, that makes sense. I think I’ll just carry on doing, I’ll do that. Um, because it’s easy and it looks good, and why would I invent 

Murray: something?

Yeah, it works. Yeah, I agree. So, So that makes a lot of sense to me. I have a, 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, you are all got all these problems.

Do you know what I mean? I’ve had that situation where you there architects in a different group and they just don’t take responsibility cuz they’re not involved anymore. 

Shane: Yeah, I, I mean, you know, and if you’re a consulting architect where you’re on contract, right? That’s a great way of getting another, uh, bite of the apple.

Um, I I think ideally we want those architecture skills embedded in the squats, Right. In the teams. Yeah. But that’s hard sometimes We have a separate architecture team, so it comes back to, uh, the way the two groups engage. Um, the architect should be coming along and constantly looking in, um, should be attending demo days, right?

They should be potentially coming along to a couple of the standups just to have a listen to 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, if they are outside their team, when they know there’s a decision that needs to be made that is outside the, the good practices they have been, um, suggested.

So to me it’s no different than a product owner, right? A product owner is, is involved with the team as much as they need to be. I mean, 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, uh, the idea of having somebody who’s a, an expert, who, who’s working at a, maybe a more abstracted level across a few teams, as long as they’re still really, um, quite involved in supporting the team. So what I would do is, um, if I was doing a, a project plan with resource allocation, Shane, I would, I would allocate an architect to the team, some percentage of their time all the way through, right?

Either that, either that or not. Have an architect just make the, the mo the technical leader, the 

Shane: architect, uh, you, you’re going on wind up with today. Um, So another, Yeah. I often talk about, uh, yeah, Agile being a mindset, right? Uh, where we adopt some approaches and patterns that other people have decided have worked out a good to make us faster.

If you think about an architect, one of the mindsets that I believe in architect needs to make, uh, might change, they need to make when we’re we’re adopting an agile way of working is who their customer. And in my view in world, the teams doing the work is actually the customer of the architect architects is to make those customers be able to go faster, safely.

And when we do, We go, Well, yeah, an architect should be involved with those teams because they can add value, right? They can identify things that the team may or may not be able to identify when they’re working on that problem because the architect may have more literacy, more experience in that domain, or just that ability to be, to step back and look at it from a higher level and not be down in the we is often valuable.

So, yeah. Yeah. Where those architecture practices exist and you don’t wanna change it, then the, the way they think of themselves not being in their ivory towers, uh, but actually been. Somebody who enables those teams as their customer to be more effective. Yeah. Is really where we gotta 

Murray: go. I think, um, organizations, 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 and builds up expertise and capabilities.

So you have these centralized UX teams, centralized architecture teams, centralized up, you know, uh, I was gonna say DevOps. That’s tends to be what they call themselves now, but deployment teams and so on. Um, and I think that that’s a real anti patent, that that creates a lot of dependencies and creates a lot of problems, a lot of handover problems and so on.

So, um, when I’ve reorganized, you know, a, a larger organization, you know, with say 50 plus people, I, uh, tend to break those teams up and I allocate people to the, um, To the scrum teams or whatever you wanna call ’em, the product, I like to call ’em product teams. So I allocate the experts to the product teams as much as possible.

And I’m, but I might say, cause you are an expert in this thing, you are, you’re gonna sit with this team or, and you’re gonna be 50% supporting them, but 50% supporting everybody else and providing coaching and mentoring and training. I think that there’s a lot of problems, a lot of serious problems with the kind of architecture team, the design team.

It’s a very much a waterfall concept and, um, it, it just doesn’t work very well. I think the’s, a way of doing it is to distribute that expertise amongst the teams and then provide them with an alternative kind of matrix structure where you still have them getting together and still talking and sharing information, but it’s not a.

Um, ivory tower at all. 

Shane: Yeah. And I think, um, yeah, we, we’ll need to pick this up in another podcast around the idea of centralization versus decentralization of teams and skills. Um, because I think that those decisions have a, a massive impact. And the more you decentralize and let the teams be self-sufficient, the less you should control or provide standardization across those teams because you are trying to mix your toasties, right?

You, you need to pick some rocks and they have consequences. Um, but let’s, let’s cover that. When we go into the old, you know, cross functional teams, what does that actually mean? Centralized capability for some things versus others, And back to that factorization that you talk about, where we treat. Um, scrum teams as if they’re working in a factory.

Um, yeah, cause that’s a really interesting conversation, but I, I agree with you. I think, um, there are some areas of organizational behavior that are hard to change and adapt when you’re taking an, an agile way of working. And, uh, the architecture part of an organization is one of those. 

Murray: Yeah. It’s the same with the user experience design group.

They, they tend to be, not always, but they tend to be very precious, very controlling, very much into empire building in, in larger organizations. Anyway, that’s what I’ve seen. I’m sure they don’t have to be like that, but um, it does tend to be that way. 

Shane: Yeah. I mean, I don’t do a lot in that space in, in enterprise land.

Um, again, if I take it back to our startup, um, you know, we’ve got one person who looks after the UX design for us, with us. Um, I am one of the worst product owners in the world in terms of, um, being able to clearly articulate what I want and the acceptance criteria. Um, and so therefore, for me doing a whole lot of work upfront on the, the flow across our application from the beginning to the end didn’t make any sense because there are whole chunks.

There are big rocks in there where I don’t actually know how it’s gonna work, Right. I know what I need to achieve, but I actually have no idea cause I don’t have the experience of kind of what I want. Um, so, you know, we approached it at the beginning we’re we’ve a very ad hoc, un groomed requirement or approach.

What’s happened is we’ve started to evolve that a little bit where again, we’re, we’re. Drawing on a big pace on a piece of paper. Big piece of paper, Lots of big rocks, Yeah. Mm-hmm. . Um, and then when we get to the rock, we deal with what’s in that rock. But if any of those rocks change, um, then from a UX point of view, we know there’s a massive amount of rework, right?

Because we’re assuming each of those rocks is a thing that will actually happen. So again, I think it comes back to that, that idea of agile architectural, agile design a little bit upfront, because you need to have that vision and, 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. I like to think of it as, you know, looking at things from like a, you gotta have a 30,000 foot view, you know, a 10,000 foot view and then like a 10 feet view. And, um, but you, the thing is, you don’t wanna be really detailed in your 30,000 feet view. What about then the idea that, um, experts are critical.

Um, there’s a lot of people who can’t do design and so therefore we need to make sure that we have an expert architect available to every team. And then that, uh, person really sets the direction for the team. Cause they’re the ones who who knows how to do, you know, knows, understands the big picture. It, it’s what I would call the surgeon model.

You know, there’s this idea in hospitals that the surgeon is the one making all the important decisions and everybody around them supports them, like the nurse and their anesthetist. And so on. And I was talking to somebody the other day who, who was very much railing against incompetent developers and talking about, um, you know, how important it is to have an expert to make these decisions.

Cuz otherwise you could go down some very bad, um, paths. 

Shane: So, so there’s my perfect example of, uh, non agile architecture thinking, right? So if you had said to me, um, the problem the person had was they had a new team, the team had low level of literacy in, in some of the areas and they were really struggling on how they could coach and mentor.

Those people to come up to a level of literacy, that they become self su, self sustain, self-sufficient, then I’m like, great. Right. 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, you know, these people are not worthy and, and they need to come to me because I’m the expert of the room.

And that hero mentality I think is one of the problems we have. The, what I do with a team when I’m starting off with them is, uh, I use a technique called T skills. So we identify the skills we need within a self organizing team to be successful. Um, so, you know, in the data space there are things like, how do we understand the data requirements?

Uh, how do we write tests? How do we model the data? How do we write the ELT code that changes the data? How do we deploy that code? So there’s a whole bunch of skills, uh, which kind of relates to the work that needs to be done. We then get each of the team members to rate themselves, uh, for each of those skills, uh, based on their literacy, right?

So we get them to physically draw a line where, um, the page is broken up into four sections and they say, Novice practitioner, expert in coach. Do you wanna 

Murray: explain alt, 

Shane: uh, extract, Load and transform? So what it means is we take data outta something like Salesforce, we drop it into a database like Snowflake or big, and then we write some code that changes it in the database to do what we want.

So once the team have mapped out their T skills, right, so the skills they have and the level of literacy they have, we overlay. Right as if they’re transparent and we look for gaps, right? 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, uh, areas where we don’t have a lot of double ups, 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 and those skills in the literacy unset team, 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 architecture 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, and I’m gonna, 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. Yeah. Right. But my goal is to make yourself sufficient, not be the gatekeeper that tells you you did it wrong.

Murray: Right? Yeah. I like, I like that approach. I, I agree with that approach too. I’m a bit, I’m quite worried about the hero model. Um, but there is this, there is this concept, um, that, uh, you know, all this, all this agile stuff is about process and it’s really irrelevant because you just need to get a group of experts together and they’ll just do it, right?

Cause the expert architects will, will think 12 months and three months and, you know, 10 feet like 

Shane: sprint. Have you ever, have you ever sat in a room of expert architects tend to 

Murray: rabbit on about abstract concepts. 

Shane: So, so what we say is what is a, what do you name? A group of architects and it’s called an argument of architects, right?

if we ever get in the room together, we argue semantics. In fact, I’m doing a presentation on that thing next week. Um, so yeah, a team of experts don’t work. And there was, uh, there’s a scenario and I don’t, I read it and I use it a lot when I’m coaching, but I don’t actually know where it came from, right?

So I dunno if it’s a made up scenario. It’s actually true, but the scenario goes, if you took the best soccer players from every team in the world, if football players and put them into a team, Yeah. Um, they’re not gonna perform as well as a team of players who, um, have been playing together for a long time and still have good skills, right?

Because it’s the team forming and norming, installing, and all that good stuff that makes them efficient and a team of experts doesn’t mean you’re actually gonna get there faster or safer. And in my experience, coaching teams, Yeah, I’ve, I’ve seen that. 

Murray: I, I think that the, um, the expert, whether they’re an architect or a user experience architect or designer, um, needs to do what you said, coaching, training, mentoring, capability building.

But they also need to be able to paint, help the team paint out the big picture, because the team just may not have the awareness or understanding or experience of, you know, a range of different possible solutions. So I’d like to see them do both. I, I would, um, I would want. An architect I’m working with to, to help me map out the big picture as well as capability building.

Shane: Yeah. And so let’s, you know, let’s not beat up on architects. Let’s look at what good looks like. And for me, you know, an architect sitting with that team going, have you thought about right? Is a really good way of them engaging with the team to help the team understand they probably missed something. Um, you know, an architect saying, There is a pattern that looks like this.

Do you think if you applied in that situation, um, it’ll solve that 

Murray: problem? Well, you could. Well be working with a group of people who just don’t understand the patterns. Yeah. And it’s quite common you think you people build up their experience over time, as you said before. They go from novice to what was the, what were the stages?

You 

Shane: had a novice practitioner, expert in coach. 

Murray: Yeah, so this is a bit like the Sari model as well from Elster, Coburn from martial arts. Um, like if you’ve got a novice or even a practitioner, I, I think a lot of practitioner developers don’t really understand the frameworks. They’re, they might understand the current framework they’re working with moderately well, but they just don’t understand other frameworks and other patterns and they probably don’t, might not even understand the concept very well of patterns.

Shane: I think also, um, going from expert to coach is really hard because what it requires you to do is to take your expertise and then be able to articulate it in a way that you can coach somebody else how to do what you do. Um, and that’s hard, right? To take things that you have unconsciously done for years and you are just good at because of that experience and your skill.

And then be able to articulate it in a way, And I’ll give you an example. When we’re doing this app development, we started down the path of design systems. Mmm. Um, and it took me ages to find somebody that could actually explain what a design system was. I started off pinging on my mates going, Hey, we we’re doing some app development.

Can we, um, grab a copy of your design system? Cause I wanna apply it. And they just laughed at me and I was like, Well, 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, uh, a design system is for, uh, for a ux. Um, so again, right, that ability to take your expertise and articulate it back to other people in a way that will make them more literate is a really hard thing to do in my experience.

Murray: Yeah. I, I think that the, the experts need to think of themselves as consultants. Who have coaching as one of their, um, approaches. Right. And I say that because I’ve been encountering quite a few coaches, um, who will only, um, Asks Socratic questions or engage in a kind of therapeutic approach. And some of those people, as it turns out, don’t have the experience to contribute anymore.

And that’s kind of why they’re taking that approach. Um, but I want, uh, say if I engage in 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, they can ask Socratic questions and they can, you know, mentor people individually, but they can also do the work if that’s needed, like in a particular area.

Or they can, they can teach, they can train, they can mentor. The difference between mentoring and coaching is that, um, Mentors offer possible solutions based on their experience, whereas coaches don’t offer solutions according to the International Coaching Federation. So, um, I, I, I want somebody to take a bit of a broader approach where their expertise is available as well.

Shane: So, Sorry, 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. Um, cause I can go down a big rant about, um, the number of times I’ll work with a team and the scrum and the team will asked the scrum master something and the scrum master will reply with depends, and that does mine up.

Um, so they shouldn’t dictate what next, but they should at least provide some guidance and options that coaching thing’s really interesting. Right, because. If I think about the coach of the All Blacks, you know, the world’s best rugby team, um, I don’t get the impression that the coach of the All Blacks is, is not providing any guidance.

Right. I, I just, I. 

Murray: No, I, I agree. I agree with you. My model of a coach is the sports team coach, you know, Um, they’re, they’re adding a lot of value and guidance. They’re not playing the game or kicking the ball, but they are, um, or passing the ball with the rugby. They are, uh, but they’re, but they’re providing a lot of, you know, help and strategies and guidance as well as, um, so other people can do it.

But there is, there is this strong trend in the agile coaching community at the moment to say that a, a coach, Is very different to a sports coach. An agile coach is not a sports coach. An agile coach is more like an executive coach, which is to say 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, you know, make their own choices.

But you don’t provide any, um, any suggestions at all. And it does my head into, I think it’s just a really low value. 

Shane: I think it’s, um, about balance, right? So, uh, one of the, so I’m a great fan of, um, Bob Galen and, and, um, his podcasts. Yeah, you probably know. Um, and a while ago I was attending some meetups in New Zealand and, and we started going down, well the group started going down this whole thing of ethics for an agile coach.

Um, cuz you, you know, from, I dunno if you agree, but it seems a bit wild west out there in terms of, um, who can call themselves a coach and, and what’s acceptable for coach to do or not. Yeah. And you know, I could see that, you know, some coaches believe they were life coaches and some were coaches believe that, um, you know, you should be very clear that if, if a person has personal issues, Um, as an agile coach, you, you, you can’t go there because you don’t actually have that training, right?

You, you don’t have any of that ex training or experience. Uh, and you could, you could do bad, right? You could, you could, uh, damage people effectively if, if you do it badly. And so as a result of that, I looked around and, and Bob actually had, um, uh, a, a code of ethics that he publishes, gives his customers, um, 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. And so I think, uh, that’s important, right? Um, I think. The ability for say, these are my skills. Right? And so if you are come from more of a life coaching, uh, saying, Hey, I’m more of a life coach than a, um, domain expert, right? Um, and that’s okay, as long as that’s the expectation between you and the people you’re working with.

Um, but again, I see very few agile coaches that actually have that, that charter. You know, we teach our teams start off with a team charter, right? Um, 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, their customer or their team on day one?

Um, sure that there’s, 

Murray: there’s, um, there’s this, uh, consulting model which came from a guy. Douglas Champion and a couple of others, Champion Keel and McLendon from the mid eighties, which, which suggests that there are nine possible, um, 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.

And, um, people have rebranded this as an agile coaching stance now, but basically you could be an observer and just watch people do it and then, you know, provide feedback later on, like a, like a report on, on what you thought. You can be an advisor who answers questions. And you can be a hands on expert who’s doing it.

So those first three are, are all where you don’t take much responsibility for growth of the team, but the hands on expert, you’re actually doing it. Right. Um, going up a level, you could be a facilitator, a teacher, or a mentor, which is starting to take responsibility for their growth as the team’s growth.

And the top level you can be, uh, a visionary, a coach or a partner. So I, I want a, you know, expert in architecture or design to be able to just use all of those approaches, um, not just the, you know, kind of therapy approach that some people take. So 

Shane: I think that sounds like a great framework. I think let’s put a link to that in the show notes.

And, and I think just to close it out, yeah. 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, you know, your literacy in each one of those and what you’re good at and how you can help and where the gaps are, right. So that, uh, everybody’s clear on, on the value and what you’re, what you helping and what you’re helping.

That’s the important message. 

Murray: Now we do a little bit of a summary, Shane. We started talking about evolutionary design and the problem with just a very narrow focus, like a two week focus leads to all sorts of problems. And then I think we talked about different, 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. Um, the importance of having roadmaps but not fixed roadmaps. I think we, we very clear on that they provide you direction, but you change your roadmaps as you learn. Um, and then we started talking about, um, the kind of centralized teams and the role of the architect, uh, which I want distributed, but we can talk about that more another time.

Um, and then we went into quite a big discussion about the role of the expert. If you are, if you are the expert, architect or the expert designer, what, 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 guess my point was that I also want, um, The expert to, to help me get results for the client.

So I want ’em to do both, both build the capability of the team and get results for the client. And that can, that can mean that they’re, you know, on the field as well to some extent just when it’s needed. 

Shane: Yeah. So, so for me, that’s where I, I go back to the literacy model that I’m comfortable with, which is if you’re at that expert level, then you, you can be on the team, right?

You can be on the field. That’s okay. Yeah. When you get to the coaching level, you typically shouldn’t. Because your whole focus is changing from getting the thing done to teaching other people how to do it as well as you do. And I think that that’s a big jump, right? I mean, we all, we all have to sometimes do things, um, because they just need to be done, but your focus should be coaching that team or many teams to be as, as much of an expert as you are.

Murray: Well, if we are going to, to become those coaches, then, then I want the, those people to be sports coaches. So, um, they are, you know, doing a lot of strategy planning with the team, even if they’re not on the field. Yeah, Yeah. 

Shane: And you know, again, Park it for another podcast. But this idea of, um, if you are the product owner for a product, should you be a domain expert or can you be a professional product owner for something you have never done before?

Uh, same question for an agile coach. Should you have least have played on the field of the team you are coaching? Uh, or is it okay to come in when you’ve never played that game? Right. So some good questions when we talk about, uh, those kind of things that we, we can cover in another session. I agree with you.

Uh, we do tend to start somewhere and end up somewhere else. . I still always feel like we kind of got there in a natural way, but yeah, sure. I like the way you summarize this one up. So thank you for doing that. 

Murray: That’s so we should close by a, uh, let’s keep real. Excellent. Next time. All. Thanks. That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson.

If you’d like help with Agile contact Murray, that’s evolve with the Zero. Thanks for listening.