Team Skills vs Roles

Join Murray Robinson and Shane Gibson in a conversation about effective agile product teams. Business people and technical people work together daily in one long-lasting customer-focused team. Roles vs Skills. The power of words. Do titles create hierarchy and functional silos within the team? T-shaped people. Should everyone be a developer? Are specialised roles useful? Specialists need to be on the team all the way through. Should people be paid the same and treated the same? Long-lasting product teams vs project teams. The best requirements, architecture and design come from self-managed teams. Servant leadership vs hierarchy. Teams have multiple leaders. One united product team across vendors and organisations.

Read along you will

Shane: Welcome to the no nonsense agile podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Shane: This week we are gonna talk about what makes a team. What roles or skills or who do you need to be in it? 

Murray: What I would call a product team. A team that is developing, digital software based products and services. 

I wrote about this on LinkedIn, and it was very controversial. So my view is that in order to develop a product or service, you need to have a mix of business people and technical people in the team because there’s a lot of business things to be done as well as technical things. In agile and all these new ways of working, we’re gonna break down dependencies and silos by bringing all of the skills that you need to develop a product from beginning to end into one team. So one team across departments across the vendors, across the client and suppliers, it’s one product focused team. That has at its core, the customer or user needs that you’re trying to meet.

Shane: I agree. The idea for me is removing those dependencies. We want a group of people let’s call ’em a team who can take it from the idea all the way to fruition. So they can go from the beginning to the end. They can make it go live. They don’t need to go and talk to other groups of people. Because when we do that we introduce latency. We introduce the requirement to hand over context, via a conversation or a document. And that’s hard. We introduce dependencies on their workload and their priorities and how they relate to us. We want a group of people that can get the work done by themselves. 

Murray: As much as possible. They may not be able to do everything, but as much as they can. It’s quite common to have a scrum team that is dependent on a design team that does user interface and user experience design that is in a functional silo somewhere else. Basically it’s waterfall over again with the design team. And it’s also very common to have a separate test team, you think people would know better in agile that you don’t have a separate test team, but it’s still very common to have a separate test team. And it’s also very common to have a separate infrastructure team. The DBAs and, other people who manage infrastructure are all in specialized groups and you’ve gotta wait a long time for them to do something.

It’s vastly better to get everybody you need into the team. So let’s have a developer in the team who’s good with infrastructure and get them to manage the infrastructure for the team. Take it off the security team, take it off the performance team, take it off the infrastructure management team and get one of your developers who likes doing that stuff to do it. And if they don’t know yet how to do it all, then, get somebody who wants to learn and have them interface with those teams. So the idea would be embed security into the team rather than have security in another team. People talk about this as shifting left. Shift security left in the process, shift performance testing left into the team. So all those things go into the team that often come after. And also the things that come before like design or analysis, put them into the team as well. That’s what I’m saying, basically.

Shane: And I agree. So all the skills you need should be in that team. There’s some challenges with that. Often you don’t have people with the experience level. So you end up with novice or practitioners rather than experts or coaches when you need them. But that’s something you can manage. Sometimes the organizations in a silo and it behaves in that hierarchal pipe liney handoff way. Again, it’s something you have to solve over time. So the end state, the goal we’re aiming for is single self organizing team of all the skills they need to go end to end. But often it takes time to get there.

Murray: It takes will. So when you’re doing agile you can say we’re gonna challenge the current structural hierarchy of the organization, cuz we’re doing things differently and this way is going to be much more effective. So maybe your designer still reports to a design manager. They have a dotted line, but they spend all of their time in the product team. And take direction from the product team, not from the design manager. The design manager just provides pastoral care for them. And the same for, your developer who is going to be looking after the infrastructure for the team. So there’s no handoff. And these handoffs create enormous delays and enormous costs. Far more than organizations realize, I think I’ve told you this story before Shane, that it was working for big telco in order to get a five minute firewall rule change, it would normally take 12 weeks going through all the different silos and it would cost $50,000 maybe even a hundred thousand for a five minute firewall rule change by the time you took everyone’s time into account. And that’s just because there’s just so many silos and different people involved.

