Emily Bache - Technical Leadership and Empowered Teams

[Applause] hi thank you so much I'm very happy to be here at the craft conference let me just introduce myself a little bit I'm a technical agile coach with pragma and I speak at conferences and I wrote this book a few years ago about coding dojos how to learn test-driven development and I spoke at craft a few years ago on that topic I'm based in Sweden but I grew up in the UK do you get in touch with me on Twitter or email so this is a talk about technical leadership and that naturally brings us to a discussion of Architects and architecture so I wanted to start with a slide showing a beautiful building a beautiful piece of architecture this is a church in Barcelona and it was the architect of this incredible piece of architecture is Gaudi who's very famous they started building this building in 1883 and Gaudi was the original designer and architect on the project and they're still building it and he died in 1926 so this is perhaps why I'm not so convinced that architect and architecture is the best metaphor for what we do in software I don't think that in software you can do all the architecture work and then leave or die and then they're still building the thing like a hundred years later that's not what kind of how it works in software so I'm pretty skeptical to this whole architect architecture analogy in the first place but then I also wanted to tell you a little about my experience when I was a young software developer quite new to the industry 15-20 years ago Architects in my organization they were these distant figures who kind of they were somewhere in their ivory towers coming up with beautiful documents about what I should be doing and it just felt really quite irrelevant I think these people had the best of intentions and probably they were very competent but they no longer wrote any code and they just didn't feel relevant to me today I think we live in a very different kind of landscape and I hope that everyone is working with more modern methods and has more help from their technical leaders because that's what I think architects basically are they're they're leaders with very technical advice to give and the whole purpose of the the leadership is to help everyone all the developers to make better choices in their daily work and that's what I the kind of technical leader I aspire to be today now that I'm in that senior position I want to be the kind of person who's helping everyone to make better decisions so that's the theme I'm coming back to but these days of course we're all working in agile organizations and I like to tell this story to illustrate what I mean what what I think this illustrates agility really well so this is a tweet exchange that happened a few years ago the the first tweet is the owner of a a Tesla car and he's complaining and saying look when I want to charge my car the spot for charging is always full of of people have just parked there even if their car is already charged so very surprisingly the the head of of Tesla and on musk actually responds to this tweet and says yeah this is a problem I agree we should do something about this and that in itself is surprising enough that that customers are getting direct contacts with the company and even the higher levels of the company but then what really like I like about this story is it was just six days later six days after this tweet exchanged Tesla rolled out an update all of their cars so that if you were standing at a parking spot and your car was fully charged at a charging spot you would be charged an idle fee of 40 cents a minute which is enough money that it was cheaper to move the car to an actual parking spot and of course this solved the problem people were no longer filling up all the charging spots so I like this story because it illustrates some really important aspects of agility being able to understand your your customers your users that the company is is taking notes and able to respond with a change in their software in a matter of days a timely timely updates and that's what we want for agile we want to be able to respond to what our customers need in a timely way so these days we're all working in these agile teams trying to achieve this agility which is great and I've just got some quotes here about a scrum and extreme programming and safe and they think they all say basically the same thing that in agile you have self-organizing & cross-functional teams and all the necessary skills are present in that team to deliver the software that those customers are going to be delighted by so this originally agile teams were quite independent and you would have an organization of you know one scrum team or one XP team that would deliver the product the organization's I work with today more typically have a lots of agile teams and they're typically collaborating on the same product or the same product landscape and you we divide them up into different value streams or perhaps some team is looking after a particular back-end service or a particular piece of infrastructure but these days it's it's we have a lot of teams basically and they're all supposed to be cross-functional and self organized and this is great but what I'm seeing in in the future is that these teams are going to be even more strong even empowered and I get that from this book now this book has come up a couple of times at this conference already so I'm hoping some of you will have read it it's a book about the science of DevOps and one of the authors is Jess Humble who is here and he gave a talk yesterday and what I really think is significant about this book is it's about his research he's done with Nicole for scren and they have done over several years they've surveyed thousands and thousands of people and they've constructed scientifically relevant hypotheses and done proper statistical analysis on them and they've worked out some of the practices that we as software developers do that then lead to success for the business as measured in the real world you know making money basically so it turns out that it actually matters what we as software developers do for the success of the business we work in but that in itself I think is a fantastic conclusion and then they of course then go into more detail about what it is that we should do that would make a difference and one of those things is is you know stuff like continuous delivery trunk based developments lots of DevOps practices but what I really wanted to pick out in my talk today was this piece about empowered teams so they found that organizations that have empowered teams are more successful in the marketplace they make more money and they characterize empower teams quite specifically and I'm going to go through that what they mean by an empowered team it's more than just a self-organized team they say well an empowered team can make large-scale design changes to the software they're working on without detailed coordination outside of that team they can deploy their software on demand when they want to when they need to and they do their own testing without waiting for some integrated test environment that they share with other people so this all sounds fantastic as a software developer I'm going to be in control I'm going to be autonomous I'm gonna be able to empower and I'm going to deliver my stuff but then if you look at this from the point of view the architect or the technical lady you're like yeah what could possibly go wrong here this this might have some downsides I'm not entirely sure about this I mean you've got this this landscape of all these teams and you can kind of think okay I've got all these teams that I'm kind of technically responsible for the architecture of and they're each going to be making large-scale design changes to their system without getting my permission and what's going to happen in a few years is we're going to have competing standards we can have data fragmentation in consistent user experience we're going to have code duplication wasted efforts unhappy developers and that can all come and shout at me because they're gonna say it's my fault so this is a very different world for a technical leader than the one that I experienced 15 20 years ago if all these teams are really empowered that is a challenge and I think it's quite clear that if your teams are empowered this architect can't be this remote figure who is dictating things and expecting stuff to happen they really have to get off this this ivory tower and get down to earth and start actually helping in a different way so I think when it comes to technical leadership of a bunch of empowered DevOps teams the leader has to behave quite differently and then the aim is still the same of course you want the developers to be making good choices but the means of achieving that I think you need to change quite a lot I think basically the the leaders cannot be slowing down the teams you can't put barriers in their way that's kind of what the empower team thing is about you have to be seen as help not a hindrance so you can end up what you need to do then is turn into the good person who is giving gifts the architect is they're giving timely relevant advice when the team's need that advice kind of on demand and they are that the teams want to follow this advice because they trust the leader knows what they're talking about they have respect for them and they appreciates the the experience that they're bringing they can give gifts of convenient libraries and convenience useful deployment tools and all sorts of other pieces of software and infrastructure that is going to help those teams and I think this is this is just basically a mindset change the architects with we're doing this kind of thing before but now they have to realize that the what they're doing is giving gifts and gifts sometimes are rejected so this is a different mindset for the technical leaders but I think it's more productive for everyone so I wanted to talk about my own experience when I worked in an organization for several years where I was in a team and we were the the most experienced developers in the organization and we were there to support all the other development teams there other teams were responsible for delivering features building stuff we were responsible for making their life easier and making it easier for them to deliver features and my major piece of work over those years was a test automation framework that I was very proud of and I think was helpful for them and it meant that the development teams knew the best way to write their their tests for whole features that would impact several micro services so this was good but looking back on it I was working alone most of the time and I think that was the big mistake that I made at that time I should have spent a lot more time with the developers understanding what they needed in in their test framework and training them to use it so that's something that I learnt let's talk a little bit more about agility I just mentioned before agility is about responding to change and I like to use an analogy for how we can affect how quickly we can respond to change we need to be able to win those customers ask for something we want to be able to deliver that software in a timely manner so the first thing that's going to affect how long it takes if you're baking a cake this is the analogy I'm using baking if you're going to bake a cake it's going to take a certain longer if it's a complicated cake if they have you must have seen bake-off you must have cookery competitions in in this country this is what I'm talking about you know you've been asked to build this amazing chocolate creation with five layers and four different fillings it's gonna take you longer than if these are some brownies that you're going to take along to your football team and give them a halftime so it does matter how complex the feature you're being asked to built is is it a really elaborate thing that's going to take some time to build or is it quite a simple feature that's just adding a new button on an existing form the next factor when you're baking a cake is how skilled is the chef and this is what the baking competitions are measuring of course they want to know how skilled you are at separating eggs when you have to redo it all because you've got some yolk in the wrong bowl and you're gonna have to break another 24 eggs you know or can you make the chocolates so beautifully tempered that you can create some amazing thing or whether you're going to have to content yourselves with doing it twice in the second time it doesn't quite look right and it's all these skills as a baker that you need and I think your software developers it's similar we need to know our tools and how to use them and we need to know our programming languages and how to use them and the the best programmers I know are so good with their tools and their languages that they they produce stuff so much faster good stuff than the the less skilled developers so I think skill plays a role in how at agile you can be and the last factor that I want to really highlight is the state of the kitchen if you're in a cooking competition of course you walk into this amazing kitchen with this clean work surface and all the tools you need it exactly there and the ingredients are on hand and everything just is gonna be set out for you if I'm gonna bake at home sometimes it's not quite that easy some of the tools are buried in the back of a cupboard and and there's some piles of washing-up in the corner and it's gonna take me longer to bake my cake in that environment I've got to spend some time doing a bit of washing-up cleaning gotta find my tools and that's I think the same with software the environment that your software development team is working in makes a difference so for a software developer the environment of course comprises the IDE that you're using and that that build tools the the debugging tools the the testing tools the deployment tools lots of tools but also the existing code base of course software developers spend an inordinate amount of their time reading the existing code and it matters how clean it is so this is basically my analogy that how quickly you can respond to change will depend on these factors maybe not added in a linear manner but in some kind of function of these factors so this is what I'm really talking about with technical leadership is how can we make that kitchen as perfect as possible for these developers to work in and how can we help those developers to become more and more skilled so that they work more and more effectively so agility is about infrastructure and skill for technical leaders I would say I want to have the kind of kitchen available to my developers where it's easy for them to make good decisions that it's obvious what the right tool is it's just there in the cupboard they can take it out and they can start using it it comes with instructions it's easy intuitive they have existing code bases that are possible to work with they they know that when they come in that's your storage your deployment pipeline your testing framework and if you want to use another tool okay you're an empowered team you can choose another tool but really these ones are easiest take these ones first the other thing the architects need really to be able to achieve this then is that you have to understand what the teams need and what tools to build for them and provide for them and you need to communicate and teach them to use the skills that you want you you you don't want to discover your team using a wisk that's just a fork when you provided them with an amazing machine that whisks you know they have to know that it's there and how to use it so let me talk now about mob programming now because I think this is really part of the solution to the the situation that I've been outlining here more programming if you haven't heard about it I'm just gonna summarize it's a structured collaboration for a group of programmers coding together all on the same machine would ease all one of the co discoverers of the technique describes it as all the brilliant people working on the same thing at the same time in the same space on the same computer and that's that's really what it is it's a collaboration of a group of people working together if you've done any pair programming then you'll know this this concepts of two developers working together on the same machine and that this can be a powerful technique for collaboration and producing quality code and it isn't actually as slow as everyone makes out that it should be when you've got two people doing the work of one no actually you work better when you're two and mob programming is basically just turning up the dials to eleven and having the whole team for it to work though you need a little more structure in my experience than you do with pair programming so we talk about roles and in the mob so the most obvious role is the driver that's the person who has the keyboard and their responsibility is to enter the code into the computer that the whole mob is using you're going to rotate these roles relatively often so it's important that everyone is competent with every role the next role here I've highlighted is the navigator the navigator the person who is instructing the driver what code to write into the computer so they are actually the ones who are deciding the direction of the code the driver really is the easiest role they just have to type whatever they're told they can make decisions about how best to use the IDE and the shortcuts and the menus and stuff but really that's the only concern it's the navigator and the mob who are deciding the direction so the members of the mob who are not currently navigating are there to assist the navigator when that's needed or take over the navigation when that's appropriate and their job most of the time is just to make sure they understand what's going on so they are ready to to contribute and if the navigator needs help they are ready to prompt them and coach them often there is additionally a coach who is not really a member of the mob who is there to actually just facilitate and makes everything work more smoothly so that's the roles the working agreement is very important to establish that everyone in the mob is agreeing that's we treats everyone in the mob with kindness consideration and respect this is important for the relationships if you get a group of software developers together in a room and ask them to write code together it may happen sometimes that there are differing opinions about how to write that code I think that could happen and the thing is when software developers have differing opinions they might get a little bit worked up and enthusiastic about their chosen approach so it's it's good to know that they've already agreed to treat everyone with kindness consideration and respect even when they're right you know so at some point it might happen that people can't follow this agreements and that that's a situation you might ask them to leave the mob just until they can calm down enough that they can return and follow the the working agreement so this is also important in the mob it's full of people people and relationships are hard but if you can get people to collaborate like this it really does have a lot of benefits and I'm talking from my own experience of mobbing but also from these books which I wanted to highlight this first book here is by wood easel and Kevin Meadows and this is published on lean pub what is all this one of the originators of this technique and he writes very well this other book is actually one book and the two authors of it started the book together and unfortunately they didn't finish the book and they are currently in a dispute over the copyright so you can download the book from either of the authors at present and it's not finished but it's still worth reading it's got some good stuff in so I've got a picture here from Woody's book this is his team that he has worked with previously and he want has included this picture in his book to show what it looks like when the mob is working effectively you can see woody standing at the back there and the members of the mob are there and one of them is using the keyboard to enter code into the computer but there are other computers there there are other keyboards are the mice you don't have to all use the same one the other computers can be used to a research and help the mob in other ways then you can look at the same picture from the back and you can see they've got a really big screen and it's actually duplicated so everyone has a really good view you've got your white boards at the side your team status board you can always refer to your next task and people of course when they hear about more programming thing this must be really unproductive we've got all of these things we want to increase our velocity we're having pressure we yeah measuring productivity in programmers is really hard as I think this cartoon illustrates really well it's really hard to measure productivity because you can game the system it's very easy to raise your velocity if you all agree to increase your estimates so perhaps it's not so useful to look at measuring productivity as basically acknowledging what kinds of things reduce productivity and I've just got a short list here of some of the things that you might mention if you asked about as a programmer what makes you less productive context switching I don't understand the requirements the code is terrible and my best team buddy is off sick I don't have the credentials for the test environments I can't look in the database you know all these kinds of things slow you down but if you put your whole team in the same room and get them collaborating and working together in a mob then a lot of these kind of issues just kind of go away and you can see that some if you get rid of a lot of the sources of being less productive that's that should make you more productive right as a team and even if I can't prove it this is my experience let's look at the benefits of mob programming so I've noticed from my work in mob that's when you're in the mob everyone has to understand the code that you're working on and this immediately shows itself when you bring a new person into the mob perhaps a new team member they very quickly learn your environments they learn very quickly what coding standards you care about what frameworks you're using and how you like to structure your code how to access the QA database and run the tests and all that kind of thing so it's very effective way to introduce a new team member in my experience another thing I've noticed about the mob is the way it's acts as a skill multiplier and by that I mean if you have one person in the mob who knows a thing and the mob needs to use that thing it really doesn't take very long until everyone in the mob knows that thing I've got this example here where one of the mob members knows about kubernetes and they're saying okay well I'm gonna navigate and I'm gonna explain and you can configure the Kuban et's with all this memory and I need you to open this Yama file and write this thing and so the whole mob has hearing that person explain in words in real language and then they see the driver typing that into the editor and they have the opportunity to ask questions and say well why did you do that and the the experienced and skilled person can explain and this turns out to be an excellent way of learning stuff and soon everyone in the mob could configure cuban ets with this much memory for their pod and they will hopefully learn the skills that they really need in the software that they're working on another thing about the mob that i've noticed is how quickly a visitor can become an assets you you can be an experienced developer who doesn't know the code base at all and has not worked with this team before but after only a short while of mob programming with that team you know enough to start contributing your expertise you don't need to know everything about the framework and the language and the tools the team knows that stuff you can contribute with what you know that they don't know and you can start to become an asset and this is a really interesting effect that i've experienced quite a bit and it's it's really cool to come in and help a team when you don't know that code base so i hope you can see where I'm going with this I've just highlighted three major benefits of mob programming everyone in the mob understands the code that you wrote together it's easy and quick to transfer skills if if that skill is needed by the mob and visitors are very quickly contributors in the mob so how does this relate to technical leadership in a world of empowered teams well I think it's absolutely relevant and you can join the mob you can as the technical leader you can join the mob of one of your teams and you can transfer skills you can contribute your expertise and you can learn about the problems that that team is facing so that the coach the the technical leader the technical coach can encourage and assist and and spend time with many teams this thing about only needing to be there a short while before you can help my experiences is working with the same team two hours a day for a few weeks and in that time really being able to contribute quite a bit and I can work with two perhaps three teams concurrently and then switch out to other teams so what I'm personally coaching when I come into these teams a lot of the time I'm teaching test-driven development and helping them to follow the process take small steps and write the test cases sometimes I will step into that navigator role specifically to navigate the creation of test cases and explain why this is a good way to write that test case I don't normally take the keyboard and drive because the person who has the keyboard their full focus is taken on on entering the code and at managing the IDE and their expertise and design skills are lost to the mob while they're in that role this is why it's important to rotate out to the driver role and not take it all the time because you're not part of the discussion in the same way so when I'm coaching a team I will tend to either sit at the back and coach and just prompt or I will take the Navigator role and this turns out to be a pretty effective way it's the most effective way I've found so far of teaching TDD to a team because you're I back it up with some teaching which I'll mention in a minute but when you're in the the mob you're working in their codebase you're working on an item from their backlog challenges that they have identified and you can bring your full expertise to bear and show them how you would solve these problems of course you also include a retrospective that also reinforces the learning and the reflecting on what's happened I also tend to collaborate with other coaches now if you're going to be really agile I think there's organizational changes that you need as well and and you need coaches who will help with those kinds of things coaches who who are very technical focused like myself who work with the developers and the operations people you also need coaches for the product management perhaps setting up dual-track discovery and and all that stuff and you need coaches who really understand agile methods say for scrum or whatever and with the combination of all these different kinds of coaches I think the organization as a whole can become agile so I I would like usually when I'm coaching developers to have a counterparts who is coaching the rest of the organization around or several counterparts it's a it's a team effort so when I talk about mob programming people ask well how much of the day should we we spend mob programming is this something that teams should be doing all day every day or is it something that they just do for awhile when they're with with the coach so let me answer this question I think first you have to learn to mob program this is a skill it takes some time before a team of developers will be confident using this approach and I suggest that if you have a coach two hours a day two weeks might be enough to learn the skill some teams might take more some less and I've my experiences that's some teams that this is this is kind of typical and then after that initial period of learning the technique where the team agrees yes we're going to try this for a limited period so we can learn the technique after that they're an empowered team this is the kind of decision they should be able to make and if that team decides that they want to continue ma being full-time I would be delighted so far I haven't seen that happen what I've have seen happen is that some teams will will continue mobbing two hours a day even when the coach is not there I've also seen them agree to a 12-hour coach this week when we've got this new person coming in until they're up to speed or they'll say oh well well mob while we're working on the initial stages of this new piece of architecture design that we need to do and then we'll split up basically I think once you've learnt the skill of mob programming and realize some of the benefits it brings then you are in a position to actually decide when do we want to use this and for what purpose so that's kind of answering when how much to do it so this thing going back to the technical leaders and instead of these remotes architects who communicate with the teams through documents and edicts you have the the coach acting as a coach they come into the empower teams they can see the kitchen that the teams are working in they can influence the decisions the team is making while they're there and they basically you know come off the pedestal and join join the the developers and become one of it one of the team for a short while until they go to the next team and as a technical leader you can get an overview of what's going on in quite a few teams in not too long a period and that gives you great insight into what you can do to help those teams to make better technical decisions so I mentioned before about these three factors which I think are involved in being agile and we've talked a while now about the the kitchen and how you as a technical leader can can it contribute to a better kitchen for the developers to work in and there's also this other factor with the skill of the chef and I think as technical leaders we we need to have a response bility for for that part too now this is what my my book is about it's about how you can learn these kinds of skills and when I wrote the book it was about the coding dojo and I in visited this as a place that you would go when you wanted to learn and it might you might go there once a week or once every two weeks and stay there are a few hours and then you would practice on code Carter's and so on so since then I've discovered that it's actually very effective if you start to introduce this kind of activity into the working day I do it with on work time with your team and if you make it shorter and do it more often it's even more effective because it turns out that learning skills is it's easier to do a little than often if you've ever learned some musical instruments you already know that the recommendation is 20 minutes a day not three hours at the weekend and it's the same I think with learning coding skills it's it's best to do a little every day make it part of your routine it's part of your normal work we are knowledge workers it's part of our job to stay up to speed with the latest tools and technologies and it's part of our job to get better at what we do and that should be part of our working day so I'm not going to say so much more about that that's that's another talk but I do encourage you to include time for learning in your normal working day so this is my summary slide I've been talking about technical leadership in a world of empowered teams and I talked about the the traditional architect in this remote ivory tower and how that just that just doesn't work anymore not if your teams are empowered I think you need to work in an entirely different way if you're working with empowered teams so I think as technical leaders we need to care a great deal about the environment that our developers working in and making those environments conducive to those developers making good decisions and in order to understand the environment they're working in we need to sit in the teams coding with them and then we might have a chance of understanding what they need and giving it to them and training them to use it we also need to pay attention to the skills of the software developers and make sure that there is time allocated in the normal working day for learning skills I really recommend you the practice of mob programming and learning how to do it and working out what the benefits of it could be for your team and then I also encourage you to see this kind of technical agile coaching that I'm describing as another kind of agile coaching and you need to work together with the the people who are coaching the organization so you're pulling in the same direction and the organization as a whole is going to become more agile I also should say that coaches technical coaches if you've got more than one in your organization which I hope you have they need to collaborate together as well and to be pulling in the same direction have time to talk so that's a summary of what I wanted to say today I think there are some questions [Applause] okay do you need to stand by me so you can use my mic no is it no it's definitely on that's oh no it's okay so let's go through some questions we actually have some okay so mmm-hmm how does mob programming work with remote members yeah I knew I'd go this question I should have mentioned it so I don't have very much experience myself of working with remote members and I refer you to Woody's book I haven't done it myself but I I know that it can work all right cool about mob programming again a steam working room service company how do you explain value to your client that for this feature we're all going to work on the same things all right so convincing managers that they should let your mob program yeah so you're an empowered team why'd you need your managers permission for this just say we are working on this full stop I mean they trust you they've hired you as the experts why do they get to also dictate how you work together and collaborate it's necessary just say oh we're having a meeting meetings are good right some people might get stubborn egged six people working on the same task sounds like a project managers nightmare how do you convince your business stakeholders that it's actually worth it so the same it's the same question but um six people working on the same task means that you have single piece flow you are working on one thing there is no merging there's no handovers talk to your your project manager about lean and tell them you're doing single piece flow and they'll be impressed and maybe they'll let you carry on okay is it a good idea to empower a team which does not have a proper skill set well this is the nightmare isn't it this is why I said this could easily degenerate into us a terrible idea so this is where the technical leaders need to make sure that there are there are supports their support in place to try and prevent those kind of catastrophes and that there is an architecture in place that can cope with a team delivering a service that totally fails that there is automated rollbacks and there is infrastructure to help with that kind of thing great um how to approach team members when they are underperforming and it is affecting the rest of the team how can we inspire or help them to perform better oh oh that's hard and you have a team member who you feel isn't isn't pulling their weight well I mean as I said the mob is a great forum for learning stuff and transferring skills and ideally that person will by taking part in in the more than that the learning hours they will become more productive and a better team member that would be the hope that you would you would help them to become better programmer Narain what programming sounds very inefficient are there any studies which compare mob programming versus pair programming versus single development I'm not aware of any such studies there are Studies on pair programming and they've generally shown that pair programming is is not as inefficient as all that and I would like to hope that you could extend those results to more programming but I don't think those studies have been done yet try it out you will see in the last night's mob exercise thanks for the Cata Emily the Navigator decided what to do how to handle discussion or disagreement is it better to have a whiteboard near and discuss when the mob disagrees yes having a whiteboard near nearby is an excellent idea for your mob you should definitely do that and when I'm working with a mob and there's disagreements and we need to we pause the the mob rotations and we will have a discussion and go to the whiteboard and after a while hopefully either a consensus emerges or a couple of ideas emerge as frontrunners and then we will try both ideas in sequence and then then the whole mob having tried both ideas in a time box will then be able to choose one to proceed with so there are there are mechanisms in the mob to resolve these kinds of conflicts whiteboard is beneficial for just about anything north and what's the ideal mob size the size of your team it depends and do you have any recommendation for too much autonomy how to align teams or not to build opposing things so this is hard this is hard when you have empower teams who can make design decisions without asking people I my best answer is having these wandering coaches who go around all the teams and can see what they're doing at least and having things like forums where remember what are they calls communities of practice these kinds of things there's lots of stuff in this area I don't have all the answers but I think mob programming is a piece of the answer alright maybe let's go for the last question cuz you're running out of time more programming in practice driver navigator and one other team member work on the problem but others are inactive what can we do with inactive members rotating the roles just rotate to inactive role so the mob members are not inactive they are actively listening to what's going on and making sure they follow they can also interject coaching questions at any time if they feel that that would be helpful so they're absolutely not just passive passengers in the mob and as the mob becomes more mature and used to working in this way then the the mob members know when they should be stepping in and taking the navigator role or the driver role and generally it becomes more of a collaboration between everyone who's in the mob same kind of maturity thing thank you so much for your talk thank you [Applause]

Channel: CraftHub Events

Views: 599

Rating: 5 out of 5

Keywords:

Id: qnujkFY2gKs

Length: 45min 34sec (2734 seconds)

Published: Thu May 16 2019