#046 - Team skills vs roles

Foreign.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

This week we're going to talk about what makes a team. What roles or skills or who do you need to be in it.

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 going to 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 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.

I agree. The idea for me is removing those dependencies. We want a group of people, let's call them a team, who can take it from the idea all the way to fruition.

Yeah.

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.

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 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 if 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 got to 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 they 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, frequent analysis, put them into the team as well. That's what I'm saying basically, and I agree.

So all the skills you need should be in that team. Yes, 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 organization's in a silo and it behaves in that hierarchical pipeline y 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, it takes will. So when you're doing agile, you can say we're going to challenge the current structural hierarchy of the organization because 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 they 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 I 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 fifty thousand dollars, 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.

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 assigned as roles, not skills. And we should be talking about the skills in the team, not the roles.

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're 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 going to be called a UX UI designer. They're probably going to be currently sitting in a design team and if you don't call them a UX UI designer, nobody is going to know what you're talking about. So you have to call them that, even though when they're in the team they're going to be a T shaped person.

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 team. 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. 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 analyst. 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 tee. 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 the 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.

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 recommended. And of those, four of them are coding and four of them are not because they don't have coding skills. But the objections to it with 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.

Ideally they don't, but it just reinforces my message that as soon as you write down a diagram with a role of UXUI designer and right next to them, software developer, and then quality engineer, people infer the designer's going to do the work and hand it over to the engineer, the developer, who's going to hand it over to the quality engineer. Even though you didn't do it in linear, you did it in a nice circle. But that's what people do.

But you've got to explain it some way because if you're going to go and recruit people for these roles, you've got to 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 going to be any titles or roles. It's just a stupid thing out of Scrum, which this 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.

Nirvana is everybody is at a coach level and therefore anybody could do anything. We know in reality that's never going to happen again. I'll reinforce how I say it. I 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 at an expert level. You would typically find that with somebody who's had the title of senior BA in the past.

Why not just call them a BA in the team and just get everybody to agree that they'll do other things as required because they're T shaped. It's easier to say this is a role within a team that is going to be done in a T shaped way.

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 the 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 as 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 it's just called developer.

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 was quite a bit of pushback with people saying, who are all these other people who are not software developers? It's too much overhead.

So when I'm working with my teams and they say, what's this developer role? I explain to them that in Scrum there's only three things. You can be the product owner, 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? 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 and 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 automagically thought overhead. Talkie talkie. No, dooey dooey. 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 talkie 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 known definition.

Well, I noticed 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.

It's interesting though, isn't it? Because 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.

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.

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

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

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 into it. 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.

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 is 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's 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.

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 and 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 a novice or practitioner may have missed. But it's not a hierarchy and that's as soon as we apply a hierarchy on it. That's just wrong. Oh, it's not wrong. Sorry. Because nothing's wrong. It's not an approach that I would recommend.

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.

So I say bollocks to that and use it because it helps us understand the gaps. But if you're in an organization that will turn it into a hierarchy and use it for evil, then don't do it.

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. I don't really see anything wrong with that as long as they have the right behaviors. See, 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.

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 have experts, and then some people who are tech leads. That last sentence, it doesn't go because we're now taking a hierarchical role and 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.

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

I strongly suggest there is no hierarchy at all in a team.

What about in an organization?

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 have achieved my goals with a hierarchical organization. My answer now is never have an organization that's more than 15 people and you never have to worry about a hierarchy.

How are you going to scale up then? Shane?

That's the problem. You don't, right? You just end up with a company of 50 but you don't have the hierarchy problem and life is good.

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 out of 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.

I was just thinking, now you put sports into it. I was just thinking about that most awesome team, the All Blacks.

You have roles in the rugby team, don't you?

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 one game and then on the bench on the second game. We've got three or four really strong fullbacks and they can actually go in and play other roles in the team because 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 ten, 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.

Everybody understand what each other's doing.

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.

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 going to 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 because 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.

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 upon 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 going to be a little bit harder because each person has more variability in what they paid.

I don't think everybody should be paid the same amount. They got to 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 will go up 30% all of a sudden.

So I'm just thinking through that as you talk. So what we do it 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.

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

I don't know now because 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 in your diagrams has tested part of the market to say it's probably not the right word. So I don't know. I'm going to have a think about it. I don't know if I, if I'm going to change it or not. I'm not sure I can find a word I'm more comfortable with.

You could call them a lead.

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 give me a problem. Thank you.

Not the other one. Shane, is what should you call the scrum master in a team that's not doing scrum?