Shane: So looking at the commentary on the post you made, there were some robust discussions . And my observation is you were describing things in a way that people were assigned as roles, not skills, and we should be talking about the skills in the team, not the roles.

Murray: Scrum has this idea of three roles. There’s developers, there’s a scrum master and there’s a product owner. And the developers are supposed to be whatever skills you need for the team, but the way that nearly everybody in the scrum community interprets it is that the developers are actually software developers and that they do everything. Even though that’s not what the scrum guide says anymore, a lot of people assume it that way. Whereas what I’m saying is that you should have a bunch of T-shaped people who have a specialty in a particular thing, and you need all those specialized skills. So you need somebody who is very skilled in user experience design and UI design, and working with customers and testing prototypes. If you are building a product that has a user interface, because the user interface is critical for usability. Now that person, once they’re in the team, can start to do other things, to help the team. Maybe they can code up the CSS for the team. Maybe they can develop content for marketing. They could do other things once they’re in the team. What I’m talking about here is somebody who’s really good at UX and UI design. Now that person is gonna be called a UX UI designer. They’re probably gonna be currently sitting in a design team. And if you don’t call them a UX UI designer, nobody is gonna know what you’re talking about. So you have to call them that even though when they’re in the team, they’re gonna be a T-shaped person.

Shane: So I think it’s the way we describe and draw these pictures. So the way I do it is I actually draw the skills as a T. I don’t draw any roles. I don’t draw any hierarchies. I don’t draw any circles of people in them because I’ve fallen into the same trap. So I draw the skills and then we color code in each of the members of the team and the skills they’re strong in and the skills they’re not so strong in, but I do end up using some of that terminology in terms of the roles in the same way that you’ve just described it.

So we’ll talk about the skills needed in the team that are around analysis, we’ll talk about facilitation, the ability to run, some interactive sessions to draw out some understanding of what people need. We’ll talk about the, creation of documentation, where it’s fit for purpose.

And then we would typically say, and those skills are normally found in the role we used to call business analysts. If you’ve got somebody in your organization, who’s got the title of business analyst, they will typically have the skills that fill out that part of the T. So I definitely end up mapping it back to the roles, but I never draw a diagram or any other documentation that looks like it’s defining a person in a role because everybody then automatically puts that role based lens on it.

It becomes familiar to them. It’s what they know. A whole lot of behavior comes as soon as we do that in my experience. So, I talk about skills. I talk about their level of competency in those skills and what we need and what we’re missing and where we might find somebody who typically would have the skills that we’re looking for.

Murray: So I did a diagram of a product team that would have these kind of roles in. It would have a product owner it would have a team coach or a scrum coach, a business subject matter expert, a designer, some developers, a senior developer who I called a software coach and a quality engineer. So that’s the eight people I recommended and of those four of them are coding. And four of them are not, cause they don’t have coding skills.

But the objections to it were you have roles, so therefore you have functions so therefore you have handovers. So therefore you have silos. So you’ve got all these silos in one team, which is just being argumentative for no reason. It’s just not the case. If you have somebody who’s a designer in a team working closely with other people on a full-time basis, you’d have to be pretty stupid to say, oh, tools down waiting for the designer. People don’t really behave like that.

Shane: Ideally they don’t, but, it just reinforces my message that as soon as you write down a diagram with a role of UX UI designer, and right next to them, software developer and then quality engineer people infer the designs, gonna do the work and hand it over to the engineer, the develop. Who’s gonna hand it over to the quality engineer, even though you didn’t do it in linear, you did it in an nice circle, but that’s what people do. 

Murray: But you’ve gotta explain it some way. Cuz if you’re gonna go and recruit people for these roles, you’ve gotta know what they are. You can’t go to a recruiter and say, I just want six people for my software team and they need to be able to do all these things and there’s not gonna be any titles or roles. It’s just a stupid thing out of scrum which just is just trying to say everybody’s the same. There’s no hierarchy. There’s no grades. Everybody’s interchangeable and fungible and does everything. And I just think that’s stupid.

