Agile Architecture and Design
Agile Architecture and Design - 8 August 2021
SUMMARY
In this episode, 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. The role of the coach is to build the team’s capability. A coach should be a sports coach, not a therapist.
SPEAKERS
Murray Robinson, Shane Gibson
Shane Gibson
Welcome to the no-nonsense agile podcast. I'm Shane Gibson.
Murray Robinson
And I'm Murray Robinson.
Shane Gibson
Hey, Murray. Another podcast day. We've decided today we're going to talk about something we call evolutionary design or agile architecture.
Murray Robinson
Let's talk about evolutionary design. Or agile design, if we wish.
Shane Gibson
Why don't we start from your domain and how we make it work? Then I'll jump in from my data and analytics architecture view.
Murray Robinson
I first did agile back in 2004. I got into it by reading “XP Explained” by Kent Beck, and that's what we tried to implement. In XP, Kent talks a lot about “we ain't going to need it” and “the rule of three”, which is the idea that we code a solution for the story we're working on and don't worry about reuse. We have automated test cases, but we just focus on the present. The reason is that there is an enormous amount of waste in designing for a future that may never happen. When we're working on a code module a second time, we change it a bit for a new feature or rule, then the third time, we restructure it to make it modular and abstract. Apart from that, we avoid any more extensive architecture or design decisions because it’s not needed, or we don't know what it is, or we will get it wrong. This approach has become a big part of Scrum. Scrum has this idea that we just focus on the current iteration. We design and build in the current iteration. When we groom the backlog, there'll be a discussion about how we might solve something to estimate it, but the idea is to always focus on the next sprint. I've seen this go wrong with UX design. It makes us take this microscopic focus on buttons and small modules, and we can't see the forest for the trees. I've seen fragmented user experience design come out of this constant, short term focus. UX designers and UI designers complain about it constantly because they work on a bigger picture level. They work at the level of user experience and user flows, user journeys and pages. They will argue that we can't design a button or part of a form unless we understand what the page is, and we can't design the page unless we know what the user journey is. I've seen bad design come from this total focus on micro-decisions. On the other hand, I've run waterfall projects where there were months of requirements, months of architecture, months of design and months of technical design before we ever built anything. A lot of that design ended up being wrong and wasted because we miss many things that we only find out during development. There's a place for evolutionary design, but it needs to sit somewhere in the middle. We've got to have a big picture, a medium-term and a short term. We don't want the big picture to be too detailed. We want it blocked out to know what context we're working in when we're making micro-decisions during a sprint. What's your view on it?
Shane Gibson
I can take two lenses on this. One is in the data and analytics space where I'm coaching teams, and the other is with our startup, where we're doing application development. That’s given me an insight into what we're talking about. From a data and analytics point of view, I started on the same journey with a different book, with the idea that we could build the aeroplane while we're flying. We didn't go in and do any architecture design at the beginning. We started with the team beginning the work. We were starting from nowhere and trying to design the architecture as we built it. In the data world, that seemed to cause a major problem. Over the last couple of years, I've been contemplating that. In the app dev world, there are many known patterns, architectures and design concepts that work together. We can pick one of those without a lot of effort. Whereas in the data and analytics world, we're not at that level of maturity. We've still got 101 different choices with massive consequences.
I recommend agile architecture, which is the idea of using time horizons. In the beginning, we take a piece of paper, draw big rocks and make decisions about those big things that will have a massive impact if we change our minds. We put those on the picture and say, that's where we're going to start. Then as we're building out, we're changing within those boxes. That's okay because they don't have a lot of detail in them yet. If we're starting to change one of those rocks, then we should be aware that there's a lot of change coming. Then we need to go through and iterate the architecture to find the impact. I find that drawing the wireframe architecture helps the entire team understand what we think the future state might be. It's a picture. We can speak and wave our hands, but as soon as we draw, we get the message across better. It allows any of the team members to identify when one of those changes will be massive. In the app we're building, we had to decide what we're going to develop the front end in, what we were going to develop the back end in and how we would make those talk. We changed it quite a bit over time. I talked to friends and worked out that I could go down the React or Angular path. Then we worked out that this decision impacts the people we hire. If we go to React, we have to hire specialists. So we experimented with a front end capability called Flutter. As we tested it, we worked out that it wasn't at the level of maturity we needed to do what we wanted. It was a little bit too early in its lifecycle to be safe for us. So then we moved to a front end technology called Svelte, which was a bit more mature. Now, that's a big rock. If I decide to go from Svelte to React in the middle of development, I’ve got to incur a massive amount of cost and change. I’ve got to retrain my whole front end team or find another one. I have to rebuild all my components or buy them. For me, that rock doesn't mean it's never going to change. If we decide to change it, then the cost and consequences of that change are pretty high, so it has to be a well thought out decision. If we decided to bring in one of the CSS kits that were Svelte compatible, then that's fine. It's a small change within the rock.
Murray Robinson
I agree. We've got technology choices that we need to make early on, and they are going to have a significant impact on the direction we're going in. I would prioritise those choices early for exploration so we can understand the risk and usefulness of the technology. We covered that during the initiation podcast last week. From a technical architecture point of view, the purpose of those first two weeks has got to be to understand and explore the platforms and components that we're planning to use to see if they're going to work. During the first two weeks, I'd like to have the technical leaders in the team explore React, Angular and Flutter to see which one is best for us. Then we'd start with one of them. How far did we get before we switched over from Flutter to Svelte?
Shane Gibson
It was pretty quick because our app is designed to work on a large device. It's not designed for a smartphone. As we started to experiment with Flutter, we worked out that it was intended for mobile apps and was not built on a desktop browser. It was in the roadmap for that product, but it was pretty clear that it wasn't a priority for them at that stage. We knew it wasn't going to meet our needs, so we decided to switch.
Murray Robinson
So did we deliberately focus on exploring the potential issues with Flutter before we went far with it?
Shane Gibson
We did. We're also lucky that we weren't executing as fast as we wanted. If we were running pretty quick, we would have to make the decision a lot quicker. We had delays that were, in hindsight, lucky. Whereas with Svelte, we started using it in anger straight away. If we got a couple of weeks down the track and worked out that it wasn't the thing, we would have to take another look at our blueprint and work out what to change.
Murray Robinson
That is a big advantage of an evolutionary design approach. If I was doing a waterfall project, we could have spent nine months and a million dollars going down an architecture path, assuming that we were using React. Then we would only discover well into development that it didn't give us what we wanted. Then it would be a big problem.
Shane Gibson
We've always designed with our architectural rocks being loosely coupled. We're designing so that we could remove one of those rocks and replace it with something else. There will still be a cost and a consequence, but we're always architecting so that we can do that. Our back end didn't need to change in that scenario, and the way our front end talked to our back end didn’t need to change. We figure out how we're going to store the data into which type of technology and which modelling technique we want to use. If we take that approach, it's always possible to change the technology we're storing the data without changing our modelling technique. If we need to change our modelling technique without changing our technology, we can because they're loosely coupled. Architecture is essential when we're using an iterative development process.
Murray Robinson
How are we getting a loosely coupled architecture?
Shane Gibson
It's primarily in the thinking when we define that architecture. We've taken it from the principle that everything is loosely coupled. There are proven technology components and architecture components that naturally work together in a decoupled way. If we're adopting a pattern, in the beginning, we're relatively certain that it's going to be okay because it's been done before. We still need to test that and be aware that something might differ in what we're doing. We’ve got risk when introducing something unknown within our architecture, where we can't find any references. That's when we've got to do research spikes during initiation and spend time exploring whether it's safe or not. I'm a big fan of reusing proven blueprints that other people have done. Reusing patterns is a good technique when we're starting from scratch.
Murray Robinson
There's a lot of patterns out there that we can use. User experience designers go to websites like Dribbble, where they can see examples of other people's work. From a UX point of view, we're trying to work out what the best practice is and apply it. So they'll look at competitor websites, look at user flows, and then they’ll map out the UX. There is a big advantage in mapping out at the big block level to provide context for everything else we're doing. I would map out the big blocks from a 12-month view, then pick the first component we're going to work on and map that out in a bit more detail at a three-month view. We're not talking about writing big documents. I'm just talking about whiteboard stuff. We take a picture of it, and we put it in JIRA or Confluence. Or put photos of it up around the team room so people can refer to it. So that when the teams make decisions in a sprint, they know what the context is. That context is essential. The team is constantly making small decisions all the time about the technical solution and user experience solution. If they don't understand the context and the direction, they quickly go off in another direction, which may solve a short term solution, but cause problems in the longer term. I'm worried that with Scrum, people take a short term focus. I've had pushback on this view from Scrum trainers who tell me I’m wrong because the product backlog has big rocks for work that’s far away and small rocks for work that is close-up. In my experience Scrum and XP discourage design work during product backlog grooming. Grooming is just about trying to identify what the feature is and what it might mean to prioritise. There seems to be strong discouragement of any design more than one sprint ahead. We can do technical spikes during a sprint to research something, but they are discouraged because they don't deliver immediate business value. Everyone is focused on what we're going to be building next sprint, and that's it.
Shane Gibson
I have seen a pattern, which is called the three amigos, which balances how we're working. In the three amigos pattern, we have the product owner, a BA, and a technical lead. People at an expert or coach level with those skills. These three roles work together slightly ahead of the scrum team. They're doing very light mapping of stuff to walk into the backlog grooming with more structure. They’re identifying the proven paths where they know should be relatively safe where there's a high level of uncertainty; a research spike is a good idea.
Murray Robinson
That feels like that's an addition to Scrum.
Shane Gibson
I coach Scrum patterns because they have value, but I also adopt patterns from other agile approaches. I'm not a scrum purist. I'm very opinionated on words, like best practice, because I call bullshit on best practice. I believe there's a thing called good practice, which is a known solution to a known problem in a known context that will make us faster if we adopt it. They're good practices with no reason not to do them. The term “best practice” comes from consulting firms trying to say there is one way to do it. I don't believe that. The other trigger word we used was JIRA, but I won't go there.
Murray Robinson
I agree with you. I retract best practice and substitute it with good practice.
Shane Gibson
Good, we're just going to break this habit from now on and call bullshit on each other if one of us regresses. Anyway, so three amigos are not out of the scrum guide. I'm okay with it.
Murray Robinson
Scrum is not the whole of agile. We can do agile without doing Scrum at all, which is pretty shocking to some people.
Shane Gibson
I talk about adopting an agile mindset. We should talk about what agile means to an architect because that's an interesting conversation, but back to the three amigos. The danger of three amigos is we start to regress into pipelining and waterfall behaviour. We start overworking that early work. We spend too much time on it. We start defining too much detail outside of the team rather than giving them a quick start with guide rails.
Murray Robinson
But aren't those three amigos part of the team?
Shane Gibson
Ideally, but sometimes we'll see three scrum pods and one set of three amigos. Those three amigos become busy because they're trying to keep ahead of three Scrum teams. One of the things I like about the scrum guide is that it provides good practice to read and understand. Then there are other good patterns, like the three amigos.
Murray Robinson
There's a lot of XP practices, like user stories, that are not in Scrum. There's an argument that Scrum without XP is pretty empty. It just doesn't work.
Shane Gibson
Pair programming came out of XP, not Scrum.
Murray Robinson
So did stories.
Shane Gibson
And the Kanban board that we use as a scrum board that came out of the Kanban lean track is not part of Scrum, if I recall.
Murray Robinson
Scrum had product backlog, sprint backlog and done. The idea of setting up a kanban board for the work came out of the kanban community.
Shane Gibson
Have you ever worked with a scrum team that doesn't visualise the work on a Kanban board?
Murray Robinson
Everybody does it now because that's what we get with Jira and tools like that.
Shane Gibson
So if we go on a two day Scrum certification, we get taught to visualise the flow of the work on a Kanban board.
Murray Robinson
It is all part of it now. Scrum has evolved. I don't want to go and look up the scrum guide to see what it says about visualising the work, but I'm sure it does say something about it now—anyway, coming back to the Three Amigos. We need people looking at the bigger picture of the product, the user experience, the technical architecture and the business processes. That's four amigos. They tend to be more senior people with more advanced skills and the ability to look at the bigger picture.
Shane Gibson
I've been crafting the words I use around that for a while now. I talk about four levels of literacy - novice, practitioner, expert and coach. I used to use the words master and journeyman, but I've found other words I'm comfortable with to remove those words from the vocabulary. I regressed as I talked about the three amigos because I was talking about a technical lead. I’m purposely trying not to use the word leader because that infers a hierarchy, not literacy. I shouldn't be using the word. I mean somebody that's technically competent at an expert or a coaching level. In an enterprise organisation, especially in the data analytics space, we end up with a team of architects. Where do they fit in? One of the other podcasts I listened to had this saying that is “The brakes on our car aren't there to slow us down. The brakes on the car are there to allow us to go faster safely”. That's the theme I use for architects. We're not there to slow the team down. If we wait for the team to give us something and review it because we're outside the team, we're slowing them down. We should be setting principles and practices, and patterns that allow them to go faster. They have to use these guides unless they have a conversation with us. As long as they're within those boundaries, they don't need to talk to us because we've done the hard work and said these good practices make sense. Please use them. Visualising our work on a Kanban board makes sense. If we're not going to do it, let's have a conversation because it seems like a good idea.
Murray Robinson
I worked for a big telco and other places that had Enterprise Architecture teams. There were a lot of good people in those teams. I had a lot of respect for their skills, but quite a few of them had stopped coding some time ago and had become entirely theoretical. The ones I had the most time for were the ones who could do POC’s and get their hands dirty. That makes a big difference.
Shane Gibson
My view is that the world's changed, and architecture practice should change. If we think about the idea that we're creating these practices and these policies that make people go faster, then the way we behave changes. I think a good architect observes all the teams, harvests that knowledge and provides it back to the other teams to use it rather than reinventing it. So we’re copying what's good from all the stuff that's happened and then describing it in a guide that somebody can read and go, Oh, that makes sense. I'll just carry on doing that. It's easy, it looks good, and it works, so why would I invent something?
Murray Robinson
That makes a lot of sense to me. I have a big problem with the architect who works at the start and then comes back at the end and says, it's all wrong. I've had that situation where the architect is in a different group, and they don't take responsibility because they're not involved anymore.
Shane Gibson
As a consulting architect on contract, that's a great way of getting another bite of the apple. Ideally, we want those architecture skills embedded in the teams. That's hard when we have a separate architecture team; it comes back to the way the two groups engage. The architect should constantly be looking in and attending demo days. They should be coming along to a couple of stand-ups just to listen to what's going on or just checking in with the team about anything they should worry about. The team should be pinging the architects when they know there's a decision that needs to be made outside the good practices they've been suggested. To me, it's no different than a product owner. A product owner should be involved with the team as much as they need to be. In my view, a product owner should be at least 50% 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 Robinson
I agree with the idea of having somebody who is an expert who is working at a more abstract level across a few teams, as long as they're still quite involved in supporting the team. So, for example, if I were doing a project plan with resource allocation, I would allocate an architect to the team a percentage of their time all the way through. Either that or make the most technical leader the architect.
Shane Gibson
I often say that agile is a mindset where we adopt patterns that make us faster. One of the mindset changes an architect needs to make is to think of the team doing the work as their customer. The architect's job is to make those customers go faster safely. When an architect is involved with teams, they can add value. They can identify problems that the team can't because they have more experience in that domain. They can step back and look at it from a higher level and not be down in the weeds. They should get out of the ivory towers and be somebody who enables teams to be more effective. That's where we've got to go.
Murray Robinson
Most organisations are set up like factories, with specialised teams doing specialised work, because that's supposed to be more efficient and effective. Centralised UX, architecture and deployment teams build technical skills, but they also create dependencies and handover problems. I would solve this by allocating these experts to the product teams as much as possible. I might say that they're going to sit with the primary team they're supporting 50% of the time while providing coaching, mentoring and support to other groups. There's a lot of severe problems with an architecture team or a design team. It's a waterfall concept that doesn't work very well. The agile way is to distribute that expertise amongst the teams.
Shane Gibson
We will need to discuss centralisation versus decentralisation of teams and skills another time. Those decisions have a massive impact. The more we decentralise and let the teams be self-sufficient, the less we can provide standardisation across those teams. Let's cover that when we go into cross-functional teams versus centralised capability. Let's go back to that pattern where we treat Scrum teams as if they're working in a factory. That's an interesting conversation. Architecture is one part of the organisation that is hard to change and adapt when we're switching to an agile way of working.
Murray Robinson
It's the same with the design group. They tend to be precious and controlling, very much into empire building. That's what I've seen. I'm sure they don't have to be like that, but it does tend to be that way.
Shane Gibson
I don't do a lot in the UX space in enterprise land. If I take it back to our startup, we've got one person who looks after the UX design for us. I am one of the worst product owners because I find it hard to articulate what I want clearly. For me, doing a lot of work upfront on the flow across our application, from the beginning to the end doesn't make any sense. There are whole chunks, big rocks, where I don't know how it's going to work. I know what I need to achieve, but I have no idea what I want. We approached it at the beginning with a very ad hoc, ungroomed approach. We've started to evolve that a little bit. We're drawing big rocks on a big piece of paper. When we get to the rock, we deal with what's on that rock. We know that if any of those rocks change, there's a massive amount of rework from a UX point of view. It comes back to that idea of Agile architecture and agile design. We develop that vision and shared language, and then we dive a bit deeper as we get into it. Everything can change, but there's a cost and a consequence when we change those big rocks.
Murray Robinson
I think we need a 30,000-foot view, a 10,000-foot view, and a 10 feet view. But we don't want to be detailed in our 30,000 feet view. We've mostly talked about one team, but what do we do when we've got a product that requires six to 10 groups of 10 people like Spotify. How do we do the design and the architecture then? Also, what about the idea that experts are critical? Few people can design well, so we need to make sure that we have an expert architect available to set the direction for the team because they're the ones who understand the big picture. It's the surgeon model. There's this idea in hospitals that the surgeon makes all the crucial decisions, and everybody around them supports them, like the nurse and the anaesthetist. The other day, I talked to somebody who railed against incompetent developers and talked about how important it is to have an expert make decisions. Otherwise, we could go down very bad paths.
Shane Gibson
So this is a perfect example of non-agile architecture thinking. If the problem is a new team with low literacy in some areas, we should coach and mentor them to pass on the knowledge we've gained so they can become self-sufficient. But what I heard you say is these people are not worthy. They need to come to me because I'm the expert. It is a hero mentality. When I start with a new team, I ask them to identify the skills the team needs to succeed in the data space. They might say they need to understand the data requirements and write tests, model data, write the ELT code that changes the data and deploy that code. So there's a whole bunch of skills that relate to the work that needs to be done. Then I get each of the team members to rate themselves as a novice, practitioner, expert and coach on each of those skills
Murray Robinson
Do we want to explain ELT?
Shane Gibson
ELT means Extract, load and transform. We take data out of something like Salesforce and drop it into a database like Snowflake or BigQuery. Then we write code that changes it in the database to do what we want.
Once the team has mapped out the skills they need and their literacy, we overlay them to look for gaps. We look for skills where nobody in the group is an expert or coach. We also look for areas where those skills are only held by one person, because then the team is in trouble if that person is off for a week, on holiday. Once we identify those gaps in skills and literacy amongst the team, we have to work out what we will do to increase the literacy of those team members. That's what a good architect should do. They should see that the teams are light on data modelling, so they help people become practitioners in data modelling. My goal is to make them self sufficient, not be the gatekeeper that tells them what they did wrong.
Murray Robinson
I agree with that approach. I'm worried about people who think agile is irrelevant, and we just need to get a group of experts together to solve the problem.
Shane Gibson
Did you know that a group of architects is called an argument of architects? If we ever get in a room together, we argue semantics. If we took the best soccer players from every team in the world and put them in one group, they're not going to perform as well as a team of good players who have been playing together for a long time. A team needs to form, norm and storm to become efficient. A group of experts doesn't mean we're going to get there faster or safer.
Murray Robinson
I agree that the expert needs to build capability, but they also need to help the team paint the big picture because they may not understand the range of solutions available. So I'd like to see an architect map out the big picture as well as build capability.
Shane Gibson
Let's not beat up on architects; let’s look at what good looks like. I think an architect should sit with the team and ask, “have we thought about this?” An architect should say there is a pattern that looks like this. Do we think if we applied it in this situation, that it will solve the problem?
Murray Robinson
Well, we could work with a group of people who don't understand patterns. People build up their experience over time, going from novice to practitioner, expert and coach. This is like the Shu Hari model from Alistair Cockburn and martial arts. Many practitioner developers understand the framework they're working with moderately well, but they don't understand other frameworks and patterns. They might not even understand the concept of patterns.
Shane Gibson
Going from expert to coach is hard because it requires that we take our expertise and articulate it so that we can coach somebody else to do what we do. It's hard to define something that you've done unconsciously for years. For example, when we're doing this app development, we started down the path of design systems. It took me ages to find somebody who could explain what a design system was. I asked my mates if we could get a copy of their design system, and they just laughed at me. I was like, What the hell is it? And then they'd say words, and I'd go, I don't get it. What the hell is it? It took me ages to figure out what a design system for UX is. That ability to take our expertise and articulate it back to other people in a way that will make them more literate is a hard thing to do in my experience.
Murray Robinson
Experts need to think of themselves as consultants who have coaching as one of their approaches. I've encountered quite a few coaches who will only ask questions or engage in a therapeutic approach. Quite a few of those people do this because they don't have the experience to contribute. If I hire an architect or UX designer, I want somebody who has many different things that they can do. They can ask the right questions, and they can mentor people individually, but they can also do the work if needed. They can teach, they can train, and they can mentor. According to the International Coaching Federation, coaches don't offer solutions; that’s mentoring. I want somebody to take a broader approach where their expertise is available as well.
Shane Gibson
Did you just say that the definition of a coach from their organisation is that we don't provide solutions?
Murray Robinson
Yes. Because that's mentoring, and that's different to coaching.
Shane Gibson
Wow, I'm going to have to become an agile mentor then. I can go on a big rant about the number of times I'll work with a team, and the scrum master will reply with depends. That is so annoying. They shouldn't dictate what's next, but they should provide guidance and options. That they're coaching is interesting. I don't get the impression that the All Blacks coach, the world's best rugby team, is not providing any guidance.
Murray Robinson
I agree. My model of a coach is the sports team coach. They're adding a lot of value and guidance, but they're not playing the game or kicking the ball. They are providing help, strategies and advice so other people can do it. There is a strong trend in the Agile coaching community to say that an agile coach is not a sports Coach; they are more like a counsellor. The important thing is to be curious about the person, how they're feeling, and what they're thinking. And ask questions to help them make their own choices, but we don't provide any suggestions. It does my head in, too; it’s just low value.
Shane Gibson
It's about balance. I'm a great fan of Bob Galen and his podcasts. A while ago, I attended agile meetups in New Zealand, and we started discussing ethics for an agile coach. It seems that anyone can call themselves a coach. I see coaches who believe they are life coaches and other coaches who say that agile coaches should not get involved in personal issues because we don't have any training or experience. We could damage people if we do it poorly. I looked around, and Bob had a code of ethics that he publishes and gives his customers at the beginning of every engagement that says, this is what I will and won't do as an agile coach. If I'm more of a life coach than a domain expert, that's okay, as long as that's the expectation between us. I see very few agile coaches that have that charter. We teach our teams to start with a team charter. To agree on what we will and won't do and what good looks like, and what's not acceptable. How often does an agile coach do that with the customer or the team on day one?
Murray Robinson
A consulting model from Champion, Keel and McLendon from the mid-80s says that there are nine possible consulting stances that we can take depending on how much responsibility we take for the clients’ results and how much responsibility we take for the client's growth. People have rebranded this as an agile coaching stance now. We can be an observer and provide a report on what we saw. Or we can take some responsibility for the team’s growth, and we could be a facilitator, a teacher or a mentor. Or we could bring more responsibility for growth and outcomes and be a visionary, a coach or a partner. I want an expert in architecture or design to use all of those approaches, not just the therapy approach.
Shane Gibson
This seems like a great framework. I think it's unlikely that somebody has all nine of those at a level of expert or coach, so we need to be clear on what we're good at, how we can help and where the gaps are. So that everybody's clear on the value and what we're helping with and what we're not. That's the critical message.
Murray Robinson
So maybe we can do a little bit of a summary. We started talking about evolutionary design and the problem with a very narrow focus. So a two-week focus leads to all sorts of issues. Then we talked about looking at different time horizons. And we talked a lot about big blocks and small blocks and the importance of having roadmaps but not fixed roadmaps. They provide direction, but we change our roadmaps as we learn. Then we started talking about centralised teams and the advantages of distributing these skills. Then we had an extensive discussion about the role of the expert. We agreed that a big part of our job as experts is to build the team’s capability, but I also want the expert to get results for the client.
Shane Gibson
That's where I go back to the literacy model that I'm comfortable with. If we're at an expert level, then we can be on the team. But when we get to the coaching level, we shouldn't be on the team because our focus is changing from getting the thing done to teaching other people how to do it. That's a big jump. Our focus should be coaching teams to be as much of an expert as we are.
Murray Robinson
If we are going to become coaches, then I want people to be sports coaches that are doing a lot of strategic planning with the team, even if they're not on the field.
Shane Gibson
If we're the product owner, should we be a domain expert, or can we be a professional product owner for something we have never done before? Same question for an agile coach. Should we at least have played on the field of the team we're coaching? Or is it okay to come in when we've never played that game?
Murray Robinson
That was the no-nonsense agile podcast from Murray Robinson and Shane Gibson. If you'd like help with agile, contact Murray at Ev0lve.co. Thanks for listening.