I think you should call them an agile coach. I think the idea of an 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.

Scrum's 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 B.S. in my view, because that's exactly how you define a role anyway.

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, halftime and a developer. The other halftime. I have to think through some of the way I describe things and change it.

Well, 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 the organization will divide them over two teams or even more, which is bad.

So I'm going to 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 let's take the rugby one. You hardly ever see the head of the All Blacks running 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 were too cheap to do that because 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. She was doing 20 or 50 teams and that was hard.

I've been a hands on scrum master a 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 BA and 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. It's pretty easy in only half your time. I think.

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

Should we call them a scrum coach from now on? Shane, since we object to scrum master, I'm going to. Yeah, I like that too.

It doesn't help me when I talk about novice practitioner, expert and coach because now it's saying you have to be coaching level to be the scrum crunch. And so again you've broken my words so I have to go and fix them.

Used your words. You persuaded me Shane. And then I got in trouble for using it.

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 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. Heracle. I think we should start using scrum coach. I think we should remove the word master.

I object to master as well. So the scrum coach. Fine. So if they're in A product team and the team is doing things other than Scrum, and maybe they're not doing sprints anymore, then we'd call them an Agile coach because it's bigger than Scrum. Could include Scrum, could not include Scrum.

Should include parts of Scrum, because parts of Scrum have value.

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

Or they should be able to pick up some of the stuff from Flow or XP or Lean. Again, we pick up patterns from all the Agile ways of working and we apply them where they have value. And an Agile coach should know more than Scrum.

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.

No, 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.

So should we use terms that people are familiar with Chain, because it's easier to communicate with them?

The answer is no. But I still do.

And that's really not fair, is it? Because I thought this was going to be a great podc 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, 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 systems. 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, oh, it's an IT technical Business analyst.

So that's an interesting one. A 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. They've got a bunch of skills that are highly valuable in a team that's rolling something out so they can be a member of the team because of those skills. Now, we've got to be careful when we're 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 going to build or the next focus area, then really they're a stakeholder because we only value them for the knowledge they have on 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.

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 just makes a team much more effective. And there's usually one person who knows that and they do end up doing analysis as well, because probably they're called a business analyst or a business process analyst back in the operations group that they're in.

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're dealing with will often change and the part of the hierarchical organization we're adding value to will change. And so in that case, what I say is that the product owner 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 train 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 going to ask you questions or if it's remote, in the morning of every day, we're going to ping you whenever we need to.

I just find that teams work much better when everybody is full time than when some of them are half time. Because when they're half time, you have to wait for them. So it just introduces all these slowdowns and delays and on. 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 owner's too busy to be there full time and the subject matter expert's too busy to be there full time. So we make compromises. The compromises hurt. They have consequences.

I suppose they could be half the time. Let's say you do need a couple of business subject matter 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, because 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 out of the organization. Sometimes people will come and go because the team is going to change its focus. Maybe they're changing their focus from developing new features to marketing the features. My key point is you want to have a designer all the way through from beginning to end, somebody who's skilled at testing all the way through, somebody skilled at business analysis all the way through. People who's skilled at software development all the way through. So we want to have all those skills all the way through from beginning to end, not just in stages.

Yeah, no, definitely. We don't have those skills dropping in and out. And that's why people typically have a strong skill, a strong T 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 typically 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's 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, then picking up and doing that works to his 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 always something they can do that adds value.

And the way that happens is that the team talks to each other. The team is self managing. They work out amongst themselves who's 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 because we're not strong enough in it.

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.

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

I agree. I think we come back to those core themes which is the team should be end to end. It 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 role so other people understand where they find those skills, but we're talking about skills in the team, not roles.

Yeah, we want everybody to be multi skilled and T shaped. But we recognise that people do have different levels of skills within the team. Some people are novices, others are practitioners, some are experts and some coaches.

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 because everybody takes a servant leadership approach of helping each other rather than dominating each other.

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 and the way they work with those skills. And more importantly, if you do a diagram with a circle and roles on it and you put it out into LinkedIn, lots of people will have an opinion depending on which word you use.

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 a lot of technical people underestimate or forget the importance of all of that other business stuff.

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 TSkill matrix, I'd be guessing that you're pipelining, that you're waiting for other teams to deliver something to you and then you're handing over to another team. For me, that's not the best way of doing it. There are better ways in my experience.

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. We don't want to 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 for us or with us.

Yeah, 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 is 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.

All right, thanks for that, Shane.

All right, catch you later.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with agile, contact murrayvolve.co. that's evolve with a zero. Thanks for listening.