Shane: Nirvana is everybody is at a coach level and therefore anybody could do anything, but we know in reality that it’s never gonna happen. Again, I’ll reinforce how I say it. I’d identify the T skills that we need. The level of skills on those four levels. And then I’d say we need somebody who’s got some facilitation and analyst skills. We need somebody, an expert level. You would typically find that with somebody who’s had the title of senior BA in the past. 

Murray: Why not just call them a BA in the team and just get everybody to agree that they’ll do other things as required. Cause they’re, T-shaped. It’s easier to say this is a role within a team that is gonna be done in a T-shaped way. 

Shane: So with the teams I’ve worked with as soon as we use role based descriptions, we would see that role based siloing happen. Not all time, but, we’re giving them something that looks like what they used to do. And we’re looking for major change and it doesn’t happen. When people see things they’re comfortable with, they revert back to the way they used to. So soon as you do that role based stuff, even though you’re right it’s just a different language for the same thing, but as soon as we use the language, they know they work the way they used to know. And that’s one thing I like about scrum. I like the fact that its just called developer. 

Murray: There’s another big problem here. And that is you get a large number of people who say developer, that means software developer. So everybody has to be a software developer. There’s quite a bit of pushback, with people saying who are all these other people who are not software developers. That’s too much overhead. 

Shane: So when I’m working with my teams, and they say, what’s this developer role. I explained to them that, in scrum, there’s only three things. You can be the product owner of the scrum coach or the developer and the person I’m talking to is not the product owner. And it’s not the scrum coach. So therefore they’re called a developer, whether they code or not. In the data world, people with the analysis skills often do write code. They’re normally used to writing SQL code for that part of the data analysis. They’re probably closer to the developer persona in terms of code generation than in some of the other domains. But that doesn’t matter right. Where they’re just a person that does the things that need to be done. One of the things I picked up and again, it’s around terminology is, as I’ve said before, I talk about novice practitioner expert in coach.

And I really found it interesting that a lot of the feedback you got was by using the word product coach or software coach, people automatically thought overhead talky, talky, no doey doey. So there’s a lesson for me by reusing the term coach to say that it’s the person that does as well as help other people get better. People automatically inferred it was a talkie talk role. So again, just proving my point. As soon as you use something that has a known definition in a different way, people adopt the nine definition.

Murray: I notice in discussing and arguing with people on LinkedIn that a lot of arguments boil down to the meaning of words, like somebody else is using quality to mean something different than, I mean, by quality and, can take quite a long time to realize that’s what they’re talking about.

Shane: It’s interesting though, isn’t it? Cuz the quality engineer or the QA role has come out just lately. We used to always call it testing. Same set of skills. But, we have changed the name of that role when we’re talking about role based models.

Murray: I talk about quality engineer, because I want them to be somebody who can help the team, automate their tests, as well as develop their tests and help the team improve their quality overall. So it needs to be somebody with technical skills, so that we can do DevOps and continuous integration and deployment.

Shane: I’m interested that you use the word software developer and quality engineer. So again, you’re interchanging the words that mean create code.

Murray: If I just have a diagram that says, there’s a product owner, a scrum master and six developers, then that’s not gonna get the point across, which is that you need specialized skills in the team. You can’t all be a software developer. 

Shane: I love the, two messages, which is you should have a team that can do everything end to end without relying on other teams and to do that, your team needs all the skills to do all the work within the team. And then that subtle one, which is, it is unlikely that every person in that team will be strong in every skill that is needed to go end to end. So you will have some specialization, so they’re all good messages that I agree with. Again, it comes down to, as soon as we draw it, it becomes hard to articulate and people start applying the meaning of certain words in a different way than we intended.

