DIESEN PODCAST GIBT ES NUR AUF ENGLISCH

Abonniere den Podcast

LINKS

Episode 10 - Should Scrum Teams Always Be Cross-Functional?

Transcript

(disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)

foreign

 

sessions podcast here in Dallas I am q and I was always with my friend in Berlin hi everyone my name is carrion and welcome to the podcast Okay so girion we talked a lot of a bunch of stuff today in the scrum sessions itself we had some great discussions right yeah but one thing we didn’t have time to talk about is uh do we need teams that are specializing something because everybody tells you we have to have t shape T shape T shape everybody can do everything and all that stuff there’s a lot of misconceptions about what she’s shaping means and uh is everybody t-shaped or is there a place for a specialist team what’s your take so I’m actually sensing that we’re going to disagree on that so first of all um especially for the beginners I think it’s really important to understand whether t-shaping is coming from and what it means right so traditionally you would have traditional Orcs with silos right you would have a bunch of marketing people in a department you would have a bunch of Finance people in the department you would have software development in the department right and a lot of the delays and problems arose from that structure of the organization were you know is for example as as the marketing people you talk to the customer and you found out some requirements right and you had to hand them over to development but then there would be delays and you wouldn’t know who to talk to you wouldn’t know how to talk to them Etc right and so scrum is breaking all of that up by saying well this actually doesn’t make a lot of sense these functional departments function on Silas let’s just take one Finance person one marketing person once after developer one Hardware developer whatever it may be whatever you need to get the job done and put them in a small team together so they can learn from each other and so they have all the skills that are needed to actually get something done right and so I think this is very important to understand the context of of the debate and actually I’m going to push back a little bit why would she even have none cross-functional teams do you see any reason for them well you see I think we’re gonna get into the idealist versus pragmatism discussion I agree with you as much as possible I want to have a cross-functional team of course right and not only that I want people in the team to be able to do more than one thing they have a broader skill set as well as a deep skill set right so when I was writing code I was really good into doing anything scene related C sharp straight C C plus plus right but also could do a bunch of other things one of them was architecture and then eventually learned this thing about scrum and I start doing scrum things right and my brother’s queue what at the time was a scrum and up becoming one of my deepest skills a decade later right so I’m not against it however you also have to be understanding that some skills take a long time to develop and uh some situations I’ll give you for instance projects that involve defense Contracting that are highly confidential highly compartmentalizing Etc some people are specializing for instance radar or or heat seeking sensors and all that stuff and it has to be that way because they created that component and that component for instance a sensor is going to go on a missile right a heat-seeking sensor is going to go on a javelin for instance that’s going to be used in combat to bring down a tank and Etc right now it doesn’t mean that everybody in that team that’s building that sensor has to be a specialist but there is a certain level of people in there that’s going to be highly specialized and highly segregated so that’s one situation there are a few more that I can think about but that’s my point of view so I don’t think we totally disagree I just see there are like everything in life exceptions to the purest to the idealism that song wants to have and yeah I’m not quite sure I agree so for example if we were to say that being a scrum trainer is like you know very difficult to achieve it takes a lot of training to get there and we would be talking about an agile practice for example right an angel Center of Excellence whatever you want to call it um we still wouldn’t put just five scrum trainers on that team right who would still make it cross-functional and say okay so we have a scrum trainer we have a team coach we have an Enterprise coach and so on and try to still make it as cross-functional as we can so just saying well they need a high skill level it’s somewhat tricky for me and and the reason why I’m saying this is the following I I’m not sure I actually disagree with you I just see too many people always using this excuse for not making the change over to cross-functional right they’ll always come up with some sort of some sort of excuse always saying well we are different we are in a highly regulated environment we have this we have that and they can do it but they are trying to find excuses so I’m not quite quite following on this like high skill level set no I I totally agree with you and one thing you probably heard me say multiple times is I do not tolerate people saying that with the excuse of customization that that doesn’t work here because that’s just hiding a shortcoming okay and I don’t agree when people are hiding shortcomings with the excuse that’s not gonna work here I working plenty of regulated Industries and we did a bunch of things that other people in the industry say cannot be done no it could be done you just didn’t have the the world to be done because people don’t like Chinese right yeah however I’ll give you an example where a specialist team is not necessarily a bad thing I had clients in the past that of course we have to automate tests right who in these days especially in the software business is not on automate test and it’s not even in a software business for instance in Harbor if you get a full double phone right they have those machines that keep folding and unfolding the phone has to be automated you’re not gonna put some guy in there and doing this on the phone right but when we automate things there is also the need for consistent for consistent results in testing and Etc right and what I noticed over the years is if you leave okay this team automates this way using some tool this team automates there’s using a different tool and Etc right it becomes a bit convoluted right so what we did in the past is okay let’s try with a community of practice people come together and they talk about this they try to extend our dice tools and etc etc sometimes that work sometimes the community or practice is seen as just say hey I’ll go there and I have time right so what we notice is creating a team specializing in in test automation that would come up with infrastructure select a tool etc etc and create actually some canned resources that people can use in conjunction with the community of practice and in conjunction with the other teams so what happened is Discord group of people they would do a lot of the foundational work they would expose that work through the community of practice the other teams would consume that work but they would also contribute to getting that testing harness better and better and better so we had testing people at the team level and we never had dedicated testers testing was just part of the G shape of some of the team members but we also have a team that coalesced all the information who brought everything together who created the standards and Etc and we had the debt exposed via a community of practice yeah and I mean the way you explain it it sounds like like even within that test automation team they are probably still somewhat cross-functional inside of that whole theme right so somebody has a focus on this kind of test Automation and somebody on a different one yeah I can see that and um yeah so so I’ll I’ll give this to you I think there are some cases just in general I’m a little bit allergic to that because in most of the situations people just try to stay stick in that old kind of way of of doing things and so I do see some things and actually while you were talking like one thing came to my mind that is really a little bit tricky so let’s say we don’t want in scrum we don’t want the teams to get too big right and let’s say um we have one marketing person two back-end developers one front-end developer and maybe something else right and so what happens if the marketing person is just out of fresh out of University right how’s she going to learn how to be good at marketing if she’s alone with people that are not interfunctional class right who are not marketers right if I’m a market beginning marketing person right I went to University but that doesn’t teach you everything you need to know and then I come into the company I’m joining a team which is really great because I’m learning all these different perspectives and what’s really needed to get product to production but how am I actually going to learn how to practically do marketing if I’m surrounded by developers all the time yeah well that’s the point of having a community of practice right having a group where you can learn from other people and you can also I am assuming the company have enough space there that there are other marketing Specialists with where you can learn by pairing with them right the concept of apprenticeship that I so much love as you know right but um I think is still there has to be a way to aggregate that skill as a community so everybody can benefit from Lessons Learned and the things that are new and people bring and you can bring speakers to the community of practice external to the company and Etc so there is that but things like testing things like architecture for a large corporation you have to have an architecture group I am not saying they are going to be the dictatorship that says this is the way you’re gonna have it but they can coordinate all the good ideas because good ideas come from everywhere right and propagated as ideas one of the things that uh we talk very much on the in the agile communities the learnings the learnings the learnings we talk a lot about the learnings right and I always tell people how do we propagate them well this team learn and they are learning all the time I said yeah but you have to propagate their learnings to the other teams in that group of teams to the department to the whole organization it’s important to propagate knowledge is important to gather ideas from everywhere so when you have a team that can collect all of this create a structure around it and people can work to better that we I see the role of a specialized team calls this a knowledge team and say if we have the concept of a systems team right but we should never use that to hide a shortcoming with the excuse that is not going to work here or how we are different than everybody else yeah so we agree that you shouldn’t go back or stay in functional silos right we say you should be as cross-functional as possible however don’t be dogmatic about it right really really really try it do it as much as you can but sometimes there are situations where it’s actually smarter to have like a like an infrastructure team like a virtual team like an expert team is that how we see the thing the thing yeah that’s the way I see it you know and again I have to re-emphasize this silos are a very bad thing because silos create bottlenecks bottlenecks in paid flow and you know I am a maniac for facilitating flow uh every every other word out of my multi is usually about product or is about flow right so we should never create silos and sign was also create group thinking which is something we’re discussing offline yesterday right group thinking get gets very prevalent into companies and creates a lot of damage yeah so let’s be very careful with that yeah it’s extremely dangerous yeah absolutely so like the way I like to to always talk customers through it is like to just ask them a series of questions right and so once they know cross-functional teams are very useful I ask them well would it make sense to have an I.T architect on every team and then they’ll usually say no right because it doesn’t make sense right sometimes it might but usually it doesn’t right and so then I ask well if you have team of teams like a couple of teams working very closely together maybe on some component would it make sense to have one it architect for every team of teams and then they might say well maybe yeah you know we have four or five teams and maybe it makes sense to have an I.T architect or some other specialized skill in there and then I asked them well does it make sense to have them in a separate team because let’s not forget sometimes they need some physical info infrastructure right maybe they need a clean room or some kind of really expensive Machinery right and it doesn’t help help me to have that expert on my team when I’m very far away from that piece of Machinery right so maybe I need to have a have a specialized team for that so how how do we connect those specialized teams into our regular spring Cadence like if I need something from them how do we like make that work oh we can make the server ways right like animation you may have a group of Architects for the whole organization for instance right and which is a central point you can have small nucleus of Architects for each one of the Departments or investors right so there’s less people around the involved but they’re always talking to each other and they’re talking to the teams I had situations that we had an architect with a team for a Sprint or two or three to help them out with something they didn’t know to transfer knowledge to help sort of pair program right apprenticeship help in there but once that work was done they would go back to their original team right team of Architects and sometimes they would be there for a while working through something right infrastructure stuff or they would go somewhere else to another team and we even had across divisions people moving from one division to the other to help out and what we notice is that eliminated dependencies for instance right because a we don’t have knowledge about this okay so let’s put this on their backlog and then there’s all the coordination problems with that and we notice that by moving somebody from that organization into our organization to help with testing architecture or data science or whatever the case was we eliminated a lot of dependencies those things so I’m not advocating that we have a silo but it’s good to have these teams that are Specialists that we can allocate temporarily where they’re needed the most yeah and that’s the business case that I make for the existence of that team but I like them to be part of an overall community of practice so they don’t become the dictatorship and say hey we told you to do this way this is the way you’re gonna do it and they suggest they inform people and then we can proceed with whatever the solution is it’s more appropriate to a particular domain team organization yeah and I mean if if you can’t have them travel around between teams you can always do like a service level agreement or something with them so we need the clean room or the Machinery right and let’s let’s discuss and figure out like what kind of service level we can expect if it’s you know let’s say we need it in three days with like a 95 percent guarantee that will be done right and this way you can actually connect a lot of different parts into your agile systems yeah and I actually see the place or system teams or knowledge teams whatever we call it in increasing uh engagement at Team level right because one of the things I hear from scrum Masters and teams is oh Q I’m gonna get pigeon hold into doing this for the next six years or no and I would like to learn something different I want to do something different than the training yeah they pay for training but training I go there for two three days I come back and sometimes I don’t even use this ever again right when we have this traveling let’s call them ambassadors right ahead that go around they you can be learning from them yeah right you can acquire new skills from them real practical skills because he or she is there to help you for necessary with test automation so if you’ve never done that before it’s much better than a training class you are learning by doing it right but in order to propagate that knowledge we have to have a specialized team where people dedicate themselves to this so they can coach they can mentor they can teach other peoples around the organization but they also can standardize things as much as we want teams to be self-managing you cannot have one team we’re using one tool and another team and the same department or organization using another tool to do the same thing yeah you’re creating waste doing that right and in order to have standardization it again it’s not a dictatorship but we have to at least have a conversation and have people created that standard and then we can use the standard or modify it with contributions from everywhere and I don’t know if if you’re noticing but I’m suppressing an evil grin because it actually it’s helpful for the Ito architect as well right if they’re traveling because it keeps them real because I don’t know if you know this expression PowerPoint architect right you have people that are so disconnected from reality in the position of it architect and of course uh a lot of other and different specialized um positions that they just don’t know what’s going on anymore and they’re just living in their own world and making up stuff in PowerPoint that’s really not not feasible in any kind of way yeah good point so I want we actually mentioned that we mentioned that when we talked about pet peeves right Enterprise coach they said I don’t care what the teams are doing you know I mean that’s not my job you know I I want them to do this but uh the last time I had a team was 12 years ago you know so exactly yeah and I wanted to mention one more thing because this is something that’s really getting under my skin and that I think is is really an unhealthy Trend which I’m seeing a little bit more than I used to and so when we were talking about t-shape for those that don’t know we are talking about the letter T right and meaning that you have you’re an expert at something right and so you have a long stem and then you also have some capability in other fields like you were saying okay so after some time he was the expert in scrum right but he also knows how to code and he also knows some other stuff right and this is the way we want it to be to be more resilient than for a couple of other reasons but the thing I’m hearing more often now is that you shouldn’t actually be t-shaped but pie shaped you know the letter Pi 3.14 right and it has two stems and this really drives me crazy because I think this is kind of the theme of our times right we’re always demanding too much from people right it’s not enough to be an expert anymore right because this is what t-shaping actually says it says you have to be an expert and you have to be some more right so we’re already asking people to be experts we are already asking them to be more than experts because we would like them ideally to do uh some more things right and now some people are coming along and saying well you need to be expert at two things and then know some stuff and honestly give me a [ __ ] break people this is too much you’re demanding too much of people and let’s just try to have people t-shape this is working very well this has been battle tested and don’t just keep asking people to add stems to that it’s not possible right and usually those people that talk about it are not expert at anything right so please please please if you hear this pie shape thing please think back to us and please don’t use it anymore because you’re just demanding too much of people and it’s it’s really not helping here which brings the point of cognitive load right there is so much you can handle there’s so much you can learn there’s so much you can practice and you’re gonna end up like you mentioned a master of absolutely nothing yeah and uh you’re also gonna be awfully stressed because of that yeah so I I believe that it’s good to have primary skills the the bottom of the T and the additional skills in here we always have to be able to do a lot a little bit more than just this thing in here right otherwise we don’t survive yeah now asking the person to have the the base of the tea is this wide or there’s two bases for the T right and then that’s even worse that’s cognitive load gets to the point that you’re gonna be over stressed and underproductive right yeah and a lot of people talk about team happiness but uh nobody is gonna be happy team or person or whatever with a cognitive load that’s just destroying your brain so I The Specialist teams help alleviate a lot of the cognitive load but this is not a license to make a silo of everything and have specialist teams for everything and because that actually slows down the system and impedes flow through the system so we have to be careful not to just assume that one solution takes care of everything and we should be very careful not to demand from people now then it’s beyond what is humanly possible to deliver right we can use automation we can use AI we can use a lot of things to help us out into achieving a mission without trying to overload somebody and then having some really bad results yeah very good

 

I think that’s it for today my friend and uh next month will come with another interesting subject you know hopefully interesting you guys can watch yeah or find some interesting things the the latest ones have been very interesting right from the feedback we got today from the session so um you guys feel free to Ping Gary on and I any any way shape or form either to the to the through the streaming platforms we’re pretty much everywhere right to LinkedIn to our emails we always want to hear from you guys like us up and the platforms give us feedback suggest ideas we’re always looking for stuff so we can help people do a better job in being an agileist right and that’s it for today that’s for this episode on the podcast here in Dallas I am q I hope you liked and I’ll see you next time carry on up to you and this people is cute for you he says everything that has to be said and then he says after you get it up yes so thanks guys for listening and I hope you join us again soon and goodbye from Berlin bye