Murray: Scrum used to say that scrum recognizes only these three roles, one of which is developer. So most people are developers and scrum doesn’t recognize any hierarchy or grade or, any functions within the team, apart from those three roles. A lot of people have taken that to mean that everybody’s equally skilled, equally able to do everything and effectively interchangeable. But in reality, people do have very different levels of skills in different specialties. So if you have three people who are software developers ideally you’ll have one who is very experienced and who is going to be able to provide leadership and coaching to the others. But there’s a bunch of people in the scrum community that object very strongly to that sort of idea, that somebody is more experienced than another person in something.

Shane: For me, the ability to determine. How strong in a skill a person is, helps us understand the makeup of the team. So I think it adds value. I don’t think we should use it to create any type of hierarchy. The idea that the person with the expert or the coaching level skills in co-development becomes the hierarchical leader of the group, doesn’t always make sense to me. They would typically be doing the peer reviews because they have more experience to pick up stuff, that the person that’s at novice or practitioner may have missed, but it’s not a hierarchy. And that’s essentially put a hierarchy on it. That’s just wrong. It’s not wrong. Sorry. Cause nothing’s wrong. It’s not an approach that I would recommend. 

Murray: I don’t think that having somebody who’s an expert and other people who are a novice and recognizing that immediately puts in place a hierarchy, but other people do argue that it does put in place a hierarchy. So you must not use any terminology like that.

Shane: So I say BOLs to that, use it because it helps us understand the gaps. But if you’re in an organization that we’ll turn it into a hierarchy and use it for evil then don’t do it. 

Murray: People are regularly using these agile things for evil, no matter what you call them. In teams that I’ve been in , the expert software developer who provided coaching and mentoring to the others called themselves the tech lead. And that’s what other people called them. Even if they didn’t have management responsibility for the others in the team That s what they like to call themselves the tech lead. And I don’t really see anything wrong with that. As long as they have the right behaviors. See, now this is where I differ from you a bit Shane, because I don’t think it’s about the name. It’s about the behaviors that it’s important.

Shane: look, I agree. It’s about the behavior. All I’m saying is that with certain words, certain behavior tends to come with it. So tech leads a really interesting one in theory, you could say that your tech lead is the top of the skills expertise. But as soon as we use tech lead, you get inference that there’s a hierarchy. So, we have a bunch of skills. So let’s say the skills are around architecture. And we have some people who are novices at architecture, some people that are practitioners, some people who are experts, and then some people who are tech leads. That last sentence, it doesn’t go because we are now taking a Hial role in applying it to a skill and that maturity model doesn’t work in that language. So for me, when the language doesn’t work, you should change it.

Murray: So are you saying Shane that there should be no hierarchy at all in an organization?

Shane: I strongly suggest there is no hierarchy at all in the team.

Murray: What about in an organization?

Shane: I have had a number of experiments over a number of years at flat organizations. And I have not achieved my goals in any of them, but I don’t believe I would’ve achieved my goals with a hierarch organization either. My answer now is never have an organization that’s more than 15 people and you never have to worry about a hierarchy.

Murray: How are you gonna scale up then Shane.

Shane: That’s the problem you don’t right. You just end up whoever come of 15 but you don’t hit the hierarchy problem and life is good. 

Murray: I’m happy to say let’s not have a hierarchy within a team because we want them to be self-managing and to help each other out. These behaviors we want are things like, humility, continuous learning, servant leadership. I think you can keep some of the names of roles the same, as long as you put people into a cross functional team where they’re full time and you agree that this is the kind of behaviors that you’re looking for.

It works fine. I’ve done it lots of times and it’s not a problem. All of these things only become a problem when people are working in functional silos with jealous managers, protecting their empires. That’s when you get the bad behaviors, you don’t really get it. In reality. When people are working together in a team, you take them outta their functional silos. You put them in a team together and they start behaving like a basketball team or a football team that, recognize each other’s skills and pass things around. Sometimes, it takes a bit of explanation that that’s what you’re looking for. We want you to be a football team. That’s all on the field, all handing things around. You can have some roles and some specialties and some positions in the team. Those are starting points and then the team does what they need. 

Shane: I was just thinking now you’ve got sports into it. I was just thinking about that most awesome team, the all blacks.

Murray: You have roles in the, rugby team, don’t you. 

Shane: One of the things about our rugby team at the moment, the all blacks is we’ve got some very strong skills in the team. Half the time our bench is actually on the field in one game and then on the bench, on the second game. We’ve got three or four really strong fallbacks. And they can actually go in and play other roles in the team. Cuz their skills are just so awesome. as a team, they have a role, when they hop on, they know if they’re playing the role of number nine or number eight or number 10. They know what that number means. They know what it means on the field and so therefore that helps them understand what they’re doing, even though their skills are really strong.

Murray: Everybody understand. What each other’s doing

Shane: Yes, I still don’t like it. I still find working with a team and using the terminology of skills is easier to adopt that change.

Murray: I find that people who are in software development drastically underestimate how much work there’s required by people, in the business to, define what’s needed, to define new business rules, to change business rules, to train people, to do marketing, finances and everything. If I just put software developers in a product team, it’s gonna be a disaster because the software developers will start demanding all this stuff from other people, so they can do their job. And those other people won’t be available. Cause we haven’t asked for them. And also they may well not do their testing properly. So you need to have other people than software developers. And it makes a lot of sense to ask for them when you’re planning a product team.

Shane: Oh agree. So you need all the skills to go end to end. So not just people that can code and you need to make sure that those skills are available in that team before you start the work. I don’t agree that we should be pricing the team based up on roles. We should be pricing the team based up on the number of people and the level of expertise those people are.

Because, at the moment, the higher level of expertise, the more you get paid. It introduces a challenge though, because, if a person who was traditionally a designer and therefore has strong design skills if they’re paid more than somebody that’s a software developer with those skills, then, estimating the total cost of the team is gonna be a little bit harder because each person has more variability in what they’re paid.

Murray: I don’t think everybody should be paid the same amount. They gotta be paid on the basis of what the market is paying and what their skills are. And if there’s a huge amount of demand for software developers, like there is now then maybe the amount of money they get, or go up 30% all of a sudden.

Shane: So I’m just thinking through that as you talk. So, what we’re doing is based on their strong T skill and the level they are at that T at that skill. And therefore that’s the benchmark in terms of what a person with those skills would normally get paid.

Murray: So people seem to object strongly to coach now. Cause they think that coaches don’t do anything, which is interesting considering we do coaching. What would you call the expert software developer and the team who’s going to be hands on and doing coaching 

Shane: I don’t know now. Cause I’ve spent ages getting to the level where I’m comfortable with novice practitioner, expert and coach. I’ve spent quite a bit of time with those different words to make sure they’re politically. Okay. We used to talk about mastery and I don’t think we should anymore.

So I don’t think that should be a level. I was really happy with the four I came up with and , you can be as happy as you want until you go and test it with your customer and your users. And I think you using the word coach and your diagrams has tested part of the market to say it’s probably not the right word. So I don’t know. I’m gonna have a think about it. I dunno if. If I’m going to change it or not, I’m not sure I can find a word I’m more comfortable with.

Murray: you could call them a lead.

Shane: I definitely won’t be calling them a lead. Because for me that brings in all that hierarchy. They’re not there to lead from the front, they’re there to lead from the back. So , you gimme a problem. Thank you. Not,

Murray: other one, Shane is what should you call the scrum master in a team? That’s not doing scrum.

Shane: I think you should call them an agile coach. I think, the idea of a agile coach, if you’re not doing scrum and a scrum coach, if you are, is the words we should use. Of course that’s a role, not a skill. So again, I’m contradicting myself. 

Murray: Scrums quite happy with certain roles. Scrum master is perfectly fine as a role. So is product owner, although now they say it’s not a role, it’s just a set of responsibilities with accountabilities, but that’s just BS in my view. Cause that’s exactly how you define a role anyway.

Shane: And this is where we get really interesting, because if we do take my philosophy and do skills only, then again, I break one of my other recommendations, that the scrum coach is actually a separate role and that it’s not a member of the team who have good skills in that area that adopt that behavior. They don’t be , the scrum coach half time and the developer the other half time. I have to think through some of the way I describe things and change it..

Murray: I find a scrum master who is also a business analyst, a really good combination because there’s a lot of overlap in the roles. And there’s a lot of time for a scrum master to do business analysis. If they’re full time on a team and if they don’t do business analysis to help the product owner what usually happens is that the organization will divide them over two teams or even more, which is bad .

Shane: So I’m gonna disagree with you here again. I think to be a good scrum coach is a specific set of skills. I agree with you that if I was looking for somebody to become a new scrum coach that finding somebody who previously was a business analyst tend to have the skills, which mean they become an awesome scrum coach.

So I think, yes, if we’re looking at a previous role, that means they have the skills that you need, that’s where you look. I typically recommend that the scrum coach goes across two squads. Because I think the ability for the scrum coach to sit back and not be in the team and observe is where a lot of the value is. And what I’ve found is when they’re in the team doing a doing role, they lose that ability to step back and observe because they’re on the field. So you just take the rugby one, you hardly ever see, the head of the, all blacks run out in the Jersey nowadays. .

The coach sitting back and watching, observing and helping I think’s important. And for me having the scrum coach dedicated is ideal. If people are too cheap to do that, cause they don’t think there’s any value then across two teams, which make it horrible for the second team, because, they’re always waiting. But only two I know somebody who’s an awesome agile coach and she was doing, 20 or 50 teams and that was hard. 

Murray: I’ve been a hands on scrum master, few years back with an awesome team of software developers, really very excellent skills. And I found that it only took half of my time to do the scrum master role. And so since I’d come from a bam project management background, and the product owner was absent a lot of the time I stepped in and helped the product owner a lot with defining the requirements. I think that the reason why people spread scrum masters over two teams is because it’s pretty clear that it’s not a hard role for one team, pretty easy and only half your time. I think.

Shane: I agree that a scrum coach really only needs 50% of their time with one team

Murray: Should we call them a scrum coach from now on Shane? Since we object to scrum master? 

Shane: I’m gonna. 

Murray: Yeah, I like that too. 

Shane: It doesn’t help me when I talk about novice practitioner, expert and coach, cuz now it’s saying you have to be coaching level to be the scrum coach, so again youve broken my words I have to go and fix 

Murray: You persuaded me Shane, and then I got in trouble for using it.

Shane: So now, it’s novice scrum coach and a coach scrum coach. If you look at some of the cool technology companies Uber and Spotify and Airbnb and Google. They have, expertise levels in their roles. You hear of a staff developer or a staff engineer, and that’s actually the highest level. They’re paid the big bucks because their level of expertise is so high. So that idea of people having a level of expertise and having a way to increase their expertise, therefore increase their worth. I think it’s important. And I don’t think we should lose that, but it’s not, it shouldn’t be Hial. I think we should start using scrum coach. I think we should the word master.

Murray: I object to master as well. So the scrum coach fine. So if they’re in a product team and the team is things other than scrum, and maybe they’re not doing sprints anymore, then we’d call them an agile coach. Cause it’s bigger than scrum could include. Scrum could not Inco include scrum.

Shane: Should include parts of scrum cuz parts of scrum have value.

Murray: I like scrum too, but the team should be able to iterate away from scrum into say continuous delivery, for example.

Shane: Or they should be able to pick up some of the stuff from flow or XP or lean. Again, we pick up patents from all the agile ways of working and we apply them where they have value and , an agile coach should know more than scrum. 

Murray: But what if we want the agile coach to know more than agile? What if we want them to know about lean, which isn’t part of agile really, and what if we want them to know about product development and the lean startup and design thinking. All those things that are friends of agile, but are not agile. I dealt with this by calling them a product coach, but then people didn’t like that either.

Shane: I don’t like that. I don’t know. Maybe I’m using the word agile wrong, but for me, agile is really thinking about a way of working that’s different to waterfall. So I still treat lean, XP flow all that stuff as under the agile umbrella.

Murray: So should we use terms that people are familiar with chain? Cause it’s easier to communicate with them.

Shane: The answer is no, but I still do and so and so that’s really not fair is it? Cuz I thought this was gonna be a great podcast of me ridiculing your role based paradigm and then I’m like, damn I do it sometimes too. So do, as I say, not as I do. All right.

Murray: So I quite like agile coach. The other role I had was subject matter expert. Now I was trying to get at those people in the business who know the business operations well and who are going to help the team define, new customer journeys, new business processes, and also help the team define the rules, change the rules, implement it, train other people, work with customer service to help them, understand the new system.

I’ve seen people called subject matter expert in that role. I’ve also seen people doing that role called business process analyst, and I’ve seen them called business analyst, but I was afraid that if I called them business analyst, everyone would immediately think, ah, it’s an it technical business analyst.

Shane: So that’s an interesting one. Subject matter expert is often a person who’s worked in the organization for a long time and just knows how everything works. They know what the poor business processes are. They know what the systems are. They know where the data is. They know lots, so they’re the expert that you go and ask on that subject matter because they have that knowledge. Those people often have those really good analyst type skills. They’re normally good facilitators. They’re normally good at doing customer journey mapping, they’re normally good at change management. They’re normally good at training material. They’re normally good at training. They’re normally good at answering questions that they’ve got a bunch of skills that are highly valuable in a team that’s rolling something out. And so they can be a member of the team because of those skills. Now we’ve gotta be careful when we are bringing them on because of their knowledge and their skills. And the test for me is the team should last forever, as much as it can. So if we expect that subject matter expert to exit the team, when we move on to the next thing we’re gonna build, or the next focus area, then really they’re a stakeholder, because we only value them for the knowledge they have in that particular subject. Therefore, it’s the skills that we’re valuing. And we’ve just got the benefit of the domain knowledge or the subject matter.

Murray: I find it extraordinarily helpful to have that expert in the team available to the developers and the designers to just, bounce things off immediately. It’s just makes the team much more effective. And there’s usually one person who knows that and they do end up doing analysis as well. Cause probably they’re called a business analyst or a business process analyst back in the operations group that they’re in.

Shane: So if they have knowledge that you need I recommend that we do the same thing we do with a product owner when the product owner changes. So in the data space, we’re a little bit different in that we tend to swap product owners. We don’t have a consistent product owner over the life of the product. Because the data we are dealing with will often change. And the part of the hi organization, we are adding value to will change. And so in that case, what I say is that the product donor should sit with the team 50% of their time. They may not have anything to do with the team because there’s no questions or no trade off decisions to be made. But 50% of the time they should sit with the team. And in a remote world, be available for half a day, every day to be pinged whenever the team needs to. So if that subject matter expert is somebody who has knowledge, we need the same behavior. We need to say to them, 50% of your time, can you sit with the team, please carry on doing what you normally do. We’re just gonna ask you questions. Or if it’s remote, in the morning of every day, we’re gonna ping you whenever we need to. 

Murray: I just find that teams work much better when everybody is full time than when some of them are halftime. Cause when they’re halftime, you have to wait for them. So it just introduces all these slowdowns and delays

Shane: Yep. . And I believe everybody is more efficient when we all sit together physically and none of us are remote, we work in a world of constraints. I’ve worked with many teams where the organization says the product owners’ too busy to be there full-time and the subject matter experts, too busy to be there full time. So we make compromises the compromises here. They have consequences. 

Murray: I suppose they could be half the time. Let’s say you, do need a couple of business, subject mad experts. Maybe you can have them both half time. The other thing I wanted to touch on Shane was. This discussion about an ongoing team. Cause I’m talking like, I think you are about an ongoing product team that could be going on for years and continually developing and updating the product. So they might start by developing something new, but then they move into more of a, content development and marketing of the product.

You should set them up so that they can go on for a long time. People will come and go as they move outta the organization. Sometimes people will come and go because the team is gonna change its focus. Maybe they’re changing their focus from developing new features to, marketing the features. My key point is you wanna have a designer all the way through, from beginning to end somebody who’s skilled at testing all the way through somebody’s skilled at business analysis, all the way through people who skilled at software development all the way through. So we wanna have all those skills all the way through from beginning to end, not just in stages.

Shane: no, definitely. We don’t have those skills dropping in and out. And that’s why, people typically have a strong skill, a strong tea that they love, but they always have a bunch of other T skills that they’re good at. A person who’s got strong analysis skills in the data world can write good tests. The person that’s got the strong code development will typically have reasonable skills in the architecture and technical space. There these kind of symbiotic skills that go together. And the person who has the strongest skills often doesn’t have to do that task. We don’t wait for them. If there’s somebody else in the team who has skills in that area, and they’re not as good as the person, that’s the most expert them picking up and doing that work still as value. We’re still getting the work done. It might take them longer. But we’re still getting the work done. So we don’t have them sitting there doing nothing because there is something they can do that adds value.

Murray: And the way that happens is that the team talks to each other. The team is self-managing. They work out amongst themselves who the right person is to do it. And, I’d hope that the team would realize if they’re missing a skill and go to the organization and say, Hey, we need a data analyst now. Cause we are not strong enough in it.

Shane: They know what they need. As they do the work time and time again, they know the skills that are missing that are hurting them. They’re the ones getting the impact of that skill be missing. 

Murray: The people who do the work, know how to do the work and we should recruit good people and trust them and support them. 

Shane: I agree. I think we come back to those core themes, which is the team should be end to end. They should have no reliance outside the team that’s our goal. We should focus on the skills and making sure we’ve got all the skills we need. We may use the word roles, so other people understand where they find those skills. But we’re talking about skills and the team not roles.

Murray: , we want everybody to be multi-skilled and T-shaped, but we recognize that people do have different levels of skills within the team. Some people are novices, others are practitioners, some are experts and some are coaches.

Shane: But we don’t treat that as a hierarchy. So we don’t say that there is, a traditional hierarchy based on that level of expertise. It’s just that some people are more experienced.

Murray: Cause everybody takes a servant leadership approach of helping each other rather than dominating each other.

Shane: And then we want that team to be together as long as possible because they’re learning and forming and norming and storming and all that. And there’s value holding that team together in the way they work with those skills. . And more importantly if you do a diagram with a circle and rolls on it and you put it out into LinkedIn lots of people will have an opinion, depending on which word you use

Murray: I agree with your summary Shane. I suppose all I would add to that is that teams need to recognize that they need business skills and design skills from beginning to end when you’re setting up a product team and it’s so common for people to underestimate that or just leave it out. And that’s typically because so much of this agile stuff comes from and is set up by technical people and, lot of technical people underestimate or forget the importance of all of that other business stuff. 

Shane: I can’t imagine a scenario where you would only have a team of software coders. If that’s all you’ve got, when you draw out the TKI matrix I’d be guessing that you are pipelining, that you are waiting for other teams to deliver something to you and then you are handing over to another team for me, there’s not the best way of doing it. There are better ways in my experience. 

Murray: Just one last thing I wanted to add is I’m talking about one product team that goes across organizations. So if you have Accenture and Deloitte and KPMG and your own staff working on a product, then you make them part of the same team, they’re one product team. And we don’t wanna know that they work for a particular consulting company. We don’t want them fighting for their consulting company’s revenue. We want everybody to be part of one team across all of the different departments and organizations that are developing that product us or with us.

Shane: I agree. The majority of teams I work with end up being made up of permanent employees. I think there’s no reason why it can’t work when team members are employed by another organization. But in my experience a whole lot of new problems turn up when that model’s used. So if you’ve got, other organizations, people involved, they should just be part of the team providing the skills that the team need. 

Murray: All right. Thanks for that, Shane.

Shane: All right. Catch you later.

Exit: That was the no nonsense at y’all podcast from Marie Robinson and Shane Gibson. If you’d like help with agile contact marie@evolve.co that’s evolve with zero. Thanks for listening.