# 5 Whys: full text > 5 Whys is Roy Osherove's blog about leading software teams: the Elastic Leadership model (survival, learning and self-organizing modes), growing people, and team-leader anti-patterns. Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/. Source: https://www.5whys.com/ . Generated 2026-10-22T23:33:36.133Z. 166 posts, 8 pages. ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/ --- title: "Possible Anti Pattern: A Remote Team Member is Never Ever Visible in Video Chat (Zoom, Teams)" url: "https://www.5whys.com/articles/2020/6/15/possible-anti-pattern-a-remote-team-member-is-never-ever-visible-in-video-chat-zoom-teams.md" canonical: "https://www.5whys.com/articles/2020/6/15/possible-anti-pattern-a-remote-team-member-is-never-ever-visible-in-video-chat-zoom-teams" published: "2020-06-15T08:59:00.533000+00:00" updated: "2020-06-15T09:01:27.472000+00:00" tags: [] author: "Roy Osherove" description: "Team members that don’t show their face ever, or 99% of the time when video chatting with the team used to be OK, before COVID. But in the age of COVID this shouldn’t be the new normal. Team facilitation and communication with people’s…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Possible Anti Pattern: A Remote Team Member is Never Ever Visible in Video Chat (Zoom, Teams) Team members that don’t show their face ever, or 99% of the time when video chatting with the team used to be OK, before COVID. But in the age of COVID this shouldn’t be the new normal. **Team facilitation and communication** with people’s faces visible can be 10 times more efficient and provide more information that audio alone cannot provide. This can also be an **early warning sign** for team members who really like to work alone and not share information, not like pairing etc. That isn’t inherently bad, but in the age of COVID and remote collaboration, Agile and XP teams need to communicate with each other and pair with each other even MORE in the age of COVID, because there’s no longer an office water cooler or coffee machine to talk with others or gain information passively. **I’d have a 1-1 w**ith each team member that seems to always have a great reason not to show their face and find a way where they could, even _partially_ show their face every once in a while. Some members might not even have a webcam (get a webcam) . Some will say their home is a mess (virtual backgrounds), some will find other creative reasons. From a skill point of view, it is just another example of “getting our of your comfort zone” and learning new skills. In this case the skills are communicating & collaborating with the team. **Examples of “experiments”** we can agree on with individual members: - Show your face at least during online team retrospectives - Show your face at least during daily meeting - Show your face at least during pairing or 1-1 meetings - Do one group presentation where you face is visible. **Is this micro managing?** I can see it being understood this way. But if we treat this as a skill that’s required as part of the team we can prevent long term knowledge hoarding and “Bus Factors” in the team because, hopefully ,people will be more likely to share information with each other, and showing your face can be the first step in this direction, or the first sign that it’s going to be difficult. --- title: "InfoQ Book Q&A on Elastic Leadership" url: "https://www.5whys.com/articles/2019/5/30/infoq-book-qampa-on-elastic-leadership.md" canonical: "https://www.5whys.com/articles/2019/5/30/infoq-book-qampa-on-elastic-leadership" published: "2019-05-30T05:54:20.543000+00:00" updated: "2019-05-30T05:54:21.359000+00:00" tags: [] author: "Roy Osherove" description: "I had the privilege of being interviewed by Ben Linders over at InfoQ regarding my book on Elastic Leadership. You can read the article over here. Some of the main takeaways from it: A team can be either in survival mode, learning mode, or…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # InfoQ Book Q&A on Elastic Leadership I had the privilege of being interviewed by [Ben Linders](https://www.benlinders.com/) over at InfoQ regarding my book on Elastic Leadership. [You can read the article over here.](https://www.infoq.com/articles/book-review-elastic-leadership/?itm_source=infoq&itm_campaign=user_page&itm_medium=link) Some of the main takeaways from it: - A team can be either in survival mode, learning mode, or self-organizing mode.   - Each mode calls for a different style of leadership. - The ultimate goal of an agile leader is to make themselves unneeded (self-organizing teams). - Survival mode might leave us feeling helpless, but it’s very easy to stay in our comfort zones and stay in it. There are ways out of it. - Getting out of the comfort zone is a key technique for learning new skills. Discomfort comes with the territory. Be happy when you find it uncomfortable, and actively seek it! Thanks Ben, it was a pleasure. --- title: "The Elastic Leadership Model in a picture" url: "https://www.5whys.com/articles/2019/3/22/the-elastic-leadership-model-in-a-picture.md" canonical: "https://www.5whys.com/articles/2019/3/22/the-elastic-leadership-model-in-a-picture" published: "2019-03-22T13:25:40.184000+00:00" updated: "2019-03-22T13:26:15.005000+00:00" tags: [] author: "Roy Osherove" description: "I realized that there isn’t one picture that shows the entire elastic leadership model with the right amount of details out there. So I made one. Would love any feedback in the comments!" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Elastic Leadership Model in a picture I realized that there isn’t one picture that shows the [entire elastic leadership model](https://elasticleadership.com/) with the right amount of details out there. So I made one. Would love any feedback in the comments! ![ElasticLEadership-2.png](https://www.5whys.com/img/posts/d457f535-ElasticLEadership-2.png) --- title: "Johanna Rothman Interview - Agile, a Decade Later" url: "https://www.5whys.com/articles/2019/2/16/johanna-rothman-interview-agile-a-decade-later.md" canonical: "https://www.5whys.com/articles/2019/2/16/johanna-rothman-interview-agile-a-decade-later" published: "2019-02-16T21:46:02.132000+00:00" updated: "2019-02-16T23:13:01.488000+00:00" tags: [] author: "Roy Osherove" description: "12 years ago I interviewed Johanna Rothman About Agile development and her then new book “Behind closed doors: secrets of great management”. A few weeks ago we ran again into each other on twitter and decided to see what changed in the decade that had passed in our views on management, agile development and everything in between. …" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Johanna Rothman Interview - Agile, a Decade Later 12 years ago [I interviewed Johanna Rothman](https://www.5whys.com/archived-interviews) About managing people and her then new book “Behind closed doors: secrets of great management”. A few weeks ago we ran again into each other on twitter and decided to see what changed in the decade that had passed in our views on management, agile development and everything in between. We decided to record a new conversation, and here it is. **Johanna-Rothman-Roy-Osherove-Interview-Jan-2019** [Audio](https://www.5whys.com/audio/Johanna-Rothman-Roy-Osherove-Interview-Jan-2019.m4a) [Download the audio](https://www.5whys.com/audio/Johanna-Rothman-Roy-Osherove-Interview-Jan-2019.m4a) You can listen to the result or download the file above above (1 hour and 15 minutes). I’ve also did an auto-transcription of the interview below. It’s not perfect but it’s good enough to get the information out. When I get more time I’ll try to smooth out all the rough edges in the text.. ## Some of the topics discussed: - Teams and Iterations then and now - When to use flow and iterations - Agile grey areas and zombie lands - Convincing managers - Agile Scaling Frameworks thoughts (SAFE, Less) - Products vs projects - Choosing what to work on - Program Management - Collaboration on remote teams - Managers collaborations and metrics - Challenges in transformations - Product manager vs product owner - Types of documentation - Theory of Constraints, Kanban  and Agile. - Writing skills  - Lean Publishing ## Relevant Links: - Johanna’s website: [https://jrothman.com](http://jrothman.com/) - Johanna’s Books: [https://www.jrothman.com](https://www.jrothman.com/books/)[/](https://www.jrothman.com/books/)[books/](https://www.jrothman.com/books/) - Johanna’s blogs/articles: [https://www.jrothman.com/articles/](https://www.jrothman.com/articles/) ## Interview transcription: **Roy:** \[00:00:08\] Welcome to the big interview where you had a rough man 12 years later. Joanna Nice to see you again. **Johanna:** \[00:00:18\] I'm great. And it's so nice to see you too. And 12 years ago we did not have this technology. We actually had to meet when I was in Israel which was not a problem but. **Roy:** \[00:00:34\] People and interactions over process and tools **Roy:** \[00:00:37\] As they say it's a new world though it's a new world. Joanna is currently in theU.S. while recording this. I am here in the near Tel Aviv in Israel and we are going. \[00:00:56\] We were we were kind of you know you and I we got we we spoke via Twitter and we realized we haven't spoken in a long time. But we still have a lot of the same interests. And in 2006 I know we got to I got to interview you all about agile process and leadership and a bunch of project management stuff. And we thought it would be a great idea to do like 12 years later. How have things change. Interesting interesting thing we've we've learned and you know just to have an interesting discussion. So why don't we just get started. So. \[00:01:39\] You know your'e a very successful author and trainer you've written a bunch of those as well. What's your latest. Just by the way I just wanted to make sure to get that out of the way. Maybe we can use it in the conversation as well. \[00:01:52\] So the book that I'm finishing right now with Mark kelpie is "from chaos to successful distributed agile teams- collaborate to deliver". \[00:02:04\] Wow. Yeah. Yeah that geographically distributed agile teams because it's really. \[00:02:12\] Boy oh boy people really have trouble. \[00:02:16\] So we can have we're like have a conversation about why you know why you ended up writing that book etc. Before that though I want to go back to you know 12 years ago we had a bunch of discussions but when we look back in the past decade. \[00:02:36\] What have you seen changed in you know in the agile world and project manager management world. You know in the past 12 years so we so you know I'm sure you've seen things change and working toward specific areas cetera. \[00:02:50\] So what are the main main things that you see that have changed. \[00:02:57\] So when we first spoke all those years ago it was. Relatively easy to have a month long iteration. Right that that teams only worked on one project at a time maybe a little support for that product for that product that previous version that was out there. But. It was OK for teams to work on something for a month they could actually define what they were doing for the next month. They could develop and test it and it was it wasn't easy but it was doable. And now the pace of change is at least every two weeks very very few teams I meet are doing a month long iterations and often the teams are not working on just one project at a time. They're working on a little bit for this product and a little bit for that product. All this stuff and and of course support. And they're still trying to use iterations which I find so interesting that they're they're using a tool that does not really lend itself to the problems that they have. \[00:04:15\] So you don't see it as a positive you're seeing the team stress themselves to a point where it doesn't make sense to use the currents and say the rituals that they used to use before. \[00:04:27\] I'm not saying it. I started to see this I think about it must have been about 2010 or 2011. I've been teaching my version of an Agile class which is not SCRUM specifically is specifically the KANBAN method. It's more a mashup of when to use iterations versus when to use flow. How do you estimate when should you not estimate. I mean all that stuff right. You know me I've I always had my own version of everything and I found that when I taught that people said oh we can use like this from column A and that from column B and that from Column C to be successful. Now we don't have to try and do what the frameworks are saying that we have to do because the frameworks are not really working for us but we thought it was us not that we were trying to misapply a tool okay. \[00:05:30\] So when you teach that for example that it's really interesting to me because I think that's something that a lot of teams struggle with. When you teach when to use flow when to use iterations what would be some of the major deciding factors like that. \[00:05:48\] So if if it's possible for the product owner to not change his or her mind and if it's possible for the managers not to inject more work into people on the team then iterations might be a great opportunity to manage the WIP the work and progress. Right. Because every. That's the whole point of agile approaches manage the WIP, finish stuff so you can changing on to the next thing. But if you can't can't do that if the product owner is under a lot of pressure from customers or the product managers or or whatever and the managers are not capable for any number of reasons of managing the project portfolio. So they ask people to do things they're injecting work into the team then yeah don't don't use iterations use flow. Yeah. \[00:06:48\] Do you find it that. It's a challenge for teams to move from iteration thinking to flow based thinking is that you find it to be difficult or easy to move a team from one to the other. I'm sure people aren't so comfortable with changes. \[00:07:06\] So it's firstly the change and partially. Somebody said to them you have to have this board and it's a SCRUM board. And it's an a tool regardless of their location. Let me roll my eyes a little bit more and therefore if they can if they have no control over the tools that they use and they only have access to a scrum board and many of the tools do not allow you to easily move from a SCRUM board to a KANBAN or from a KANBAN back to a scrum I mean it's just columns. \[00:07:43\] I don't know what the problem is just columns. \[00:07:47\] So so so I'll play devil's advocate for you for four minutes and I'll say that in the past decade or maybe five or six years before you know in anger almost that I got the chance to work at some of the biggest companies in the world. You know you have a lot of experience with huge companies and you know what I've noticed is of course that's when we're dealing with enterprise. There is there is no black or white. There is just a lot of very very different shapes 5000 different shades of gray and so less so what we would end up with is you know we're trying to change something. Is we would end up with a company that has no policies and rules but also going through transformation. \[00:08:43\] OK. \[00:08:44\] So it seems to me that you know since transformations take such a long time there. There will be a period of time which is not a few weeks. It's probably a few months to maybe a couple of years where the teams will have to work with the tools that have been dictated while management kind of makes up its mind of what they really want to enable them to do. And so in that area grey area like a zombie land where you kind of try to move that but you're also kind of forced what are some of the techniques that you like to use or that. Now the ways that you try to accomplish you know missions of transformation. Or do you just say you know what if that's the case. Well it's there's nothing to do here. Move on to a company that's either smaller or it has already done the transformation and mindset change. I would say that. isn't most of our work as consultants to help the company kind of understand what it really is trying to do which means we live in a gray area most of the time. \[00:09:53\] You're right. Sorry I appear to be. Having allergic to questions. \[00:10:02\] yeah.... \[00:10:04\] We'll see how I do. You might have to edit this. OK. So. I think the key is. When when a company says we will have we will define our processes for all of our teams and all of our people even though we want to use an agile approach which is based on change I mean I actually. \[00:10:36\] With a contradiction there obviously. Q When you encounter this contradiction which you will in your life what are the steps that you take as a consultant to try to solve this contradiction. \[00:10:49\] So I asked them what what value are they looking for. And they often say I want to see velocity I want to see the burndown chart and I say. Okay. How what what decisions will you make . \[00:11:05\] Who are the or the people addressing those questions. \[00:11:08\] So first I start with the first line manager. It's almost never enough. Right cause somebody over there. Decide that. But I asked for the first. I asked them the very first person who might be able to change it. \[00:11:24\] So is that usually what product owner or project manager scrum master or someone else. \[00:11:29\] So it's often not anybody in the team are associated in the team. It's often somebody above the team. And so in the end what they often say to me is we really want to understand that the team is making progress and I say can you go to their demos can you watch the software being built. Well I'm a busy person I don't have a lot of time. I say OK so how often could you go to their demos. Could you go to their demos once every month. Would that be sufficient. Well I knew really. I really need this to report every week and then I go back and ask them the question again What are what decisions will you make based on this data. Well I just need to know that they are doing their job right. So we go into this little circle think and after we go into this little circle thing before it really becomes an infinite loop I say to them. So you you're telling me you want to know that they're doing their job. I'm suggesting that you can go watch their demos. You're a very busy person. And so watching the demos does not really seem to fit for you know how about if they recorded that demos and you could watch them at Twice speed. I mean how long could a demo possibly be for what you're interested in or what would you like to say the roadmap narrow so you can see what's actually been done. Or would you like to see a different chart such as the product backlog burnup a chart that shows you here. Here's how much was in this particular feature set. The team has done this much and then they do this much and then they do that much. So you know that that feature set has done and then that's when they start to say oh maybe some of that would work. Especially that product backlog burnup chart. And I say them the product backlog burnup chart has nothing to do with velocity and nothing to do with the burn down for a burnup right because it's for their product. And what you want to understand is what is the product doing not what this team has done for given iteration. Given whenever. And then when we figure out what they really want these people want something they have a right to ask for it. Can we offer something else that will be reasonable. And then if we can offer something else that's reasonable how can we shift them so that the team now has the capability to change their own board. \[00:14:35\] So from there to the capability. So I had a few interesting discussions with the various managers in various roles and a lot of them seem to have a fixation on and I realize I'm using this session as Q&A for my own special needs. But hey this may be useful to other people listening as well. A lot of managers that I see live in a hybrid world where on one side are using agile metrics such as burned down but then they'll put in old fashioned managerial spin on it for example instead of measuring velocity in points. They'll still measure velocity in time and they'll even try to measure that per person in the team because they want to try to optimize right. And I've had a lot of you know sometimes even tough conversations about it with people and I find that a lot of it goes back to the education that most people have had with a specific way and once a person believes that this is just the taylorist way of managing people in the way of you know optimizing each percent. You find that deep is the only way around that is just take all these managers and leaders and put them through like a training workshop and just say ok brain time everybody or you think that there is kind of an incremental way to slowly get them to acknowledge that there is value. Because I can see what you're doing with what you said before. \[00:16:13\] But the reason I'm asking this is because sometimes by having those hybrids we actually might get even worse results because the measurements will actually hurt the behavior of people such as you know we're measuring coverage. And so what we're going to get is coverage we're not going to get quality just going to get coverage. So that's an example of no measuring velocity of a specific person in a team and by name would only hurt performers that person or being you know being named for something. So what do you think is an incremental way or is it like OK everybody hold the boat there is no other way but we all get together for a day just talk about this needs to change and the order needs to come up from about above that no longer is discussed. What do you think is the right way to go about that stuff. \[00:17:09\] I would love to have a day with managers and brainwash them. \[00:17:14\] they have A lot of time right. There are a lot of free time. \[00:17:15\] Sure yeah. So so I have yet to have that day. I often have an hour. Sometimes only 30 minutes. So I say to them. Let's talk about what you want. Do. If you if you have to compare what one person does versus getting the product out the door. What you really want. And they almost always say their product at the door and I need to know that that person is working. \[00:17:47\] I say OK but let's assume for now that that person is working but the product at the door is what gains your revenue or keeps a customer or acquires a customer or something like that minimizes waste right whatever. Whatever the metric is so I say I'm not sure you know about this but the best way to get the product out the door is to have the team work as a team. I'm not talking about that mobbing stuff you don't have to do that mobbing stuff although it would be really great in that team doesn't have to pair. But the more the team collaborates together to work together as opposed to separately then you don't incur a cost of delay. Now notice when I said I actually used the word cost of delay and every manager's ears perk up kind of like bunny eears right cost ! delay!. We know that those two things are bad. \[00:18:51\] So then I can talk about the issues of cost of delay where when people multitask when they're not available on other things. Right because they're they're spreading out say they are not focused on this one particular project. That means that they will be cost of delay while other people wait for them so I I walk them through the thinking I don't actually show them any of the graphs that I have. I don't show them value streams first I don't talk about cycle time First. \[00:19:28\] I specifically talk about the things that matter to them and what matters to managers is accelerating the rate of what they think is production. How fast can they get the product out the door. How fast can they acquire another customer. How fast can they retain a customer. How fast can they get rid of waste. So all of those things. And that's where I think that we in in the agile community really can use our knowledge flow and cycle time and flow efficiency and optimizing up at the team level and then optimizing up at the product level. Keep keep moving up. What what people think of is the hierarchy to really make a change and. \[00:20:21\] And then then the manager says to me okay I get that for the agile teams but I got all these waterfall teams. What the heck to do with them. And I say ask them to release something every three months and they say yeah and I say you can take a cue from the release train people. Right. We often did release trains back in the 80s released trains are nothing new. I think I first started to use them in I don't think it was 79 but certainly 82 Yeah. **Roy:** \[00:21:02\] So you're referencing the release trains that exist today. A lot of people who hear about really strength from SAFe from Scaled agile framework. So you're saying that the term is not new. Do you think that the implementation is new in some ways. There is no novelty implementation or is it really going jumping the gun a bit. No one is looking at these new frameworks that have come in in the past few years such as Scaled Agile framework and large large scale scrum which is called less cetera. Did you find that these things are more just a rehashing or a real you know modeling of existing you know Frankenstein of multiple things or are there any kind of innovation there. What do you think about those in this context. **Johanna:** \[00:21:58\] So I am not a fan of any of the scaling frameworks because when you scale a process you end up with more hierarchy and more control points. As opposed to more autonomy for the teams. \[00:22:14\] Now I will tell you I mean you know one of my books says Agile & Lean program management Scaling Collaboration across the organization. So I take me we had this perfectly good name which is called program management which is how the core team Sheppards the business value across the organization making sure everybody does their job is legal doing theirs a sales doing there's it's deployment doing there's right everybody has to do their job. \[00:22:46\] And then the software program team which is infinitely scalable assuming you use small world networks where the teams say honor really need to be at that program team meaning I'll either ask Roy or I'll ask Johannah or or I am part of another small program that is part of where 1 person goes and they tell me what's going on and their job is the program team's job is not to do Stanis but to resolve impediments that the team members are linked to enough in the organization that they can figure out what's going on for themselves. So yeah. So it's a different approach it's not a scaling process it's scaling collaboration. And when you have a framework especially SAFe which I have to admit they keep updating the picture. I don't understand the picture. I'm kind of a smart person. But the picture is too hard for me to understand. So I might not get it but every time I see a really good SAFe implementation it's terrific RUP it's a wonderful rational unified process. It's it's really outstanding at that. But for me that's not enough change. No no no. Yeah I don't to do that. \[00:24:21\] I got the chance to work with a couple of organizations that have implemented or are in the process of implementing SAFe and we're talking about really larger orgs here. Hundreds of thousands of people. Yeah. And what I've seen you know a couple of insights that I've had is first of all what's safe seems to be doing right is that it gives a good enough excuse for waterfall people to adopt Agile because it basically is kind of or at least it tries to be in some way agile wrapped in bureaucratic flow which basically means here is a different waterfall but it's really hiding inside of it. A lot of agile processes. So it's like oh do you need a chart for this. Here's a chart for that for Extreme Programming or here's a chart for a SCRUM team that tries to get you know burn down or whatever. Here is a communication issue. OK so now you have a booklet that you can go and open. So you know what to do with this specific step. \[00:25:33\] And I think in a way that's kind of like braces or you know when you're trying to walk his project it's like agile with crutches. But and in a way it tries to solve the problem of connecting the dots in larger organizations that are trying to move forward in a specific way and maybe it is rough in some way. What I've seen in latest latest version is that it tries to adopt a loop at least at least in some way. A lot of it sucks in a lot of these concepts like continuous delivery et cetera. And he said ok no this goes right here. And then he can do that. So it's kind of like an excuse he's like get on the train and then we will give you a chance to work in an agile fashion. \[00:26:21\] Now on the what on the other side what I've seen is in a larger organization the problems are the same problems which our teams live in a bubble and that even if you are part of part of an agile stream the communication patterns are still broken especially in organizations that do a poor job of getting everyone on the same mindset. So I've seen teams that are part of an agile released train and are stuck on something and they think that they have nobody to turn to. There is nobody to help with the impediments. And then there are these specific you know. First of all we're talking about PIs which is you know program increment. We're talking about three months increment suddenly again. Somehow this has become another waterfall base something. And so it takes three months to change something technically SAFe has a way to change things in the middle. And there are special buffer iterations in the middle to handle that stuff that requires communication between people that have special roles and in organizations. \[00:27:30\] What I see is that those roles are not always implemented by people either not at all or by the right people. So there is nobody to turn to to fix impediments on time and so suddenly you say I guess that waits for the next PI. And that really hurts because there is good but maybe it is an impossible equation to solve. So maybe because what I heard you say is like the org is too big. It's not going to work. You have to go back to the words of agile at agile really works in small teams. So what does an organization that has a huge you know huge software project ahead of it try to do when it's you know does it just say no we're just going to build this whole huge thing in a very very thin you know light line and just a small set of people is just going to build it. It is going to take probably longer but it's going to be managed by a smaller set of people. Or is there a way to you. I would say divide up the work is that's an implementation detail. But is there a way to scale a large software projects in a large org. **Johanna:** \[00:28:42\] So I've used the program management. Like I wrote about it for only about five or six hundred people on the program not thousands. only 5 or 600 so we had many many teams. And I think I think one of the questions I have for people is are we dividing it up by products. Or by function. Because when we take a product perspective. We often discover we have fewer people. Than we thought we needed. So. Maybe that's one way it may be. I mean look if you have 12000 people working on one product I suspect you have several products there. Right. That's I mean that's just not been my my experience now. I I haven't experienced everything. I mean I have been I have worked with very large divisions of very large companies where they had anywhere from 5000 20000 people in a division. But that division had several products or more than several. And I what I keep seeing managers wanting to do is make progress on everything all at once instead of picking and choosing. This is the project portfolio problem that it's so difficult for and especially I think in larger organizations who do you even say no to. Right. You get work coming in over the transom right. People kind of lob work at you and you're supposed to start on it. How do you actually say no to something if you if you can't even tell who the stakeholders are. **Roy:** \[00:30:46\] So how do you. So you're saying that right now the best way that you see is a traditional program management and core team that kind of directs like the firehose in a way this is now the word goes out way. Now the word goes our way and this is the direction that those companies they kind of a traditional view in a way it is a hierarchical top down view. Is it does it does it include some of the same issues of kind of cause that can cause I got the chance to work in a in a place that kind of has like a core team and management team not doing agile specifically. And I remember just all the different meetings that occurred and nobody really knew what everyone else was doing. And like three people at the top and everyone else was just kind of working in the dark. So I don't know what I'm working on ask that person. Who just knew maybe 10 percent more. And then it's like Lego pieces. So that's the intimidation in my head when I hear program management. I didn't read the book that you wrote on that specific subject. Obviously that's OK. Yeah but I'm sure you know that a love to hear as well. **Johanna:** \[00:32:07\] So when I think about program management I think about enabling the teams to deliver their work. It's not that their program teams control everything and especially not knowledge. The program teams enable . They clear impediments across the organization. So I I have been a part of several programs where they had multiple program teams not just the core team in a software program team but several software program teams and several core teams. I felt that that was kind of crazy. That was that was more hierarchy. But if you don't have a lot of hierarchy how can you arrange this . And that's my whole perspective. \[00:32:58\] If we go back to the very large organizations I think that one of the issues is what is driving their desire to be to use an agile approach. What is it that they want to get out of using an agile approach. And often they say to me it's time to market. So or time to release or time time for something they almost never start with technical excellence. So if it's really about time then how can we then possibly the very first thing they do is just divide up they're very long releases into 3 month chunks. I mean that's what I did back in the 80s and the 90s now except I did one month chunks. **Roy:** \[00:33:49\] Do you think it's like an agile slippery slope if you can do three months you can two months maybe into one month as well so the skills grow because of that because of the ability to just split and slice these that you're looking for them to grow. What is this skills that's missing in the organization to become faster in a way. **Johanna:** \[00:34:10\] So I think I think there really big skill is this notion of collaboration as a team. Right. So many people have and market nine knows this when we were writing that geographically distributed agile teams. Look there's so few teams actually collaborate as a team. They they are so affiliated with their functions right the testers feel pulled back into a test. The developers feel pulled back and doubt that they don't collaborate as a team. And I think if the one thing we could do is help teams figure out how to collaborate as teams then all the other stuff might fall into place. I'm not sure if it would really fall into place but we would have a much better shot now. **Roy:** \[00:35:04\] So obviously there are you know there are many impediments to teams working collaboration, a lot of it is not people not wanting to do it. A lot of it is you know the system itself is built in this specific set of rules of what's allowed and what's not allowed. So for that to be enabled what is a skill that is you know management needs to adopt to be able to you know allow teams to collaborate better. **Johanna:** \[00:35:33\] So I think that there's a mind shift that managers seen managers actually need to collaborate among themselves. Managers too often are pitted against each other which is exactly the wrong thing for any organization. Why not have managers collaborate for the betterment of the entire organization. \[00:35:59\] And so there. Is the collaboration mindset the experimentation mindset. I am continually astonished by how little experimentation managers do. Right. I mean I knew I did not know everything about management and I would actually say to my teams either or one team were an entire division. I want to experiment with this this month. I need your help. I need help with this data. You know I I am asking you to gather this data from me and some people really wanted to prove me wrong. And some people help me but I learned an awful lot by experimenting. \[00:36:49\] I guess the third thing is really seeing the whole . If we if if instead of looking in our fiefdoms as managers how can we see the whole and ask how can we better at the entire organization as opposed to the whole. Now there's a huge problem with me with the way managers are paid and incented. Right now they're incented on their own narrow piece and they're incented as a zero sum game. So it's not a win win for everybody. It's I WIN YOU LOSE. Which is crazy. **Roy:** \[00:37:30\] So do you think that the metrics that we use can help you know adopt some of those new skills. So for example what are some of the metrics that men want to look at were being measured by to enable more collaborative behavior. **Johanna:** \[00:37:48\] So I'm actually starting to right the agile management book and bits and bits and pieces. I'm running it as a novel. And I think that one of the incentives is how can you coach and mentor others and how can you help the entire product. move along so I'm not so sure we need to move to product based organizations where that projects are no longer useful. I find their projects are very useful because I don't know but I'm sure you and I have the same problem. I have more projects than I know what to do with. And there's really only me and any outsourced people I have as part of my team. So I want to be able to start and stop projects so I finished stuff and I release stuff. \[00:38:45\] I might not be able to do all of it all at once but I can do something that's good enough for now and then move to a different project. And I think a lot of organizations are like that too. They have more stuff than they know what to do with. But how do we help managers collaborate with with a product management function and say how do we carve off enough now of this product to create a project so we can start it and finish it and then go on to something else. So for me it's all I probably not articulating this very well but it's how did we see the whole for the organization. And then how do we help whatever piece that is move forward and get it done. **Roy:** \[00:39:36\] So as a generic idea that sounds amazing but what metrics measure those things well how do you know. I mean because in the world that I'm you know at least familiar with in some way the world of software which are also big obviously are you can kind of measure the output of the system by you know deployments to production you can measure escaped Bugs you can be you can measure you know lead time from one point to another etc. So there's these are for example metrics that to me but it encourages the sort of behavior that will eventually lead to that. \[00:40:20\] But how do you measure that someone for example is mentoring or coaching other people or what are kind of maybe it's just impossible. QUESTION But do you need. Maybe you don't even. But is it makes sense to look for a metric that says if that number goes up or down I know you're doing a better job of doing that. \[00:40:45\] So all the that is before you answer. Yeah I don't know the name of the speaker but I know that I'm in Norway. And he talks about the fact that everything is quantifiable you can measure technically anything you can even measure love in a way by you know or you can measure how much a customer likes your product by you know either how many clicks there are in something specific et cetera et cetera. So can you quantify you know coaching or something like that there are many. I'm wondering what you think about that. **Johanna:** \[00:41:20\] So was that Tom Gilb. Yes. Yeah. Yeah that's one of Tom's things I do. I don't know the answer to this yet. And there are pieces of it. I think that there that there are ways to think about this. First is throughput how do we measure cycle time lead time for an entire organization and my experience is that as I learn as I get better my throughput goes up right now it does not go up evenly over time. So every book has a different number of weeks or months or years to point out. But I am I am better every single time I work on a book. **Roy:** \[00:42:11\] yeah. So your velocity increases. **Johanna:** \[00:42:15\] Yeah. Yeah. So you might think about cycle time you might think about throughput any of that might be helpful and that's some of my learning from all of my previous experience and some mentoring and coaching and classes and whatever. So I think that there's something about the throughput or the lead time for a for an organization. And the problem is if you're working on a 100,000 person organization that number is meaningless. You have to come back down to our product level. Right. It's just you yeah you have to make it reasonable in some way. \[00:42:59\] I think that there's also something about the number of questions that you ask and answer and the number of decision points. How often did you have to insert yourself into what decision point and how often does a team successfully make that decision without you. Yeah I think that this is very scary for many people. But the only way for people to learn how to take more responsibility is for them to do it. **Roy:** \[00:43:35\] Now I fully agree that. To me that really brings about. You know when I when I talk about the elastic leadership I can say you can measure your effectiveness as a leaders by how much a bottleneck you are. So the more you are needed the less effective you're actually you actually are in coaching other people etc. So you can literally measure and that's qualifiable thing how many questions do you get from people where those people could have you could have taught that person to solve it or enable that and solve it versus how many that you really are the only person who could have solved it and either one of them is an important number because one of them is a systematic problem and the other is ta coaching problem. So I think I really connect with that as well. Yeah. Okay cool. \[00:44:27\] So actually given all those things right with all these you know grand gestures of trying to change organizations. What are some of the biggest challenges that you're facing these days. Over the past few years with customers. Well what are the things that you find the most difficult to tackle as an agile consultant that you know seem to be either repeating themselves in one variation or another or there was that one time that you know has not happened again but you're not sure what to do about the things that stumped you in a way. I'd love to know. **Johanna:** \[00:45:09\] So. The biggest problem I see is the product owner problem and that's because we are product managers. And product owners who work with a team and too often those people are the same people. So that product owner does not spend enough time with the team or the product owner spends so much time with the team that's a PO stops being. In touch with. What the customers want or need. And that I think we have a real. Product. Management problem where we have to have the strategy for the product at the organizational level. We need the tactics and the team and sometimes we need actually help creating stories. **Roy:** \[00:46:07\] Would you mind For my benefit and maybe other people listening what do you see as the main difference or definitions of product managers vs PO as I see a lot of confusion with a lot of organizations myself included by the way. **Johanna:** \[00:46:22\] So I might not get this right because I'm still working on this. Yes there's a product donor book in the works also. I know you're so surprised. But for me the product manager is the person who goes to the project portfolio your team and says I've done an impact map. We need a project to do this thing to deliver this kind of value to the organization. So a product manager is thinking strategically what does the organization need for products and services now. And I actually think that there's a team of product managers for any given organization. They might not be working as a team right now. What we need them to work as a team as a collaborative team. \[00:47:16\] And then there's the tactical work in the team. So who writes the product purpose or the vision. I would hope that that would be the team with the product owner. So there are often people go out to visit customers on a regular basis. Those people cannot be product owners right. If they're if they're out three to five days a week they can not be working with the team and we need somebody to work with the team. **Roy:** \[00:47:50\] So our PO is internal facing and a product managers is external facing ? **Johanna:** \[00:47:55\] For me that's what it is right now. And I think that those people need to be on a product value team where they collaborate together. Working at these various levels to talk about what should be in the roadmap when . are are our customers asking for this kind of a thing now or do they want that kind of thing later. So it's a product owner would actually create the roadmap and involvement. I'm a big fan of continual planning but it may be with input from the product manager if you get a lot of input from a product manager. But I think we have to separate those two roles. **Roy:** \[00:48:44\] It seems to me that if you're saying to the product managers is the person who is really connected to the products and the product owner is more of a translator for proxy for a product manager. That makes sense?. **Johanna:** \[00:48:57\] No I think you're right. And I I wish I could say that it was. I don't know how to get the team closer to the customer unless they actually visit the customer which I think is a really good idea. Yeah but I'm trying to bridge that gap between the people who are always out on the road and the people who are in with the team. **Roy:** \[00:49:21\] So so so the problem you're trying to solve is that the absence of product owner because they're always out. So we want to have an internal facing and then and then we have to solve the communication issues between them because you want them to have the same same brain in a way like the same person possesing two bodies in a way. **Johanna:** \[00:49:44\] Well I think that I think that product managers are not accustomed to writing stories I mean. I mean I come from a time when product managers were supposed to write PRDs. They didn't do that either. They said to a BA go write the PRD. **Roy:** \[00:50:04\] And you still believe PRDs BRDs. Let's talk about documentation for a second. What documentation do you think we need to get rid of even in larger organizations. And what is absolutely necessary for you think we still think you know I remember 2006 behavior driven cucumber based. I still see organizations trying to implement that stuff. Do you still see that as the end goal do you see something else. Do you think it should be that with a combination something else maybe something that you thought was true. Now think you know I was wrong that something else is true. How do you see that you are engaging in the actual music business. **Johanna:** \[00:50:48\] So I would really like people to document a picture of the architecture in on paper. Let me show you a piece of paper write a piece of paper. So not in PowerPoint. \[00:51:06\] Not in Vizio not in any drawing tool. I want to see them drawn on a piece of paper maybe put an image of that paper on the wiki and say as of where recorded in the sun January 17th as of January 17th 2019. This was my best picture of the architecture. And then as we started to implement features and we make decisions about what the architecture should be what the constraints are we add to that picture. And then at some point we say okay we are not past the point of no return. It is time for us to define the scheme or define the architecture defined find something is the same way for me with the requirements. I'm totally fine with big picture roadmaps. \[00:52:02\] I'd love big pictures right. I think in big pictures I wouldn't know a minimal marketable feature if it bit me on anywhere. At the very beginning of a product right or project I wouldn't know it but I have some ideas about where some of them might be. So I'm happy to evolve the roadmap all the time. And for me as long as I understand what does Done mean what are my release criteria. How who am I delivering this project for and what what will make them satisfied. Then I I do is little documentation as possible but as much as necessary to get there. So I have yet to ever see any requirements document be useful. **Roy:** \[00:52:58\] Let me challenge you a little bit on that. Okay you mentioned the piece of paper I have. Just in case I have another one here. I think those are the last two pieces of paper on earth. **Johanna:** \[00:53:11\] My office is full of paper **Roy:** \[00:53:17\] So but we're talking about a large large ish organization. Where does that piece of paper go. Does it go on a wall with a specific team. What about remote teams what about teams on the other building on the other side of the road. Where does that piece of paper go is it really is it. Is it a pipe dream that we were able to use it or does do we have many copies of the piece of paper on many walls for example. **Johanna:** \[00:53:47\] So I'm not sure that copies on walls or not are a bad idea. And maybe have I mean as we have either iteration or cadence of finishing and demoing and reflecting reflection inspecting and adapting to whatever it is we do every week or two why not update that that paper on the project wiki. I'm assuming there's a wiki and might be something else. But why. It's our unbelievably cheap. You know why are we so worried about saving bits. This is not like when I was a young programmer right there. I mean I I don't think I can find a USB stick right now. on My desk. . Let's not discuss that. **Roy:** \[00:54:40\] So are you saying we should use weeklies or should we use walls. Like I'm really saying what is now in and agile you know the documentation way where does documentation live? **Johanna:** \[00:54:51\] So if you need to keep this is another it depends answer. **Roy:** \[00:54:58\] also another book?. **Johanna:** \[00:55:00\] Maybe maybe not if you need to keep a history of how we were thinking until a certain point right. We often find we thought this way at the beginning then we thought this way in the middle and then just before it was time to make a decision. We catalized those ideas. Decided what we were going to do for now. One of the nice things about an agile approach is it does not cut off our potential too early in the project so we might want to keep a history of what we were thinking and decisions we made if we don't need it don't keep it. Yeah. **Roy:** \[00:55:42\] You know you know I'm facing these I'm facing one of the customers has a huge project that they basically inherited from offshore teams and they have to maintain it and add stuff to it. And I'm thinking to myself we're having this conversation what would it have been. Because currently right now of course you know it's chaos. \[00:56:01\] Nobody knows anything the communication boundaries are so difficult that you know even when you do get the person to ask that person might not know everything and that communication is so difficult between different continents that now. Very nice. It's like the old modems where you can hear me like you know for every 100 words you get five of them right. Right. So the communication's horrible. \[00:56:27\] I'm thinking what would have been the best documentation in this. Now what would we have killed for at this point. And I'm thinking in one of the best things that I've ever encountered is you know on a wiki a set of videos where a person literally says they're recording with a microphone. kind of like the way you're sitting now with a in that case it was a PowerPoint but he was recording the screen and that person was explaining the architecture and that decision even if it was five years ago. \[00:56:59\] Because now we understand the main intent and you still see the big picture of where things were. as you can see this thing is now no longer and a set of those videos would have been a lifesaver. And I'm sure it would have saved hundreds of thousands of dollars of people just wasting time trying to find out why how something is working or not working and where it was the right person to even ask that question. \[00:57:27\] So maybe the documentation that the new that documentation is video and in the video and audio and not ncessarily the paper I'm just being kind of spit balling here as an experiment. **Johanna:** \[00:57:41\] There's no reason not to do that now. I think and again I think that when even even ten years ago we did not have the tools that we're using right now. It was a lot more difficult to create video. And even audio ways. Not that easy. So if we have all these tools why not use that now. **Roy:** \[00:58:12\] I'm going to change the subject for a second because I have something I've been you know kind of I promised myself this year that I would do that I will get into understanding the large scale framework so less and SAFe and all that stuff because not because I might agree with them because I don't necessarily agree but it's very difficult for me to discount something that which I don't feel I fully understand yet. So I said this year going to teach courses and all. Each one of them. \[00:58:40\] And by the way as a side note I noticed that a lot of you know people that I meet in the conference circles etc. they will publish their own stuff etc. but they rarely go to trainings by other people in the industry. I don't know if it's ego or time or whatever. And to me that you know I am also to blame on that I've also not done my job well enough to say you know what I think I know what I'm doing. But what are the other people doing. I might read a book or read a few articles. It's almost like what I'm going to go to a person's course and just sit there like a regular student. No I am a published author and I know it's such a stupid ego thing anyway. So that's that's my resolution. That and losing a few pounds. \[00:59:31\] But one of the things that I've I've heard a lot about and I've decided to also learn other than SAFe and less is a THEROY OF CONSTRAINTS (TOC) because the way I see it a lot of the stuff we're talking about kanban as well is based on those things and lean and the Toyota method. They're connected in a very deep way. to TOC which has been adapted to multiple types of industries but I have yet to connect the dots in software to me today. TLC combine is the best representation of TOC in a way. But I don't understand well enough about suicide. Do you have experience with that do you. Is it a formal experience is it something that you've tried. What are your thoughts on it. I haven't taken the course. I'd love to hear what you think about . **Johanna:** \[01:00:29\] So back in the early 90's I experimented with buffers in projects I said to people don't add buffers to your estimates and I only asked people to estimate for a month at a time what they would be able to deliver. Right. I wanted something to deliver at the end of the month because I was using more of a staged delivery lifecycle at that time. Not quite agile but. staged delivery . **Roy:** \[01:01:02\] And just for the listeners. I think the reason you were mentioning buffer is because in TOC the buffer rope method is it is a very prominent thing. so that's why you're mentiniong it right. **Johanna:** \[01:01:14\] Right. That was so I had read the goal in the early 90s and then I read a few more T.O.C. books. I've been friends with Clark Ching for a long time and he wrote rolling rocks (downhill). \[01:01:34\] I don't remember if it's downhill or uphill and then his most recent book about bottlenecks and the focus method. So that's all TOC. I'm friends with Jack Vincnt who actually lives in my little suburb here of Boston and we go out for lunch every so often and we talk about T.O.C. and Agile and the KANBAN and all this. when We were totally geek out for lunch. \[01:01:57\] It's lovely. And so I. I have not actually taken a TOC class but I think I understand it pretty well. Which is what is the constraint in the system. How do you optimize for that constraint. So I've written several articles that people tell me are really a theory of constraints article which I was not planning on when I wrote that article. \[01:02:29\] So one of my clients actually has you know 11 UI people and 45 teams. Every single team needs a UI person. What do they do. They they ask for a UI person. The UI person comes and sits with their team for two or three days and then goes back into the pool. So they have a problem. They have to wait and ask for another U.I. person. I mean this is the cycle is mind boggling. Yeah. Mind bending and and just perturbs everybody yeah. Everyone is kind of out of their mind. **Roy:** \[01:03:11\] SO in the world of TOC how would you handle that. **Johanna:** \[01:03:14\] So I said to them only have teams only may make sure that a UI person is on every team and if you don't enough UI people make the team bigger. So they all finish something right. So instead of having 45 smaller teams have 13 large teams or whatever it is for the net the number of U.I. people don't have 45 teams because you're not you don't have 45 teams now. You just think you do so optimized for the UI people. \[01:03:51\] Well how were the UI people gonna learn anything. I said how the community of practice. Right. They still need to learn the devs in that way everyone else needs to learn. But you're not counting the throughput that you think you have. So optimize on the constraint that you have. So for me it's identifying and optimizing that constraint. So back end back in the 90s it was about buffers because we all thought that the schedule was constraint but it wasn't and and now it's how we see the constraints that are there. **Roy:** \[01:04:32\] So do you think that KANBAN is a good presentation of TOC or do you think it's a parallel. It's more of a like the interpretation of TOC in software. I'm talking about specifically kanban in software. Yeah. **Johanna:** \[01:04:47\] So yeah. So let me if you put together a convent board for your team you can see your flow. And now you can see where the constraints might be. Right. So it's not that I think Kanban implements T.O.C. As much as it helps you visualize your constraints because often I often find teams have once we figure out what it is that one constraint it's not one constraint it's 14. Well we can't deal with 14 constraints we can only deal with one at a time. **Roy:** \[01:05:30\] And to me it's really is kind of I'm looking for that maybe that doesn't exist the Holy Grail that the theory of everything. The thing that connects all the parts you know and I've been reading about unit testing and leadership and devops but there are things that unite all these dead the problems of implementing those things are usually not taken at all human related and those human related problems are connected to systems where this humans interact. Those systems create those bottlenecks or or incentives. So maybe that also kind of maybe by understanding that base under that base it's like understanding gravity in a way. Right. It's not that we use gravity every day to solve a problem by understanding that gravity exists. We can create tools that leverage that knowledgeetc. So to me that's that's how I think about it and that's why I think I'm going to learn safe less. My feeling is that theU.S. is going to help me. I think it's actually going to help me figure out something and figure out something that I've known design patterns in a way when you when you write code you do design patterns if you don't realize just like you're writing Arby about you see. But having a name for that thing and realize that thing repeated it has a name and then has variations and it has no obstacles and patterns do it. I think that's a language that the today's missing for a lot of managers as well. That kind of thinking maybe is part of the occasional system of management. **Johanna:** \[01:07:09\] So I actually think that there's two things here that you and I would both agree on. I think that too few organizations focus on technical excellence that if they had technical excellence they could actually get a lot more stuff through their system and that they had managerial excellence they would have more humane more usable systems of work. So I am. Please continue to work on the technical excellence. I am starting my journey well are continuing my journey on the managerial excellence part. **Roy:** \[01:07:53\] So speaking of that you know before we kind of go. So you're in the process of writing this book which is all about distributed teams. **Johanna:** \[01:08:03\] Yep. **Roy:** \[01:08:04\] What else are you kind of involved in these days any kind of training courses people where can we find you these days. on and offline. **Johanna:** \[01:08:14\] OK so online everything is jrothman.com cause you know I got my domain name back when it was fine to have our first initial and your last name. So everything is there my books are ךך there. I have online workshops I have in person workshops. I am about to about to announce my writing workshops for Q2 and I need to figure out how to get the product owner workshop up and on teachable.com So it's all right so there's more there.. **Roy:** \[01:08:50\] are you doing writing workshops. **Johanna:** \[01:08:53\] I offer writing workshops. **Roy:** \[01:08:57\] if you want to be a book author. Is that what. **Johanna:** \[01:09:00\] Well the first thing is actually to to free your inner writer. Right. So. And this is for nonfiction all of the ideas work for fiction also. But I'm focused on nonfiction. So how do you actually sit down and write on a regular basis. And then the second workshop is about publishing cause and then I really want to get the book wrting workshops up which is first. There's one about writing the book. \[01:09:30\] And then there's one about publishing and marketing the book. **Roy:** \[01:09:34\] Wow I didn't realize that you're also kind of jumping into that world as well. That's very interesting. You find that there are a lot of people are interested in trying to jump into that ship and for some reason or they don't feel comfortable or they're looking for those tools and it's hard to find you know the kind of that kind of training. **Johanna:** \[01:09:54\] So a lot of people don't realize that writing is not editing right that if they're writing down just writing and cycling to make sure your ideas are there is very different from the final editing you do later. And a lot of English teachers taught people oh you must edit Everything you write. Well yeah maybe but not while you're writing it. **Roy:** \[01:10:23\] Do you think writing the writing you're teaching who's your target audience is it people who already want to write or do you think this helps. Also people never planned on it but that skill will help them in their job. And your day to day job. **Johanna:** \[01:10:38\] So I've I've had people who were consultants who are coaches who are actually entrepreneurs of many stripes where they say I need to write. It takes me too long. I've got to figure out how to do this faster and better. \[01:10:57\] So it's all it's all that. **Roy:** \[01:11:00\] What do they need to write like like letters or memos or like blog blog posts. Right. **Johanna:** \[01:11:08\] So a lot of a lot of consultants have blogs or are write articles for other places because the SEO points back to them. **Roy:** \[01:11:19\] OK cool. Anything else that I should have asked you but I did not. **Johanna:** \[01:11:26\] I'm sure that there's plenty. But I think we've we've gone on for long enough so that's probably fine. OK. **Roy:** \[01:11:33\] Well Joanna thank you. It's been a pleasure. I will probably see you again in about ten years. **Johanna:** \[01:11:40\] Let's hope it's not that long. **Roy:** \[01:11:43\] Yeah it's been a pleasure as always I hope like is there an upcoming conference what people can find you in the next few next six months. **Johanna:** \[01:11:53\] So I'll be doing a bunch of the no fluff just stuff and uber conference conferences in this next few months. I have my submissions in to the agile conference we'll see if they take me.You know it's always it's always a crapshoot. **Roy:** \[01:12:10\] Is this funny that the agile conference proceedings or some of the most waterfall based proceedings ever is is this is the most ironic bureaucratic nonsense I've seen in a while. Isn't that crazy? **Johanna:** \[01:12:27\] I find it quite humorous that we have to propose stuff a good nine months in advance and give an entire outline of what we're going to do which might change it. **Roy:** \[01:12:40\] Yeah exactly. But I find that the process of book writing is very much the same it's the opposite of agile because you have to create a table of contents in the first place and then you have to fit the book into that plan. Now obviously you're going to change your mind. So luckily a lot of publishers are very very happy to change it. But for some reason you have to come up with a full book in your head before you start writing it. **Johanna:** \[01:13:06\] This is why I do not work with any traditional publishers at all. **Roy:** \[01:13:11\] You work with leanpub.com These days as well ? **Johanna:** \[01:13:14\] All my books are on all my self published books are on leanpub.com. I I cannot imagine a time when I would actually work with a publisher. In the future I cannot. I mean maybe it'll happen but I am... \[01:13:33\] So Mark Kilby and I we organized this book several times and and we totally reorganized. What's in the chapters. Never mind that. But why did they ask us to do all this work that we're not going to use again. **Roy:** \[01:13:52\] And for the viewers listening to this LeanPub is an online publishing platform we can actually deliver your book early and even get paid for it for specific sounds that that throw away as the book becomes bigger and bigger. So you kind of have this continuous delivery way of writing a book and I even the elastic leadership book that I wrote actually started on lean pub and then I moved it to a traditional publisher because I found that the marketing was better. That was the only main reason. So I kind of try to get the best of both worlds. Like early feedback and then OK traditional. **Johanna:** \[01:14:32\] That's why that's why I need to have two workshops for book writing. One is the book and one is marketing and publishing or publishing and marketing. Yeah. **Roy:** \[01:14:43\] Perfect. Okay Johanna thank you very much for your time. It's been a pleasure. And hopefully we will meet in one of the future conferences I'll put links to all to to your website and your books and all that stuff. Thank you again and thank you very much everybody for viewing and feel free to leave comments or send us questions via e-mail. Thank you and have a great day. **Johanna:** \[01:15:08\] Thank you. --- title: "A Critical Chain of Bus Factors" url: "https://www.5whys.com/articles/a-critical-chain-of-bus-factors.md" canonical: "https://www.5whys.com/articles/a-critical-chain-of-bus-factors.html" published: "2017-02-21T22:02:03.767000+00:00" updated: "2017-02-22T07:22:57.363000+00:00" tags: [] author: "Roy Osherove" description: "I've spoken before about the meaning of a bus factor . It's basically the idea that if there is only one person in your team that can do a critical part of the work, and that person gets hit by a bus, the team stops functioning. (I've been…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A Critical Chain of Bus Factors I've [spoken before about the meaning of a bus factor](https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html). It's basically the idea that if there is only one person in your team that can do a critical part of the work, and that person gets hit by a bus, the team stops functioning. (I've been asked to call this the "Lottery" factor... which is a nice twist on it). It's not just developers who are susceptible to this. In any team, IT teams in particular, this seems to happen very commonly. In larger organizations, you might even have an infrastructure group and an "IT" group, and they both have different areas of responsibility, and in each group, there's only one person who can do some critical task.  **A chain of bus factors** happens when you have bus factors depending on bus factors: Your one developer who knows how to configure the pipeline can't test the changes because the agent is down. The one guy in IT who has access to the agent needs to reboot it, but does not have access. The one person who has access to reboot it (in the Infra team) is sick, so now there are three people waiting, and there is nothing in this earth that can help that situation.  **Here is another example of a critical bus factor chain:** - Developer can't check in the one feature only they can code so the application is released, - because the source control is down, and the source control person can't fix it, - because the private cloud node is down, and the one person who can fix it, can't,  - because the certificate is expired, and the one person who can fix it, can't, - because the person who acquires certificates is away etc... **Steps to avoid this hell on earth may include:** - Giving more access to other groups for the same resource - Sharing knowledge and responsibility with other people - pairing while working on critical things so knowledge sharing is guaranteed - Create a company policy of (2 bus factors or more) required. Look around you at work right now, and realize how many bus factors you see, and are a part of. Each one slows down the system more and more. Each one causes the system to be more and more fragile.  When you are a bus factor you might think: > "I need to work only on this one thing, otherwise I'll have too much to do, and so will everyone else on my team". **But realize that you are also creating more work for yourself this way:** Whenever someone needs work done on this topic, **you** will be the one person they turn to. **You** will be the pain point for every project that needs this type of worl from now on. Sharing the burden also means alleviating the load, and letting more people finish their work without needing you. Yes, there is a balance to be had, but remember that balance means not only "I won't give admin rights to the whole world" but it also means "I won't be the only one with the ability to do something". How much time, money, pain and sufferingin the workplace is caused by people just waiting for people who are waiting for people who are waiting for people? The answer will shock you! (OK, bad ending, but hey, great punch lines are not my job...) --- title: "Elastic Leadership Book Published" url: "https://www.5whys.com/articles/elastic-leadership-book-published.md" canonical: "https://www.5whys.com/articles/elastic-leadership-book-published.html" published: "2017-02-21T22:00:00.074000+00:00" updated: "2017-02-21T22:01:42.487000+00:00" tags: [] author: "Roy Osherove" description: "I'm happy (if a little late) to annoucne that \"Elastic Leadership\" has now been officially published by Manning. You can grab the book here" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Elastic Leadership Book Published I'm happy (if a little late) to annoucne that "Elastic Leadership" has now been officially published by Manning. [You can grab the book here](https://www.manning.com/books/elastic-leadership) --- title: "Elastic Leadership Book: The re-publishing of \"Notes to a Software Team Leader\"" url: "https://www.5whys.com/articles/elastic-leadership-book-the-re-publishing-of-notes-to-a-soft.md" canonical: "https://www.5whys.com/articles/elastic-leadership-book-the-re-publishing-of-notes-to-a-soft.html" published: "2015-10-21T04:45:24.247000+00:00" updated: "2015-10-21T05:53:38.117000+00:00" tags: [] author: "Roy Osherove" description: "I'm happy to announce that I am re-publishing the \"Notes to a Software Team Leader\" as a new book under Manning publishing, re-titled \"Elastic Leadership\". The new book will contain a couple of new chapters, regrouping the \"notes\" chapters…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Elastic Leadership Book: The re-publishing of "Notes to a Software Team Leader" I'm happy to announce that I am re-publishing the "Notes to a Software Team Leader" as a new book under Manning publishing, [re-titled "Elastic Leadership".](http://elasticleadership.com/)  The new book will contain a couple of new chapters, regrouping the "notes" chapters under common themes, and extra annotations from me on the external notes, to add where I think they fit into the elastic leadership framework. The new chapters I will be adding: - Line Manager's leadership manifesto - [Bus Factors](https://www.5whys.com/articles/team-bus-factors-how-to-reduce-them-and-how-to-prevent-them.html) I am thankful to Manning for publishing my second book after ["Art of Unit Testing](http://artofunittesting.com/)" 1st and 2nd editions, and hope that the book will end up in the right hands of the right readers who need it most. --- title: "Team Bus Factors: How to Reduce Them and How to Prevent Them" url: "https://www.5whys.com/articles/team-bus-factors-how-to-reduce-them-and-how-to-prevent-them.md" canonical: "https://www.5whys.com/articles/team-bus-factors-how-to-reduce-them-and-how-to-prevent-them.html" published: "2015-10-16T03:37:34.086000+00:00" updated: "2015-10-16T17:11:37.457000+00:00" tags: ["First Steps during chaos"] author: "Roy Osherove" description: "There was a discussion on HN asking about good tips for team leaders. So I thought I'd chime in a bit more deeply. The following is a new chapter from the upcoming second edition of my book for software team leaders They’re all around you…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Team Bus Factors: How to Reduce Them and How to Prevent Them There was a [discussion on HN](https://news.ycombinator.com/item?id=10395046) asking about good tips for team leaders. So I thought I'd chime in a bit more deeply. The following is a new chapter from the [upcoming second edition of my book for software team leaders](http://teamleaderbook.com/)  They’re all around you, and they are huge risks to your projects. Bus factors. A bus factor can be defined as “How many people need to get hit by a bus for the project or team to stop functioning”.  A bus factor of 1 is the most risky. If you’ve worked in software any length of time and I’d ask you “Do you know a person in your project that, if they had disappeared tomorrow, the project or team would get stuck?” it is very very likely that you can provide me with multiple names.  These people (roles, really) are what I’ll call “bus factors” from now on. I had a friend who joked that _“every successful software company is hiding one “Yuri” in the basement that does all the important stuff"_.. Joking aside,  “_Yuri_” represents talent, a specialist, acquired from overseas perhaps, that is hard to reproduce. Many companies indeed do have multiple “Yuri”s. And they are a huge risk. Let’s break down some of the reasons they are a risk: \-       Having a single point of failure \-       Having a bottleneck that slows things to a crawl \-       Reducing moral/Avoiding moral boosting/job insecurity \-       Avoiding team growth - ·      **Having a single point of failure** I once consulted at a large insurance provider One of the projects, with about 200 developers, had just one build consultant who had been working there for several years, but was still an outside consultant.  His job was to take care of the build and release. A release took a week. There was one release every month. Everyone stayed out of each other’s way, and he mind his own business as well. One day he got tired of working at the same place and same project and transferred to a different consulting gig at another place.The project (the copany’s main source of revenue) was unable to release software, at all.No bug fixes to production, no new features seeing the light of day. Nothing. Huge money loss, as well as possible new customer loss. Everyone was running around like headless chickens, trying to fix this. Eventually they called the build consultant again, paid him 3 times his usual hourly to sit there for a couple of weeks, while they attached a mic and screen recording software to his machine, while he was doing two releases (fake and real one). They paid dearly for getting rid of the bus factor. Lesson: The less people you have that know an important part of your business, the more you will pay when they move on. - ·      **Having a bottleneck that slows things to a crawl** One of the large projects I consulted for had a huge problem with code quality and slow release cycles. When I paired with developers several things were very clear. One developer that I paired with was working on a long function that was very unreadable and unmaintainable. He was just adding spaghetti code onto more spaghetti code. When I asked him why he wouldn’t refactor his new code a little bit or just extract some stuff to an external method, his reply was “That’d be crazy. If I do that, I’m going to have to ask for a new code review for that code section, and those things take days until they're done by an architect. There were only two architects that were allowed to do code reviews, and they were busy writing new code most of the time. So they had little time to review code changes and approve them. So getting code into even a regular dev branch would take days, which slowed the place down to a crawl. It is harder to keep up with fixes, add changes quickly or even show demos and get feedback fast enough in a sprint cycle. If you’ve read about the “Theory of Constraints”, then a bus factor is a type of a constraint, and thus everything will move as slowly as the slowest constraint.  ·      **Job insecurity/Reducing moral/Avoiding moral boosting** There’s also negative consequence to the bus factor person themselves. I once consulted at a large software/hardware firm. The build process was managed by three people and they were very defensive about teaching other people how to use the build process (we’ll talk about job security in the next point regarding this). One of them was adamantly against showing other people how the build worked, because he felt that this was his job. He was the specialist with 20 years of training on the job. It can be said that being the only expert at something is a good way to have job security, but it is is very much a double edges sword. An organization will usually seek to reduce the bus factor risk. A person who is a bus factor and avoid reducing the factor will usually have to take a forceful stand against the organization, effectively holding the project or team hostage since no one else can fill the role. It is very likely for the organization to try to find the first “match” to come along to replace or augment that person’s job to reduce the bus factor. The more forceful he was originally, the less chance he has of staying onwards when someone else with the same or better skill set comes along. It’s the same people hate buying from monopolies, and can’t way to jump ship with an adequate competitor comes along, even if it is just on principle. - ·      **Preventing team growth** I’ve seen many people quit their jobs because they were’t learning anything new in them They got bored of doing the same work, of not being challenged, and they moved on to more challenging pastures.  Bus factors are knowledge silos by definition. Knowledge silos that are not broken can lead to the “not my job” mentality (Go yourself a favor and google “No my Job Award” and see extreme versions of that mentality when it gets perpetuated by the organization itself.) In that mentality, even people who want to learn and be challenged are going to have a hard time finding new challenges since they are expected to stay in their own little cube. That , in turn, makes for a team of specialists, or, to put it more bluntly, a team of bus factors. One of the places I was consulting for once had an issue: the search server the product was using was failing and since it was setup by an external company, nobody on the team knew how to fix it. The people form the external consultancy were on a company vacation or something of that sort, and it took three days to fix. Here’s how it got fixed: A developer called the expert on the phone,The expert told the developer exactly what to type into the terminal.The developer blindly typed it into the terminal , waited, then said “ok it seems to work now” and hung up.  What a wasted opportunity to learn something that might really help solve this problem next time. Not even a “why did that command fix it?” or “Why did it fail? What can we do next time on our own to prevent this?”. Nothing. This is what that mentality begets: lots of lost time, and people putting cubicles inside their minds, preventing learning.  **Removing Bus Factors** There are several ways that I’ve used in the past to remove existing bus factors. Some of them are slower, but more effective in the long run. Others are faster but are a bit less effective in the long run.  -       Pairing Ask the bus factor to pair up for at least 30 minutes a day with one other people in the team, and during that time, the less experiences person will do most of the hands on work, with the bus factor sitting next to them coaching and explaining what to do next. Do this until the less experienced person knows how to accomplish one task without the bus factor’s help, then either move to a new task, or have the newly minted person stop pairing with the bus factor, and pair with some other member of the team to achieve the same goals. The best way to learn is to teach, and by teaching, the new person will have learned the new task in a much deeper way.  -       Make them in charge of teaching Have the bus factor be in charge of a project that requires multiple people to accomplish tasks relating to the bus factor’s area of knowledge. Then make sure part of that project is the bus factor teaching others on how to accomplish this.  -       Prevent them from working on area of knowledge Ask the bus factor to not work hands on in their  area of knowledge for a day a week, while others try to take over. This might feel scary but it is a great way to get up and running fast.  -       Apprentices Assign a full time apprentice to that expert and make sure they pair as much as possible.  **Avoiding future bus factors**  You can’t always avoid bus factors from sprouting, but you can minimize the likelihood of it happening by: \-       **Pairing** The more pairing your team does, the less likely it is that only one person knows how something works. \-       **1-1 code reviews** it’s almost as good as pairing: Each code checkin gets personally reviews locally or via remove call (skype etc) with at least audio. This provides learning since it is meant to be a conversation. \-       **Rotation (support, scrum master, build..)** Set a daily, weekly or bi weekly rotation on tasks that are bus factors or with new tasks to prevent them from being bus factors.  -       **Pushing people out of their comfort zone instead of asking the veterans to do it** If a new task comes up, select the person on your team with the least skills to accomplish it (assuming it is not high risk). If it is high risk, save that thought for a low risk task (don’t tell me everything is high risk!)  Next, we’ll discuss survival mode, which , if you don’t take care of your bus factors, you can easily fall into. --- title: "A Realistic HackerRank Developer Interview Question List" url: "https://www.5whys.com/articles/a-realistic-hackerrank-developer-interview-question-list.md" canonical: "https://www.5whys.com/articles/a-realistic-hackerrank-developer-interview-question-list.html" published: "2015-07-09T17:33:39.028000+00:00" updated: "2015-07-09T18:59:04.043000+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "When I was looking for a new job it always puzzled me that companies looking for senior developers, team leaders, architects and Dev managers were asking me to fill out silly hackerrank style questions such as : * How to effectively…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A Realistic HackerRank Developer Interview Question List When I was looking for a new job it always puzzled me that companies looking for senior developers, team leaders, architects and Dev managers were asking me to fill out silly hackerrank style questions such as : \* How to effectively measure the diameter of a tree \* How to compute Prime factorials \* If two eggs are all you have and you have 100 story building... Unless you are specifically looking for an algorithm related developers, can we stop this lunacy? This is not the stuff 99.9% of developer and tech leads have to deal with in real life. Here are some questions that will tell you if that person can really help in your team. Unfortunately it's hard to "measure" the answers. But I'll try. If I were building a "hackerrank" website: **1\. You have a team of 12 people spread out across three different locations. It takes an hour to get to one location (A) from your house. 90 minutes (without traffic) to get to the second location (B) , and 3 hours (no traffic) to get to the third location (C). Each person in the team seems to be over committed: they are behind on things they haven't even started yet.** **The people in site A have knowledge abouttechnology T and T2. The peoplein site B have 1 person who knows about technology T and all the rest know about a technology T1. The people in site C know about technology T but not about T1.**  **There are 7 people in site A, 6 people in site B and 2 people in site C.** **The project manager for the highest priority project is hounding you because a project with technology T is 2 months late. However, all the people who know  technology T are already busy working on solving this and everyone else can't help you from your group.** **What is likely the root cause? what can you?** A. Root is cause is the project is demanding things that are unreasonable. Plow onwards and hope for the best. B. Root cause is project is demanding things that are unreasonable. Tell that to the project leader and your manager.  C. Root cause is there isn't enough cross training. Plow through and do some cross training when the fire is out. D. Root is cause id there isn't enough cross training. Stop all other work by your group and do cross training so people can help the folks in site A get the job done. E. A and D F. B and D G. Other (open ended) **2\. The project manager is complaining about the amount of of bugs found in production, and you know that your code quality sucks (you just joined and took a look at the code). What questions must you be able to answer before starting to fix this?** A.  What's our deadline(s)? B.  What other commitments do we have? C. Why are people writing bad code? D. Is bad code really the problem? E. What's our code coverage? F. B C and D G. A D and D H. B D and E I. all of the bove J. none of the above K. Other (open ended) **3\. How would you measure your success as a tech leader?** A. The quality of the code my people write B. Our code works in production C Our code works in production and is maintainable D We live up to the targets provided E It's fun to work in our team F The project manager likes our outputs G I am not a bottleneck for making decisions **4\. You have a developer that no one wants to interact with because they are very aggressive. What do you do?** A. Fire them. No asshole rule applies. B. Coach them for a few months and get them off the team if it doesn't work out. C. Have 1-1 and tell them to behave better. D. Ask the people that complained to talk to your developer about his/her behavior E. other (open ended) **5\. A developer sends you an email showing that he's being requested by various stakeholders to work on a project that is not top priority. What do you do?** A. Send a stern email to the stakeholders with CC to my manager B. Ask developer to send email to stakeholders with CC to me, with the promise I will back him/her up with what he thinks is the right thing to do C. Tell developer to find a way to support this in spite of time pressure D. Tell developer to ignore that email E. Find another developer to support this activity. If none are available use A or B F. Find another developer to support this activity. If none are available use C or D **6\. Which of the following design patterns would make it harder for you to follow SOLID design rules? Select all that apply.** A. Singleton B. Chain Of Responsibility C Composite D Decorator E (more pattern names here) **7\. Write down as many uses for a blanket that you can think of within the next 60 seconds. Think out of the box.** Can you guess why I'm asking the last one? I want to see how creative the person is. Less creative people might come up with 5 or 10. The really creative ones might find up to 20 in a minute. If you give them 5 minutes you might get 50 uses or more. Less creative folks might give up after 10 or less. --- title: "When I Want to Give Up" url: "https://www.5whys.com/articles/when-i-want-to-give-up.md" canonical: "https://www.5whys.com/articles/when-i-want-to-give-up.html" published: "2015-06-11T04:28:07.403000+00:00" updated: "2015-06-11T04:48:50.737000+00:00" tags: ["Critical Thinking"] author: "Roy Osherove" description: "When I'm at work and I suddenly feel like everything sucks and the world can just burn as far as I'm concerned, I take a look at this picture I found on the web a while ago, printed it and mounted it on my door: It helps me take an inward…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # When I Want to Give Up When I'm at work and I suddenly feel like everything sucks and the world can just burn as far as I'm concerned, I take a look at this picture I found on the web a while ago, printed it and mounted it on my door: [![](https://www.5whys.com/img/posts/6c2b210e-4655535-26304912-thumbnail.jpg)](http://i.imgur.com/rxwEiSl.jpg) It helps me take an inward look and try to identify what exactly is it that I currently feel. When I can name the feeling(s) it generally becomes less of a blocking issue. Like a shadow under the bed that you shine a light on. I go through each one, asking myself: > "Do I feel like this now? Why?" . Maybe I just left a meeting where I felt the rug was swept under my feet. > "How do I feel about that now? does it fit one of these things? Oh, I think I'm just expecting fast results." Then I can plan my next steps.  This also reminds me that everyone feels these things from time to time. They are universal.   Some of them are temporary shortsighted views on a long running path (expecting fast results..).Some of them are just something to be acknowledged and dealt with (overworked). These things are also called "[Gumption Traps](http://en.wikipedia.org/wiki/Gumption_trap)" (Thanks, [John Crowe](https://twitter.com/TheCrow1213/status/606580150952697856)) and I find them quite helpful. --- title: "Dangers of Survival Mode" url: "https://www.5whys.com/articles/dangers-of-survival-mode.md" canonical: "https://www.5whys.com/articles/dangers-of-survival-mode.html" published: "2014-11-03T02:07:59.827000+00:00" updated: "2014-11-03T02:14:44.003000+00:00" tags: [] author: "Roy Osherove" description: "I have just finished teaching a two day elastic leadership class in Denmark. One of the exercises I ask leaders to do is to try and finish a time based LEGO building exercises while the world if crumbling around them (lots of factors that…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Dangers of Survival Mode I have just finished teaching a two day elastic leadership class in Denmark. One of the exercises I ask leaders to do is to try and finish a time based LEGO building exercises while the world if crumbling around them (lots of factors that create chaos). The goal of that exercise, where I play the customer, is to win by delivering to the customer what they expect to be delivered. This does not mean that what was initially discussed as the requested building is what will be delivered. Team leaders are expected to negotiate and try to change their surrounding "reality" by discussing and explaining to the customer what they can and cannot deliver, and negotiate on time, feature scope, or amount of people they can work with to achieve the task. It's always a very interesting experiment to see how people handle the stress associated with Survival mode. _Survival mode_ is that awful place where you are over committed and have no time to learn, so you are left only "reacting"; fixing fires, cutting corners, and never really proud of your work. Many times it is a spiral, since lack of time to do things "right" leads to much more messy fixes, and slower release cycles, since everyone has very little confidence in whatever it is they are building. So, how do people, even leaders with experience, react under this situation? In a very human way. The most common reactions are: - _Give up almost immediately_. As a customer, I tell them they have x minutes to finish, and not even a hint of trying to negotiate, or saying that this time frame doesn't fit the work. Many accept this time limit as a given even without asking simple things about the scope such as "how big is this LEGO bridge supposed to be" or "which color does it need to be?" - _Forget to show demos along the way_ so they can see if they are doing the right thing. Then failure ensues as what I requested and envisioned in my head is very different that what they envisioned. - During the work, _fail to notice any team bottlenecks_. For example people with disruptive behavior. - If helping out as part of the team, _forget to look at the big picture_, such as how much time is left, showing demos, or are there any inherent problems in the way of work. As a result, many teams fails to give what the customer _expected_ in the time negotiated. And many teams fail to even negotiate a reasonable amount of time, or even notice they are building the wrong thing in time, or at all. You might say "It's just LEGO." But lots of the same symptoms arise in real life software development (and other types of teams).How many projects have you been to where, on the _first_ day of the project, you knew it was going go fail? There is a certain release in knowing something like this. It helps you shed any responsibility to the well being of a project, and you feel less accountable. Here's the problem with that approach, though. _Many team leaders are "thrown" into a dire situation, thinking that the whole situation is "a given". A fact of life that cannot be changed._ Doomed project? Guess we're screwed then. Nothing left to do but twiddle your thumbs. No. You are _paid_ to _change_ the situation you're in, and do good professional work. If that's not what you are paid to do, I think you should leave your job. Most software team leaders have options if they started looking, and there are plenty of companies out there looking for people who want to be proactive bout making things right. So, what are those things that people think are "given" that aren't really most of the time? - _The time you have to finish the project is not really a given_. It is a direct factor of the estimates that you give at the beginning, and as time progresses you _can_ and _should_ ask for more time/ change of scope or adding team members (although that might make the project even later in some cases) - _The low quality is not a given_. You can change the low quality (at least for new work) by demanding it from your team. Don't have time? make time. Re-estimate. Is that scary to do? Guess what, part of being a leader is doing things that are uncomfortable. - _People's behavior in your team is not a given_. You can influence and help change unproductive behavior. Sometimes leaders avoid directly talking to people in their team about unproductive (problematic) behavior. Part of the work. You don't have to be an asshole about it, but you can be direct without being hurtful. People need to know that there are consequences for problematic behavior. You can even ask people to stop contributing, or ask for people to be replaced. Though usually you should try and work on the problem instead of getting rid of people. It will do good for you as well to try and jump into such a challenge, and you will learn a lot from it. --- title: "Ask Royo #1 - Team Leadership and Influence Edition" url: "https://www.5whys.com/articles/ask-royo-1-team-leadership-and-influence-edition.md" canonical: "https://www.5whys.com/articles/ask-royo-1-team-leadership-and-influence-edition.html" published: "2014-11-03T02:00:46.003000+00:00" updated: "2014-11-03T02:04:21.527000+00:00" tags: ["Video", "people patterns"] author: "Roy Osherove" description: "A new experiment I'm making. Twieet me questions about anything relating to leadership or software dev, and I'll try to answer as best I can if I have any knowledge in the area. In this episode I answer the following questions: How do you…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Ask Royo \#1 - Team Leadership and Influence Edition A new experiment I'm making. Twieet me questions about anything relating to leadership or software dev, and I'll try to answer as best I can if I have any knowledge in the area. In this episode I answer the following questions: - How do you show the benefits of test first vs. test last? - When jobseeking, how do I look for places that are in chaos or survival mode? - How big should your team be before you need a team lead? - Examples of Team "Homework" - How to encourage devs to write unit tests - The role of designers and architects in agile. is tdd irrelevant? - Code reviews with remote teams [![](https://www.5whys.com/img/video/youtube-EV5gdyRYV8M.jpg)Watch on YouTube](https://www.youtube.com/watch?v=EV5gdyRYV8M) Ask Royo Ep.1 --- title: "A Value System for Code Reviews, and How to Scale Them for a Large Project" url: "https://www.5whys.com/articles/a-value-system-for-code-reviews-and-how-to-scale-them-for-a.md" canonical: "https://www.5whys.com/articles/a-value-system-for-code-reviews-and-how-to-scale-them-for-a.html" published: "2014-09-18T14:16:44.583000+00:00" updated: "2015-01-02T07:56:18.086000+00:00" tags: ["First Steps during chaos", "Growing People"] author: "Roy Osherove" description: "One of my customers wanted my help is increasing their code quality. When I spoke with the developers the following conversation happened several times: Me: \"Wow, this code... how many lines long is this method?\" Dev: \"about 700. Yeah I…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A Value System for Code Reviews, and How to Scale Them for a Large Project One of my customers wanted my help is increasing their code quality. When I spoke with the developers the following conversation happened several times: _Me: "Wow, this code... how many lines long is this method?"_ _Dev: "about 700. Yeah I know"_ _Me: "Have you tried to refactor some of it?"_ _Dev: "oh.. noooo."_ _Me: "What if we just extract this small part over here , these couple of lines, to a method with a good name?"_ _Dev: "Yeah, let's not.  If I do that then I have to do a code review on that, and that can take 24 hours to 3 days. The architects are so busy.. too much of a big deal. I'd rather focus on what I'm doing"_ When I went to the architects I heard from them how overworked they were. They meant well, but 2 architects on 30 devs, with more of their own stuff to do as well.. it just didn't scale. I went to the chief Architect and told him what I saw. I told him I felt that the way the code review process worked (reviews are done through a tool, and take very long) is actually deterring people from changing the code for the better. He was surprised to hear it. After all, they had instituted mandatory code reviews to _increase_ code quality. So we talked about what we can do. Here's the plan we setup in place: We will organize a team meeting of all the architect where we will agree on some basic values of what we want from code reviews. I noted that the following values worked for me: A code review is successful if: - The developer who wrote the code learned something new (even if small) - The code ends up being better  (even if slightly, even if it's just one character or a name change) - To achieve this, an effective code review [has to be in person](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html), not through a tool if possible. if not, then through a non text tool (visual+ audio) - It also has to occur quickly , or even immediately when the code is ready for check in - It increases the amount of people that can review code, or the amount of code they can review well We decided to experiment for a couple of months with doing reviews this way: - When a developer needs a code review, they can just go to an architect and ask for it in person (not using a tool hopefully). - The architect will join the dev and review the code, while talking as much as possible about their thinking process, coaching in the process - A THIRD person will join (another dev) the review, sitting near and learning how to review the code. - The next time a review is requested, the learning dev (third person) will try and do the review while the architect sits back and sees how it goes, then goes over any missing things with the reviewer  - Developers will check in **early** and **often** so that code reviews are nice and short (a few minutes hopefully) In this way we: 1. Make the reviews more effective since they are in person 2. Less bureaucratic since they happen very quickly 3. This also  makes developers less afraid to change code and get feedback on it since it doesn't take a long time 4. We make more developers able to be code reviewers, thus making the code review process more scalable. Anyone can review anyone's code within a couple of months. I wrote more about [code reviews in the face of horrible code quality here.](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html) --- title: "Scrum Master 2.0: A Scrum Master is Not" url: "https://www.5whys.com/articles/scrum-master-20-a-scrum-master-is-not.md" canonical: "https://www.5whys.com/articles/scrum-master-20-a-scrum-master-is-not.html" published: "2014-07-21T21:21:09.023000+00:00" updated: "2014-07-21T21:49:34.627000+00:00" tags: [] author: "Roy Osherove" description: "I'm a big fan of the idea that you should grow your team to be self organizing . I also used to hold the idea e that a Scrum master is just another word for \"team coach\", that should grow their team. I felt that people who say that Scrum…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Scrum Master 2.0: A Scrum Master is Not I'm a big fan of the idea that you should [grow your team to be self organizing](http://teamleaderbook.com/). I also used to hold the idea e that a Scrum master is just another word for "team coach", that should grow their team. I felt that people who say that Scrum masters should guard their teams from outside interference would be doing a disservice to their team, because they hold them back from learning and growing new skills needed. I felt that scrum masters who protect their teams become bottlenecks, and they do.  But in the past couple of years I've had some interesting discussions with some of the original Scrum Folks (Especially [Martin Devos](https://skillsmatter.com/courses/151-martine-devos-scrum-master)) and what most of them seem to agree on is this: Scrum today, and the Scrum master role as it is taught, is very different, and less effective, than the original intent of the role. This has been gestating in my head for a few months, but I think that now I see this weird role like this: **A Scrum Master is not:** - A Team Leader - A Tech Leader - Permanent - A Coach **A Scrum Master should be:** - A constant role that is temporarily held by a person (weekly or even daily basis)  - Fulfilled by all members of the team, in turn, in cycles, so that they learn to deal with outside interference and grow their skills of working within an organization - The person that does all the "dirty day to day minutia" that keeps the team from doing their stuff (paperwork, meetings etc) Notice that the key factors for an effective scrum master are that they are not one fixed person, but a role shared and cycled through by all members of the team. This way you get the following benefits: - They are not a bottleneck, since each member of the team should be able to perform this function (or learn in the process of doing) - They save the team from unneeded red tape and delays by having one person take all the "heat" for a week, then moving to the next person. So why is this so different than what many today say? I'm not sure. I think somehwere the idea of "rotating" got lost and we were left with "fixed role".  Then, many people, me included, tried to reconcile the notion of a self organizing team with a fixed scrum master (a bottleneck! [a bus factor](https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html)!), and the only way that made sense was if the scrum master was indeed taking the role of a coach or a team leader, growing and pushing the team out of its comfort zones.  On top of that were all the extra "bonuses" of being in charge of the process and other weird business. I'm really not sure where that stuff came from, but it's really really weird.  Funnily enough, if you go down the rabbit hole of a leader\\coaching SM making themselves unnecessary, you might come in the end to the point of this post: That a Scrum Master will ask their team to do his/her job , weekly in cycles, so that they learn that set of skills. **So, my current way of thinking:** 1. If you are about to decide who will be the team SM, don't choose anyone. make them a all a SM, on a week by week basis.  2. If you are a fixed role Scum Master (that is, there is only one person assigned), you do need to become the coach, and get everyone to cycle through your role in dealing with red tape and outside interference. A Scrum Master 2.0 is really the Scrum Master 0.1 in its most basic form. --- title: "3 Reasons to stop solving other people's problems for them" url: "https://www.5whys.com/articles/3-reasons-to-stop-solving-other-peoples-problems-for-them.md" canonical: "https://www.5whys.com/articles/3-reasons-to-stop-solving-other-peoples-problems-for-them.html" published: "2014-05-23T22:18:27.091000+00:00" updated: "2014-05-23T22:29:12.092000+00:00" tags: [] author: "Roy Osherove" description: "If you re an expert in some field in your team (the DB guy, the UI gal, the search Guru.. you know), it also means you're a bottleneck, and people have to constantly wait for you to make decisions on important things. Here are three…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 3 Reasons to stop solving other people's problems for them If you re an expert in some field in your team (the DB guy, the UI gal, the search Guru.. you know), it also means you're a bottleneck, and people have to constantly wait for you to make decisions on important things. Here are three reasons why you should stop solving other people's problems, and start pairing with them when they come to you with questions: 1. You will be reducing the risk factor in the project. The risk is that you won't be there when you're needed and people will be stuck without you (also called the bus factor). Can the team handle you being a way for a couple weeks? if not, that is a huge risk. 2. You will teach other people to solve their own problems, thus making them better at decision making. This will improve your status from "expert at X" to "Expert factory on X". You will have  force multiplier of sorts. Think world of warcraft and you getting one level up. You can start influencing more people and more decisions, by teaching them how to think like you. Now you're the person who you can bring into a team to make them better at doing X, instead of just solving X for the team. That might also mean a salary raise for you. 3. You will have more free time to do the things you really want to do. Instead of solving the same boring problems for everyone, you now have time to focus on more interesting problems, research or dive into new areas. Delegation is free time. Now you get to become better too! ### So what should you do? - Someone comes to you with a problem: "hey the build is failing and I don't know why. please fix it for me". - You: OK, come sit with me and we'll check this out together. I want you to try and do this with me so you won't have to wait for me next time this happens, or so that I won't be the only person here who knows how to solve it" - Them: "ugh, I don't have time for this now" - You: OK, so come to me later when you have time and we'll do this together. I have something I need to finish anyway. - OR you again: "So what if I wasn't here? that's a huge risk we can't afford. Let me teach you at least how to think about this problem and some common ideas to solve it. it will take five minutes" Usually that breaks the ice enough. If not, keep at it for next time, but be PRO ACTIVE. No one will do it for you. --- title: "Signs you might be in survival mode" url: "https://www.5whys.com/articles/signs-you-might-be-in-survival-mode.md" canonical: "https://www.5whys.com/articles/signs-you-might-be-in-survival-mode.html" published: "2014-03-27T07:37:29.863000+00:00" updated: "2014-05-22T21:12:54.667000+00:00" tags: ["First Steps during chaos"] author: "Roy Osherove" description: "We had an interesting discussion in class on how one can detect you might be in survival mode. Here are some possible early warning signs: There is a perception or feeling of continuous urgency There is lack of context (why are we doing…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Signs you might be in survival mode We had an interesting discussion [in class](http://osherove.com/trainingoptions) on how one can detect you might be in survival mode. Here are some possible early warning signs: 1. There is a perception or feeling of continuous urgency 2. There is lack of context (why are we doing this? where are we heading? When is this expected? what are the expectations?) 3. The team is forced into a state where they are always _reacting_ to changes (key word here is _forced_ because a self organizing team can choose to simply react with changes such as during  a continuous delivery flow). Not being able to choose whether to plan some things out. 4. There is no time to reduce risk (technical debt, bus factors etc) 5. The team is unable to deliver 6. There is only time to take shortcuts 7. A long period of stress 8. Being non productive for a long period of time --- title: "Technical Disobedience" url: "https://www.5whys.com/articles/technical-disobedience.md" canonical: "https://www.5whys.com/articles/technical-disobedience.html" published: "2013-11-03T12:39:22.001000+00:00" updated: "2014-05-22T22:52:22.573000+00:00" tags: [] author: "Roy Osherove" description: "Rachel's Suffering In one of my first jobs as a programmer I joined a team working on a governmental project. The team was sitting at the code shop, not at the governmental place. The coding shop I was working for as a coder at that time…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Technical Disobedience ## Rachel's Suffering In one of my first jobs as a programmer I joined a team working on a governmental project. The team was sitting at the code shop, not at the governmental place. The coding shop I was working for as a coder at that time had some really good people working there. Many of them were suffering silently. I remember this one specific coder working there. I'll call her _Rachel_ because that's not her real name. _Rachel_ was in her 40s, and she was an expert database person. She mastered _SQL_ syntax, stored procedure optimizations, index optimizations and partitioning like nobody else at that office. I remember the first time I came up to Rachel's desk to ask her something. She was hunched over the screen, like _Golum_ staring at his precious ring. Her nose almost touching the screen. I turned my face at the screen to see what was so interesting. For half a second, I didn't understand what I was seeing. It looked like very small, dead black ants, on a white background, all over her screen. I squinted (I must have been 25 at the time) to try and see better. These were words. > "SELECT \* FROM…" There were well over a hundred lines of SQL code, in a tiny, oh so tiny font, all made to fit the small 15" screen. "What the…" I muttered. Rachel smiled with pride. "Yeah, I know". She was proud of having been able to work on such a small screen with such a large amount of data. She accepted the smallness of the screen as a god given commandment, and was just trying to do her best. She wasn't unhappy, or at least unaware of how unhappy she was. I could not understand what she was smiling about. She has been working there for at least five years before I stepped through the door, and I tried to imagine her life as a developer, hunched over the code, trying to get just enough real-estate to be able to do their job. Focusing her eyes so many hours a day at such small text must not have made much good. It was madness. I looked around, and everyone around me had 15" monitors. A 15 inch monitor was not unheard of at the time, but most developers had at home nothing less than a 17" monitor, and some had 19". These were the old, bloated CRT screens, not the nice thin ones like we have today. ## Breaking the Screen Rules I had a 17" screen. Well, not at first. I started out with a 15" screen, but having had a 17" screen at home, I knew I couldn't go back to working on a 15" for long. I asked my team leader if I could get a 17" screen. I heard back that there was a line of seniority to receive the screens. There were at least six people ahead of me. Rachel was number 8 on that list. New screen would arrive only when an older screen had broke, which was every couple of months. I couldn't stand it. I just couldn't accept it. I had just finished reading "Mythical Man Month" and "The Pragmatic Programmer" and was all riled up about having good developer environments and tools that help rather than hurt. So I took my 17" screen from home and brought it to work. I would work at home with a 15" and work at work with 17". So one morning I just showed up at the office with a big box containing a 17" screen and connected it to my computer. As I walked down the corridor I had to explain to everyone that I got it from home, so that nobody will feel like I cheated my way up to a 17" screen. How silly is it to have a screen size measure your "seniority" anyway? I _was_ cheating, though. I didn't go by the rules. I went around the rules, and made up my own rules. Nobody got hurt. But I got to work in an environment that was better than I had, and it helped me do better at my work. I didn't care that it wasn't "my job" to take care of the tooling I was working on. Because _it is_ my job to worry about the tools I work with. > If you don't worry about your technical environment, nobody else won't either, probably. A year later I got my new screen, but it was old news. I had already been working with such a screen for a year, so I gave up my turn and gave it to the next in line after me. ## The Creeping Whiteboard As I reach back into my mind, I had behaved like this in other technical projects. Always trying to find a way to shorten, simplify or simply work around things that bother me. In a recent (again, governmental) project, we had to use TFS to manage the tasks. It was a team of 7 developers. And the testers were using Mercury tools to manage their own tasks. I was coaching the Scrum Master at the time and suggested that we also use a whiteboard to "you know, manage just the weekly tasks". This task board became more and more sophisticated, and the product owner liked it as well. Soon, all work would revolve around the task board and its notes. People started to forget to put tasks in TFS, and nothing happened. When I left the project six months later, the product owner asked me: > "Hey, am I crazy, or do we not really need TFS to manage our tasks anymore? we seem to be doing just fine with the whiteboard." > > "Exactly" - I replied. Win for common sense over company bureaucracy. The only reason this worked is because people _felt_ it working. It's not enough to just discuss something and try to convince people. _Show them what it feels like_. ## Technical Disobedience I never had a name for this behavior that I seem to be repeating over and over again at various places. I do know that it helps move things and get shit done. I know that [I teach it in my book for software team leaders](http://teamleadskills.com/), to never accept the status quo for what it is and to realize you always have things you can do. Then the phrase "Technical Disobedience" finally clicked into place when I saw [this short film about Cuba and the "Technological Disobedience"](http://blog.p2pfoundation.net/technological-disobedience-in-cuba/2013/09/22) the cubans had to come up with to survive in a society that had choked out any input of mechanical parts, new technology and new science. The cubans had to deal with being in a very closed bubble, and had to make their own luck and their own innovations with the things they already had. So they reinvented old ideas, and gave them a twist. Old ventilator engines became bicycle engines, freezer engines. Cars and Bicycle would be combines to create half breed mutants that did what they couldn't do with the things they already had. get around. ## And what about us developers? We take so many things for granted, when we could be going so much farther and faster with just a little more courage to break and remake the small rules that govern our technical life. We are all locked in our own little technical world; A technical kingdom with DOs and DON'Ts. From startups to "enterprise software houses" — we are all bound by some rules. Those rules can be as simple as "we don't have the budget to do this", as annoying as "approving a budget for this will take three months", as frustrating as being unable to have test or staging environments due to oblivious "security restrictions" and as down right stupid as "we'd rather spend $20,000 on the wrong thing rather than get the right thing for $1000 because that's where the budgets are". If you just accept it, you're stuck just like everybody else. If you realize that you can actually do small hacks in the way the system works, you can get things done that none in that organization ever thought possible. Sometimes you just have to say "screw it" and try out something. It's better to try than to continue to fail and sometimes it's better to ask forgiveness than permission. It's actually pretty easy once you try it. Here are some other examples. ## The Test Machine(s) A project I was consulting for wanted to get things just right. The team even got an OK from management to try this new _Kanban_ and _Continuous Integration_ they have been hearing so much about. So I introduced the team to the idea of [Shipping Skeleton](http://osherove.com/blog/2013/1/7/build-pattern-shipping-skeleton.html). You start with a shipping "hello world" application that gets deployed to test, staging and production with the click of a button, while also passing all the tests. then you start working on the actual code. Great idea? Only in theory for that team. They tried, but they didn't even have test machines to deploy to and show a demo. To get new virtual test machines would take a month, and they wanted to start as quickly as possible without compromising on their new values. You had to go through a whole system of things to get something as precious as that, and the people responsible were always so damn busy, and in a totally different country. This is a classic case of management saying one thing, and the system fully designed to say a totally different thing ("screw you, you ain't going nowhere so quickly"). So I went to management as asked their permission to stop using the company that was providing the virtualization services for that team. They were happy and said "go ahead. try other things. it will give us leverage with that 3rd party company come negotiations day. " So I urged the team to try and look into amazon EC2 or Azure machines. No such luck. Security would not let something as simple as that work. Too many loopholes. So I went to master architect at the company asked him if there are any machines lying around that we could use for internal test and demo machines. He pointed me at the machine we had then used to show demos on the big screen TV, and that as long as it is not in use, it should be ok to use it. Bam, we had a machine under our control that we could at least do automated deploys and demos on. Better than nothing. ## The unplanned team room and hardware Me and a team once took over a non used project room along with a bunch of non used machines from an abandoned project. We had 4 test machines for load testing. it was a good project. ## Summary In software, it is far to easy to accept the system around you as status quo. It is harder to realize that software is soft, and that systems can be soft as well. There are many small rules you can try and hack around to get things done. Innovation is part of your job, even if the system directs you otherwise. If you are not going to quit your job, do what you can to innovate in your own boundaries, and get things done by changing the rules just enough. That is why I write about continuous experimentation as part of your role as a team leader [in the team leader manifesto.](https://www.5whys.com/articles/team-leader-manifesto-take-3.html) --- title: "Definition: Survival Mode" url: "https://www.5whys.com/articles/definition-survival-mode.md" canonical: "https://www.5whys.com/articles/definition-survival-mode.html" published: "2013-10-20T11:52:39.097000+00:00" updated: "2013-10-20T11:59:08.008000+00:00" tags: ["First Steps during chaos"] author: "Roy Osherove" description: "A team is in \"Survival\" mode if they do not have time to learn and slowly practice new skills. Such a team is usually over committed and is too busy chasing fires instead of having enough time to hone and practice the skills that prevent…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Definition: Survival Mode A team is in "Survival" mode if they do not have time to learn and slowly practice new skills. Such a team is usually over committed and is too busy chasing fires instead of having enough time to hone and practice the skills that prevent the root cause of the fires in the first place. For example, a team may be too busy fixing all the bugs that keep popping up, that they do not have time to learn and slowly practice design,  refactoring and automated testing of the code to prevent future occurrences. Another example: A team is too busy deploying things manually and preparing for a release instead of spending the time to create a release and build chain. Survival mode is usually patterned as a downward spiral. The less time you have to fix the root causes, the more time you will need to fix the fires that are caused, and then you have even less time to fix the root causes. To get out of survival mode the team needs to: 1. Remove over commitments 2. Change current estimates to include quality in the estimates (usually an increase estimates on current work by 100%-500% is needed) By taking these actions you can create a positive loop in which you fix root causes and then have less fires to fix so you have more time to fix more root causes etc. --- title: "Two Techniques to Avoid the Bus Factor In your Teams: Push and Pull" url: "https://www.5whys.com/articles/two-techniques-to-avoid-the-bus-factor-in-your-teams-push-an.md" canonical: "https://www.5whys.com/articles/two-techniques-to-avoid-the-bus-factor-in-your-teams-push-an.html" published: "2013-09-06T12:52:41.357000+00:00" updated: "2014-05-22T21:40:49.127000+00:00" tags: ["Learning Phase"] author: "Roy Osherove" description: "I spoke before on this blog about BUS FACTORS and how to get rid of them . A bus factor is calculated the the amount of people on your team or project who need to get hit by a bus before the project comes to a halt. There is something that…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Two Techniques to Avoid the Bus Factor In your Teams: Push and Pull I spoke before on this blog about [BUS FACTORS and how to get rid of them](https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html). A bus factor is calculated the the amount of people on your team or project who need to get hit by a bus before the project comes to a halt. There is something that only THEY know how to do. I am revisiting this because there are many ways to get rid of it. Today I cover a couple. But first, a true story. ## The Robot In one of the projects I was consulting for a few years back, we had four teams and many bus factors relating to many things. One of them was related to the search technology the project was using at the time (sharepoint search…shudder!) One day I saw the architect\* running around like a headless chicken trying to figure out how to fix a problem. I asked him what’s wrong and he said “the search guy is out on vacation this week and not answering his phone. I have no idea how to fix this”. It took a couple of hours until he found an external company that once provided these services to the project, and got them on the phone to ask if they knew how to fix this problem. Of course they did. They coached him on the phone what to type to reset some indexes. I was sitting in the next seat listening to him typing word by word into the terminal, pressing enter, and then saying “ok now it works thanks”. Then he hung up. What a great loss of knowledge! Instead of using the opportunity to LEARN something about the problem, its causes and WHY what he typed fixed it, he simply made himself a remote controlled robot for the person on the other side of the phone. I coached him to do the following next time: When you find the situation has been solved, ask the following questions on the phone: -   - **What exactly was the problem?** (tag this type of problem in your mind. like a design patterns, we can have “problem patterns”) - **What made you realize that was the problem? if you indeed realized it.** (learn their thought process. learn to think like them) - **What did the actions we just took mean? where can I learn the full syntax of those commands?** (learn the solution pattern) - **Who else around me knows what you just told me?** (see how bad the bus factor really is. Maybe you just did not know who to ask? maybe you are the ONLY one who does not know how to do this?) ## Pull Based Learning What I coached him to do was what I call “PULL Based Learning”. Before I discuss that, let’s talk about why it is important to learn this pattern. One of the best ways to remove bus factors, is by pairing. Pairing is an act of **active learning** where knowledge is constantly back and forth. A person asks a question “How did you do that?” . that is an act of deliberate learning. But pairing is also hard to achieve in a culture where pairing was never a “thing” people do.  If you cannot get enough people to pair, or the bus factor is happening when a person from a DIFFERENT team knows something that your team replies on, it’s time to start encouraging active knowledge gathering, or active learning. Active learning comes in two forms, or two directions: - Pull Based Learning: The person who does not know X asks another person who knows X to teach them about X in some way. They initiate a PULL of the information from the other person. - Push Based Learning: The person who knows about X asks a person who does not know about X to join them to learn about X. They initiate a PUSH of information towards the other person. So pulling or pushing depends on who initiated the knowledge transfer. If you find that you have many bus factors, it is important that you teach and coach people how to work in BOTH directions: - When people who need to learn are too shy to ask for help, coach the more experienced people how to PUSH knowledge by asking others to join them in a task that will teach that person something new. - When the people who are the bus factors do not have many opportunities to share knowledge\*\* coach the people with less experience to jump in when they see the bus factor doing something the less experienced person does not know how to do that affects them, and ask to join in for a few minutes to see how things are done. ## Get Permission This also means you might need to get an upper level manager to send an email or have a group meeting letting all developers know that “it is OK to do pairing,  ask for help, request someone to join you to learn new things – even if it means tasks take longer than estimated. it is OK to estimate tasks longer because you want to build these things into your iterations”. In cultures where hierarchy matters a lot, this could be the beginning of the breakthrough you might be looking for – giving people permission to learn and teach is usually the thing most cited (by people I ask) as the reason why they are not doing it. ## Bi-Directional Knowledge Handshake Having only a single direction knowledge sharing culture is very ineffective. In a project full of consultants, who love teaching, but also full of people who hate learning, knowledge will not be shared very often, and if so, with a tea spoon instead of a fire hose (which is usually what you need to start with in extreme cases) In a project full of people wanting to learn, but having all the people with the knowledge be in a different building, company or country, mostly unavailable, knowledge will not be shared. There has to be a knowledge HANDSHAKE for knowledge to actually flow through. otherwise we are talking about tear drops in the ocean. Notes: \* Remember that having a non coaching [architect is having a bottleneck](https://www.5whys.com/articles/the-architect-as-a-leader-and-other-specialists.html) \*\* Maybe you should think about increasing the amount of opportunities? --- title: "What's your Position, Velocity, and Acceleration? by Neal Tibrewala" url: "https://www.5whys.com/articles/whats-your-position-velocity-and-acceleration-by-neal-tibrew.md" canonical: "https://www.5whys.com/articles/whats-your-position-velocity-and-acceleration-by-neal-tibrew.html" published: "2013-09-05T18:51:28.217000+00:00" updated: "2013-09-05T21:14:46.137000+00:00" tags: ["TeamLeader2"] author: "Roy Osherove" description: "About Neal: Neal Tibrewala is the head of software development at L5 Software Group in Austin, TX As a software consultant for 25 years, the thing that I've found the most useful is measuring to figure out where you are and where you're…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # What's your Position, Velocity, and Acceleration? by Neal Tibrewala > About Neal: Neal Tibrewala is the head of software development at L5 Software Group in Austin, TX As a software consultant for 25 years, the thing that I've found the most useful is measuring to figure out where you are and where you're going as a team. Let's take something like the number of known defects in a product. Most software projects track their defects using some kind of defect management tool.  Therefore, a team could know that they have, say 100 known issues with a certain product.   This is their "position". Is this good?  Is this bad?  Is action required to address this fact? Often, someone will make a gut call at this point and say that it is either "fine" or "bad" and try to make a change.  I would argue that change is premature at this point.  As a team, having 10 defects or 100 doesn't tell you if you're in trouble. Smarter teams will say: > "Aha!  We should track our defect rate instead!"   Indeed, tracking your defect rate is the next step.  Take a certain fixed time period, say a scrum iteration, and track the number of defects fixed and new ones discovered to see the total number of open defects at the end of each iteration.  This is called the team's velocity.  In the example above, the team with only 10 defects could be accumulating new ones at a rate of 10 per iteration, and the team with 100 could be decreasing them at a rate of 10 per iteration. Clearly that means the team that's bringing defects down instead of up is the team on the better course, right?   Maybe not. The final step is to track your acceleration.  This is looking how the defect rate changes over time.  The team with a defect rate of +10 per iteration could be learning, thus, the following iteration be at +8 defects, then only +6, etc.  While the team at -10 per iteration could be slowing down, thus be fixing 8, then only 6, then -4, etc.   This number is either plus or minus 2 defects per iteration per iteration (2 defects/iteration^2).  This is the team's acceleration, and this is the number that should be looked at most by the team's leader. Learning will always impact position and velocity.  Spending time learning will slow a team down in the short term, but acceleration, measured over a long period of time, is the surest sign of a team that's learning or not. A team that's not only able to adjust their position, but also control their velocity, is the kind of team that you most want to encourage. Changes that affect acceleration are powerful tools as they can have drastic impact on velocities over time.  Likewise, they can serve as early warning indicators as slowing velocity can be seen far before a project gets into visible trouble. --- title: "Audio Book - Notes to a Software Team Leader, Now Available" url: "https://www.5whys.com/articles/audio-book-notes-to-a-software-team-leader-now-available.md" canonical: "https://www.5whys.com/articles/audio-book-notes-to-a-software-team-leader-now-available.html" published: "2013-08-15T23:42:58.097000+00:00" updated: "2014-05-22T22:11:51.687000+00:00" tags: ["Audio", "Book"] author: "Roy Osherove" description: "Good news everyone ! After more than a year in the making, the text version of my book for team leaders is in final production stages, and the audio version is now already available. You can purchase the audio book in this link, or on…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Audio Book - Notes to a Software Team Leader, Now Available Good news everyone ! After more than a year in the making, [the text version of my book for team leaders](http://teamleadskills.com/) is in final production stages, and the audio version is now already available. [You can purchase the audio book in this link,](http://audio.5whys.com/) or [on Audible.com](http://www.audible.com/pd/Science-Technology/Notes-to-a-Software-Team-Leader-Audiobook/B00FASCIVG?source_code=soc_twi_nr&)  I had it professionally narrated, and I think this book has some sound advice that will actually help you at work. The Audio book contains 4 hours of professionally narrated audio in 31 chapters. Here\`s a sample from chapter 1: [Listen on SoundCloud](https://w.soundcloud.com/player/?url=https%3A%2F%2Fapi.soundcloud.com%2Ftracks%2F104936971) The audio will be available in several formats: 1. Separate Chapter Based mp3s 2. An .m4b file playable as an ITunes Audio Book All these will be included in the zip file that you get upon purchase if you get it at gumroad.com (audible has their own format which is not DRM free I'm afraid). I hope you enjoy it. I know I never have enough time to read all the books I want, so I\`m happy that this book\`s content lends itself to an audio format, that one can listen to in the car or in a gym. If you have any comments or feedback, please let me know in the comments :) Roy --- title: "Be a Book Reviewer for 'Notes to a Software Team Leader'" url: "https://www.5whys.com/articles/be-a-book-reviewer-for-notes-to-a-software-team-leader.md" canonical: "https://www.5whys.com/articles/be-a-book-reviewer-for-notes-to-a-software-team-leader.html" published: "2013-06-20T12:00:23.433000+00:00" updated: "2014-05-22T22:01:37.056000+00:00" tags: [] author: "Roy Osherove" description: "Want a free book ? Willing to review it on Amazon when it is published? Willing to give me valuable feedback? Fill out this form. Open the form (Google Forms)" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Be a Book Reviewer for 'Notes to a Software Team Leader' Want [a free book](http://teamleadskills.com/)? Willing to review it on Amazon when it is published? Willing to give me valuable feedback? [Fill out this form.](https://docs.google.com/forms/d/1zCIU-IAJ5ki-k5ptiycgA3-vnnJQQfeGo3szOYdeSYY/viewform) [Open the form (Google Forms)](https://docs.google.com/forms/d/1zCIU-IAJ5ki-k5ptiycgA3-vnnJQQfeGo3szOYdeSYY/viewform) --- title: "Audio: Preface–Notes to a Software Team Leader" url: "https://www.5whys.com/articles/audio-prefacenotes-to-a-software-team-leader.md" canonical: "https://www.5whys.com/articles/audio-prefacenotes-to-a-software-team-leader.html" published: "2013-06-18T13:12:29.493000+00:00" updated: "2014-05-22T22:07:06.263000+00:00" tags: [] author: "Roy Osherove" description: "Here is a little experiment. Below is the audio version of the Preface of my upcoming book “ Notes to a Software Team Leader ”. Listen on SoundCloud I am thinking of turning this into a saleable audio book. How much should I charge for the…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Audio: Preface–Notes to a Software Team Leader Here is a little experiment. Below is the audio version of the Preface of my upcoming book “[Notes to a Software Team Leader](http://teamleadskills.com/)”. [Listen on SoundCloud](https://w.soundcloud.com/player/?url=https%3A%2F%2Fapi.soundcloud.com%2Ftracks%2F97299501) I am thinking of turning this into a saleable audio book. How much should I charge for the entire book, with each chapter being an mp3 (book is about 110 pages) and where should I sell it? (I do not live in the US, so cannot use Stripe) --- title: "Developing Critical Team Thinking" url: "https://www.5whys.com/articles/developing-critical-team-thinking.md" canonical: "https://www.5whys.com/articles/developing-critical-team-thinking.html" published: "2013-02-25T01:08:47.005000+00:00" updated: "2013-02-25T01:08:47.005000+00:00" tags: ["Critical Thinking", "Meta"] author: "Roy Osherove" description: "Borrowing a few terms from critical thinking, this is another map, or model, of how I feel I need to guide my teams. When do I feel like I have successful gotten my team where they could have been all along? Here is a great quote from this…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Developing Critical Team Thinking Borrowing a few terms from critical thinking, this is another map, or model, of how I feel I need to guide my teams. When do I feel like I have successful gotten my team where they could have been all along? Here is a great quote [from this PDF file](http://www.aft.org/pdfs/americaneducator/summer2007/Crit_Thinking.pdf) on critical thinking: > From the cognitive scientist’s point of view, the mental activities that are typically called critical thinking are actually a subset of three types of thinking: reasoning, making judgments and decisions, and problem solving. > > I say that critical thinking is a subset of these because we think in these ways all the time, but only sometimes in a critical way. Deciding to read this article, for example, is not critical thinking. But carefully weighing the evidence it presents in order to decide whether or not to believe what it says is. > > Critical reasoning, decision making, and problem solving—which, for brevity’s sake, I will refer to as critical thinking—have three key features: effectiveness, novelty, and self-direction. > > Critical thinking is **effective** in that it avoids common pitfalls, such as seeing only one side of an issue, discounting new evidence that disconfirms your ideas, reasoning from passion rather than logic, failing to support statements with evidence, and so on. > > Critical thinking is **novel** in that you don’t simply remember a solution or a situation that is similar enough to guide you. For example, solving a complex but familiar physics problem by applying a multi-step algorithm isn’t critical thinking because you are really drawing on memory to solve the problem. But devising a new algorithm is critical thinking. > > Critical thinking is **self-directed** in that the thinker must be calling the shots: We wouldn’t give a student much credit for critical thinking if the teacher were prompting each step he took. > > —D.W. the last part hit home on many levels about what it means to coach someone to learn a new skill.: > Critical thinking is **self-directed** in that the thinker must be calling the shots: We wouldn’t give a student much credit for critical thinking if the teacher were prompting each step he took. Learning a new skill  means that they do not need **you** there to continue doing something. that you are no longer a bottleneck. **A self organized team is a self-directed team**, as far as critical thinking is concerned. But we want our team to not only be self directed, but also **effective**, by avoiding common pitfalls as as discounting new ideas, seeing only one side of an issue, etc. Learning to be effective is to acquire a set of new skills, of each of these pitfalls, if they occur for members of the team. A critical thinking team uses **novel _ideas,_** not always blindly applying templates to different problems, but always experimenting, and finding new, better ways, of doing new, or even the same things. there is always something new to be learned. As I usually say, if everyone is too comfortable, you’re not learning anything. so something _new_ has to jump into the equation in the form of a new experiment (‘what if we did no iterations for 3 months?’) --- title: "Elastic Leadership in Devops Survival Mode" url: "https://www.5whys.com/articles/elastic-leadership-in-devops-survival-mode.md" canonical: "https://www.5whys.com/articles/elastic-leadership-in-devops-survival-mode.html" published: "2013-02-24T20:51:27.057000+00:00" updated: "2014-05-22T21:37:31.017000+00:00" tags: ["First Steps during chaos"] author: "Roy Osherove" description: "This blog post from the devops guys , shows that the idea of “survival mode ” or chaos can exist in many different places. and a command and control leadership can help buy valuable time that you can then use for learning. to quote : Step…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Elastic Leadership in Devops Survival Mode This [blog post from the devops guys](http://blog.devopsguys.com/2013/02/17/devops-does-not-equal-developers-managing-production/), shows that the idea of [“survival mode](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)” or chaos can exist in many different places. and a command and control leadership can help buy valuable time that you can then use for learning. to quote : Step 1. Kill the current fires, so sanity and actual thinking resume. > “When I took over the Operations of a high-volume UK website about 8 years ago I spend the first 3 weekend working fighting fires and troubleshooting Production issues. > > My first action after that baptism of fire was to revoke access to production for all developers (over howls of protests). Availability and stability immediately went up. Deafening silence from Development – Invitations to beers from the Business owners. Next step, get some friendly forces to help with the effort, if no one within has any idea what you are driving at: > Next step was to hire a build manager to take over the Build and Deployment automation, and a Release Manager to coordinate with the Business what was going into each release, when etc. End result – 99.98% availability, with more releases, being deployed within business hours without impacting the users, and a lower TCO. The Business was much happier, and so was the Development Manager, as he was losing far fewer developer-hours to fire-fighting Production issues, and hence the overall development velocity improved considerably. Win-Win. Their view of survival mode Command and control: > Was that a DevOps anti-pattern? Did I create more silos? Probably… but in a fire-fight a battlefield commander doesn’t sit everyone down for a sharing circle on how they are going to address the mutual challenge of killing the other guy before he kills you. Sometimes a command & control model is the right one for the challenge you face (like getting some suppressing fire on the target while you radio in for some air support or artillery!). The post goes on to talk about using the freed time for learning and getting better (in not so many words): > That said, once we had developed a measure of stability we did move partway to a more DevOps pattern – we had developers on-call 24×7 as 3rd line support, we virtualised our environment(s) and gave Developers more control over them, and we increased our use of automation. Later on, the post mentions that organization influences ([see ‘structural motivation - six forces](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html)) like different incentives, stopped the continuous learning from breaking up any new silos of knowledge. overall, this is a very interesting read for me, as I can see many parallels in the ops word to the software world and the elastic leadership principles. --- title: "Feeling Stupid is Highly Recommended" url: "https://www.5whys.com/articles/feeling-stupid-is-highly-recommended.md" canonical: "https://www.5whys.com/articles/feeling-stupid-is-highly-recommended.html" published: "2013-02-10T17:00:37.343000+00:00" updated: "2013-02-10T17:09:10.857000+00:00" tags: ["Growing People"] author: "Roy Osherove" description: "So, to show you that the whole idea of taking risks and feeling stupid or frustrated is actually a good thing, because it's the only way to really learn a new skill, here are videos from my second day ever doing any kind of skiing. This is…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Feeling Stupid is Highly Recommended So, to show you that the whole idea of taking risks and feeling stupid or frustrated is actually a good thing, because it's the only way to really learn a new skill, here are videos from my second day ever doing any kind of skiing. This is from a few hours ago: [![](https://www.5whys.com/img/video/youtube-W_alfZdN9dg.jpg)Watch on YouTube](https://www.youtube.com/watch?v=W_alfZdN9dg) Feeling Stupid is Highly Recommended 1 [![](https://www.5whys.com/img/video/youtube-Csm2pdGNoGM.jpg)Watch on YouTube](https://www.youtube.com/watch?v=Csm2pdGNoGM) Feeling Stupid is Highly Recommended 2 this is from the first day [![](https://www.5whys.com/img/video/youtube--TVFXzqxwc0.jpg)Watch on YouTube](https://www.youtube.com/watch?v=-TVFXzqxwc0) Feeling Stupid is Highly Recommended 3 (the first day) My muscles are still calling for help, but on the second day, things are much much better. I am happy I didn't give up trying, and I watched a lot of online videos on how to successfully get up after falling from skies. The first day was HELL. Second day - Not Hell, but a country side road with a view to hell very close by. --- title: "Two Day Leadership Workshop–London April 11-12" url: "https://www.5whys.com/articles/two-day-leadership-workshopndashlondon-april-11-12.md" canonical: "https://www.5whys.com/articles/two-day-leadership-workshopndashlondon-april-11-12.html" published: "2013-02-03T19:24:21.817000+00:00" updated: "2013-02-03T19:24:56.063000+00:00" tags: ["Courses"] author: "Roy Osherove" description: "I would love to see you at my upcoming two day workshop in London . Place is limited to 20 participants. The workshop is for architects, team leaders, and managers of software people. The point? Learn how to make the things you believe in…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Two Day Leadership Workshop–London April 11-12 I would love to see you [at my upcoming two day workshop in London](http://leadbetterlondon2013.eventbrite.com/). Place is limited to 20 participants. The workshop is for architects, team leaders, and managers of software people. The point? Learn how to make the things you believe in come true in your team. Understand why and how to influence works, and learn to harness it. Most importantly, we discuss the role of a leader as a grower of the team, instead of just the guidance of it. The following video gives the big idea: [![](https://www.5whys.com/img/video/youtube-uvwW_CRmWmo.jpg)Watch on YouTube](https://www.youtube.com/watch?v=uvwW_CRmWmo) The Coaching Leader & Architect - Roy Osherove --- title: "12 Lessons Learned for a New Team Lead" url: "https://www.5whys.com/articles/12-lessons-learned-for-a-new-team-lead.md" canonical: "https://www.5whys.com/articles/12-lessons-learned-for-a-new-team-lead.html" published: "2013-02-02T22:00:46.387000+00:00" updated: "2013-02-03T07:25:23.267000+00:00" tags: ["Guest Post"] author: "Roy Osherove" description: "This guest post is by Oren Ellenbogen . I’ve personally known Oren for a few years, and he is one of those people that you just know you will be seeing on the cover of some tech newspaper sometime in a a few years. Oren is a Senior…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 12 Lessons Learned for a New Team Lead This guest post is by [Oren Ellenbogen](http://lnbogen.com/). I’ve personally known Oren for a few years, and he is one of those people that you just know you will be seeing on the cover of some tech newspaper sometime in a a few years. Oren is a Senior Developer at Commerce Sciences and Editor of [SoftwareLeadWeekly](http://softwareleadweekly.com/). Prior to Commerce Sciences, Oren served as Director of Engineering at Delver, where he was responsible for the development process, delivering kick-ass products and growing the next generation of team leads in his group. Oren likes talking with awesome, passionate people and hates people who call themselves "ninjas", unless they carry a sword. \-------------------- [![image](https://www.5whys.com/img/posts/175e806d-Windows-Live-Writer-eed324298410_13708.jpg)](https://www.5whys.com/files/Windows-Live-Writer-eed324298410_13708) During the years 2007-2011 I had the honor leading an incredible group of engineers, working at Delver. It started from leading a team of 3 engineers and grew to a group of 13, made of three smaller teams. It was an amazing learning experience, probably the best one in my career. This post is my self-retrospection, trying to extract my lessons learned and put it on paper. Hopefully, sharing my experience could help you in your own journey as a team lead. ### Write things down Being promoted to a new role, having people under your responsibility, is a huge change. Suddenly, it is no longer about you but rather about your teammates. Many first-time leaders struggle to leave the "superstar" spot they're so comfortable with and make the required switch, helping their team jell together and fulfill their potential. It's a long journey. it takes time crafting your people skills, figuring out how to prioritize between your company's needs and your teammates' needs, finding your own ways to keep your technical skills and deliveries. My advice to you is write things down - end your day with writing 1-2 decisions you've made during that day that involved your new skills. Review these decisions once a week with yourself and in your 1:1 with your boss. Call it "code review for managers". use it as a [framework to improve your management skills](http://lnbogen.com/2012/12/16/a-proven-framework-to-improve-your-management-skills/). ### Show that you care - it's the little stuff that matters most Little surprises can lead to a long lasting impact on your team, bigger than any salary increase or fat bonus. Make it your job to know your people better, understand what drives them and show them that you've noticed. To fuel your creativity, think of framing a [Let's Say You've Gone Back in Time](http://hackyourlifeblog.blogspot.co.il/2010/08/lets-say-youve-gone-back-in-time.html) poster for a new employee, just because you saw he likes this kind of humor on Facebook or his blog. Imagine his first day at work, arriving to his workstation, looking above at the poster you've put there. Do you feel it? At [Commerce Sciences](http://commercesciences.com/), where I currently work, we've got a little tradition welcoming new employees to our startup - the last person to join the company is responsible to create a "starter kit" for the next one to join. It's our little [culture hack](http://www.quora.com/Startups/What-are-the-coolest-startup-culture-hacks-youve-heard-of/answer/Oren-Ellenbogen?srid=nZO&st=ns). It's the little things that make us proud to be part of something. Show your teammates that you care. ### Be extra careful with cynicism Cynicism is a dangerous killer in disguise for your team's culture. Don't get me wrong, sarcasm and cynicism are pretty much my entire jokes vocabulary, but I urge you to pay attention as it can quickly slide from having a good time to insulting someone else or demoralizing the entire team. Many first time team leads avoid dealing with cynicism because they are afraid of looking "uncool" or too uptight. I call Bullshit on that. Your teammates will appreciate you more for being a leader with strong opinion and real passion to create better culture. That's your responsibility, earn it! ### Educate yourself about the things they like This is a trick I learned along the way to better understand my teammates. Some of them loved JavaScript performance optimization, so I bought [High Performance Javascript](http://www.amazon.com/Performance-JavaScript-Faster-Application-Interfaces/dp/059680279X) and read it on the weekends. Others enjoyed exploring service-oriented-architecture (SOA) so I found some awesome blogs (check [Udi Dahan's blog](http://www.udidahan.com/?blog=true)) to get my weekly dose of that. Some were more about UI and UX, so I got a few more books ([Don't Make Me Think is awesome](http://www.amazon.com/gp/product/0321344758/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0321344758&linkCode=as2&tag=iserializable-20)). You get the pattern. I am far from being an expert on these topics, but I can conduct an intelligent conversation, provide feedback, and help with prioritization. I used what I've learned to drive my teammates to take ownership of these topics they were so passionate about. Getting to know what drives them, being able to talk in their own language, helped me set clear expectations about deliveries and responsibilities. They knew I would go the extra mile for them. ### Use productivity questions to drive code-reviews I've always preferred using productivity questions to judge quality of code, simply because I've learned that we tend to put too much time and effort in the wrong places, building things no one would use to begin with. So, best-case scenario for every engineering team is to create code that will allow them to test as many directions as possible in the shortest given time. My mental model when looking at code: 1.    How easy will it be add new features? 2.    How easy will it be to change existing features? 3.    How easy will it be for a new teammate to become productive? Some examples: - Using the right amount of tests will help with every bullet above. Adding too much tests or the wrong kind of tests will damage both the first and second bullets. For example, too many integration tests instead of unit tests may make your tests break too often, if the flow tends to change a lot by adding more features. - Using complex architecture might help with (1) and sometimes (2) but will probably hurt (3), so there is an interesting balance to be thought of. Using the questions above, makes the entire discussion around the productivity of the team and company instead of whether or not one should have 90% test-coverage or what is the right amount of code lines per class. ### Develop your proactive voice There are two kinds of people – those who will tell where they are standing only when someone else will ask for it ("pull") and those that will come to you when needed ("push"). It could be related to a progress made in some feature, maybe there is something or someone that holds them back or simply to share an interesting observation. I believe that being a great leader requires us to become proactive, to communicate before people ask for it. Being communicative will reduce the need of your boss, peers and teammates to double-check everything with you. They will get accustomed to the ritual of “when shit happens, she’ll raise a flag”. This is how proactive leadership should be – being aware, communicative and setting the tone. Oh, and there is my [secret trick for Proactive Leadership](http://lnbogen.com/2012/12/09/my-secret-trick-for-proactive-leadership/) you should also check out. ### Send your teammates to events and encourage them to share [Joel Gascoigne](http://joel.is/) has a great post called [Your startup is a rocket ship](http://joel.is/post/26269175818/your-startup-is-a-rocket-ship), where he explains how to leverage your company to increase your employees reputation. This is exactly what great companies should strive to do in order to keep their talent level so high. It's a classic win-win situation: your company gets to engage with highly talented candidates while your employees get to earn their reputation and impact their eco-system. Open [meetup.com](http://meetup.com/), check for interesting groups around your area that your teammates can learn from and contribute to, and encourage them to go. If they want to speak, help them to prepare, offer your help with building the presentation, ask them if they would be interested in presenting to the team before. Having your people out there will increase the chance of getting awesome candidates and will increase your teammates options in the market. Even if it sounds like a dangerous path ("I am scared of losing my best people!"), it will let your people know that you've got their back, that you put them first. If you want their true loyalty, you have to earn it from a place of trust and genuine care. ### Do not try to fix everyone Sometimes, you'll be tempted to change a behavior of someone in your team. > "He's young and a bit arrogant, but so incredibly smart! No one seems to enjoy working with him but I know that I can fix it". Sounds familiar? Every time you commit to help someone else grow, ask them to commit to be willing to make the effort first. If someone has a bad attitude and no willingness to improve, it doesn't matter how brilliant or productive this individual is. In order to build a team, everyone has to be willing to find their own spot and enjoy being part of the team. Do not invest yourself and your team in people that don't give a damn. It might cost you with letting go of some great people, but will also set the tone for the rest of the team. Don't worry, you're building a team for the long-run and it will pay off. ### Celebrate just as hard as you work Focusing all your energy on getting stuff done just produces more stuff that needs to get done, and that’s a trap. Your teammates can easily keep their heads down and continue to work their ass off, but without explicitly sharing progress and celebrating it, you're adding a risk of losing your purpose. Instead of enjoying those victories, every time you'll do something huge, you will treat it as a small step forward – "yea, we finally got to 10 customers, but we need to be at 10,000 so there is no time now to celebrate". Take a minute, celebrate your achievement and take this opportunity to say how much you are proud of your team for the effort they did. ### Avoid the local maxima Don't try to compare yourself or limit yourself to the surroundings you're familiar with. If you don't know of anyone that is doing Test Driven Development, using Continuous Deployment or practicing Kanban, it doesn't mean that you shouldn't try it. Some people will always call you naïve or optimistic for thinking you can do more than seems possible, but there is no way to get radically better other than pushing yourself out of your comfort zone. Read about companies and individuals that drive you crazy with passion and admiration. Set your path reaching to your true potential, not the closest maxima, using your current skill set. If you seek to improve your teammates and lead them, it must begin with you first. ### You're talking too much As a previous superstar, you might feel the urge to keep everyone informed about your own capabilities, to prove exactly how smart you are. This is not a good idea. As a new team lead, your job is to make \*others\* shine. People will not feel comfortable coming out of their shells, unless you will allow them to speak up, to own things, to become the voice of the team. Push them from behind and get out of the way. ### Be awesome Enough said. \--------------------- > If you found this post helpful, I'd be humbled if you'd follow me on twitter ([@orenellenbogen](https://twitter.com/orenellenbogen)), subscribe to [my weekly newsletter](http://softwareleadweekly.com/) with great articles about leadership and management and [check out my blog](http://lnbogen.com/). > \------------------------------------------------------------------------------------- > photo credit: [Angelo González](http://www.flickr.com/photos/ag2r/5180330074/) --- title: "Video: The Coaching Architect" url: "https://www.5whys.com/articles/video-the-coaching-architect.md" canonical: "https://www.5whys.com/articles/video-the-coaching-architect.html" published: "2013-02-01T20:08:00.327000+00:00" updated: "2013-02-06T20:47:54.983000+00:00" tags: ["Video"] author: "Roy Osherove" description: "A few days ago I gave a talk at the Architect Meetup here in Oslo. It was about the role of the architect, and how to become a coaching architect. I hope you enjoy this video. Watch on YouTube The Coaching Leader & Architect - Roy Osherove…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: The Coaching Architect A few days ago I gave a talk at the Architect Meetup here in Oslo. It was about the role of the architect, and how to become a coaching architect. [I hope you enjoy this video.](http://blogg.bouvet.no/2013/02/01/video-the-coaching-architect-with-roy-osherove/) [![](https://www.5whys.com/img/video/youtube-uvwW_CRmWmo.jpg)Watch on YouTube](https://www.youtube.com/watch?v=uvwW_CRmWmo) The Coaching Leader & Architect - Roy Osherove If you want to join me for a two day workshop on elastic leadership, I am running a two day elastic workshop here in Oslo, on February 28-29 2013. For details just contact me. Or you can attend this workshop [in London during April](https://www.5whys.com/articles/two-day-leadership-workshopndashlondon-april-11-12.html). --- title: "Elastic, Agile, Adaptive Leadership Workshop, January 31 2013, Oslo" url: "https://www.5whys.com/articles/elastic-agile-adaptive-leadership-workshop-january-31-2013-o.md" canonical: "https://www.5whys.com/articles/elastic-agile-adaptive-leadership-workshop-january-31-2013-o.html" published: "2013-01-16T21:19:35.006000+00:00" updated: "2013-01-16T21:22:01.016000+00:00" tags: ["Courses"] author: "Roy Osherove" description: "This January, the 31st, I will be giving a two day Workshop for team leaders, architects, and scrum masters, titled Elastic, Agile, Adaptive Leadership. If you’re interested in joining, please contact me directly (or email roy at…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Elastic, Agile, Adaptive Leadership Workshop, January 31 2013, Oslo This January, the 31st, I will be giving a two day Workshop for team leaders, architects, and scrum masters, titled Elastic, Agile, Adaptive Leadership. > If you’re interested in joining, please contact me directly (or email roy at osherove.com) so I can save you a seat. We need only two more people to finalize course registration. I’ll be happy to see one of my blog readers there! In this 2 day workshop, 30% of the time is dedicated to exercises. we will cover: - The three basic stages of team abilities (Survival, Learning, Self Organization), - Elastic leadership concepts - The leader manifesto and reasoning - Influence forces and understanding why people do what they do - How to grow your team to be self organizing - Why most team's are not really ready to become agile yet (and what to do about it) - How to deal with difficult behavior in the team. - How to lead self organizing teams - Comparing elastic leadership with the cynefin framework and other frameworks. **Audience:** Architects, Technical and non technical team leaders, scrum masters, soon-to-be leaders, project managers, senior developers, consultants. No experience in management needed, but at least one year experience working/leading in a software team. This is based on my book “[Notes to a Software Team Leader](http://leanpub.com/teamleader)” This will be held at Bouvet Oslo HQ, with the cost of 11,900 NOK per person (includes food). Again, f you’re interested in joining, please contact me directly (or email roy at osherove.com) so I can save you a seat. --- title: "Things to consider when building a new team" url: "https://www.5whys.com/articles/things-to-consider-when-building-a-new-team.md" canonical: "https://www.5whys.com/articles/things-to-consider-when-building-a-new-team.html" published: "2012-12-26T11:31:59.237000+00:00" updated: "2012-12-26T11:31:59.237000+00:00" tags: ["Meta"] author: "Roy Osherove" description: "Look for inherent knowledge creating experts(leaders) A potential leader is someone who is a bottleneck. an expert. They can become a leader by coaching and sharing on that knowledge. Architects are a good example. If you get to choose the…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Things to consider when building a new team ### Look for inherent knowledge creating experts(leaders) A potential leader is someone who is a bottleneck. an expert. They can become a leader by coaching and sharing on that knowledge. Architects are a good example. If you get to choose the people who will be in your team, I would look for people who are leaders in specific fields, but that are willing to teach and share their knowledge. These are the people that will make sure they are not the only expert on technology X in your team. ### Look for people who like to speak publicly They make great teachers, and are great at sharing knowledge. ### Look for people who work well together If people already have fun working together, everyone benefits. ### Look for people willing to sit with everyone else If you can get the whole tea in the same room easily, communication wins. ### Look for people that COULD make you feel stupid if they wanted to, but make you feel great to be around them instead. There aren’t many of those, but people skills are the wheels that drive a good team. Knowledge is the oil. ### Look for people with time If they start out not having time to learn (survival mode), you are already starting a race with the odds against the team. I would rather have a person with potential that is not doing any other projects currently, than a person with the realized potential, that is doing two other projects at the same time. ### So? The idea is not to create the perfect team, but to create the perfect soup mix. Get ingredients that grow and assemble as they come close to each other, that with the right mix of love and care, can grow to be bigger than the parts. If you build a team, build a team that has the best potential to grow leaders within in the future, because you won’t find the perfect team today. --- title: "Video (Hebrew): On Time, With Quality? Yeah Right." url: "https://www.5whys.com/articles/video-hebrew-on-time-with-quality-yeah-right.md" canonical: "https://www.5whys.com/articles/video-hebrew-on-time-with-quality-yeah-right.html" published: "2012-09-18T11:14:27.477000+00:00" updated: "2012-09-18T11:17:16.059000+00:00" tags: ["Video", "hebrew"] author: "Roy Osherove" description: "A few months ago I gave a talk at at secret military base in Israel. It was for some of the future tech leaders growing in the womb of Israel's technical military units. It talks about leadership, and how to make it more effective, and…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video (Hebrew): On Time, With Quality? Yeah Right. A few months ago I gave a talk at at secret military base in Israel. It was for some of the future tech leaders growing in the womb of Israel's technical military units. It talks about leadership, and how to make it more effective, and accomplishing difficult things. enjoy. [![](https://www.5whys.com/img/video/youtube-23ke8YriwUA.jpg)Watch on YouTube](https://www.youtube.com/watch?v=23ke8YriwUA) Roy Osherove - Hebrew - On Time with Quality... Yeah Right --- title: "Video: Lejla Giske on Listening Modes and Techniques" url: "https://www.5whys.com/articles/video-lejla-giske-on-listening-modes-and-techniques.md" canonical: "https://www.5whys.com/articles/video-lejla-giske-on-listening-modes-and-techniques.html" published: "2012-09-14T14:02:38.033000+00:00" updated: "2012-09-14T14:26:19.023000+00:00" tags: ["Growing People", "Self Improvement", "people patterns", "bouvet"] author: "Roy Osherove" description: "while at bouvet here in Norway, I'm getting to meet lots of interesting new people. It's a shame for those conversations to go to waste, so if they are interesting, I record what they have to say (not my job descriotion, I'm just having…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: Lejla Giske on Listening Modes and Techniques while at bouvet here in Norway, I'm getting to meet lots of interesting new people. It's a shame for those conversations to go to waste, so if they are interesting, I record what they have to say (not my job descriotion, I'm just having fun doing this on the side). Today I met with Lejla Giske, a consultant here, who coaches people about people skills. As a student of these topics I found her ideas about listening modes very interesting. if you want to contact her to ask questions, just email her directly (no blog yet...mayebe sometime soon?) [![](https://www.5whys.com/img/video/youtube-O5schEU7138.jpg)Watch on YouTube](https://www.youtube.com/watch?v=O5schEU7138) Lejla Giske on Listening Modes and Techniques --- title: "Consulting and Leadership Courses in Scandinavia" url: "https://www.5whys.com/articles/consulting-and-leadership-courses-in-scandinavia.md" canonical: "https://www.5whys.com/articles/consulting-and-leadership-courses-in-scandinavia.html" published: "2012-09-05T08:10:15.027000+00:00" updated: "2014-05-22T22:31:52.063000+00:00" tags: [] author: "Roy Osherove" description: "My move to Norway is now almost complete (should be getting my id number mid September.) Bærum Kummune, I am in you. Yeah. And I have the Norwegian keyboard to prøve it. Now that I’m here I plan to do a lot more in Scandinavia. Here’s just…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Consulting and Leadership Courses in Scandinavia My move to Norway is now almost complete (should be getting my id number mid September.) ### Bærum Kummune, I am in you. Yeah. And I have the Norwegian keyboard to prøve it. Now that I’m here I plan to do a lot more in Scandinavia. Here’s just the tip of the iceberg.  > I’m now fully available to do consulting and training in Norway, through [Bouvet](http://bouvet.no/). If you want me to come **t****each something about unit testing or team leadership**, or **do test reviews**, or help you **automate everything**, or just **coach** your development **team or team leader or architect** on better ways to accomplish things, feel free to just email the person who helped make it all happen for me - Simen. He’s also working with me at Bouvet and is in charge of making sure my time is well spent. Make him work. Hard. BTW - if you’re in DENMARK and want to help me arrange more courses there about various topics, [please ping me.](http://osherove.com/request-more-info/) I need to do more of these! ### Out of Norway training or Coaching? if you want me to come and teach or consult out of Norway, [just contact me directly](http://osherove.com/request-more-info/) (that is not through Bouvet) ### Denmark : - October 22 - [3 Day TDD Master Class](http://www.ative.dk/agile-teknikker/test-driven-development-master-class-in-c.aspx) - November 12 - [1 Day Team Leadership Skills With Elastic Leadership Concepts](http://www.ative.dk/scrum/elastic-leadership.aspx) ### Norway: - 29 October - [Trondheim Developer Conferences](http://www.trondheimdc.no/foredrag/) - [Team Leader Skills and Elastic Leadership](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Teamledelse-og-smidig/) (2 days) - [Team Leader Skills and Elastic Leadership](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Teamledelse-og-smidig/) (1 day) - New: [Succeeding with Agile Adoption](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Teamledelse-og-smidig/) (1 days) - [Test Driven Development 3 days](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Kurs-om-testdrevet-utvikling-TDD/) (zero knowledge needed) - [Test Driven Development 5 days master class](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Kurs-om-testdrevet-utvikling-TDD/) (zero knowledge needed) - New: [Advanced Test Driven Development Subjects](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Kurs-om-testdrevet-utvikling-TDD/)  New: - [From test, to build automation, to deployment - tools and techniques for .NET](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Andre-NET-kurs/)     - [Windows, Visual Studio.NET and Resharper Ninja Moves and productivity techniques](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Andre-NET-kurs/)   - [Introduction To Agile and Lean development ideas (zero knowledge needed)](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Andre-NET-kurs/) - [Introduction to Ruby and rails for .NET and Java developers (zero knowledge needed)](http://tema.bouvet.no/no/Teknologi/Kurs-med-Roy-Osherove/Andre-NET-kurs/) ### Sweden: - [Stockholm, October 19, 2012 - Advanced TDD Subjects in .NET](http://foocafe.org/#event-stockholm-master-class-software-team-leader-essential-skills-and-elastic-leadership-concepts-roy-osherove)  - [Malmo, October 15, 2012 - Advanced TDD Subjects in .NET](http://foocafe.org/#event-master-class-advanced-tdd-subjects-for-net-developers-roy-osherove)  - [Stockholm, November 2. 2012 - Essential Skills and elastic leadership for software team leaders](http://foocafe.org/#event-stockholm-master-class-software-team-leader-essential-skills-and-elastic-leadership-concepts-roy-osherove) - [Malmo, November 5, 2012 - Essential Skills and Elastic Leadership for software team leaders](http://foocafe.org/#event-master-class-software-team-leader-essential-skills-and-elastic-leadership-concepts-roy-osherove) --- title: "Elastic Leadership Team Survival Vs. Team Chaos Vs. Cynefin" url: "https://www.5whys.com/articles/elastic-leadership-team-survival-vs-team-chaos-vs-cynefin.md" canonical: "https://www.5whys.com/articles/elastic-leadership-team-survival-vs-team-chaos-vs-cynefin.html" published: "2012-07-30T14:16:05.833000+00:00" updated: "2012-08-09T17:26:01.047000+00:00" tags: ["Meta"] author: "Roy Osherove" description: "I've decided that the word ' chaos ' isn't a good match to describe the phase where a team has no time to learn. Instead, the word 'survival' is going to be used from now on. There are several reasons for this: 1) The word 'chaos' is…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Elastic Leadership Team Survival Vs. Team Chaos Vs. Cynefin I've decided that the word '**chaos**' isn't a good match to describe the phase where a team has no time to learn. Instead, the word 'survival' is going to be used from now on. There are several reasons for this: 1) The word 'chaos' is already used in the context of another decision framework called '[Cynefin](http://en.wikipedia.org/wiki/Cynefin)'.   Cynefin is a powerful framework that uses scientific arguments to describe various states teams and systems are in. 'chaos', in the context of Cynefin, is a state where given an action in the system, the results will be totally random.  In that sense, 'chaos' in the elastic leadership framework as I present in this blog, means something else. 'chaos' (or 'survival' from now on), is a state where decisive action is needed, and a specific set of results is expected.  My notion of elastic leadership does not deal with a state where there is no telling what action needs to be taken. It divides the world of states into 'survival' (no time to learn), 'learning', and 'self organizing'.  In terms of Cynefin, I only deal with complex and complicated systems. Though I'm not sure where 'software team' as a system lies between these two notions. 2) The word 'Chaos' was initially chosen out of necessity. I had no better word to describe this phase. After  discussing the Cynefin framework ideas with Dave Snowden via email, the word 'survival' came to me, and I think it much better described the phase I believe most software teams are, unfortunately, in. There for, a team can have three phases: - **Survival phase** (where most teams I see are in) -- in which team has no time to learn -- requires a more command and control type of leadership to create that learning time from nothing. - **Learning phase**  -- where a team has time to learn and is using it -- requires coach like leader, with bursts of control when things will take too long to learn the hard way (choosing no source control, for example) - **Self Organization Phase** -- Where teams can solve their own problems -- requires more of a facilitator type of leader, that does not tell people what to do, but simply provides constraints and end goals. The team will get there on its own. A team can move between all three phases in a matter of days, really.  The leader should detect this phase change, and change their leadership type accordingly. --- title: "Assume you are wrong" url: "https://www.5whys.com/articles/assume-you-are-wrong.md" canonical: "https://www.5whys.com/articles/assume-you-are-wrong.html" published: "2012-06-21T12:12:09.553000+00:00" updated: "2012-06-21T12:37:00.307000+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "Here's a chat conversation that actually happened. See if you can find all the places where each person is telling themselves a story about the other person, and then assuming its true, and notice how volatile the conversation can get in…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Assume you are wrong Here's a chat conversation that actually happened. See if you can find all the places where each person is telling themselves a story about the other person, and then assuming its true, and notice how volatile the conversation can get in such situations: > **A: is it some kind of disrespect @B? nice...** B: what? **A: nothing, I've just asked u a question that u just ignored, so i asked if it some kind of disrespect. i guess so** B: and the answer is in the hipchat which you supposed to have open. you are welcome to open it now and read the answer **A: it is opened, and was opened all that time** B: well, you are not in the room B: the name of the room is \[something\] you know.. like the company ;) You can never assume what the other person's reason for behaving in a specific way is. But we like to tell ourselves stories about why they did or didn't do something, so that we don't have to engage in "real" conversations.  Always try to assume that the other side means well and has good intentions, and is trying their best, and they have good reasons. Under that assumption, you could see that you'd be right most of the time. People don't intentionally try to "hurt the project" . You'd be usually wrong to thing someone "doesn't care" or "isn't smart enough to get it" or that "they did it wrong".  Many times the fault is miscommunication, and if we understand that, we can disarm many conversations that naturally we tend to make worse, when they can be quite pleasant as figuring out a misunderstanding on our part. How to fix this: Instead of "is it some kind of disrespect?" you can say "I can't see any answer from you". Simply describe your reality from your side.  Instead of "The answer is in the hipchat you're supposed to have open" you could say "I did answer. it's in the hipchat room. Does anybody else see my answer? start with "bla..." " you can see that this can disarm the chat quite easily, because nobody is being blamed for being an idiot here. There are only facts, and tries to figure out why they are different on both sides. > It is much like debugging a situation: "I can see X on my side. But you can't. Let's see what we missed" --- title: "Upcoming leadership 1 day courses in sweden" url: "https://www.5whys.com/articles/upcoming-leadership-1-day-courses-in-sweden.md" canonical: "https://www.5whys.com/articles/upcoming-leadership-1-day-courses-in-sweden.html" published: "2012-06-20T12:33:59.627000+00:00" updated: "2014-05-22T22:21:16.677000+00:00" tags: ["Courses"] author: "Roy Osherove" description: "I will be joining foo-cafe in sweden to do some one-day courses with them. If all goes well, this will be a continuous schedule every month : Stockholm, November 2. 2012 - Essential Skills and elastic leadership for software team leaders…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Upcoming leadership 1 day courses in sweden I will be joining foo-cafe in sweden to do some one-day courses with them. If all goes well, this will be a continuous schedule every month : - [Stockholm, November 2. 2012 - Essential Skills and elastic leadership for software team leaders](http://foocafe.org/#event-stockholm-master-class-software-team-leader-essential-skills-and-elastic-leadership-concepts-roy-osherove) - [Malmo, November 5, 2012 - Essential Skills and Elastic Leadership for software team leaders](http://foocafe.org/#event-master-class-software-team-leader-essential-skills-and-elastic-leadership-concepts-roy-osherove) These courses are based on the currently-in-progress book: [From chaos to self organization](http://leanpub.com/elastic) [![](https://www.5whys.com/img/posts/0cec6adc-title_page.jpg)](http://leanpub.com/elastic) --- title: "Submit your story about a team leader you had - good or bad" url: "https://www.5whys.com/articles/submit-your-story-about-a-team-leader-you-had-good-or-bad.md" canonical: "https://www.5whys.com/articles/submit-your-story-about-a-team-leader-you-had-good-or-bad.html" published: "2012-06-19T22:51:15.157000+00:00" updated: "2012-06-19T22:53:57.041000+00:00" tags: ["Book"] author: "Roy Osherove" description: "Have something really important to say to software team leaders out there? Why not publish it in my upcmoing book? It could be anything, as long as there is a PERSONAL story in it. Outline why you liked/disliked that team leader's…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Submit your story about a team leader you had - good or bad Have something really important to say to software team leaders out there? Why not publish it in my upcmoing book?  It could be anything, as long as there is a PERSONAL story in it. Outline why you liked/disliked that team leader's behavior. Explain how things could have been better, or worse. If it's about you, and a lesson you've learned about being a team leader - tell it, so others can learn from your experience! --- title: "New chapter: \"Learning\" in the book \"From chaos to self organization\"" url: "https://www.5whys.com/articles/new-chapter-learning-in-the-book-from-chaos-to-self-organiza.md" canonical: "https://www.5whys.com/articles/new-chapter-learning-in-the-book-from-chaos-to-self-organiza.html" published: "2012-06-19T22:30:58.023000+00:00" updated: "2012-06-19T22:37:45.817000+00:00" tags: ["Book"] author: "Roy Osherove" description: "I just added a new chapter to \"From Chaos to Self Organization \" . You don't know that book? You would have known it by it's previous name \"Elastic Leadership\" , and before that it was part of \" Notes to a software team leader \". Now I've…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # New chapter: "Learning" in the book "From chaos to self organization" I just added a new chapter to ["From Chaos to Self Organization](http://leanpub.com/elastic)" . You don't know that book? You would have known it by it's previous name "Elastic Leadership" , and before that it was part of "[Notes to a software team leader](http://leanpub.com/teamleader)".  Now I've split them into two different books, because I wanted each one to be "purely" about either notes from other team leaders, or about my specific framework for growing effective teams. NOTE: if you are an existing owner of "notes to a software team leader" you should have gotten a FREE code by email a few weeks ago for the split book which was then called "elastic leadership". this code should still work with the book even though its name has changed. Here's the link to a bundle for both books together: [See the book bundle on Leanpub](https://leanpub.com/b/leaders) --- title: "Leadership and management talk videos from NDC Oslo" url: "https://www.5whys.com/articles/leadership-and-management-talk-videos-from-ndc-oslo.md" canonical: "https://www.5whys.com/articles/leadership-and-management-talk-videos-from-ndc-oslo.html" published: "2012-06-15T20:13:13.287000+00:00" updated: "2012-06-15T20:20:35.777000+00:00" tags: ["Video"] author: "Roy Osherove" description: "There weren't many of those, but here are some talks from NDC Oslo 2012 that you might find interesting: The Software Team Leader Manifesto (me) Panel - The State of Agile and the road ahead What does Self-Organizing Team Really Mean?…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Leadership and management talk videos from NDC Oslo There weren't many of those, but here are some talks from [NDC Oslo 2012](http://ndcoslo.com/) that you might find interesting: - [The Software Team Leader Manifesto](http://ndcoslo.oktaset.com/t-4891) (me) - [Panel - The State of Agile and the road ahead](http://ndcoslo.oktaset.com/t-6010) - [What does Self-Organizing Team Really Mean? (Esther Derby)](http://ndcoslo.oktaset.com/t-4986) - [The Surprising Science behind Agile Leadership (Jonathan Rasmussen)](http://ndcoslo.oktaset.com/t-4941) - [Embracing Uncertainty (Dan North)](http://ndcoslo.oktaset.com/t-4941) --- title: "Video: The Team Leader Manifesto, Growing Effective Teams" url: "https://www.5whys.com/articles/video-the-team-leader-manifesto-growing-effective-teams.md" canonical: "https://www.5whys.com/articles/video-the-team-leader-manifesto-growing-effective-teams.html" published: "2012-06-15T20:10:03.667000+00:00" updated: "2012-06-15T20:12:55.032000+00:00" tags: ["Conference", "Growing People", "Video", "manifesto"] author: "Roy Osherove" description: "Here is my talk from NDCOslo 2012 , two weeks ago. It details my current view and thoughts about the role of the team leader, and the manifesto is a good way to capture that. A video was embedded here. It is no longer publicly available on…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: The Team Leader Manifesto, Growing Effective Teams Here is my talk from [NDCOslo 2012](http://ndcoslo.com/), two weeks ago. It details my current view and thoughts about the role of the team leader, and the manifesto is a good way to capture that. A video was embedded here. It is no longer publicly available on Vimeo. [Roy Osherove - The Software Team Leader Manifesto](http://vimeo.com/43612918) from [NDCOslo](http://vimeo.com/ndcoslo) on [Vimeo](http://vimeo.com/). --- title: "Free for Elastic Leadership Training in June/July" url: "https://www.5whys.com/articles/free-for-elastic-leadership-training-in-junejuly.md" canonical: "https://www.5whys.com/articles/free-for-elastic-leadership-training-in-junejuly.html" published: "2012-06-12T11:49:15.727000+00:00" updated: "2012-06-12T11:50:26.563000+00:00" tags: [] author: "Roy Osherove" description: "With all the work going on with our move to norway this august, I managed to not book anything for end of june, and all through july. If anyone wants me to come over and bring some TDD sense , or leadership techniques to your team leaders…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Free for Elastic Leadership Training in June/July With all the work going on with our move to norway this august, I managed to not book anything for end of june, and all through july. If anyone wants me to come over and bring some [TDD sense](http://osherove.com/tdd-training/), or [leadership techniques](http://leanpub.com/elastic) to your team leaders and teams,[please ping me.](http://osherove.com/request-more-info/) --- title: "Team Leader Manifesto - Take #4" url: "https://www.5whys.com/articles/team-leader-manifesto-take-4.md" canonical: "https://www.5whys.com/articles/team-leader-manifesto-take-4.html" published: "2012-06-06T22:15:30.004000+00:00" updated: "2012-06-06T22:21:46.547000+00:00" tags: ["First Steps during chaos", "Meta"] author: "Roy Osherove" description: "Here's what I have, before speaking at NDC next morning:" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Team Leader Manifesto - Take \#4 Here's what I have, before speaking at NDC next morning: ![](https://www.5whys.com/img/posts/ca6512c4-4655535-18616798-thumbnail.jpg) --- title: "Team Leader Manifesto - Take #3" url: "https://www.5whys.com/articles/team-leader-manifesto-take-3.md" canonical: "https://www.5whys.com/articles/team-leader-manifesto-take-3.html" published: "2012-06-06T01:24:16.313000+00:00" updated: "2012-06-06T01:28:33.947000+00:00" tags: ["First Steps during chaos", "Meta", "manifesto"] author: "Roy Osherove" description: "As team leaders our goal, and the way we measure our work, is the overall growth in skills of self organization and self maintenance of each person of our team, and the team as a whole. To that end: We accept that the team’s needs from us…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Team Leader Manifesto - Take \#3 #### As team leaders our goal, and the way we measure our work, is the overall growth in skills of self organization and self maintenance of each person of our team, and the team as a whole. To that end: We accept that the **team’s needs from us change continuously** based on their skills for handling the current reality of work, so: - We embrace a **continuously changing leadership style**, over a one-style-fits-all leadership approach We believe in **challenging ourselves and our teams** to always get better, so:  - _We **create slack time** for the team to learn and be challenged_  - We embrace **taking risks** for our team over staying safe  - _We embrace **fear and discomfort** as learning new skills over keeping people within their comfort zones_ - We embrace **experimentation as a constant practice** over maintaining the status quo  - **With people**  - _With **tools**_  - **With processes** - With the **environment** We believe our core practice is **leading people**, not wielding machines, so: - We embrace **spending more time** with our team than in meetings  - We embrace treating software problems as **people problems**  - We learn **people skills** and communication techniques --- title: "Should you grow even a short-term consultant in your team?" url: "https://www.5whys.com/articles/should-you-grow-even-a-short-term-consultant-in-your-team.md" canonical: "https://www.5whys.com/articles/should-you-grow-even-a-short-term-consultant-in-your-team.html" published: "2012-05-06T13:17:05+00:00" updated: "2012-05-06T13:18:16.015000+00:00" tags: ["Growing People", "Learning Phase"] author: "Roy Osherove" description: "What if you have a short-term consultant on your team? What if you're the team lead for just this project, and there will be a new team lead in the next project? Should you work on growing people even in those situations? My answer is an…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Should you grow even a short-term consultant in your team? What if you have a short-term consultant on your team? What if you're the team lead for  just this project, and there will be a new team lead in the next project? Should you work on growing people even in those situations? My answer is an unequivocal yes. (unless we're in chaos mode). People who come across my path , even for a short time, will get the same amount of respect, expectations and challenge from me, as if they were there forever. I will try to always leave people who I've led, better off than they were, in terms  of new skills and challenges. It is in my personal integrity to do so. If you conduct yourself this way, you'll find that people will want to work more with you, and will remember you  even years later, no matter how short the project was. You never know when you're going to meet those people again, and  you may find hidden treasures are laying down in your future path, just because  a few years back, you did the "right thing" with people who didn't expect you to. Show a personal example that even in the short term, you do not give up  on quality (of people, of leadership). --- title: "Elastic Leadership course in Amsterdam - July" url: "https://www.5whys.com/articles/elastic-leadership-course-in-amsterdam-july.md" canonical: "https://www.5whys.com/articles/elastic-leadership-course-in-amsterdam-july.html" published: "2012-05-06T13:01:06+00:00" updated: "2012-05-06T13:03:22.857000+00:00" tags: ["Courses"] author: "Roy Osherove" description: "Join me this July for two days of elastic team leadership workshop. Learn new skills, get out of your comfort zone, and learn to lead better. We can tackle all the hard questions together. I'm also looking for a venue to host the course in…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Elastic Leadership course in Amsterdam - July Join me this July for two days of elastic team leadership workshop. Learn new skills, get out of your comfort zone, and learn to lead better. [We can tackle all the hard questions together.](http://elasticamsterdam.eventbrite.com/) I'm also looking for a venue to host the course in - so if your company is willing, you can get a couple of free tickets! [Ping me.](https://www.5whys.com/contact) --- title: "On time, with quality - why is this mostly failing?" url: "https://www.5whys.com/articles/on-time-with-quality-why-is-this-mostly-failing.md" canonical: "https://www.5whys.com/articles/on-time-with-quality-why-is-this-mostly-failing.html" published: "2012-05-06T11:50:23+00:00" updated: "2013-02-24T21:13:36.343000+00:00" tags: ["First Steps during chaos", "Meta"] author: "Roy Osherove" description: "Everyone in the software industry seems to be talking about the quality mantra lately. Agile, XP and kanban brought this issue to full front, but I see many team leads failing with the quality part. Many of us keep chasing quality and…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # On time, with quality - why is this mostly failing? Everyone in the software industry seems to be talking about the quality mantra lately. Agile, XP and kanban brought this issue to full front, but I see many team leads failing with the quality part. Many of us keep chasing quality and never achieving it, because we don't know how to make time. We don't have any time to learn/teach the team and practice true quality code (unit testing, tdd, acceptance and automation to start with) because [we're in chaos and we are addicted to it.](https://www.5whys.com/articles/the-chaos-addiction.html) Our lack of time makes our decision to focus on "getting things out the door" more frequent, and so we have more quality issues and even less time, because we just have more and more fires to put out. To break this pattern, true leadership from us, the team leaders at the bottom, is needed. It's about taking a risk and breaking the cycle. It's about making time to learn. Want to ship on time with quality? remove some of the commitments you have, make time to learn, practices, and build quality into the code you're writing. You can't get better at what you do if you don't have time to get better. and You don't have time because you keep chasing your tails. So you have to break away and make time by removing some existing commitments. That's scary, but it's your job, remember? [Here's your manifesto again](https://www.5whys.com/articles/team-leader-manifesto-take-3.html). --- title: "Middle Management or puppet management?" url: "https://www.5whys.com/articles/middle-management-or-puppet-management.md" canonical: "https://www.5whys.com/articles/middle-management-or-puppet-management.html" published: "2012-05-06T11:19:00+00:00" updated: "2012-05-06T11:48:31.213000+00:00" tags: ["First Steps during chaos"] author: "Roy Osherove" description: "Most team leaders I've seen in lead roles usually feel quite helpless. Someone put them in their position, and no one taught them how to do their jobs. So they are mostly developers who are just trying to keep the status-quo. They either…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Middle Management or puppet management? Most team leaders I've seen in lead roles usually feel quite helpless. Someone put them in their position, and no one taught them how to do their jobs. So they are mostly developers who are just trying to keep the status-quo. They either don't want to, or not sure how to lead the team, and what's their role in the team.  They don't feel like leaders, and they mostly act as puppets for upper management for setting (sometimes) impossible goals and chasing them. If you're that team leader, you should realize that your job is to lead people to do the right things, and to do the right things the way you believe is right(for everyone involved). That's your job. That's why they pay you more. Management, done right, is a very tough job. That's why you get paid more. But maybe no one ever told you this. I'm telling you this now. Your job is to make your own decisions, and find your own voice. and to lead. Your job is to build value, and knowledge in the company. Your job is to grow your team to become the best bloody team they could be. [This is your manifesto.](https://www.5whys.com/articles/software-team-leader-manifesto-take-2.html) Scared? Great. Means you're about to start learning new skills, and get out of your comfort zone. --- title: "If you're looking for a QA to automate your tests, you've started to fail" url: "https://www.5whys.com/articles/if-youre-looking-for-a-qa-to-automate-your-tests-youve-start.md" canonical: "https://www.5whys.com/articles/if-youre-looking-for-a-qa-to-automate-your-tests-youve-start.html" published: "2012-05-06T10:44:20+00:00" updated: "2012-05-06T10:53:36.743000+00:00" tags: ["Learning Phase"] author: "Roy Osherove" description: "If you are looking for someone to join the QA team to automate tests, the failure is in the way the system is built. Your *developers* should be proficient (or start learning how to) in automating the tests, creating automated tests, and…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # If you're looking for a QA to automate your tests, you've started to fail If you are looking for someone to join the QA team to automate tests, the failure is in the way the system is built. Your \*developers\* should be proficient (or start learning how to) in automating the tests, creating automated tests, and overall  be able to automate the hell out of everything. Having a separate QA department is a fail in that, there is an explicitly delegation of all those "things QA folks do" to that other department, so that devs can focus on the other things. at the very least start with each team having a QA in the team, that is part of the team. then spread the knowledge of the QA dude to the rest of the team.  By looking for someone to do all that "other work" is keeping the system in fail state. instead of starting to grow your devs to be able to become better, and do that work so it's part of their work. \*it is\*. Steps I'd take(assuming the team is in the [learning phase](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)): 1. Start getting each dev/team into automation thinking mode 2. Having small goals to automate more and more things, as we write them 3. doing code reviews with an "automation" theme 4. Having "automation week" a the team level --- title: "Different ways to view organizational change" url: "https://www.5whys.com/articles/different-ways-to-view-organizational-change.md" canonical: "https://www.5whys.com/articles/different-ways-to-view-organizational-change.html" published: "2012-05-04T13:21:44+00:00" updated: "2012-05-04T13:25:00.253000+00:00" tags: ["Influence", "Meta"] author: "Roy Osherove" description: "I've written about how to change your organization in a couple of places, but I also highly suggest you read this very interesting blog post referencing different models, some of which I've only had a glipse at uptil now. It helped clear…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Different ways to view organizational change I've written about [how to change your organization](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html) in a couple of places, but I also highly suggest [you read this very interesting blog post](http://www.donaldegray.com/organizations-change-people-transition/) referencing different models, some of which I've only had a glipse at uptil now. It helped clear the picture on the "language"  related side of things. Think of it as "design patterns" for organizational change. Of those models, where do you think [this post](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html) belongs? --- title: "Chapter four - commitment language - is online" url: "https://www.5whys.com/articles/chapter-four-commitment-language-is-online.md" canonical: "https://www.5whys.com/articles/chapter-four-commitment-language-is-online.html" published: "2012-05-02T15:32:24+00:00" updated: "2012-05-02T15:35:42.074000+00:00" tags: ["Book", "Learning Phase"] author: "Roy Osherove" description: "I've just released a new chapter to my team leader book. Chapter 4 is about commitment language, as the first step as part of the learning stage. It's about bringing your team closer into Integrity thinking, and an important tool in later…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Chapter four - commitment language - is online I've just released a new chapter to [my team leader book.](http://leanpub.com/teamleader) Chapter 4 is about commitment language, as the first step as part of the learning stage. It's about bringing your team closer into Integrity thinking, and an important tool in later challenging people to master new and hard-to-earn skills. [Get the incremental book here.](http://leanpub.com/teamleader) --- title: "What should a good code review look and feel like?" url: "https://www.5whys.com/articles/what-should-a-good-code-review-look-and-feel-like.md" canonical: "https://www.5whys.com/articles/what-should-a-good-code-review-look-and-feel-like.html" published: "2012-05-02T11:06:56+00:00" updated: "2014-05-22T21:51:06.277000+00:00" tags: ["First Steps during chaos", "Growing People", "Learning Phase"] author: "Roy Osherove" description: "The way I see code reviews, is that they are a great cover for learning, mentoring _and_ finding interesting quality issues in your code. If our main goal as leaders is to grow our teams, then code reviews are a great way to grow team…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # What should a good code review look and feel like? The way I see code reviews, is that they are a great cover for learning, mentoring \_and\_ finding interesting quality issues in your code. If our main goal as leaders is to grow our teams, then code reviews are a great way to grow team members, by helping them gain many skills: how to mentor others, how to communicate better, Not being shy about asking questions, stopping hoarding knowledge and much more. You should leave a code review either feeling like you've learned something new, or that you've shared something new, or that you've caught something stupid, or too smart, and you're more proud of the codebase. To achieve all these great benefits there are some important points you can't neglect: - **To increase learning on many levels from each other**, code reviews are always between at least two people (sometimes a third person can join in to learn how to review), sitting side by side. Not in different work stations, not in different offices and not in different buildings. Those learnings can be as simple as "how did you do that with the keyboard?" to "why would you even do that?" to "I didn't even imagine that's something you could do" - **To increase code quality and remove the chance of forgetting to implement them**, code review comments are taken care of either \_during\_ or right after the code review has ended - **To increase focus and energy**, code reviews should be short. 30 min. is almost too long. 5-15 min. is good. To do that you'll need to make sure that code reviews cover smaller parts of the codebase. One way to achieve that is by _reviewing on every check-in_, so that the batches to review are smaller. - **To increase overall team proficiency and share knowledge**, code reviews are done by all members of the team to all other members. At least, that's the long term goal (within 2 months it's possible to achieve for a team of 10). If you want to get started with code reviews, and read how I'd recommend teaching everyone to review each other's code, [I expand on those things here.](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html) What about all those code review tools out there? I don't use them and never have. If you use them, you're missing out on the most important part of code reviews, the interaction with other people to learn and teach something. Remove that interaction, and you're left with a dead, boring feeling of having to look through someone else's list of boring things they think you got wrong. Who has time for that? --- title: "Do new startup leaders need to grow their teams?" url: "https://www.5whys.com/articles/do-new-startup-leaders-need-to-grow-their-teams.md" canonical: "https://www.5whys.com/articles/do-new-startup-leaders-need-to-grow-their-teams.html" published: "2012-05-01T09:44:28+00:00" updated: "2012-05-01T09:50:41.873000+00:00" tags: ["First Steps during chaos"] author: "Roy Osherove" description: "I've been involved with several small startups. My feeling is that in the first few weeks or months of a startup's life, your main goal is to make sure you're running in the right direction. You're about to release something as quickly as…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Do new startup leaders need to grow their teams? I've been involved with several small startups. My feeling is that in the first few weeks or months of a startup's life, your main goal is to make sure you're running in the right direction. You're about to release something as quickly as possible (minimum delightful product) to the market to see if you're on the right track. That means that, you're mostly in chaos. you don't have time to learn new skills. You hire the best people and pay them well so you don't have to worry about teaching anything. It's about running as quickly as possible and wasting little money in the process. That means that to me, the learning phase only happens after the startup has matured enough to be in the right direction. after the second funding phase, probably, it has time to worry about things like quality, and growing the people. That's why I would not recommend TDD either when you're just trying to gauge people's reaction to something you might throw away in two weeks. I think that's also the reason why in many established companies who started as startups, the code base is so crappy - because the initial idea was to get something out there. It's fixing the code base that considered part of the "learning phase". But unfortunately, many companies continue to exist in chaos even after initial startup phase, and don't give enough time for skills and practices to be learned by the team. But that's a whole 'nother story. --- title: "Grow your \"feature teams\" into just \"teams\"" url: "https://www.5whys.com/articles/grow-your-feature-teams-into-just-teams.md" canonical: "https://www.5whys.com/articles/grow-your-feature-teams-into-just-teams.html" published: "2012-05-01T09:36:33+00:00" updated: "2012-05-01T09:42:21.747000+00:00" tags: ["Growing People", "Learning Phase"] author: "Roy Osherove" description: "A feature team, as I see it, is a team consisting of all the people needed to accomplish a released specific feature. So on such a team you might have an architect, a DBA, a coder, a UI guy, a frontend guy etc.. In that case it's important…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Grow your "feature teams" into just "teams" A feature team, as I see it, is a team consisting of all the people needed to accomplish a released specific feature. So on such a team you might have an architect, a DBA, a coder, a UI guy, a frontend guy etc.. In that case it's important to notice that a team consisting of different specialists is also a team with [a very bad bus factor](https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html).  The team can stop being productive as soon as even one person on the team gets sick for a couple of days. Knowledge is not shared. That's why, in the learning phase, it's important to have a goal to turn feature teams into just "teams" of people who work together, each with the minimal skills to do the work of the others. It takes a lot of time, but growing people, taking them out of their comfort zone, and teaching them new skills, is part of your job as a team leader. As a team leader, you should view feature teams of different specialists as something to grow out of. To be left with only teams of people who can self organize and do the work and have the skills needed to overcome problems such as a person on the team missing. Most organizations don't even have feature teams yet, but as a leader, your vision should strive to have "feature teams" be just a mid-point on the way to teams that share knowledge. --- title: "You're not self organizing if you have a go-to architect" url: "https://www.5whys.com/articles/youre-not-self-organizing-if-you-have-a-go-to-architect.md" canonical: "https://www.5whys.com/articles/youre-not-self-organizing-if-you-have-a-go-to-architect.html" published: "2012-05-01T09:22:08+00:00" updated: "2014-05-22T21:46:00.757000+00:00" tags: ["Learning Phase", "Self-Leading Phase"] author: "Roy Osherove" description: "I realized that while I was writing the previous post , I came up with another simple way to tell if your team is self organizing or not, In my courses , people always ask me, how to tell if I'm in chaos, learning or self organizing. My…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # You're not self organizing if you have a go-to architect I realized that while I was writing [the previous post](https://www.5whys.com/articles/the-architect-as-a-leader-and-other-specialists.html), I came up with another simple way to tell if your team is self organizing or not, In [my courses](http://osherove.com/leadership-course/), people always ask me, how to tell if I'm in chaos, learning or self organizing. My answers are usually based on reduction. as is this one. If your team needs to go ask an architect outside the team questions to finish its job, it's not truly self organizing. A self organizing team should know how to solve its own architecture problems. (That's why feature teams can potentially be self organizing, because they don't need to get out of the team to do their job). If your team consists of an architect, it's a different story. it \*could\* be self organizing, but I would push that architect to use their leadership position in this area so that everyone became the architect (of course, only in learning mode. in chaos you don't have time to do that.) --- title: "The architect as a leader, and other specialists" url: "https://www.5whys.com/articles/the-architect-as-a-leader-and-other-specialists.md" canonical: "https://www.5whys.com/articles/the-architect-as-a-leader-and-other-specialists.html" published: "2012-05-01T08:49:02+00:00" updated: "2012-05-01T14:52:22.663000+00:00" tags: ["Growing People", "Learning Phase", "Meta"] author: "Roy Osherove" description: "To me, if you have an architect on your team, their role should be To act as an unofficial leader in the team that mentors and teaches people on the team about architecture To make themselves unneeded - that their knowledge is spread…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The architect as a leader, and other specialists To me, if you have an architect on your team, their role should be - To act as an unofficial leader in the team that mentors and teaches people on the team about architecture - To make themselves unneeded - that their knowledge is spread enough so that they are no longer a bottleneck A bottleneck? Yes. An architect, by definition, is a bottleneck. If people need to come to the architect with questions that only the architect can decide on, then they are easily a bottleneck people are waiting on to deliver things.  But an architect can be so much more than just "dispenser of architecture guidance". An architect should be treated as having something missing in the team. That something is knowledge. Your team can't really be self-organizing if it needs to approach the company architect to make decisions. In that case your team is either in chaos or in learning mode. The architect can play a big role in making sure the team comes into learning more, by making time for the team to learn about architecture, and learn how to make important decisions about architecture. The architect can coach and mentor each person on the team individually, and train the team as a group, to think about the architecture aspect that the architect knows so much about. An architect should be thinking "why is there an architect role here, anyway?" and then make it their job to make sure that everyone is an architect. When the architect is no longer the bottleneck, he can start learning new skills beyond architecture, just like any other member on the team. That's because an architect who's no longer THE architect, is simply a team member. If there is a shared architect, their job is to make sure the various teams don't need him to solve their own problems. When his/her job is done, he can start propelling his/her skills in new directions, because he/she will have lots more free time on their hands. An architect that does his job creates knowledge that is shared in the company DNA, and facilitates continued thinking and challenging ways to think about the same problems. Another option when he's no longer a bottleneck, is to dedicate him/herself to a new target and learning. An architect is a leader in a specific area. A leader mentors and teaches other to become better, so that the leader is no longer needed for the team to organize. Just to set goals and constraints. But an architect is just a version of a SPECIALIST. Indeed, any any specialist in the company should be treated as a hidden leader. Every specialist should be mentored and challenged to become an unofficial leader that challenges and pushes others to learn about their specialty, to share in the specialist's knowledge, so that he's no longer a specialist, just a mentor setting overall goals and constraints about a specific subject. --- title: "Joining Forces with other leaders to make change happen" url: "https://www.5whys.com/articles/joining-forces-with-other-leaders-to-make-change-happen.md" canonical: "https://www.5whys.com/articles/joining-forces-with-other-leaders-to-make-change-happen.html" published: "2012-03-30T13:10:54+00:00" updated: "2012-04-01T07:29:25.957000+00:00" tags: [] author: "Roy Osherove" description: "Let's say you're trying to make some real change happen. Maybe you've just finished doing a course on unit testing, and your development department devs are all excited about making this a reality. But some devs are very sceptic that this…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Joining Forces with other leaders to make change happen Let's say you're trying to make some real change happen. Maybe you've just finished doing a course on unit testing, and your development department devs are all excited about making this a reality. But some devs are very sceptic that this can happen. They've been burnt before with some of the same people who just did the course. They've heard some promises that weren't kept before, form the same leaders that made this course happen. So they don't think something else will. You're the team leader in one of the teams that took the course, and you think it might happen this time, about 50% chance. But how do you help make this effort a success? Your manager is the one who promised that dev time will be increased by at least 100% for a few months until unit testing gets into the blood of the company, and you might be a bit sceptical. In this very scenario it's impotant to gather the other leaders that lead the dev group : other team leaders, architects and heads of other departments like QA. It's important to display a united front about wanting to make this a success. It's important to not show any different of opinion on weather it will or won't work, and discuss skepticism towards any of the other leaders, in private, face to face conversation. Your teams need to see a unitited effort to do this. Seeing mommy and daddy fight only creates more stress and disbelief. If people are already cynical, you don't need to add to that fire. By displaying true and honest wanting to become better, by being humble and saying you might not know everything there is to know about this subject, you are letting others see that you really care enough, even if you're changing your own skin to do so. It's also important to focus on one thing that gets better every time. If you're learning unit testing, don't stress design and styling too much in your code review. make the effort to let some things go and choose your battles to be on the quality and rightness of the tests. Dont' disrespect any of your team members or other leaders in public. or in private. not even in humor. Everything is taken into account when people need to make a decision of how commited they are to do change. if they get pissed off at you within 10 seconds of the start of a code review, you lose hope of them playing ball and making real changes. Not for you, anyway. --- title: "Contribute a note to my upcoming book - Notes to a software team leader" url: "https://www.5whys.com/articles/contribute-a-note-to-my-upcoming-book-notes-to-a-software-te.md" canonical: "https://www.5whys.com/articles/contribute-a-note-to-my-upcoming-book-notes-to-a-software-te.html" published: "2012-03-04T11:04:38+00:00" updated: "2012-03-04T11:04:38+00:00" tags: [] author: "Roy Osherove" description: "Yesterday I published the first two chapters of my incrementally publishing book \" Notes to a software team leader \". You can be part of it. I want you to. The first part of the book will contain concepts from this blog such as elastic…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Contribute a note to my upcoming book - Notes to a software team leader Yesterday I published the first two chapters of my incrementally publishing book "[Notes to a software team leader](http://leanpub.com/teamleader)". You can be part of it. I want you to. The first part of the book will contain concepts from this blog such as elastic leadership, people skills and more. It will be rather short. The second half is the most important one: The second half will be dedicated to various notes and advice you have a for a new software team leader - things they just have to know, that they would have to learn the hard way unless you tell them. If you're a : - Team member who's had a terrible or wonderful leader - Consultant who's seen team leaders work great, or make terrible mistakes - Team Leader yourself, who has made mistakes or succeeded - Project manager who deals with team leaders - A CEO who deals with team leaders - a QA person who deals with team leaders - any other stake hold who deals with software team leaders direction **Your note matters.** Write a few paragraphs or more about things that you would expect from your team leader, or write the things you hate the most when team leaders do. Write something that you wish your current team leaders would know or future ones. Team leaders need this advice. Please go and submit one. [Book](http://technorati.com/tag/Book) --- title: "Lead Better Bucharest Edition - This Month" url: "https://www.5whys.com/articles/lead-better-bucharest-edition-this-month.md" canonical: "https://www.5whys.com/articles/lead-better-bucharest-edition-this-month.html" published: "2012-03-03T18:47:03+00:00" updated: "2012-03-03T18:47:03+00:00" tags: ["Courses"] author: "Roy Osherove" description: "I'm happy to say that I'll be visiting Bucharest on the 22-23 of this month. This is the first time ever I'm visiting there and I'm bringing my new course - Lead Better (which is based on this blog, and and the new book I'm writing ) with…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Lead Better Bucharest Edition - This Month I'm happy to say that I'll be visiting Bucharest on the 22-23 of this month. This is the first time ever I'm visiting there and I'm bringing my new course - Lead Better (which is based on this blog, and and [the new book I'm writing](http://leanpub.com/teamleader)) with me. You can find [details about the course and pricing here](http://tinyurl.com/osherovebucharset2012). If you're interested in joining the course we have 6 seats free. I would love to go out for drinks while I'm there! --- title: "New Book: Notes to a software team leader" url: "https://www.5whys.com/articles/new-book-notes-to-a-software-team-leader.md" canonical: "https://www.5whys.com/articles/new-book-notes-to-a-software-team-leader.html" published: "2012-02-28T09:07:14+00:00" updated: "2012-02-28T09:07:14+00:00" tags: [] author: "Roy Osherove" description: "I've started to write my upcoming book titled \" Notes to a software team leader \" (hat tip to Kevlin Henney for the name idea). The book will combine many of the subjects this blog addresses, plus notes collected from some of the best…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # New Book: Notes to a software team leader I've started to write my upcoming book titled "**Notes to a software team leader**" (hat tip to [Kevlin Henney](http://www.two-sdg.demon.co.uk/curbralan/kevlin.html) for the name idea). The book will combine many of the subjects this blog addresses, plus notes collected from some of the best minds in the management field, various stakeholders and actual team members. If you're interested, [you can be notified when it's published](http://leanpub.com/teamleader) (chapter by chapter)- I will start publishing incrementally, in the coming days, over at leanpub. [Book](http://technorati.com/tag/Book) --- title: "Software Team Leader Manifesto - Take #2" url: "https://www.5whys.com/articles/software-team-leader-manifesto-take-2.md" canonical: "https://www.5whys.com/articles/software-team-leader-manifesto-take-2.html" published: "2012-02-23T13:32:59+00:00" updated: "2012-02-23T13:32:59+00:00" tags: ["Meta"] author: "Roy Osherove" description: "after the first one, here's what I have so far. Your comments are appreciated. We believe the role of a team leader is to also grow the people in their team, and themselves, and that this will create the most value for everyone involved…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Software Team Leader Manifesto - Take \#2 after the first one, here's what I have so far. Your comments are appreciated. **We believe the role of a team leader is to also grow the people in their team, and themselves, and that this will create the most value for everyone involved.** **To that end:** - We believe in adjusting the leadership style to the current needs of the team, over a single style of leadership - We believe in challenging ourselves and our teams to always get better, so: - We embrace taking risks for our team over staying safe - We embrace fear and discomfort as learning new skills - We embrace experimentation as a daily practice - With people - With tools - With processes - With the environment - We believe team leaders lead people, not machines, so: - We embrace spending more time with our team than in meetings - We embrace learning people skills and techniques --- title: "Stoos Gathering - Initial Thoughts" url: "https://www.5whys.com/articles/stoos-gathering-initial-thoughts.md" canonical: "https://www.5whys.com/articles/stoos-gathering-initial-thoughts.html" published: "2012-01-08T21:10:57+00:00" updated: "2012-01-08T22:06:38.347000+00:00" tags: ["stoos"] author: "Roy Osherove" description: "This past weekend I was honored to be part of what I hope will be the beginning of a transformation in management culture. The start of a tipping point. It was the Stoos Gathering . that site contains a statement that represents one of the…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Stoos Gathering - Initial Thoughts This past weekend I was honored to be part of what I hope will be the beginning of a transformation in management culture. The start of a tipping point. [It was the Stoos Gathering](http://www.stoosnetwork.org/). that site contains a statement that represents one of the things we all agreed on. and that was pretty difficult.  We were twenty one very different individuals, form four continents, many different countries, and sometimes very different cultures of communication and leadership. In that single room, I believe we had no less than 15 different "ways" of doing things. The most powerful realization was that mostly people were not aware of each other's work. From [Radical Management](http://www.stevedenning.com/Radical-Management/default.aspx), [Spiral Dynamics](http://en.wikipedia.org/wiki/Spiral_Dynamics), [Elastic Leadership](https://www.5whys.com/articles/), [Beyond Budgeting](http://www.amazon.com/Beyond-Budgeting-Managers-Annual-Performance/dp/1578518660), [Management 3.0](http://www.noop.nl/), Scrum, XP, And many other ways of work - we had to find a common ground.  We had to find something that we can all agree on. and stoos wa the first step to doing that. I think that's way there was so little that we can call "conclusions" as a result - we had discovered how big the problem really is.   To begin to change management culture (which has remained the same for decades) we need to find common ground, and the stoos network was a good start. We also agreed to meet again , and to take other actions that will be detailed by others who documented them. But mostly it is about affecting the tipping point - of how to get the people on top, the people on the bottom and those in the middle - to change how they do things. From CEOs to knowledge workers.  That is a big task, and it's supposed to be scary.  Until we get more material out there, you might want to register [to the linkedin group here](http://www.linkedin.com/groups/Stoos-Network-4243114?gid=4243114&trk=hb_side_g) to get more news. --- title: "How to be an effective code coach" url: "https://www.5whys.com/articles/how-to-be-an-effective-code-coach.md" canonical: "https://www.5whys.com/articles/how-to-be-an-effective-code-coach.html" published: "2011-12-12T11:59:02+00:00" updated: "2012-04-29T20:41:11.062000+00:00" tags: ["Learning Phase", "Pair Programming"] author: "Roy Osherove" description: "As a technical team leader, you might expect others to become better coders. You can also be a coach for them by pairing with each person for a few hours each week. Being an effective code coach means that you pair with someone, but you…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to be an effective code coach As a technical team leader, you might expect others to become better coders. You can also be a coach for them by pairing with each person for a few hours each week. Being an effective code coach means that you pair with someone, but you write less code. You mainly sit there next to them and help them out as they struggle out writing the code on their own. You might jump in, but most of the time, you should restrain yourself, and let them solve their own problems to completion. Additional techniques include asking them leading questions and jointly planning effective implementations. Remember to always be an overall coach and mentor. It's all too easy to jump in and take the reigns from a coder with less experience than you. It's much more effective to not do that - but intend give them sense that you trust them, and that it's ok to go slower, but you expect them to challenge themselves and to ask tough questions, even if they seem silly. You may find that being a code coach, you struggle just as much as your pair - but you struggle at learning to lead and coach. they struggle with learning to 'get' code. --- title: "You Can't Fire Everyone" url: "https://www.5whys.com/articles/you-cant-fire-everyone.md" canonical: "https://www.5whys.com/articles/you-cant-fire-everyone.html" published: "2011-12-09T11:12:21+00:00" updated: "2011-12-09T11:12:21+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "If you go through your leadership career wondering \"if only I'd been stuck with a better team of developers - we'd do much better\" - you're doing it wrong. Management - done right, is a tough job. That's why you get paid more. But some…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # You Can't Fire Everyone If you go through your leadership career wondering "if only I'd been stuck with a better team of developers - we'd do much better" - you're doing it wrong. Management - done right, is a tough job. That's why you get paid more. But some managers prefer to go through life taking the money and not doing the hard work. (loosely quoting Jerry Weinberg). Take a hard look in the mirror -- > Your job as a leader and manager is to turn your team into a team you can be proud of. > > If you easily resort to getting people out of the team - you're not doing your job. > Grow them -- invest time and effort. Do the hard things and the things that scare you. PS The title is [from this book.](http://www.amazon.com/gp/product/B005ZO5ZAQ/ref=as_li_ss_tl?ie=UTF8&tag=iserializable-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B005ZO5ZAQ) it's not great, but the title is very nice. --- title: "Don't be afraid to become management" url: "https://www.5whys.com/articles/dont-be-afraid-to-become-management.md" canonical: "https://www.5whys.com/articles/dont-be-afraid-to-become-management.html" published: "2011-12-08T22:36:57+00:00" updated: "2011-12-08T23:01:43.053000+00:00" tags: ["Anti Patterns", "Meta", "Video"] author: "Roy Osherove" description: "If you do it right, your fears can mostly be wrong. If you do it wrong - your fears will mostly be right. So I just made this late night video to talk about that: Watch on YouTube Don't be afraid to become management" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Don't be afraid to become management If you do it right, your fears can mostly be wrong. If you do it wrong - your fears will mostly be right. So I just made this late night video to talk about that: [![](https://www.5whys.com/img/video/youtube-Nldh-o7Svus.jpg)Watch on YouTube](https://www.youtube.com/watch?v=Nldh-o7Svus) Don't be afraid to become management --- title: "A Manifesto For Software Team Leaders - Take 1" url: "https://www.5whys.com/articles/a-manifesto-for-software-team-leaders-take-1.md" canonical: "https://www.5whys.com/articles/a-manifesto-for-software-team-leaders-take-1.html" published: "2011-12-08T05:21:52+00:00" updated: "2014-05-22T22:58:02.063000+00:00" tags: ["Conference", "Meta"] author: "Roy Osherove" description: "It occurs to me that a manifesto for a software team leader is not a bad idea. And, I intentionally not want it to be an \"Agile\" related manifesto, but more of a management/people/leadership manifesto that applies to the software industry…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A Manifesto For Software Team Leaders - Take 1 It occurs to me that a manifesto for a software team leader is not a bad idea. And, I intentionally not want it to be an "Agile" related manifesto, but more of a management/people/leadership manifesto that applies to the software industry. Perhaps later we can say that it applies to a broader scope, but software is where I am focusing, until proven otherwise. I would love to hear your thoughts on what items would appear in such a manifesto. Here are some things I would think would make a good fit, but I don't think I can articulate them well enough to be concise and to the point enough to make a manifesto: - **Adjusting leadership to the problems the team is facing**, over blindly leading in your preferred manner - **Experimenting with humans**, over status quo - **Challenging yourself as a leader to become better,** over staying safe - **Embracing yours and your team's fear and discomfort as learning,** vs. staying in safe, calm and cool waters - **Spending more time with your team** , vs spending more time in meetings - **Also Focusing on People Skills** vs. just learning methodological practices - **Taking Personal Risks** vs. keeping status quo - **Challenging and teaching your team to solve their own problems** vs. Solving everyone else's problems yourself - new: everyday - you and your team are better at something, than you were yesterday Dear reader - if you think you have more ideas, or that some of these are crap - I'd love to know, and why. if you think you can word these better (and I'm sure that should be pretty easy) - please help me out in the comments. **Trying this out in real life** In my [upcoming team leader course in Norway next week,](http://www.programutvikling.no/kurskalenderoversikt.aspx?mid_1=1352&mid=1535&id=1269909) I will try to create a shared manifesto like this for the first time. We'll see what we get…! **Stoos** I'll be pondering this out loud in the [Upcoming Leadership Summit in Stoos.](http://www.noop.nl/2011/12/global-management-warming-starts-in-switzerland.html) I'm honored to have been asked to attend,and if you read that blog post carefully, you'll see that one of the things he writes there is "probably not another manifesto". so, there - our first disagreement? should be interesting! --- title: "Stavanger Norway Elastic Leadership Course" url: "https://www.5whys.com/articles/stavanger-norway-elastic-leadership-course.md" canonical: "https://www.5whys.com/articles/stavanger-norway-elastic-leadership-course.html" published: "2011-11-29T12:42:14+00:00" updated: "2011-11-29T12:42:14+00:00" tags: ["Courses"] author: "Roy Osherove" description: "This is very short notice, (which is why there is a surprise) - but During December 15-16, I'll be doing my Elastic Leadership Course \"Lead Better\" in Stavanger, Norway. It is based on my experiences blogged here at http://5whys.com - but…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Stavanger Norway Elastic Leadership Course This is very short notice, (which is why there is a surprise) - but During December 15-16, I'll be doing my [Elastic Leadership Course "Lead Better"](http://osherove.com/leadership-course/) in Stavanger, Norway. It is based on my experiences blogged here at [http://5whys.com](https://www.5whys.com/)  - but with much more details and exercises. [For registration and info click here.](http://www.programutvikling.no/kurskalenderoversikt.aspx?mid_1=1352&mid=1535&id=1269909)   **NOTE: the course will run only if we have 5 or more attendees registered.** --- title: "Ten Things Distributed Team Leaders Should Do" url: "https://www.5whys.com/articles/ten-things-distributed-team-leaders-should-do.md" canonical: "https://www.5whys.com/articles/ten-things-distributed-team-leaders-should-do.html" published: "2011-10-03T09:01:50.943000+00:00" updated: "2011-10-03T09:34:48.943000+00:00" tags: ["Distributed"] author: "Roy Osherove" description: "This turned up in one of the LinkedIn groups I'm part of - what practices should you have as a team lead in a distributed team (assuming people work from home, for example)? Have a shared skype chat for the whole team, and always have…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Ten Things Distributed Team Leaders Should Do This turned up in one of the LinkedIn groups I'm part of - what practices should you have as a team lead in a distributed team (assuming people work from home, for example)? - Have a shared skype chat for the whole team, and always have someone senior enough available to answer important or administrative questions. - Get the team together once every x days/weeks, and in that time, make people work as much together as possible. - on skype, show your true status, so people know when you are or are not available. When you are available, answer. if you are not, set status to busy. - Set fixed times when people are expected to be working. These times should be acceptable by everyone. Don't Ask people to work in crazy hours because that is what you do - If you are not going to be online for a few days (such as vacation), mention it clearly, when you will be away and for how long. - Let people know when you come back..! - To keep people focused and not stuck, it's good to have a virtual daily standup meeting when everyone is online. - If that is not possible, have daily one on one on skype for a few minutes about today's and yesterday's progress with each team member. - Hold code reviews on commits to make sure quality is up to par. If you are not available to do code reviews, make the time to do it, and teach others how to review code, so you don't become a bottleneck. - Give people access to ask questions directly with the customer if possible. If it's not possible, and you are the only contact to the customer, make sure you are not a bottleneck, or at least try to add people in the project to conversations you have with the customer, so they get a feel for what the project is envisioned like to them. --- title: "Three reasons not to have your own private office" url: "https://www.5whys.com/articles/three-reasons-not-to-have-your-own-private-office.md" canonical: "https://www.5whys.com/articles/three-reasons-not-to-have-your-own-private-office.html" published: "2011-10-02T19:39:36+00:00" updated: "2011-10-02T21:42:46.833000+00:00" tags: ["Anti Patterns", "Influence"] author: "Roy Osherove" description: "When I was just starting out as a team lead, I remember bemoaning to myself how I wasn't being 'appreciated' enough to have my own office. For geeks like it is can often feel like a status symbol. But the more time goes by, the more I…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Three reasons not to have your own private office When I was just starting out as a team lead, I remember bemoaning to myself how I wasn't being 'appreciated' enough to have my own office. For geeks like it is can often feel like a status symbol. But the more time goes by, the more I would rather sit in the same room with the team. Here are some reasons why, if given a choice to have my own office or have a space with my team, I'd choose to sit with the team: ### **Be in the loop.** If you're in your own office, you're out of the loop. You're not hearing the rustle and bustle of things being done (or not done). You're not sensing happiness, or frustration, or lack of interest in all things to do with your project from your team. You're just not there to absorb what life is really like being in _your_ team. ### **Lead by example** If you're in your own office, you can't lead by example as effectively as you can sitting right next to your team. If you're (mostly) always at your team's room, they can see how you act in various situations - from talking with the marketing folks who come by asking for features, to solving time-scheduling problems, to talking on the phone with people (when that conversation can be made in the team room), to managing your own work environment. Act they way you'd like to see them act in these situations. Lead by example. If you keep your cool on tough technical problems, or dilemmas, or if you lose your temper - people will learn how it's OK or not ok to act in these situations. ### **Handle things before they happen** If you're right next to the team, and you notice something that, based on your experience, will have important effects that need to be handled (choosing a bad technical route to solve a problem, inability to decide on something, people taking on too many tasks they can't handle..) , you can have a chance to deal with this before something has been 'committed to paper'. you can help either change the course of a decision before it becomes fact. How you act will depend on which team stage your team is in, of course, but regardless of stage, earlier is better, even if you intend to do nothing but shutup and watch people learn something the hard way. ### **What about 'me' time?** When I suggest this to leaders, they tell me: - "but I need some privacy, some 'me' time" Well, now you know how some of your team members feel. If you can solve that 'me' time problem for yourself without having your own office all the time, you might solve that problem for your team as well - for example you can have a couple of empty meeting rooms with machines or phones where people can spend some time alone or talking 1 on 1. - "where will I hold me private meetings?" In those usually-empty couple of meeting rooms we just discussed. --- title: "Technical Anti Patterns Arising from Social Inadequacy" url: "https://www.5whys.com/articles/technical-anti-patterns-arising-from-social-inadequacy.md" canonical: "https://www.5whys.com/articles/technical-anti-patterns-arising-from-social-inadequacy.html" published: "2011-09-19T17:50:27.094000+00:00" updated: "2011-09-19T19:07:54.087000+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "The book Roundtable on Technical Leadership (SHAPE Forum Dialogues) by Jerry Weinberg is a treasure trove of interesting things that give words to feelings I've had during my work as a team leader and with other team leaders (and as a team…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Technical Anti Patterns Arising from Social Inadequacy The book [Roundtable on Technical Leadership (SHAPE Forum Dialogues)](http://www.amazon.com/gp/product/093263351X/ref=as_li_ss_il?ie=UTF8&tag=iserializable-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=093263351X) by Jerry Weinberg is a treasure trove of interesting things that give words to feelings I've had during my work as a team leader and with other team leaders (and as a team member..). The book appeals most to developers \*not\* acting as team leaders (how to influence without influence, in a way). To whet your appetite, here's just a simpe list detailing the subjects covered in chapter five (Tricks arising from social inadequacy): - Career Development Through Co-Dependency - Using Technical Tricks to Avoid Social Situations - Not Documenting Your Assumptions - Not Asking for Help - Preventing Others from Learning, by Being Impatient - Failing to Notice Your Fault Feedback Ratio and to Do Something About It - Not Documenting Why Choices Were Made - Lack of Feedback Doesn't Necessarily Mean the Code Was Good - Let Your Tools Do Their Work - Keeping in the Stuff That's Corrected by Other Stuff - Replacing One Big Mess with an Unending Series of Small Messes - Give a Fresh Start When Needed - Failing to Use Your Own Product --- title: "Five Questions to ask yourself when getting advice about team leadership" url: "https://www.5whys.com/articles/five-questions-to-ask-yourself-when-getting-advice-about-tea.md" canonical: "https://www.5whys.com/articles/five-questions-to-ask-yourself-when-getting-advice-about-tea.html" published: "2011-09-13T13:17:28.613000+00:00" updated: "2011-09-13T13:23:36.437000+00:00" tags: ["Critical Thinking", "Meta", "Ri", "Self Improvement"] author: "Roy Osherove" description: "Go through each guest post in in this blog , and ask yourself the following questions about it: In what maturity stage does this suggestion make sense? What would happen if I exercise this suggestion during each of the other team maturity…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Five Questions to ask yourself when getting advice about team leadership Go through [each guest post in in this blog](https://www.5whys.com/articles/category/Guest+Post), and ask yourself the following questions about it: - In what [maturity stage](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) does this suggestion make sense? - What would happen if I exercise this suggestion during each of the other team maturity stages that don't seem to fit? - Can you think of a time when you tried or seen someone else try such a behavior during the wrong team maturity stage? - Some posts suggest ideas that may make sense in more than a single maturity stage. What do you think makes them different than other posts? What makes a team leader's behavior apply to more than a single team stage? what makes a team leader behavior apply only to a single stage? - Can you think of team leader behaviors that make sense in \*all\* three stages? **Bonus Questions:** - What hidden assumptions about you and your team did the author make when suggesting this? Why would they make those assumptions? - How can you avoid the wrong assumptions when deciding on a course of action? --- title: "Go see, ask why, show respect" url: "https://www.5whys.com/articles/go-see-ask-why-show-respect.md" canonical: "https://www.5whys.com/articles/go-see-ask-why-show-respect.html" published: "2011-09-13T12:47:36.083000+00:00" updated: "2011-09-13T12:47:36.083000+00:00" tags: ["Guest Post"] author: "Roy Osherove" description: "The following is guest post by Horia Sluşanschi . Contribute your own here. About Horia: Horia is a passionate Agile Coach, serving as the leader of the HP Agile Mentoring Office, and the HP Software Engineering Profession. He has written…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Go see, ask why, show respect > The following is  guest post by [Horia Sluşanschi](http://inspiration4agilists.blogspot.com/). Contribute your own here. > > About Horia: Horia is a passionate Agile Coach, serving as the leader of the HP Agile Mentoring Office, and the HP Software Engineering Profession. > He has written software of various kinds, from firmware for various devices, to compilers for supercomputers and all sorts of business systems in between for more than 25 years now. Horia holds a PhD in Computer Science, is a trained Lean Six Sigma Black Belt practitioner, and holds various other certifications and memberships in various professional associations. > His calling lies in growing more accomplished leaders, helping numerous Teams to achieve amazing results. The best way to help your Team to serve their clients ever better, to achieve and sustain a culture of continuous improvement, is to start by showing them deep respect. How can you best show respect? Consider Jim Womack’s excellent advice in his [excellent collection of essays “Gemba Walks”](http://www.amazon.com/gp/product/B004OYTDM4/ref=as_li_ss_tl?ie=UTF8&tag=iserializable-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=B004OYTDM4). You do so by challenging their thinking about the current work process, asking lots of open, probing questions to uncover the root causes of the current impediments. No process is ever perfect, so you can focus on helping the Team to discover what its key constraint is at any particular time and then devise countermeasures to remedy it. The key constraint is the area in which an improvement will show the biggest bang-for-buck when measured across the entire system, improving the overall flow of the work process, likely reducing cycle time and waste, with less overburden or absurdity involved. By engaging your Team in problem-solving, you’re showing them that you choose not to attempt to solve the problem alone. You trust them to be best placed to come up with the most promising improvement ideas, as they are closest to the work being done and have all the facts at hand. As a Team Leader, you truly respect your Team’s knowledge and their dedication to find the best answer. Even so, Team members can’t quite do it all alone either, because they are often too close to the issue to fully appreciate its full context. They may also avoid tough questions about the nature of the work and the reasoning behind certain inefficient practices. By showing mutual respect, better countermeasures can be devised, the Team can derive more pride in the quality of their work and everyone enjoys a more satisfying journey of professional accomplishment. To better serve your Team, work to understand yourself better, assessing your own strengths and weaknesses. Strive to become aware of your Team’s characteristics as well, sensing their professional and emotional development needs. Be ready to adapt your leadership, coaching and mentoring style to suit the Team’s current spot on its journey to professional mastery. --- title: "Appraisals and Agile Don't Play Nicely" url: "https://www.5whys.com/articles/appraisals-and-agile-dont-play-nicely.md" canonical: "https://www.5whys.com/articles/appraisals-and-agile-dont-play-nicely.html" published: "2011-09-05T19:42:22.096000+00:00" updated: "2011-09-05T19:42:22.096000+00:00" tags: ["Guest Post"] author: "Roy Osherove" description: "The following is a guest post by Gary Reynolds . Contribute your own here. Gary is a Development Manager for a global software company, with particular expertise in transitioning teams from 'traditional' software development practices to…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Appraisals and Agile Don't Play Nicely > The following is a guest post by [Gary Reynolds](http://agilisation.blogspot.com/). Contribute your own here. > > Gary is a Development Manager for a global software company, with particular expertise in transitioning teams from 'traditional' software development practices to more Agile ways of working. Appraisals, performance reviews, 360 feedback, evaluations - call them what you will - have been present in organizations in one form or another for over 100 years. Over this time, the process has taken a number of different forms, depending on the current trends and the size of the organization. I personally have experience of written evaluations where the employee has no input, various rating systems - where both employees and managers get to rate the individual - and written appraisals where the employee makes comments on their own performance that are then used as the basis for further discussion. Some systems have been directly linked to pay and promotion opportunities whereas some have been explicitly decoupled. One thing that they all have in common is that they focus on the individual, their performance and what they've accomplished since the last review period. They encourage the individual to take credit for themselves and to compete against the other people on their team for recognition and a limited pot of money when it comes to bonuses and salary increases. I would suggest that this is in direct conflict with the adoption and use of Agile frameworks within the organization. Think about that: - Agile emphasizes teamwork and co-operation in order to successfully deliver a product, with individuals being prepared to take on any task that needs doing in order to complete the iteration and get to 'done'. Individual accountability, as valued by the traditional appraisal system, implies that individuals should be interested in taking the juiciest or most challenging tasks for themselves in order to prove their worth and progress within the organization. - Agile emphasizes the forming of self-organizing teams who direct and manage their own work, whereas appraisals involve the settings of objectives that traditionally come from the manager. - Agile processes emphasize continual process improvement and, while this can be done alongside traditional appraisals, appraisals are more geared towards making individual or process changes at review time. Is there a case for abolishing appraisals altogether in an Agile environment? - well perhaps. The challenge is that individuals within an organization expect and deserve feedback on their performance. Perhaps a step in the right direction would be for team leaders to make the appraisal process itself more Agile and encourage an environment where the annual review is replaced or supplemented with a system of continuous feedback and learning where individuals - in line with Agile - are empowered to self-organize their own career development. Here are some ideas to get you started: - Build learning and career development into individual user stories - perhaps in the form of a specific task that involves team members expanding their business domain knowledge. Alternatively, include time for learning tasks into your velocity calculations so you can increase the 'value' of each team member to the organization by expanding their skill set in a way that's relevant to their immediate task. Let the individuals drive and organize this learning process as they would a normal development task. - Encourage pairing (pair-programming for example) on tasks that help individuals to learn from those more experienced than them. - Include team member feedback sessions as part of your iteration retrospective process, where you can directly discuss what people have learnt. - Encourage individuals, on an iteration-by-iteration basis, to maintain a body of evidence that can be directly referenced at formal appraisal time. This will reduce the time taken to plan and perform the appraisal and encourages the recording of tasks at the time they happen, i.e. when they're most relevant. What else can you think of? --- title: "Making your team manage their own work" url: "https://www.5whys.com/articles/making-your-team-manage-their-own-work.md" canonical: "https://www.5whys.com/articles/making-your-team-manage-their-own-work.html" published: "2011-09-02T12:38:02.167000+00:00" updated: "2011-09-02T12:38:02.167000+00:00" tags: ["Guest Post"] author: "Roy Osherove" description: "The following is a guest post by Lior Friedman . Contribute your own here. About Lior: I’m an Agile coach and Software Craftsman with more than fifteen years of experience. In recent years I consult and train teams worldwide on how to…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Making your team manage their own work > The following is a guest post by [Lior Friedman](http://imistaken.blogspot.com/). Contribute your own here. > > About Lior: I’m an Agile coach and Software Craftsman with more than fifteen years of experience. In recent years I consult and train teams worldwide on how to improve software development. Specifically, I help companies adopt Agile software development processes and teach development teams how to improve the quality of their code by using advanced techniques like TDD, BDD and other Agile practices. I was reading [this post by John Hil](https://www.5whys.com/articles/spread-your-workload.html) in the 5whys blog recently. and it got me thinking. I took me a while to understand why I felt that one is a little wrong. After all the advise given in it is quite reasonable. and then it hits me ### The game of picking who does what, is not worth playing. It is better to avoid the problem to begin with, and the best way to do that is to let the team decide on its own who does what. If you want to become a great team leader you need to stop being the team “task dispatcher”. Normally a group of people will do a better job at this then a single person. Your job (as the team leader) is to allow this to happen. i.e. make your team self manage. If your team is not yet there, here is a good goal for you to strive for and invest effort in. The first step is to stop deciding for them. As long as you decide who does what, the team will not take charge of his own work. After all why should they worry when you do this for them? Now, I know this is not that simple to accomplish. but here’s what works for me when I approach this problem ### Making your team manage their own work Explain the new “rules” to the team – when expecting someone to start doing something new, I found it usually helps to state my expectation. so the first thing is simply to tell them that from now on I expect them to divide the work between them (I also say that if they find it difficult I’m willing to help) Teach them how to do it – When I ask for someone to do something new I like to make sure they know how to do it. In this case I would explain how I think tasks should be divided. I give my tips and advises on how to balance the work, how to make sure everything is done as fast as possible and what I would expect to see. I found that visualizing a problem goes a long way in solving it. and in this case I devise a way to put all the work “tasks” into a single visible place. I found that a physical task board is usually does a very good job at this. so that’s my preferred technique, but an excel list cam do just as well. As a lead, I do make sure to track how the team is doing (at least when at start). So a mechanism for tracking this should also be decided on. Again a Task Board  does a great job at this, but a shared excel task list with the people names also works just as well. And last, like any new skill, mistakes will be made  along the way. That’s Ok. Mistakes are what people learn from, so don’t try to prevent them, make sure the damage isn’t too big, and that people learn from them. --- title: "One Day Software Team Leader Skills Class - Lund, Sweden" url: "https://www.5whys.com/articles/one-day-software-team-leader-skills-class-lund-sweden.md" canonical: "https://www.5whys.com/articles/one-day-software-team-leader-skills-class-lund-sweden.html" published: "2011-09-02T10:52:53.083000+00:00" updated: "2011-09-05T10:14:13.973000+00:00" tags: [] author: "Roy Osherove" description: "FYI - This course has been canceled. I will be doing a one day class for new and experienced software team leaders about important skills you need to \"make\" it as a team leader. In the class you will learn how to identify and act according…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # One Day Software Team Leader Skills Class - Lund, Sweden **FYI - This course has been canceled.** I will be doing a one day class for new and experienced software team leaders about important skills you need to "make" it as a team leader. In the class you will learn how to identify and act according to the three maturity phases of a software team. how to understand and influence behaviors of team members and upper management, and more. You can find more details and purchase a ticket here. --- title: "A week in Stockholm - Open for consulting or training" url: "https://www.5whys.com/articles/a-week-in-stockholm-open-for-consulting-or-training.md" canonical: "https://www.5whys.com/articles/a-week-in-stockholm-open-for-consulting-or-training.html" published: "2011-09-01T14:22:11.049000+00:00" updated: "2011-09-01T15:13:59.123000+00:00" tags: [] author: "Roy Osherove" description: "I'll be spending the week of September 12-16 in Stockholm, Sweden. While i'm there I will be doing consulting gigs and possibly training. If you're interested in me coming to your company for a day or two and teach Test Driven Development…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A week in Stockholm - Open for consulting or training I'll be spending the week of **September 12-16** in Stockholm, Sweden. While i'm there I will be doing consulting gigs and possibly training. If you're interested in me coming to your company for a day or two and [teach Test Driven Development](http://osherove.com/tdd-training/) or [Team Leadership skills](http://osherove.com/leadership-course/), please [contact me as soon as possible](http://osherove.com/request-more-info/) so we can set up a date. --- title: "Distributed Team Evasion Tactic - Away or Offline" url: "https://www.5whys.com/articles/distributed-team-evasion-tactic-away-or-offline.md" canonical: "https://www.5whys.com/articles/distributed-team-evasion-tactic-away-or-offline.html" published: "2011-08-30T07:12:06.037000+00:00" updated: "2011-08-30T07:12:06.037000+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "Evasion tactics make sure you as a manager don't have to confront employees, or even engage with them. Engaging with your team is part of your job as a manager. It's *supposed* to be difficult. That's why you get paid more! Today's tactic…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Distributed Team Evasion Tactic - Away or Offline Evasion tactics make sure you as a manager don't have to confront employees, or even engage with them. Engaging with your team is part of your job as a manager. It's \*supposed\* to be difficult. That's why you get paid more! Today's tactic is much more likely to happen on a distributed team. ## Keep status on Skype as forced "away" or "offline" How to realize you are doing it: When you talk to people on Skype, your status remains away or offline even while chatting. ### Explanation: "Away" managers won't commit to actually talking to anyone on the team (if it's a remote team), unless they choose to do it. it's  a way to be unavailable to input, only to output. ### Possible reasons: As a team leader you may not feel that you are working as hard as you can, or that you are not available as much as you want to be for your team, and you are using 'away' statues to mask the actual times when you are actually away. ### How it makes your team feel: Your team feel as if you're either always watching, or alternatively never there. at some point they will stop caring, and just expect the random "act of god" in which you descend from the Skype heavens to instill your wisdom, but only when you magically choose to appear. ### Signs that your team is bothered by it: might include that people remark offhanded that 'you always seem to be away' or 'oh i thought you were away'. People will usually be afraid to tell you that they dislike this behavior from you. ### Problems it can cause: The team might start exhibiting the same behavior - always being away while still talking to you, so you start get the feeling that they are not there as well. Another possibility is that the team will trust you less to "be there" for them when they need you. Over time you may start to 'reach' for people in odd hours in the hopes that they, much like you, will still be there when you need them, because you won't know if they are just playing hide and seek. this can lead to people feeling like you're "popping out of the woodwork" instead of working in times when everyone else is. ### Resolution: Instill \*known\* working hours with the team, in which people are online. Specifically ask for this behavior to not happen, **and be the first to stop it**. make an example out of your self. ### One more thing: As a more manners-challenged friend of mine said "If you do that you're an asshole and I don't want to work for you". --- title: "Spread your workload" url: "https://www.5whys.com/articles/spread-your-workload.md" canonical: "https://www.5whys.com/articles/spread-your-workload.html" published: "2011-08-27T10:47:31.187000+00:00" updated: "2011-08-27T10:47:31.187000+00:00" tags: ["Anti Patterns", "Guest Post"] author: "Roy Osherove" description: "The following is a guest post by John Hill . You can submit your own guest posts here. John is a .NET Team Leader / Senior Developer for a small Australian CMS software development company. During my many years of experience as a team lead…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Spread your workload > The following is a guest post by [John Hill](http://www.foxhound.com.au/). You can submit your own guest posts here. > > John is a .NET Team Leader / Senior Developer for a small Australian CMS software development company. During my many years of experience as a team lead (albeit only very recently in software development) I have seen other team leads "flog their workhorses". In many team environments, there will be members who are less likely to willingly accept tasks that they don't enjoy - the "complainers" (i.e. they kick up a stink) and those who just get their heads down and complete any task that you give them - the "reliables". I have seen many team leaders, including myself in my early years, naturally give the less fun jobs to the "reliables" as there is less chance of resistance and less chance of conflict with the person they're assigning the task to. In the very short term, this strategy may work in your favour, however there are some repercussions: 1\. The team as a whole may begin to pass work off to the "reliables". 2\. The "reliables" will eventually burn out. 3\. The "reliables" will become frustrated and you will more than likely lose their respect. 4\. Internal conflict will arise as the "reliables" will separate themselves from the "complainers". The solution involves sharing the load equally. If you gave a "boring" task to Member A today, give the "boring" task to Member B tomorrow - regardless of whether they complain. This will build up a culture of every team member being equal. --- title: "Change your mind: your product is your team" url: "https://www.5whys.com/articles/change-your-mind-your-product-is-your-team.md" canonical: "https://www.5whys.com/articles/change-your-mind-your-product-is-your-team.html" published: "2011-08-13T04:05:30.203000+00:00" updated: "2011-08-14T08:31:26.783000+00:00" tags: ["Guest Post"] author: "Roy Osherove" description: "The following is a guest post by Jose Ramón Díaz , Agile coach at Biko. About Jose: My experience has always been in software development in the Java world. I am currently in charge of a development team in Biko2. I am interested in…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Change your mind: your product is your team > The following is a guest post by [Jose Ramón Díaz](http://najaraba.blogspot.com/), Agile coach at Biko. > > About Jose: > > My experience has always been in software development in the Java world. I am currently in charge of a development team in Biko2. > I am interested in promoting the teams to become effective and efficient, while also enjoying their work. I try to do my best as agile coach. You should change your mind about what you are building when you become project manager or team leader (as a boss). Forget your product. Look at your team. Suddenly, you do not have to worry about technical decisions or pretty interfaces. You must realize that the basics of your work has changed. My own inspiration is the mantra "team = product". **The product will be as good as your team is**. The behaviour of your team will determine the qualities of the product. So, your product as project manager is the team. Invest in the team. This will change dramatically your efforts, now redirected to make the team to grow. I first read that idea in the book “[Software for your Head](http://www.amazon.com/gp/product/0201604566/ref=as_li_ss_tl?ie=UTF8&tag=iserializable-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0201604566)”, by Jim and Michelle McCarthy. This was annoying and shocking for me. But now I believe every little effort to improve your team is translated to the products they create. And you must be ready for that. Your behavior must change to let your people do their best. If you have been assigned as project manager recently, start studying again! (little advice: read, and read a lot!) You have no more technological related problems. I love Cockburn´s cite: “If you do NOT know anything about human behaviour, you know very little about software development”. So, stop and think about your previous work, do you really know something about people and their behaviours? Start changing your focus. From product to team. From technology to people. Pay attention to people and identify the phase in which your team is and what it needs to evolve. Find the right leadership at the time, but admit you can not get to become the leader, but only that person who turns mediocre teams into great teams, a great manager. If you keep thinking about building products, these will be only as good as you were able to create managing and controlling your team. However, if you facilitate the emergence of the full potential of your team, the product will be enhanced and enriched by many people and their synergies. --- title: "The Chaos Addiction" url: "https://www.5whys.com/articles/the-chaos-addiction.md" canonical: "https://www.5whys.com/articles/the-chaos-addiction.html" published: "2011-08-07T22:18:00.006000+00:00" updated: "2011-08-10T17:33:59.563000+00:00" tags: ["Anti Patterns", "First Steps during chaos"] author: "Roy Osherove" description: "I'm convinced more than ever these days, that being in chaos is a self perpetuating state of being, unless drastic measures are taken. It is a pattern of addiction , in that it reinforces the bad habits that lead to even more chaos (less…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Chaos Addiction I'm convinced more than ever these days, that [being in chaos](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) is a self perpetuating state of being, unless drastic measures are taken. It is a pattern of _addiction_, in that it reinforces the bad habits that lead to even more chaos (less time to learn), while reinforcing the belief that those bad habits are the only way to solve problems in the short term, wihtout a long term view. Jerry Weinberg's book "[Managing yourself and others"](http://www.smashwords.com/books/view/39685) describes this type of "addiction" nicely. Below is a paraphrasing of that idea. A quality addiction cycle goes like this: ## There is an inner - reinforcing loop: 1. Team/Leader are pressured to fix an influx of problems under heavy time pressures 2. Team/Leader decide to "skip" some important measures that will provide quality control (testing, reviewing) 3. Team releases product 4. TeamLeader get a reinforced feeling that getting rid of quality measures was a good idea (and over time, that those practices just take time they don't have) 5. The next time the same scenario shows up, they are more likely to re-create the same solution ### There is an outer - reinforcing loop: 1. Because of the team's decisions to let go of quality practices (technical debt), quality goes down 2. amount of bugs or customer complaints rises 3. amount of pressure to fix said bugs complaints, in the shortest time, rises 4. The team is now under even more pressure to get into the inner loop of death - letting go of quality practices to "put out the fire" # What about the chaos cycle? Reminder: Chaos is about the team not having enough time to learn (slack). ## Inner loop: 1. Team has tasks to do and is under pressure to complete them in a schedule that'e either impossible, or close to that 2. Team doesn't complete tasks on time, or barely on time 3. Team sees that the way they are currently working seems to have "made good" on their promise to fix X amount of work 4. Team is reinforcing its belief that there is no time to learn, or they won't make their commitments ### Outer loop: 1. Team commits to X tasks and does no learning 2. The lack of learning means that the team is not learning new ways to optimize or improve their work or quality, so their output stays the same, or gets worse based on the changing conditions 3. The pressure on the team remains the same, or worse, based on their 'standard' or worse, performance. 4. Team believes even more that learning time is the last thing they can afford. Breaking the chaos addiction is also very scary for a leader - they have to take a personal risk and remove promises from their backboard so they can make time to learn for the team. they have to actually take a stand for the team's way of work, and to promise that the new way of work with be better for the organization. The team leader may lean back into chaos, because It's much more comfortable to just say nothing and continue the cycle of comfortable, whiney, addiction to over-work. It's much harder to break this cycle because the belief is that learning time is not possible, and the risk of 'losing face' in front of management is high, when fighting for learning time. it is a sort of placating to upper management - the team blames itself  for even needing time to learn or for not doing a good enough job to have time to learn after the work is done. instead of insisting that it is a blessing to have a learning team, for everyone's sake.  It is almost always an issue of personal self-worth on the side of the team leader, who may be silently disagreeing with management, and feeling powerless, when in fact they are being paid to do those tough things like taking a stand for breaking this cycle of addiction. > A team cannot become truly self organizing without learning. learning takes time, and to get time, you have to make time for your team by breaking out of chaos. --- title: "Video: How to manage a person who is always late to a standup meeting" url: "https://www.5whys.com/articles/video-how-to-manage-a-person-who-is-always-late-to-a-standup.md" canonical: "https://www.5whys.com/articles/video-how-to-manage-a-person-who-is-always-late-to-a-standup.html" published: "2011-07-30T13:39:36+00:00" updated: "2011-07-30T13:45:29.817000+00:00" tags: ["First Steps during chaos", "From the mailing list", "Learning Phase", "Self-Leading Phase", "Video"] author: "Roy Osherove" description: "I came across this common question on LinkedIn: How do you manage a person who is always late to a standup meeting? My thoughts on it are below, and the answer of course, depends on the three stages of software team maturity . I also…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: How to manage a person who is always late to a standup meeting I came across this common question on LinkedIn: [How do you manage a person who is always late to a standup meeting?](http://www.linkedin.com/groupItem?view=&srchtype=discussedNews&gid=52030&item=47774148&type=member&trk=eml-anet_dig-b_mc-ttl-cn) My thoughts on it are below, and the answer of course, depends on [the three stages of software team maturity](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html).  I also forgot to mention that in the chaos phase you need to discover whether the meeting time is an actual constraint for that person and might change it to fit. but the point is to not waste time in a team meeting when you're in chaos, but to make decisions fast enough so the team doesn't get left behind even more.  [![](https://www.5whys.com/img/video/youtube-oDluD9Ls19U.jpg)Watch on YouTube](https://www.youtube.com/watch?v=oDluD9Ls19U) 5whys: How to manage a person who is always late to the meeting --- title: "Video: Mistake #1 - Not Understanding Team Maturity" url: "https://www.5whys.com/articles/video-mistake-1-not-understanding-team-maturity.md" canonical: "https://www.5whys.com/articles/video-mistake-1-not-understanding-team-maturity.html" published: "2011-07-28T18:02:12+00:00" updated: "2011-07-28T18:07:00.323000+00:00" tags: ["First Steps during chaos", "Meta", "Video"] author: "Roy Osherove" description: "I recently posted my slides about ten mistakes team leaders make. I thought I'd take some time for each mistake and do a short video on it. Here's the first one: Watch on YouTube Team Leader Mistakes #1 - Not Understanding Team Maturity…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: Mistake \#1 - Not Understanding Team Maturity I recently posted my slides about ten mistakes team leaders make. I thought I'd take some time for each mistake and do a short video on it. Here's the first one: [![](https://www.5whys.com/img/video/youtube-7mVslT6kmAY.jpg)Watch on YouTube](https://www.youtube.com/watch?v=7mVslT6kmAY) Team Leader Mistakes #1 - Not Understanding Team Maturity Also, I'm hosting the 2nd noerwigian Team Leader Skills class in Oslo this August. [Click here to learn more.](http://put.no/kurskalenderoversikt.aspx?id=938475) --- title: "Oslo Lead Better Workshop - August 8-9 2011" url: "https://www.5whys.com/articles/oslo-lead-better-workshop-august-8-9-2011.md" canonical: "https://www.5whys.com/articles/oslo-lead-better-workshop-august-8-9-2011.html" published: "2011-07-24T07:48:40.187000+00:00" updated: "2011-07-24T07:48:40.187000+00:00" tags: ["Courses"] author: "Roy Osherove" description: "This August, I will be running my two day workshop in Oslo , for new and experienced team leaders about elastic leadership of software teams - called \"Lead Better\". You can register here. Feel free to contact me directly with ANY questions…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Oslo Lead Better Workshop - August 8-9 2011 This August, I will be running [my two day workshop in Oslo](http://put.no/kurskalenderoversikt.aspx?id=938475), for new and experienced team leaders about elastic leadership of software teams - called "Lead Better". [You can register here.](http://put.no/kurskalenderoversikt.aspx?id=938475) Feel free to [contact me directly with ANY questions](http://osherove.com/request-more-info/) about this course and others. --- **Why should you care about this course?** _A good team leader is key to Agile success. Why?_ Have you ever come across these situations? - You try to convince your team that a specific practice is a good idea, but no one really adopts it, and you don’t know what to do about it. - You are afraid of losing friendships just because you’ve become manager to the same people you’ve worked with as a team member up until now. - Your team doesn’t have time to do anything but putting out fires and you feel helpless about it. - You have a problematic team member and you feel like you’ve tried everything to solve this behavior and failed. - You are being expected to perform impossible feats with impossible deadlines, and can’t do anything to stop it. - You think that your team will never be able to be one of those “extreme programming” teams you keep writing about. - You wonder “if only I had better people in my team I’d…” --- VIDEO: I recently gave a talk on Team Leadership in the age of Agile: [Here's the video.](http://www.infoq.com/presentations/Team-Leadership-in-the-Age-of-Internet) --- **You are not alone** in these thoughts. We’ve all been there. A lucky few of us had good mentors to teach us what to do in these situations, but most of us just try our best and hope for miracles. Keep our heads down and pray nothing bad happens until the next person comes along. In this course you’ll learn the basic trade secrets for managers and coaches - how to lead teams to greatness, with a twist - this course is especially designed for _software team leaders_ - and deals with specific people issues in this highly technical world. Hopefully, by the end of this course you’ll feel not only empowered to change things for the better, but you’ll also be equipped with a set of tools and techniques to help you think through and overcome tough people issues and challenges during your time as a team leader. ****Prerequisites :**** One year’s experience developing software using any language ******Course Outline****** ## **Day 1 – Elastic Leadership Principles** **_Skills being developed:_** - Understanding [the three phases of team maturity](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) - The [chaos-command phase](https://www.5whys.com/articles/category/First+Steps+during+chaos) - Dealing with [impossible tasks, management conditions and people](https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.html) - **Exercises** - The [Learning-commanding coach phase](https://www.5whys.com/articles/category/Learning+Phase) - Managing current work with [task boards and kanban boards](https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.html) - Using [Delegation as a growth tool](https://www.5whys.com/articles/what-are-you-going-to-do-about-it.html) ## **Day 2 – Influence and Team Growing** **_Skills being developed:_** - The [Self Leading-Coach phase](https://www.5whys.com/articles/category/Self-Leading+Phase) - Influencing [the six forces that change people’s behavior](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html) - **Exercises** - Understanding and approaching [the five dysfunctions of teams](https://www.5whys.com/articles/the-five-dysfunctions-of-a-team.html) --- title: "Video: Ten Mistakes Software Team Leaders Make" url: "https://www.5whys.com/articles/video-ten-mistakes-software-team-leaders-make.md" canonical: "https://www.5whys.com/articles/video-ten-mistakes-software-team-leaders-make.html" published: "2011-07-20T07:33:46+00:00" updated: "2014-05-22T21:59:17.013000+00:00" tags: ["Anti Patterns", "First Steps during chaos", "Learning Phase", "Self-Leading Phase", "Video"] author: "Roy Osherove" description: "I've just finished a two day Elastic Leadership course - Essential Skills for software team leaders, in London. I'll be doing another one in November. During that time, I've also spoken at an \"in the brain\" session at SkillsMatter, and you…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: Ten Mistakes Software Team Leaders Make I've just finished a [two day Elastic Leadership course - Essential Skills for software team leaders,](http://osherove.com/leadership-course/) in London. I'll be doing [another one in November.](http://londonleader.eventbrite.com/) During that time, I've also spoken at an "in the brain" session at SkillsMatter, > [and you can find the video here](http://skillsmatter.com/podcast/agile-scrum/ten-mistakes). The talk is about ten common mistakes team leaders make, and it also includes 45 minutes of Q & A. ## Here are the slides: **[10 mistakes software team leaders make](http://www.slideshare.net/royosherove/10-mistakes-software-team-leaders-make)** [View the slides on SlideShare](https://www.slideshare.net/royosherove) View more [presentations](http://www.slideshare.net/) from [royosherove](http://www.slideshare.net/royosherove) ## Those mistakes are: 1. Do not [recognize team maturity](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) 2. Fear of [delegation](https://www.5whys.com/articles/what-are-you-going-to-do-about-it.html) 3. Fear of [engagement](https://www.5whys.com/articles/the-five-dysfunctions-of-a-team.html) 4. Placating 5. Being Irrelevant 6. Being super-reasonable 7. Blaming 8. Ignoring [6 forces that influence behavior](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html) 9. Fear of assertiveness 10. Help spread non-commitment (by not using [language of commitment](https://www.5whys.com/articles/my-team-keeps-breaking-their-promises-what-can-i-do.html)) --- title: "Video: Team Leadership in the Age of Agile" url: "https://www.5whys.com/articles/video-team-leadership-in-the-age-of-agile.md" canonical: "https://www.5whys.com/articles/video-team-leadership-in-the-age-of-agile.html" published: "2011-07-08T22:06:01.207000+00:00" updated: "2011-07-08T22:07:39.088000+00:00" tags: ["Anti Patterns", "Meta", "Video"] author: "Roy Osherove" description: "during QCon 2011 in London, I gave a talk about the new qualities that team leaders need to make agile succeed. It's a very small fraction of what I cover and coach during my upcoming course. See the full video here some of the things I…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: Team Leadership in the Age of Agile during QCon 2011 in London, I gave a talk about the new qualities that team leaders need to make agile succeed. It's a very small fraction of what I cover and coach [during my upcoming course.](http://londonleadership.eventbrite.com/) > **[See the full video here](http://www.infoq.com/presentations/Team-Leadership-in-the-Age-of-Internet)** some of the things I cover include top mistakes that team leaders do with teams. most of these are closely related to [elastic leadership principles](https://www.5whys.com/articles/elastic-leadership.html) - changing the leadership type based on the team's current maturity. --- title: "The Fear Of Failure And What To Do About It" url: "https://www.5whys.com/articles/the-fear-of-failure-and-what-to-do-about-it.md" canonical: "https://www.5whys.com/articles/the-fear-of-failure-and-what-to-do-about-it.html" published: "2011-06-30T09:06:46+00:00" updated: "2011-06-30T09:19:43.085000+00:00" tags: ["Anti Patterns", "First Steps during chaos", "Growing People", "Self Improvement"] author: "Roy Osherove" description: "I'm embedding this very inspiring video of Milton Glaser talking about The Fear Of Failure, because it has so much to do with your own personal development as a leader in your organization. Most team leaders are really leaders because they…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Fear Of Failure And What To Do About It I'm embedding this very inspiring video of Milton Glaser talking about The Fear Of Failure, because it has so much to do with your own personal development as a leader in your organization. Most team leaders are really leaders because they are very much afraid of failure. They are afraid of what would happen when they take the steps they "dream" about doing for many understandable reasons.  Please watch this video with me. [![](https://www.5whys.com/img/video/vimeo-23285699.jpg)Watch on Vimeo](https://vimeo.com/23285699) Milton Glaser – on the fear of failure. You can find [more of these videos here.](http://www.fastcodesign.com/1663855/five-design-demigods-on-overcoming-failure-video) While Milton talks towards designers, who usually need to take risks alone in the beginning, this very much applies to your as a team leader. Your job now is to drive things the way you believe they should be driven. that's a risk, because the second you move a bit away from the norm in your workplace you're going to be tackled with people not liking what you do, and sometimes expressing it very clearly. You will be on this road pretty much alone in the beginning, charting your own way as a leader. It doesn't mean you shouldn't consult with others, but at the end of the day, leading the team to be more mature than it is can take some personal risk taking. for example, shedding off some commitments so that the team has time to learn, beginning real conversation about reality with management, [pushing people to burst out of their bubble](https://www.5whys.com/articles/burst-your-teams-bubble-stop-protecting-them-from-the-surrou.html) - these are all personal risks (that you lose a friend, that you fail at what you do, that people will laugh at you). Embrace failure, and realize that as long as you keep learning from your mistakes, you can do very little wrong. #### Minimizing the risk with experiments one way to minimize those risks is by declaring "experiments" that last a week or a month. after that you decide what to do next. that way you also limit the risk exposure, but you also get to discover "what if"s that you'd never be able to otherwise. Sometimes doing is the only way of learning. and getting out of the comfort zone for a "timed experiment" is much easier to convince people of than saying "we're doing it this way now". I'd also venture to say that using an "experiment" is only a temporary technique you should use. at some point you _will_ have to start making permanent changes, at your own risk. Keep that in mind, and watch how many times you try to avoid risk by saying "it's temporary". You will need to decide when it's time to burst your self out of that bubble as well when the time comes. --- title: "Video: The Mistake at the heart of Agile - Michael Feathers, NDC 2011" url: "https://www.5whys.com/articles/video-the-mistake-at-the-heart-of-agile-michael-feathers-ndc.md" canonical: "https://www.5whys.com/articles/video-the-mistake-at-the-heart-of-agile-michael-feathers-ndc.html" published: "2011-06-17T22:31:19+00:00" updated: "2011-06-17T22:34:10.086000+00:00" tags: ["Conference", "Growing People", "Learning Phase", "Video"] author: "Roy Osherove" description: "A video was embedded here. Its host (Viddler) has shut down, so it is no longer available. I think this video, recorded at NDC 2011 , goes well with this post I just finished writing , actually, about bursting your team's bubble, and…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: The Mistake at the heart of Agile - Michael Feathers, NDC 2011 A video was embedded here. Its host (Viddler) has shut down, so it is no longer available. I think this video, recorded at [NDC 2011](http://ndc2011.no/), goes well [with this post I just finished writing](https://www.5whys.com/articles/burst-your-teams-bubble-stop-protecting-them-from-the-surrou.html), actually, about bursting your team's bubble, and getting them out of their comfort zone. --- title: "Burst your team's bubble - stop protecting them from the surrounding organization" url: "https://www.5whys.com/articles/burst-your-teams-bubble-stop-protecting-them-from-the-surrou.md" canonical: "https://www.5whys.com/articles/burst-your-teams-bubble-stop-protecting-them-from-the-surrou.html" published: "2011-06-17T21:54:16.427000+00:00" updated: "2011-06-17T22:14:09.343000+00:00" tags: ["Learning Phase"] author: "Roy Osherove" description: "During the learning phase of your team , one of the nicest things you can do for your team members, is to stop protecting them from the surrounding organization. It was a great thing to do during the chaos phase, when you all needed time…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Burst your team's bubble - stop protecting them from the surrounding organization During [the learning phase of your team](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html), one of the nicest things you can do for your team members, is to stop protecting them from the surrounding organization. It was a great thing to do during the chaos phase, when you all needed time to put out all the fires. But now, that you have some time to learn new things as a team, that learning can be triggered by letting the organization "leak" into your team. You can start doing it incrementally at first. It doesn't have to be a burst, but you can start with allowing some of the following to occur (under careful watch): - **Allow the sales folks to walk into the team's room and ask questions or make demands.** Your team will start feeling the pressure from within the organization and start learning how to deal with it, or how to face reality of what people in the organization feel about their performance as a team. They will, with your help, develop new skills based on this (such as talking to non technical people) - **Allow the marketing folks to ask questions about upcoming features while the team is working**. Allow them to push for closer schedules. - **Don't bridge a team member's need for something \*from\* the organization** (such as getting better chairs, or a new screen). Instead, ask them what they intend to do about it. See what happens. Back them up with any action they'd like to take (talk to the CEO? Talk to the equipment manager?). Grow their skills in navigating the network that is your organization. Help them realize that they don't need you (besides your backing), to achieve things they need. - **Get the team to do first level support**, and help them develop the skill of creating features and fixing usability problems based on customer talks. facing reality is important for a learning team, and staying in a comfortable iteration where the team is fully protected is nice, but no one is learning from it. > They will not thank you. They will, sometimes, despise you for "breaking" your promise to be their leader and protect them. YOU will feel like you are betraying them a bit as well. That's ok. That's part of YOUR growth path. you're getting out of your own comfort zone (of how to lead a team), by learning how to get your team out of THEIR comfort zone. Explain the reasoning behind it, and follow up with whatever learning they will need to accomplish their newfound tasks. By BACKING them,  I also mean that you are willing to remove some of the development time in support of learning time. A developer trying ot get a new screen might need a half hour or more off, depending on how large your organization is, after all. Here's a simple rule to follow during the learning phase: > If everyone is feeling comfortable in what they are doing, you are not doing your job. Growth comes from doing things you're NOT good at, you're NOT comfortable with. It's that feeling you get when learning a new programming language, a new IDE, or switching from windows to Linux. More about learning, in future posts. --- title: "The Clean Coder" url: "https://www.5whys.com/articles/the-clean-coder.md" canonical: "https://www.5whys.com/articles/the-clean-coder.html" published: "2011-06-17T21:24:40+00:00" updated: "2011-06-17T21:31:04.877000+00:00" tags: ["Link Love"] author: "Roy Osherove" description: "Robert Martin (uncle bob to many), released a new book - The Clean Coder : I had the honor of contributing a section to the book, called \"A language of commitment\", and it's based, in many ways, about this blog post, and a tough lesson…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Clean Coder Robert Martin (uncle bob to many), released a new book - [The Clean Coder](http://www.amazon.com/gp/product/B0050JLC9Y/ref=as_li_ss_il?ie=UTF8&tag=iserializable-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=B0050JLC9Y): I had the honor of contributing a section to the book, called "A language of commitment", and it's based, in many ways, about [this blog post, and a tough lesson that I learned the hard way](https://www.5whys.com/articles/my-team-keeps-breaking-their-promises-what-can-i-do.html). I'd recommend this book highly, becuase it talks about things that no one really talks about (ever since "the pragmatic programmer, which was close) - the human things, the 'character' that you commit to as a good developer.  many of these things I've had to learn the hard way. No doubt that many will read it and STILL want to try things the hard way, but at least they'll be a little more prepared for things to come, and what expectations are from them, and what they should expect from themselves. Uncle bob talks like, well, a good uncle, beating some sense into you as a developer. That's almost always a good thing. More perspective - more self-investigations of why we do the things we do - that can never be a bad thing. --- title: "Yelling at team members" url: "https://www.5whys.com/articles/yelling-at-team-members.md" canonical: "https://www.5whys.com/articles/yelling-at-team-members.html" published: "2011-06-17T21:08:02.095000+00:00" updated: "2011-06-17T21:08:02.095000+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "This is perhaps one of the worst things a team leader could ever do with a team. Multiply that by 10 if that yelling is done in public. It does not matter *how much* frustration you feel. It does not matter *how* much that team member…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Yelling at team members This is perhaps one of the worst things a team leader could ever do with a team. Multiply that by 10 if that yelling is done in public. It does not matter \*how much\* frustration you feel. It does not matter \*how\* much that team member might actually deserve it. > Do not yell at your team members. ### By yelling, what happens is: - You remove any good will by that team member to ever want to work with you again - You personally hurt their feelings (a little or a lot, depending on their character, but you do) - If you're not hurting them, they view you as weak and unable to control the way you behave in public or in person - You are NOT solving the problem. you are just venting. - They are not really listening to you. they are looking at you, shouting. ### "What can i do if I just can't control it?" That is the weakest most pathetic argument I've heard people say. You \*have\* to control it, and it's not a matter of yes or no. The only time you get to be a yelling-at-your-team-members team leader who doesn't get kicked out after a few months is if you're the owner, or you're part of the owner's family. Get a hobby that involves punching something. Or get a different type of job. ### Take the following steps every time you find yourself yelling at someone: - STOP yelling immediately, and excuse yourself  - "I'll be back in a few minutes" - When you come back after taking a breather, APOLOGIZE to the person you just yelled at, in private. - Don't talk to them about the subject you just yelled at them for. Wait ONE FULL DAY. - The next day, make a short list of the points you wanted to make, in a calm mood. Use the word "I" to describe what you feel - "I feel like you just don't care what I ask you to do" - That's a start. - When you're not in a more calm type of conversation, you're on a better way than you were. --- title: "London Team Leader Course this July" url: "https://www.5whys.com/articles/london-team-leader-course-this-july.md" canonical: "https://www.5whys.com/articles/london-team-leader-course-this-july.html" published: "2011-06-17T19:23:12+00:00" updated: "2011-06-17T20:42:33.077000+00:00" tags: ["Courses", "course"] author: "Roy Osherove" description: "I'll be in London next month, teaching my new two day \"Lead Better\" course - essential skills for team leaders. I hope you'll join me! Why should you care about this course? Have you ever come across these situations? You try to convince…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # London Team Leader Course this July I'll be in London next month, [teaching my new two day "Lead Better" course - essential skills for team leaders.](http://londonleadership.eventbrite.com/) I hope you'll join me! ### Why should you care about this course?  Have you ever come across these situations? - You try to convince your team that a specific practice is a good idea, but no one really adopts it, and you don’t know what to do about it. - You are afraid of losing friendships just because you’ve become manager to the same people you’ve worked with as a team member up until now. - Your team doesn’t have time to do anything but putting out fires and you feel helpless about it. - You have a problematic team member and you feel like you’ve tried everything to solve this behavior and failed. - You are being expected to perform impossible feats with impossible deadlines, and can’t do anything to stop it. - You think that your team will never be able to be one of those “extreme programming” teams you keep writing about. - You wonder “if only I had better people in my team I’d…” You are not alone in these thoughts. We’ve all been there. A lucky few of us had good mentors to teach us what to do in these situations, but most of us just try our best and hope for miracles. Keep our heads down and pray nothing bad happens until the next person comes along. In this course you’ll learn the basic trade secrets for managers and coaches - how to lead teams to greatness, with a twist - this course is especially designed for software team leaders - and deals with specific people issues in this highly technical world.   Hopefully, by the end of this course you’ll feel not only empowered to change things for the better, but you’ll also be equipped with a set of tools and techniques to help you think through and overcome tough people issues and challenges during your time as a team leader. > This course is based on my experiences and this blog #### Prerequisites : One year’s experience developing software using any language  Course Outline ## Day 1 – Elastic Leadership Principles Skills being developed: - Understanding [the three phases of team maturity](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) - The [chaos-command phase](https://www.5whys.com/articles/category/First+Steps+during+chaos) - Dealing with [impossible tasks, management conditions and people](https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.html) - Exercises - The [Learning-commanding coach phase](https://www.5whys.com/articles/category/Learning+Phase) - Managing current work with [task boards and kanban boards](https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.html) - Using [Delegation as a growth tool](https://www.5whys.com/articles/what-are-you-going-to-do-about-it.html) ## Day 2 – Influence and Team Growing Skills being developed: - The [Self Leading-Coach phase](https://www.5whys.com/articles/category/Self-Leading+Phase) - Influencing [the six forces that change people’s behavior](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html) - Exercises  - Understanding and approaching [the five dysfunctions of teams](https://www.5whys.com/articles/the-five-dysfunctions-of-a-team.html) --- title: "What to do if some people in the team just don't want to take a task?" url: "https://www.5whys.com/articles/what-to-do-if-some-people-in-the-team-just-dont-want-to-take.md" canonical: "https://www.5whys.com/articles/what-to-do-if-some-people-in-the-team-just-dont-want-to-take.html" published: "2011-06-06T17:53:07.004000+00:00" updated: "2011-06-06T17:53:07.004000+00:00" tags: ["First Steps during chaos", "Growing People", "Learning Phase", "Self-Leading Phase", "scrum"] author: "Roy Osherove" description: "Recently I found this question on LinkedIn: We just started using Scrum in our organization and today is the last day of our first sprint. In the beginning, after the second part of the sprint planning the tasks were identified and…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # What to do if some people in the team just don't want to take a task? Recently I found this question on LinkedIn: > We just started using **Scrum** in our organization and today is the last day of our first sprint. In the beginning, after the second part of the sprint planning the tasks were identified and everyone had to tell what task will be working on. > > But two members of the team just sat down on their desk and do nothing. > > I've been waiting for an hour and after that I just assigned some tasks to them. > > I'm afraid that this will happen again in the next sprint and the result will be that the team will just wait for me to tell every person what task to do. It really depends on the what stage your team is in. **In the [chaotic stage](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)**, you don't have time to wait around for people to realize that some team members are not taking responsibility. Talk to each of them personally and see if there is a good reason for them not to take that task . Either bend the process so that all team members are now able to take tasks, or get those out of order back into the team guidelines, until the chaotic stage is over. In chaos you can't afford to have people not on the same track as the others. **In the [learning stage](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)**, ask the people what they are going to do about not being part of the task taking process. ask them to fix it themselves, and make sure they commit to what they are promising. follow up weekly or even daily. "grow" them to this habit, or "grow" yourself to realize maybe that habit isn't right for your current team. Sounds weird, but sometimes you need to remember to fit the process to the team, not the other way around. **In the [self organizing stage](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)**, create constraints or situations for the team that will force them to face the choice of taking tasks on their own or not. For example, you can give requirements that no team member has specific specialization on, or the opposite. see what happens. you an also introduce people from other teams into the team, who might have a problem with this behavior and will speak up to the offending team mates on their own. The point is, at the self leading stage, you don't tell people how to do something. you just give them the boundaries in which to achieve it. --- title: "A good leader won't need to ask" url: "https://www.5whys.com/articles/a-good-leader-wont-need-to-ask.md" canonical: "https://www.5whys.com/articles/a-good-leader-wont-need-to-ask.html" published: "2011-06-06T17:43:20.042000+00:00" updated: "2011-06-06T17:43:20.042000+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "A good team leader would not need to ask you about the good things you've done in the past year. They should be attentive enough to your personal progress, and helping you shape your learning, that they might actually know about more…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A good leader won't need to ask A good team leader would not need to ask you about the good things you've done in the past year. They should be attentive enough to your personal progress, and helping you shape your learning, that they might actually know about more things you did great this year than you. If you are that team leader, and you need to ask, it may be good to take 30 minutes of personal time, and review within yourself, what you think that person has done good this year. If you can't, try the following approach: Ask colleagues of that person about one good thing they have seen him do this year (or month). compile a list of five such things. Now, compile a list of actions that you **will** take,   in the coming month, and year, to make sure this never happens again. --- title: "Video: Elastic Leadership in software - InfoQ interview" url: "https://www.5whys.com/articles/video-elastic-leadership-in-software-infoq-interview.md" canonical: "https://www.5whys.com/articles/video-elastic-leadership-in-software-infoq-interview.html" published: "2011-04-15T17:02:01.137000+00:00" updated: "2011-04-15T17:02:01.137000+00:00" tags: ["First Steps during chaos", "Meta", "Video"] author: "Roy Osherove" description: "during the recent QCON London 2011 Conference, Michael Hunger of Infoq interviewed me about what I later started describing as “ Elastic Leadership ” – The team leader changes her leadership style (dictator all the way through to coach)…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: Elastic Leadership in software - InfoQ interview during the recent [QCON London](http://qconlondon.com/) 2011 Conference, [Michael Hunger of Infoq](http://twitter.com/mesirii) interviewed me about what I later started describing as “[Elastic Leadership](https://www.5whys.com/articles/elastic-leadership.html)” – The team leader changes her leadership style (dictator all the way through to coach) based on the [current team stage](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html). [You can see the full video interview here](http://www.infoq.com/interviews/osherove-software-team-leadership). I look a bit tired, but I hope my message was clear. --- title: "12 Behavior Anti Patterns You Will Face As a Software Team Leader" url: "https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.md" canonical: "https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.html" published: "2011-04-11T18:54:37+00:00" updated: "2011-04-11T20:30:10.107000+00:00" tags: ["Anti Patterns", "First Steps during chaos"] author: "Roy Osherove" description: "Most of these, we covered today on the 1st day of my Lead Better course that is taking place in Oslo , with live simulations. The purpose was to see how a team lead deals with these anti patterns when going through team chaos . How the…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 12 Behavior Anti Patterns You Will Face As a Software Team Leader Most of these, we covered today on the 1st day of [my Lead Better course](http://osherove.com/leadership-course/)  that is [taking place in Oslo](http://www.programutvikling.no/kurskalenderoversikt.aspx?id=938475), with live simulations. The purpose was to see how a team lead deals with these anti patterns when going through **[team chaos](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)**. How the team lead might act to these behaviors when the team is in [learning mode](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html), is very different than how I'd expect them to react when in chaos, as was simulated today. ## Team Member Behavior Anti Patterns 1. Extremely shy and afraid to say when he is done with a task. can be idle and helpless if you don't notice. 1. Lead needs to give 'simple rules' to that member so they know exactly what to do in a situation when they are idle. for example _"if you see that you're not doing anything, contact me immediately. We can't afford to have anyone not working right now"_ 2. If it persists, the lead can also offer a more assertive statement such as "_If you want to continue to be part of this team, you'll have to chip into the effort. I know this is hard for you, but I expect you to rise to the challenge and contact me if you don't have anything else to do"_ 2. Lazy, who only does the simplest thing, so he can say he did what he was told 1. Lead can be direct and demand more from that person, or alternatively remove them from the team until they can spend more time understanding why this is happening. 3. Negative - constantly saying things like "I knew that would happen" or "really? that would never work" 1. Same as with lazy 4. Would only work alone. does not like working with other people 1. If they do a great job on their own, and this is usable to the team lead to get out of chaos, there's no harm in letting that person work on their own. 2. If it hurts the team, or continues chaos, see 2.1 5. Is the designated 'architect' and refuses to do anything else 1. See #4 6. Constantly multi tasking on a different task 1. Either reset expectations to mgmt about not doing that other task  2. or remove that person from ccurrent effort and reestimate effort to mgmt 7. Only comfortable working with a specific kind of work (only on the GUI, for example) 1. see #4 8. Working really SLOWLY 1. They might be perfectionists. see # 12 2. If it doesn't hurt the team during chaos, no problem 3. If it does, find work that they CAN do fast, or much better than everyone else 4. If they can't do anything fast, put them on a low risk item, because teaching them to be fast takes time you don't have right now 9. Two team members who argue without any resolution on some technical detail 1. Argument isn't bad, until it's unproductive or bottlenecks the team, so.. 2. Ask them to choose which solution they want o try _first_ 3. Give them a time box to pick one solution to go with 4. Select the solution for them (it's chaos time) 10.  One team member follows another team member blindly, even when it hurts the current effort to get rid of chaos 1. separate them form working on the same task together until chaos is over and you can handle it 2. Ask influencer to stop influencing the influenced until chaos is over 11. Working on personal projects not mandated by anyone (remember, this is during CHAOS!) 1. see #4 12. Perfectionist in a time of chaos - will make sure everything is the right color, when the wheels are not even working.  1. Explain that this is not the time for perfectionism (unless that's what's demanded!), but a time to _ship_ so that chaos can be over fires are put out. 2. Give them simple rules to follow on when to stop:"_if you see yourself matching colors, stop and go fix something that's in the bug's list. do NOT WORK ON COLOR MATCHING in the next 3 days!"_ 3. If that does not work, use authority to ask them to stop (what other anti patterns do _you_ know?) ## Outside disruptions and anti patterns - Requirements keep changing - The lead needs to keep up or set expectations correctly - Impossible Fixed time, cost, and features - what would the team lead do in this case? - Ask which of three factors can be 'moved' - "I either need more time, or more people. If I can't have either, I will need to commit to less features. Here's what we CAN do" - "I need one of your devs for X time for a customer demo" - If it doesn't hurt current team tasks, no problem - If it does, explain that the team will need to re-commit to a different time schedule, or different feature set, if other people cannot be introduced into the team (even if they were, that also takes extra time to get them into the team and project culture) Since today was all about chaos, it was interesting to see how afraid people can be to be a little assertive to get things flowing again. overall, many behaviors which would fit a team in the learning stage, were exhibited for a team in a chaotic stage.  I feel that at least one person in the course has come out of their comfort zone more than a little during this task, and for that, I am very very happy. --- title: "Lead Better - Skills for software team leads, Course next week in Oslo" url: "https://www.5whys.com/articles/lead-better-skills-for-software-team-leads-course-next-week-1.md" canonical: "https://www.5whys.com/articles/lead-better-skills-for-software-team-leads-course-next-week-1.html" published: "2011-04-07T07:25:50+00:00" updated: "2011-04-07T16:59:05.323000+00:00" tags: [] author: "Roy Osherove" description: "I'll be doing my \" Lead Better \" course in Oslo next week . There are 3 places left if you want to join us. If you've ever tried to convince your team to do unit testing or TDD, but failed miserably at getting them to do it. If you think…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Lead Better - Skills for software team leads, Course next week in Oslo I'll be doing my "[Lead Better](http://osherove.com/leadership-course/)" course [in Oslo next week](http://put.no/kurskalenderoversikt.aspx?id=938475). There are 3 places left if you want to join us.  If you've ever tried to convince your team to do unit testing or TDD, but failed miserably at getting them to do it. If you think "no way can **my** team ever be like those highly productive teams I read about", or even if you're just scared enough and not sure what to do next - this course can help you wrap your head around your job as a team leader in software. If you're about to become a team lead, or have just become one, or even if you're an experienced team lead, this course can help master the things no one guides you about: how to drive people, to make a difference, to motivate, and influence the direction and behavior of the people around you. --- title: "Elastic Leadership" url: "https://www.5whys.com/articles/elastic-leadership.md" canonical: "https://www.5whys.com/articles/elastic-leadership.html" published: "2011-04-04T08:09:28+00:00" updated: "2011-11-13T20:09:03.012000+00:00" tags: ["Meta"] author: "Roy Osherove" description: "Elastic leadership is about team context . It is about understanding that you need to lead the team differently, based on which phase you discover the team is in . The phases can change from day to day or week to week. You keep adapting to…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Elastic Leadership - Elastic leadership is about **team context**. It is about understanding that you need to lead the team differently, based on [which phase you discover the team is in](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html). The phases  can change from day to day or week to week. You keep adapting to the new phase, or you _will_  keep them from growing. - Elastic Leadership is about **team transformation**.  You continually [drive and transform the team](https://www.5whys.com/articles/my-team-keeps-breaking-their-promises-what-can-i-do.html) to get better than they are, up to the next phase. From chaos to learning. From learning to self-leading. - Elastic leadership is **personal transformation.** You may find it easy to be a command and control leader, but you'll need to learn how to _teach_ and _delegate_ when the team starts out it's _learning_  phase. In the self leading phase, you'll need to to let go of actually telling people what to do, and only change their surrounding constraints - are you ready for that? can you go a whole day without telling anyone in the team what to do? - Elastic leadership is **personally scary.** you are afraid of losing your friends, you are afraid to fail, and you are afraid of getting out of your own comfort zone to accomplish the various types of leadership for each team phase.  - Elastic leadership is **highly effective** because it looks the current situation straight in the eye, and does something to improve it. Because you assume things change constantly, you are prepared to also _change_ things constantly, and change based upon any needs the team has as they arrive. you do _not close your eyes_ in the face of hardship. instead you embrace it as a learning opportunity. --- title: "Slides: Team Leadership In the Age of Agile" url: "https://www.5whys.com/articles/slides-team-leadership-in-the-age-of-agile.md" canonical: "https://www.5whys.com/articles/slides-team-leadership-in-the-age-of-agile.html" published: "2011-03-19T04:32:55+00:00" updated: "2011-03-19T05:23:14.057000+00:00" tags: ["Conference", "First Steps during chaos", "Growing People", "Slides", "qcon"] author: "Roy Osherove" description: "Here are the slides I've used during my latest talk at QCON london 2011 : In this talk I explore the three maturity stages of a software team, and how a team leader can adjust their leadership type based on the current phase the team is…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Slides: Team Leadership In the Age of Agile Here are the slides I've used during my latest talk at [QCON london](http://qconlondon.com/) 2011 : In this talk I explore the three maturity stages of a software team, and how a team leader can adjust their leadership type based on the current phase the team is in. I also explore common mistakes and techniques team leaders can take to make sure their team gets on the road to craftsmanship and maturity in software development.  Some of the topics covered include stuff I've written about before: - [The three maturity stages](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)  - [What are you going to do about it?](https://www.5whys.com/articles/what-are-you-going-to-do-about-it.html) - [My team keeps breaking their promises](https://www.5whys.com/articles/my-team-keeps-breaking-their-promises-what-can-i-do.html) - [Steps to take on a chaotic team](https://www.5whys.com/articles/category/First+Steps+during+chaos) **[Team leadership in the age of Agile - Roy Osherove](http://www.slideshare.net/royosherove/team-leadership-in-the-age-of-agile-roy-osherove)** [View the slides on SlideShare](https://www.slideshare.net/royosherove/team-leadership-in-the-age-of-agile-roy-osherove) View more [presentations](http://www.slideshare.net/) from [royosherove](http://www.slideshare.net/royosherove) --- title: "What are you going to do about it?" url: "https://www.5whys.com/articles/what-are-you-going-to-do-about-it.md" canonical: "https://www.5whys.com/articles/what-are-you-going-to-do-about-it.html" published: "2011-02-03T13:16:22+00:00" updated: "2011-04-04T22:45:19.793000+00:00" tags: ["Learning Phase"] author: "Roy Osherove" description: "A couple of Days ago I finished the first “Lead Better” course for software team leaders in Oslo. It was the first time I had done this course out of Israel. It was a great feeling to get the following email today from Michal, one of the…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # What are you going to do about it? A couple of Days ago I finished the first [“Lead Better” course for software team leaders](http://www.programutvikling.no/kurskalenderoversikt.aspx?id=938475) in Oslo. It was the first time I had done this course out of Israel. It was a great feeling to get the following email today from Michal, one of the participants of that course. In the email he also refers to [an Integrity and commitment based technique I wrote about](https://www.5whys.com/articles/my-team-keeps-breaking-their-promises-what-can-i-do.html) before, and that we covered deeply during the course. > Hi Roy, >   > I participated in the course “Lead better” 2 days ago in Oslo. >   > I committed to you that I would ask at least one time the magical phrase “What are you gonna do about it” to my teammates and let you know about results. > It happened sooner than I would expect. More, the problem was solved very quickly. >   > On a standup meeting one of my teammates said: > \-          “we need to test the new configuration somehow”. > > \-          So I immediately asked “What are you gonna do about it?” > > \-          ... seconds of consternation... “eeehhhmmmm, I will figure out something” > > \-          “By When?” > > \-          “Today, an hour after scrum meeting, I will reconfigure the platform and let you know about the results.” > > \-          “Great” :) > >   > And it worked! In an hour I got him with a rest of a team discussing details and in another hour, the platform was reconfigured and fully tested! It would never happen so fast if he had not commited to do so :) > Thanks. >   > Michał Wikliński --- title: "3 Quotes about Leadership we should listen to" url: "https://www.5whys.com/articles/3-quotes-about-leadership-we-should-listen-to.md" canonical: "https://www.5whys.com/articles/3-quotes-about-leadership-we-should-listen-to.html" published: "2010-07-18T11:33:32+00:00" updated: "2011-04-04T22:45:38.397000+00:00" tags: ["Link Love", "Meta"] author: "Roy Osherove" description: "Some inspiring words from twitterverse today: @WilnaMurphy: You can never cross the ocean unless you have the courage to lose sight of the shore. - Christopher Columbus. @leadershipcoach: \"If I had asked people what they wanted, they would…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 3 Quotes about Leadership we should listen to Some inspiring words from twitterverse today: > @WilnaMurphy: You can never cross the ocean unless you have the courage to lose sight of the shore. - Christopher Columbus. > @leadershipcoach: "If I had asked people what they wanted, they would have said faster horses." ~Henry Ford > @aycangulez: "There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker --- title: "How to annoy your customer with usability problems" url: "https://www.5whys.com/articles/how-to-annoy-your-customer-with-usability-problems.md" canonical: "https://www.5whys.com/articles/how-to-annoy-your-customer-with-usability-problems.html" published: "2010-07-03T19:10:31.133000+00:00" updated: "2010-07-03T19:10:31.133000+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "You can’t download the software. you have to buy it and ship it on a CD set. You HAVE to buy it with headphones, and you HAVE to pay extra taxes for the shipping. During the installation process, multiple DOS windows pop up (netsh.exe and…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to annoy your customer with usability problems 1. You can’t download the software. you have to buy it and ship it on a CD set. You HAVE to buy it with headphones, and you HAVE to pay extra taxes for the shipping. 2. During the installation process, multiple DOS windows pop up (netsh.exe and others) that look pretty scary to the uninitiated eye. 3. You HAVE to install from the CD. to get around that you will have to MOUNT a cd or crack the program. 4. if the software has an update, it downloads the whole software again in full and you need to go through the whole installation process. 5. You CANNOT copy paste the activation key into the software. you have to type it by hand like an idiot. Which software am I talking about? --- title: "Choice" url: "https://www.5whys.com/articles/choice.md" canonical: "https://www.5whys.com/articles/choice.html" published: "2010-06-23T05:43:47+00:00" updated: "2011-04-04T22:46:09.086000+00:00" tags: ["Video"] author: "Roy Osherove" description: "Maybe all Microsoft developers need to watch this http://66.29.219.11/conery_ndc_talk.mp4" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Choice Maybe all Microsoft developers need to watch this [http://66.29.219.11/conery\_ndc\_talk.mp4](http://66.29.219.11/conery_ndc_talk.mp4) --- title: "Scrum vs. Kanban attitudes" url: "https://www.5whys.com/articles/scrum-vs-kanban-attitudes.md" canonical: "https://www.5whys.com/articles/scrum-vs-kanban-attitudes.html" published: "2010-06-13T03:52:16+00:00" updated: "2011-04-04T22:46:41.022000+00:00" tags: ["Meta", "Self-Leading Phase", "Shu"] author: "Roy Osherove" description: "If you’re wondering about choosing Kanban or Scrum for your team or organization, I’ve found this post to be very enlightening on the differences in attitude and change provocation between the two. I’ve also found that integrating them…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Scrum vs. Kanban attitudes If you’re wondering about choosing Kanban or Scrum for your team or organization, I’ve found [this post to be very enlightening](http://agilemanagement.net/index.php/site/comments/thoughts_on_how_kanban_differs_from_scrum/) on the differences in attitude and change provocation between the two. I’ve also found that integrating them into a single process can be very healthy. --- title: "Exclude a team member – and you’re an idiot" url: "https://www.5whys.com/articles/exclude-a-team-member-and-youre-an-idiot.md" canonical: "https://www.5whys.com/articles/exclude-a-team-member-and-youre-an-idiot.html" published: "2010-05-25T06:55:44+00:00" updated: "2011-04-04T22:41:49.147000+00:00" tags: ["Anti Patterns", "Growing People", "Learning Phase"] author: "Roy Osherove" description: "Don’t exclude people in your team. It’s important that all people in your team are treated as equals and with respect. It may feel like a “duh” moment, but people get offended, deeply if they are left out of the loop. Also, what kind of…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Exclude a team member – and you’re an idiot Don’t exclude people in your team. It’s important that all people in your team are treated as equals and with respect. It may feel like a “duh” moment, but people get offended, _deeply_ if they are left out of the loop. Also, what kind of message does this send to the rest of the team? > “It’s OK – you can ignore or exclude that person too!” If you have a team member that you find it hard to deal with, the last thing you want to do is exclude them from important discussions, team standup meetings, or even lunch. > You will only be making it worse. Be brave and confront your fear of getting that person on board. Whatever your problem is with them, remember it is _your_ problem with them. _you_  have to solve it, because no one will do it magically for you. > No, firing is almost _never_ the right answer. Firing someone means you’ve given up on yourself about growing that person and making them the dev that you _want_  them to be. You get to fire people after at least 4 months of trying. Make that your hard line. Stick by it. In those months – you _will_ make that person part of the team, and teach them (if you need to) how to act as part of the team. You _excluding_ them from the team activities (even one or two every once in a while) just helps them get more entrenched in their belief that they _should_ be different and not act as part of the team. --- title: "Video – Code Leaders and Beautiful Teams" url: "https://www.5whys.com/articles/video-ndash-code-leaders-and-beautiful-teams.md" canonical: "https://www.5whys.com/articles/video-ndash-code-leaders-and-beautiful-teams.html" published: "2010-05-24T12:09:40.603000+00:00" updated: "2010-05-24T15:00:18.567000+00:00" tags: ["Conference", "First Steps during chaos", "Video"] author: "Roy Osherove" description: "Here’s the video of a talk about team leadership and beautiful teams I gave at QCON London this year. You can download the slides for this presentation here. This talk is mainly about the first stage (out of the three team stages ) – where…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video – Code Leaders and Beautiful Teams Here’s the video of a talk about team leadership and beautiful teams I gave at QCON London this year. You can download the slides for this presentation here. This talk is mainly about the first stage (out of [the three team stages](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)) – where the team lead takes charge of guiding and coaching the team. A video was embedded here. Its host (Viddler) has shut down, so it is no longer available. note: the original video for this presentation can be found at: http://www.infoq.com/presentations/Code-Leaders-Beautiful-Teams --- title: "Leadership and the mature team" url: "https://www.5whys.com/articles/leadership-and-the-mature-team.md" canonical: "https://www.5whys.com/articles/leadership-and-the-mature-team.html" published: "2010-05-18T20:24:59+00:00" updated: "2011-04-04T22:47:25.573000+00:00" tags: ["Guest Post", "Ri", "Self-Leading Phase"] author: "Roy Osherove" description: "The following is a guest post by Mike Burrows . Until last year a developer, project leader and development manager in investment banking, Mike is now an IT Director in the energy risk management industry, still leading projects, still…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Leadership and the mature team > The following is a guest post by [Mike Burrows](http://twitter.com/asplake). > > Until last year a developer, project leader and development manager in investment banking, Mike is now an IT Director in the energy risk management industry, still leading projects, still writing code.  His blog ([positiveincline.com](http://positiveincline.com/)) covers open source development and his recent Kanban implementation. Roy's post "[The 3 maturity stages of a software team and how scrum fails to identify them](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html)" \[1\] rings true to much of my experience as a team member, project leader and development manager, but still it touches a red button of mine!  I'm grateful to Roy for his very gracious offer to let me respond to it. My red button?  I worry about the Agile community's recent focus on self-management.  Don't get me wrong: self-management is a good thing, but in its current popular usage it has two problems: 1. It fails to capture satisfactorily the much more powerful concept (borrowed from the study of systems) of self-organization 2. There seems to be a move in the community to minimize the role of leadership Self-organization is at the heart of agile methods, indeed it is the 11th of the 12 principles \[2\] behind the Agile Manifesto.  Definitions vary, but in this context it describes the ability of a system (here the project team) to create for itself ways to increase its own effectiveness.  Looking at the team from the outside, we see "emergence" - new behaviors arising without external intervention.  In the Scrum context this might happen as a result of team retrospectives (the 12th principle) or simply through the individual contributions of team members.  Either way it's important to recognize that some of these new behaviors (i.e innovations) may be highly non-standard. Leadership (whether from within or without) takes the team to places it would otherwise never have reached, perhaps never even have considered.  This can be in terms of the team's internal structures or its external goals, but in the absence of leadership it is a rare thing for a team to take itself out of its comfort zone, to redefine its approach to the outside world, perhaps even to completely reinvent itself. Here's the paradox: good leadership encourages emergence, but the leader must also be ready to take the team out of the ecological niche it has carved out for itself, however effectively.  Yes, self-management is needed at every level (or the leader has time only for management), but we need also the humility to recognize its limits.  Now there is true maturity! \[1\] [/blog/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) \[2\] [http://agilemanifesto.org/principles.html](http://agilemanifesto.org/principles.html) Mike Burrows [http://positiveincline.com](http://positiveincline.com/) [http://twitter.com/asplake](http://twitter.com/asplake) --- title: "The 3 maturity stages of a software team and how scrum fails to identify them" url: "https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.md" canonical: "https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html" published: "2010-05-17T12:36:21+00:00" updated: "2014-05-22T21:44:23.097000+00:00" tags: ["First Steps during chaos", "Growing People", "Ha", "Learning Phase", "Ri", "Self-Leading Phase"] author: "Roy Osherove" description: "Many so called ‘Agile’ teams fail so miserably to deliver for the simple fact that the teams simply are not mature enough to be part of an agile process that requires self managing teams. I’ve learned to recognize three states a team can…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The 3 maturity stages of a software team and how scrum fails to identify them Many so called ‘Agile’ teams fail so miserably to deliver for the simple fact that the teams simply are not _mature_ enough to be part of an agile process that requires self managing teams. I’ve learned to recognize three states a team can be in in terms of maturity - - Chaotic Stage – the state where a team does not posses the skills, motives or ambition to become a mature self managing team. - Mid-Life stage – where a team possess _some_ skills for self management and decision making , and can make _some_ of its own decisions without needing a team lead. - Mature stage – where a team is practically fully self managing and a team leader is mostly a coach rather than a decision maker. The trick most team leaders need to do is to recognize which stage a team is in, and to advance their team to the next stage. ### Most teams are chaotic I would easily say that most teams are chaotic – either in technical lack of knowledge _(‘what’s source control?’)_, lack of motives _(‘I just code X lines of code and try to avoid QA’)_, or lack of ambition _(‘things are fine the way they are’)_ You can’t take a team that doesn’t even do source control, and say “you’re self managing from now on, GO.”  - no one will know what to do, or have any inclination to do it. ### Maturing a team The process of bringing a team to maturity, where a team leader as a dictator is never needed, still lacks a name. I’ve been asking around for possible names for this process. some of them were quite interesting: -   - _**Resetting**_ a Team - _**Rebooting**_ a Team - _**Reorienting**_ a Team - _**Redirecting**_ a Team - Team _**Regrouping**_ - Team _**Rebirth**_ - Team _**Renaissance**_ - Team _**Reframing**_ - Team _**Reincarnation**_ - Team _**Resurrection**_ ### Each stage needs a different kind of team leader Different team lead tactics apply to each stage. For the same reasons Scrum Masters (who are nothing but active coaches) fail to really help immature teams, as do team dictators, who hurt more than they help truly mature, self managing-able teams. ### The chaotic stage needs a strong, dictator like leadership \-- if only to bring some much needed peace and quiet to a team that might be mostly struggling to keep its head above water all day long. A dictator team lead is there in the first stage, to bring the team up to a specific state, where they also have the time and patience to learn new things. The team lead will help put out fires and put the team in a bubble so that decision making becomes easier until the team can make its own decisions. they will start doing code reviews and many of the things this blog advocates for. Many of these same things will be seen with very big question marks on the faces of many agile coaches out there. They fail to realize that a chaotic team still isn’t ready for a coach. it needs a direction, a back wind, and an open road to get going. ### The Mid-Life stage needs a coach-dictator As the team lead feels that the team has reached some “safe shore” – they will move on to the next stage in the team’s life – the learning stage – the stage where a team will learn the skills needed to become self managing, all within a very concrete series of constraints that will slowly open up as the team progresses. For example, the team lead will [insist that code reviews be done on each check in](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html), but will teach the team to do its own code review so that the team lead is no longer the bottleneck, and so that the team learns essential skills for code quality and decision making on what’s an acceptable piece of code. Slowly but surely a team can progress to become fully self managing. At each stage of the team’s life, it learns skills that help it make its own decisions, until, at some point in time, the team lead does not need to make any day to day decisions. The team has all the skills needed to move on to the next stage. **This and the next, are the stages many scrum masters need** in order to achieve anything. Sadly, most teams are not at this stage, and nothing but some good old fashioned dictatorship can help change things for those teams. ### The Mature stage needs a coach A team that can self manage just needs a coach for the personal team members, to _grow_ them, to teach them new skills. They need someone to keep an open eye for interesting things that they may not have noticed, and they can use (not need!) a second look every once in a while if they are facing interesting dilemmas. --- title: "The Bus Factor - Why your ‘best’ developer is your biggest problem" url: "https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.md" canonical: "https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html" published: "2010-05-17T11:51:48+00:00" updated: "2011-04-04T22:42:09.827000+00:00" tags: ["Anti Patterns", "Learning Phase", "Shu"] author: "Roy Osherove" description: "From wikipedia , a “Bus Factor” is: an irreverent measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would need to be incapacitated, as by getting…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Bus Factor - Why your ‘best’ developer is your biggest problem From [wikipedia](http://en.wikipedia.org/wiki/Bus_factor), a “Bus Factor” is: > an irreverent measurement of **concentration of information in a single person, or very few people.** The bus factor is the total number of key developers who would need to be incapacitated, as by getting hit by a bus, to send the project into such disarray that it would not be able to proceed From my personal experience, I'd say that more than 70% of projects suffer from a bus factor of 1. It only takes one specific person in those teams to not be able to be there for the project to halt or slowly die in painful agony as people try to makeup for lost knowledge. ### How do you recognize the bus factor? in your mind, go through each person in your team and ask yourself if the project could go on pretty much as usual if they were fired tomorrow. (fired is important because people who leave in good terms can still play ball and get you through tough stuff they worked on through phone conversations). If you say “no” or even hesitate about the answer, you’ve found the bus factor in your team. ### How do you get rid of the bus factor? Most of the collaboration techniques you’ll find in many agile methodologies like XP try to solve the idea of the bus factor, but you don’t have to be _agile_ to use those techniques. - [Use daily standups](https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.html) to share critical information - program in pairs every once in a while, or at least on key components of the system - [do code reviews](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html) on every piece of code that gets checked in - do weekly half hour or one hour presentations by team members about interesting stuff they did this week - Ask the _bus factor carrier_ to teach someone else from the team to do their work and vice versa. Tell them that next week they _will_ be working alone on that material so they should get ready for that by working together on it. ### The biggest bus factor is you As a team leader, you might just be the biggest bus factor carrier of them all. What happens if you get fired tomorrow? can the team go on without you? Your biggest challenge as a team lead, over a long period of time would be to make yourself dispensable – to make the team mature enough to continue on day to day things without needing you. Removing yourself as a bottleneck is one of the best things you can do for yourself and your team. --- title: "My team keeps breaking their promises. What can I do?" url: "https://www.5whys.com/articles/my-team-keeps-breaking-their-promises-what-can-i-do.md" canonical: "https://www.5whys.com/articles/my-team-keeps-breaking-their-promises-what-can-i-do.html" published: "2010-05-09T07:12:44+00:00" updated: "2011-04-04T22:42:35.787000+00:00" tags: ["Anti Patterns", "Learning Phase", "people patterns"] author: "Roy Osherove" description: "Execution – actually having the team get things done– requires people to : Say what they will do Mean it (be committed) Do it Everyone likes to do #1. Only some do #2. Great teams also do #3. This post is about #2. There is a vast…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # My team keeps breaking their promises. What can I do? _Execution_ – actually having the team get things done– requires people to : 1. Say what they will do  2. Mean it (be committed) 3. Do it Everyone likes to do #1. Only some do #2. Great teams also do #3. This post is about #2. ### There is a vast difference between people being _committed_ to something, and people _saying_ something. For example, you can start looking for words that are not committing to execution: - “_I’ll try_ to get that to you by Monday” - “Someone _should_ get that thing fixed” - “I _hope_ to get to that later” - “I _think_ I can make it” spot these things and see if you can ask people to actually commit to the thing they need to do: - “I _will_ do this by Monday” - “I _commit_ to getting this done by Monday” - “It _will be done_ by Monday” If someone can’t commit to that – that’s good. Maybe they are not sure they can – maybe there is something stopping them. But you won’t know until you can either get them to commit, or get them to say why they cannot commit to it. Also notice how there is a specific end date. Committing to something with an end date make things more real, and also prevents whoever is depending on that thing from bothering the doer. “Is it done yet?” “How about now?” . No need to ask. They committed to do this by Monday. ### Don’t under estimate peer pressure. Doing all this talking in an open daily standup makes the commitment more important. it’s not just you and someone else. now it’s you telling the _whole team_ you will get something. If your team members don’t know how to verbally commit to something, you can teach them. You can actually ask them to say things differently: “Can you say you _will_ do it by date so and so? Is that something you can commit to? Why not? “ ### I can’t commit to something I don’t have control over Of course, the biggest hurdle is that sometimes people really can’t commit to something if they don’t have full control of it. Expecting people to commit to something that depends on other people is less realistic. If that happens, see what things that person _can have control over_. For example, if the task is about getting a bug fix to a client and making sure it’s closed by Monday – the dev might have control over actually sending the email to the client, but they have little control over when the client responds back. In such a case they can commit to _sending the fix to the client_ . ### Failing commitments There should be no such thing is a failed commitments. the moment one sees that they will not make the deadline, they should notify whoever they committed to, that they will no make it in time – this allows the team to see if something can be done to maybe still get that thing in time by reorganizing or changing priorities. A failed commitment means you won’t live up to what you promised and you didn’t notify anyone beforehand that you will not make it in time. that is something that is _fully under your control_ and should not happen. --- title: "Kevlin Henney – 3 things every programmer should know" url: "https://www.5whys.com/articles/kevlin-henney-ndash-3-things-every-programmer-should-know.md" canonical: "https://www.5whys.com/articles/kevlin-henney-ndash-3-things-every-programmer-should-know.html" published: "2010-05-08T17:53:11.117000+00:00" updated: "2010-05-08T17:53:11.117000+00:00" tags: ["Audio", "Conference"] author: "Roy Osherove" description: "During the ACCU 2010 conference in London, I got to get on audio, several of the interesting people who attended and spoke at the conference. One of them was Kevlin Henney . I first got to see him speaking during NDC 2009 in Norway. He was…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Kevlin Henney – 3 things every programmer should know During the ACCU 2010 conference in London, I got to get on audio, several of the interesting people who attended and spoke at the conference. [One of them was Kevlin Henney](http://www.two-sdg.demon.co.uk/curbralan/kevlin.html). I first got to see him speaking during [NDC 2009](http://www.ndc2009.no/) in Norway. He was fascinating in the way he approached sophisticated architecture topics, and his lively and funny way of making everything more understandable. Kevlin is also the main character behind the book [97 things every developer should know](http://oreilly.com/catalog/9780596809485/) and several other books. In this 20 minute audio mp3, we start off with a simple question: what are the three things every programmer should know? (you can watch Kevlin on [this years NDC](http://www.ndc2010.no/) in Norway as well. I highly recommend it! ([he’s also on twitter](http://twitter.com/kevlinhenney)) Download the mp3 – 20 min. --- title: "Interview: Patrick Kua : Agile Coach" url: "https://www.5whys.com/articles/interview-patrick-kua-agile-coach.md" canonical: "https://www.5whys.com/articles/interview-patrick-kua-agile-coach.html" published: "2010-04-21T17:03:58+00:00" updated: "2011-04-04T22:48:31.327000+00:00" tags: ["Audio", "Influence", "Meta"] author: "Roy Osherove" description: "This time, I talk with Patrick Kua , an Agile Coach living in the UK, about various subjects. Among them – the various types of tests, what is “Done”?, The difference between Team Leader and Team Manager and more. Download mp3 – 29 minutes." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Interview: Patrick Kua : Agile Coach This time, [I talk with Patrick Kua](http://www.thekua.com/atwork/), an Agile Coach living in the UK, about various subjects. Among them – the various types of tests, what is “Done”?, The difference between Team Leader and Team Manager and more. Download mp3 – 29 minutes. [![patkua](https://www.5whys.com/img/posts/db66c79b-WindowsLiveWriter-InterviewPatrickKuaAgileCoach_11A20.jpg)](http://www.thekua.com/atwork/) --- title: "Interview: James Bach – The role of the tester" url: "https://www.5whys.com/articles/interview-james-bach-the-role-of-the-tester.md" canonical: "https://www.5whys.com/articles/interview-james-bach-the-role-of-the-tester.html" published: "2010-04-19T22:53:16.515000+00:00" updated: "2020-03-20T22:04:53.331000+00:00" tags: ["Audio"] author: "Roy Osherove" description: "During the ACCU 2010 conference in London (at which I am still stuck due to the ash cloud while writing this), I got to speak with many interesting people, and even recorded some of those conversations. One of the talks I enjoyed the most…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Interview: James Bach – The role of the tester During the [ACCU 2010 conference in London](https://accu.org/index.php/conferences/accu_conference_2010) (at which I am still stuck due to the ash cloud while writing this), I got to speak with many interesting people, and even recorded some of those conversations. One of the talks I enjoyed the most [was with tester James Bach](http://www.satisfice.com/blog/), who gave a thrilling keynote about **the role of the tester** in the organization, and the idea of exploratory testing. In this recording I talk to James about what real testers need to be, how to interview a tester for a job, the idea of exploratory testing, automated _checks_ vs. manual, _sapient  tests_ and many other things. **James Bach Interview - The Role of The Tester**75 min [Audio](https://www.5whys.com/audio/JamesBach.mp3) [Download the audio](https://www.5whys.com/audio/JamesBach.mp3) James has taken a clear leadership role in changing the perceptions many of us have about what testers are and should be, and what testing should be like. ![JamesBachSuperman_thumb](https://www.5whys.com/img/posts/5a8d77eb-WindowsLiveWriter-JamesBachTheroleofthetester_E1A.jpg) _image: QAInsight.net_ James really made me change some of my points of view about what and where we might need testers, and how unit testing and “sapient" testing” go together, and don’t cancel each other out. --- title: "Move-Around kata for team leaders" url: "https://www.5whys.com/articles/move-around-kata-for-team-leaders.md" canonical: "https://www.5whys.com/articles/move-around-kata-for-team-leaders.html" published: "2010-02-14T13:35:42+00:00" updated: "2014-05-22T22:42:25.737000+00:00" tags: ["Learning Phase", "Shu"] author: "Roy Osherove" description: "Here’s an experiment for software team leaders: a set of katas (things you repeat exactly the same way many times). Let’s try to do the following kata once a day: Move-Around Get out of your chair and lock your computer For each team mate…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Move-Around kata for team leaders Here’s an experiment for software team leaders: a set of katas (things you repeat exactly the same way many times). Let’s try to do the following kata once a day: ### Move-Around 1. Get out of your chair and lock your computer 2. For each team mate that sits in your floor: 1. Ask _“can you show me what you are you working on?”_ 2. See at least one technical document they wrote (source code, documentation, build script..) 3. If you think they could have done a better job, challenge them to find a better way to do the job without giving them the whole answer 4. This should take no more than 5-10 minutes per team mate but you can take longer if you like. What other katas do you recommend? --- title: "my worst team leaders" url: "https://www.5whys.com/articles/my-worst-team-leaders.md" canonical: "https://www.5whys.com/articles/my-worst-team-leaders.html" published: "2010-02-14T13:20:08.067000+00:00" updated: "2010-02-14T13:20:08.067000+00:00" tags: ["Anti Patterns"] author: "Roy Osherove" description: "my worst team leaders Didn’t bother to check or see if I was stuck on something Didn’t coach me or teach me to be a better developer or team mate Didn’t earn my trust in their technical skills Didn’t have a problem with anything I was…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # my worst team leaders my worst team leaders - Didn’t bother to check or see if I was stuck on something - Didn’t coach me or teach me to be a better developer or team mate - Didn’t earn my trust in their technical skills - Didn’t have a problem with anything I was doing (good or bad) - Spent most of their time away from me - Smiled a lot, but didn’t say too much - were really nice - did not take care of any impediments I presented - did not challenge me --- title: "Confessions of a First Time Manager" url: "https://www.5whys.com/articles/confessions-of-a-first-time-manager.md" canonical: "https://www.5whys.com/articles/confessions-of-a-first-time-manager.html" published: "2009-12-14T19:32:48+00:00" updated: "2011-04-04T22:39:50.567000+00:00" tags: ["Link Love"] author: "Roy Osherove" description: "Tim Barcz just became a manager of a large group of people. And he’s got some advice for you !" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Confessions of a First Time Manager [Tim Barcz](http://devlicio.us/blogs/tim_barcz/) just became a manager of a large group of people. [And he’s got some advice for you](http://devlicio.us/blogs/tim_barcz/archive/2009/12/12/confessions-of-a-first-time-manager.aspx)! --- title: "Creating Team Trust" url: "https://www.5whys.com/articles/creating-team-trust.md" canonical: "https://www.5whys.com/articles/creating-team-trust.html" published: "2009-12-13T20:30:16+00:00" updated: "2011-04-04T22:49:21.387000+00:00" tags: ["Guest Post", "Learning Phase", "people patterns"] author: "Roy Osherove" description: "Editor’s note: The following post was written by Johanna Rothman . Johanna helps managers and leaders solve problems and seize opportunities. She consults, speaks, and writes on managing high-technology product development. She enables…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Creating Team Trust > _Editor’s note:_ The following post was written by [Johanna Rothman](http://www.jrothman.com/). > > Johanna helps managers and leaders solve problems and seize opportunities. She consults, speaks, and writes on managing high-technology product development.  She enables managers, teams, and organizations to become more effective by applying her pragmatic approaches to the issues of project management, risk management, and people management. > > She was the Agile 2009 Conference Chair, and has been helping teams, managers and organizations move to agile approaches for their projects and project portfolios. > Johanna publishes [The Pragmatic Manager](http://www.jrothman.com/pragmaticmanager.html), a monthly email newsletter and podcast, and writes two blogs: [Managing Product Development](http://www.jrothman.com/blog/mpd) and [Hiring Technical People](http://www.jrothman.com/blog/htp). She is the author of several books: > > - [Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects](http://www.amazon.com/exec/obidos/ASIN/1934356298/iserializable-20) > - 2008 Jolt Productivity award winning [Manage It! Your Guide to Modern, Pragmatic Project Management](http://www.amazon.com/exec/obidos/ASIN/0978739248/iserializable-20) > - [Behind Closed Doors: Secrets of Great Management](http://www.amazon.com/exec/obidos/ASIN/0976694026/iserializable-20) (with Esther Derby) > - [Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People](http://www.amazon.com/exec/obidos/ASIN/0932633595/iserializable-20) > - [Corrective Action for the Software Industry](http://www.amazon.com/exec/obidos/ASIN/0971323194/iserializable-20) (with Denise Robitaille). > > > Johanna is also a host and session leader at the [Amplifying Your Effectiveness Conference](http://www.ayeconference.com/). Find more of Johanna's articles and her blogs at [www.jrothman.com](http://www.jrothman.com/). Is there such a thing as team trust? If so, why do you need it? When team members have interdependent commitments, you want them to trust each other. Daughter #2, who's a senior in high school has been working on several "teams" with other seniors this year, doesn't trust her team. _"I know that I'll have to take up the slack when they don't do what they said they would do,"_  has been her slogan all year.  If that's your approach, you don't have team trust. In Solomon's [Building Trust in Business, Politics, Relationships, and Life](http://www.amazon.com/exec/obidos/ASIN/0195161114/iserializable-20), he says that there are prerequisites to trust: - Deliver what you promise to deliver - Be consistent in your actions and reactions - Make integrity a cornerstone of your work - Be willing to discuss, influence, and negotiate. - Trust in yourself and your colleagues Whether or not you have a real team, how do you create a trusting relationship with each person?  First, start with yourself. ### Do you always deliver what you promise to deliver? If you can't, why not? I've met many team leads who thought they could do the same amount of work as a team lead that they could do as an individual contributor without any overall commitment to the team. ### Are you consistent in your actions and reactions? Yes, you can become angry. No, you can't beat the table, say nasty thing to people or have other out-of-band reactions and still have trust. ### Do you ever feel as if you have to swallow your professional integrity? You might need to reframe what you think integrity is. Early in my career, I cared very much about the quality of the released product. I still care, and I realize that sometimes there are business decisions that trump actual quality. I now care very much about providing information about technical debt to the people who make the final decision. ### Are you willing to discuss issues? New team leads are particularly prone to _"I would have done it this way, why didn't you?"_ syndrome. That's fine to say that to yourself. And, you need to discuss, influence, negotiate, and not tell people what to do. ### Now, you can trust in yourself. And, you can extend trust to your colleagues. Trust is something people earn, by showing they are trustworthy. Prove yourself, to yourself, your team, your management. Then you can start building a trusting relationship with others. --- title: "How to plan and influence change at your company" url: "https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.md" canonical: "https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html" published: "2009-12-10T05:59:51+00:00" updated: "2011-04-04T22:49:37.787000+00:00" tags: ["Influence", "Self-Leading Phase", "people patterns"] author: "Roy Osherove" description: "In the book “Influencer” , the authors describe six forces that work together to influence any particular human behavior that we might want to change. The forces that influence behavior are: Personal Motivation : Why should someone care to…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to plan and influence change at your company In [the book “Influencer”](http://www.amazon.com/exec/obidos/ASIN/007148499X/iserializable-20), the authors describe six forces that work together to influence any particular human behavior that we might want to change. The forces that influence behavior are: 1. **Personal Motivation**:   Why should someone care to behave a specific way? 2. **Personal Ability**:         Can they literally do it? 3. **Social Motivation**:       Is there peer pressure push for this behavior? 4. **Social Ability**:             Do people around me support my behavior and help me out with it when i need help? 5. **Structural Motivation**: Are there rewards\\punishments for good\\bad behavior? 6. **Structural Ability**:       Does the physical environment support this behavior? Thinking more about these forces, it’s easy to understand why so many of us are finding it so difficult to influence _real change_ in our company. plenty of times we have no problems with influencing items #1 and #2 but the moment we leave our _immediate surroundings_ we find that there is lack of social motivation (in fact, there is social motivation to behave differently!) and thus social ability. in some cases, #3 and #4 are somehow made possible, but the way the organization and the environment we work in are designed prevents us from completing our change strategy. here are some examples of common failures to implement change I've encountered. now i have a sort of dictionary to try and explain where we needed to exert influence and did not: > Implementing TDD at a large company failed partially because project managers did not agree to allow more than 20% of overhead time to write automate tests for the system. on top of that, C++ developers had a horrible time testing legacy C++ code, and could not\\would not refactor it for testability. in this case, #2 was lacking (we needed better tools, or better training to teach the difficult parts) but sometimes #1 was lacking as well when people did not want to touch existing code. that also touches on #3 (social motivation) since people were not having any kind of collective ownership of the code and so did not want to mess with someone else’s code. lastly, we have #5 fail: project managers did not allow enough time to write tests,, resulting in actual “punishment” for such behavior. ### Start out by finding the vital behaviors you want to change Another eye opener for me was that the authors clearly explained that when you want to influence change, anywhere, you want to change no more than 2 or 3 _vital_ human behaviors. find these behaviors, and you have the key to making real change happen. for example, you feel that you consistently produce very low quality of released software with many bugs at the customer site. how do you know which behavior needs to change? what causes this? one way the authors state is to _look for the uncommon results_ in the crowd. for example, you may have a specific group or component that consistently presents the _good things_ that you’d like to achieve for all other groups in the company (low bug counts). find out what is different in the behavior of that specific team of individual programmer that produces that different outcome. maybe they do Test-First development? once you’ve uncovered this behavior(s) it’s time to find out why no one else is doing them. ### Find the forces, Luke. One of the sentences that has stuck most with me is the following: > Every behavior you see has been perfectly influenced by a world that was perfectly designed for this behavior to happen. That means that in order to change a specific behavior, you need to first find out why this _bad_ behavior (avoiding tests) exists in the first place. if you don’t fully address all the forces that made this behavior a reality, you will likely fail in changing that behavior. You may find that there is just one, or all six forces at play here. In the problem of automated testing, you may find that people don’t know how to do it (_can i do it?)_  and might not even want to (#1) . not only that, their managers do not believe in this system, and so will kill any attempt to do this. if you were, say, trying to push for better communication among team members as a behavior that’s missing, you may find that #6, the physical environment is actually something to address – perhaps the team is split in different rooms – putting them in the same room can help minimize communication cost. > Again, an important key here is that if you only address _some_ of the forces that affect the current behavior, it is very likely that the quest for change will not work. you need to deal with _all the forces_ that affect that current behavior. ## The silver bullet Doesn’t exist. Sorry. But with the six forces we now have a good language to talk about when dealing with implementing change in an organization. --- title: "Why XP’s influence is more effective than Scrum" url: "https://www.5whys.com/articles/why-xps-influence-is-more-effective-than-scrum.md" canonical: "https://www.5whys.com/articles/why-xps-influence-is-more-effective-than-scrum.html" published: "2009-12-09T23:31:06+00:00" updated: "2011-04-04T22:49:54.025000+00:00" tags: ["Influence", "Ri", "Self-Leading Phase"] author: "Roy Osherove" description: "in a previous post i explained what are the six forces that influence behavior. based on this, we can now begin to understand why some development methodologies are more effective when applying them at an organization or team level. for…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Why XP’s influence is more effective than Scrum in [a previous post i explained what are the six forces](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.html) that influence behavior. based on this, we can now begin to understand why some development methodologies are more effective when applying them at an organization or team level. for example, [Scrum](http://en.wikipedia.org/wiki/Scrum_\(development\)), is a process that only deals with the behavior of the customer, the scrum master and the team at the beginning and end of each sprint (getting requirements, managing backlog, estimation..) but Scrum _does not_ address any of the team activities _inside_ an iteration like XP does (_pair programming, test driven development, continuous integration and automated builds, single room..)_ but the fact is that it is precisely those things that [XP advocates](http://www.extremeprogramming.org/) that have to do with the 5th and 6th forces (physical environment and rewards) that make the biggest difference in teams. XP really deals with _all_ the forces that shape human behavior, thus _influencing change_ during its application. Scrum is a process that only uses a few of the forces and thus is [harder to achieve as a standalone process](http://www.netobjectives.com/blogs/Is-Scrum-Failing-Us). that’s why scrum and XP together (or XP alone) will always trump in terms of adoption (when done right) over bear Scrum. > can you guess which forces Scrum does _not_ use to influence human behavior? The funny thing is, Scrum is easier to adopt for management. I think this is specifically because there are less behavioral changes in Scrum (or at least appear to be). The truth is most if not all Scrum practitioners soon realize there is no Scrum possible without automated tests, Continuous integration, team in the same room and the other XP practices. but these are then introduced quietly into the process, or the process fails. Why would it fail without them? because a team cannot be expected to product software on a weekly or biweekly basis without automated tests that help it overcome frequent change. it’s just reality. as a force it’s force #2  and #6 (“persona ability – can i do it?” and “structural ability = does the environment support my behavior”). --- title: "The Five Dysfunctions of a Team" url: "https://www.5whys.com/articles/the-five-dysfunctions-of-a-team.md" canonical: "https://www.5whys.com/articles/the-five-dysfunctions-of-a-team.html" published: "2009-12-08T18:56:15+00:00" updated: "2011-04-04T22:39:25.523000+00:00" tags: ["Anti Patterns", "Learning Phase", "people patterns"] author: "Roy Osherove" description: "As part of my reading, one book i came across was The Five Dysfunctions of a Team: A Leadership Fable it’s a great book and i recommend that every team leader, at any level, read this. it connects very well to many other things I’ve seen…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Five Dysfunctions of a Team As part of my reading, one book i came across was [The Five Dysfunctions of a Team: A Leadership Fable](http://www.amazon.com/gp/product/0787960756?ie=UTF8&tag=iserializable-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0787960756) [![The Five Dysfunctions of a Team: A Leadership Fable (J-B Lencioni Series)](https://www.5whys.com/img/posts/amazon-five-dysfunctions.jpg)](http://www.amazon.com/gp/product/0787960756?ie=UTF8&tag=iserializable-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0787960756) it’s a great book and i recommend that every team leader, at any level, read this. it connects very well to many other things I’ve seen and learned in the wild, but manages to tell and explain things at a very simple and yet real world level that i think most would be able to relate to, even if they have no leadership experience. ### what are the five dysfunctions? ### 1) Absence of Trust you can detect this easily if you have meetings where no one disagrees with each other, but everyone probably disagree or don’t care what others are saying. also, meetings are very political in nature. As a team you need to be able to trust each other, so that you can expose weakness in a “safe” manner without fear. this allows raising real issues that need to be taken care of. Also, lack of trust leads to the second dysfunction: ### 2) Fear of conflict if you don’t trust each other, then you won’t want to confront any of your team mates in real world productive dialog about things that are hurting the team and company. without conflict people also won’t air their real opinions about things going on, which leads to the third dysfunction: ### 3) Lack of commitment many times, people will not commit to any decision made by the team if they feel they had not been heard. most people are ok with at least saying what they want to say and they they are able to commit even to a group decision they were against. as long as they were heard. without that, they will not feel committed to decisions. fear of conflict and commitment also leads to: ### 4) Avoidance of accountability if people can’t openly confront each other about the real issues without fearing hurting each other, then people may not feel accountable for their (lack of) actions for the team and company. Sometimes the leader takes on the role of the “accountability confronter” but this should really be on all the team. otherwise people can sit quietly on issues they don’t like and quietly expect the leader to do all the hard lifting of confrontation, but a trusting team should be able to openly and honestly confront each other on business issues. all these lead to: ### 5) Inattention to results in this state, especially with lack of accountability, team members put individual needs above the team’s needs. if as a team we cannot deliver results – specific goals the team sets itself on a weekly, monthly  or yearly basis, – then what _are_ we doing? --- title: "Other blogs on management and leadership" url: "https://www.5whys.com/articles/other-blogs-on-management-and-leadership.md" canonical: "https://www.5whys.com/articles/other-blogs-on-management-and-leadership.html" published: "2009-12-01T18:43:30+00:00" updated: "2009-12-01T19:02:42.083000+00:00" tags: ["Link Love"] author: "Roy Osherove" description: "Rands in Repose Noop Pawerl Brodzinski Scott Berkun Software by Rob podcast by David Meister Podcast: Manager tools got more?" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Other blogs on management and leadership - [Rands in Repose](http://www.randsinrepose.com/cat_management.html) - [Noop](http://www.noop.nl/) - [Pawerl Brodzinski](http://blog.brodzinski.com/) - [Scott Berkun](http://www.scottberkun.com/blog/category/management/) - [Software by Rob](http://www.softwarebyrob.com/) - [podcast by David Meister](http://davidmaister.com/podcasts.archives/3/) - [Podcast: Manager tools](http://www.manager-tools.com/) got more? --- title: "How to influence others" url: "https://www.5whys.com/articles/how-to-influence-others.md" canonical: "https://www.5whys.com/articles/how-to-influence-others.html" published: "2009-11-30T18:13:18+00:00" updated: "2011-04-04T22:50:24.123000+00:00" tags: ["Influence", "Learning Phase", "Self Improvement", "Self-Leading Phase", "people patterns"] author: "Roy Osherove" description: "Two books I’ve been occupied with recently deal directly with a very problematic topic for most team leaders world wide – how do you influence people in your team and your organization to either change or help you change things for the…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to influence others Two books I’ve been occupied with recently deal directly with a very problematic topic for most team leaders world wide – how do you influence people in your team and your organization to either change or help you change things for the better? I will be writing separately about each book, but for now keep these two close at hand – they are seriously interesting to anyone who wants to become a better leader, and a change agent in an organization of any size: - ##### [How to Win Friends & Influence People](http://www.amazon.com/exec/obidos/ASIN/0671027034/iserializable-20) ##### This book deals with influence at the _micro_ level – just you, personally, one on one, with other people. In a way, this book provided me a set of social behavior protocols that I’ve never dared to even try, or even try to figure out why they were needed. But after reading it fully, I think it is priceless, not just for the last part of it relating to _leadership and influence_. - ##### [Influencer: The Power to Change Anything](http://www.amazon.com/exec/obidos/ASIN/007148499X/iserializable-20) ##### This book deals with influence at the _macro_ level – how were people able to change and influence thousands and even millions of people, across countries, to change their behavior in an effective manner? from helping to prevent aids, to preventing unnecessary health system deaths, how do you get to change people’s _key vital behaviors_ to the effect of a whole society being affected? If you’ve ever tried to drive change in your little company, this book has some nice drills into 6 different forces that need to work in order to make change at almost any level possible. I’ll deal with both books in this blog thoroughly, but I’d suggest going out and starting to read them as soon as possible. I’m sure there are books out there that I’ve missed on such topics. I’d love it if you ‘d help other readers of this blog by sharing what resources you know to learn and master influence at _micro_ and _macro_ level. --- title: "How to deal with bad decisions made by the team" url: "https://www.5whys.com/articles/how-to-deal-with-bad-decisions-made-by-the-team.md" canonical: "https://www.5whys.com/articles/how-to-deal-with-bad-decisions-made-by-the-team.html" published: "2009-11-16T14:23:37+00:00" updated: "2011-04-04T22:43:33.007000+00:00" tags: ["Anti Patterns", "Decision Making", "Ha", "Self-Leading Phase", "people patterns"] author: "Roy Osherove" description: "I’ve been going through the book “ Succeeding with Agile ” by Mike Cohn. I like what I see so far because it talks about the various failures that happen to us all when we try to implement change in our companies and teams. One specific…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to deal with bad decisions made by the team I’ve been going through the book “[Succeeding with Agile](http://www.amazon.com/exec/obidos/ASIN/0321579364/iserializable-20)” by Mike Cohn. I like what I see so far because it talks about the various failures that happen to us all when we try to implement change in our companies and teams. One specific bit of advice was very interesting, since I see various forms of this in many different teams. The problem: > You’ve coached your team into the point where they are, in many ways, self directing. You often see that the team is taking the **wrong** technical choices (either design choices, tool choices or anything that impacts the team or the application in the long term. > > How to you influence the team to take better decisions? The book states that this can come from two different problems: either all the people in the team are too similar in mind (so no one challenged the decision) or they are very different (so some decision had to be taken by force) in the case mentioned in the book, the lead had decided to step into future technical meetings (which happen ad-hoc ish) and ask various questions to incite different opinions (she felt people did not challenge each other enough) -   - What alternatives have you considered and rejected before accepting this one? - What could go wrong with this approach? - What has to go right for this approach to work? - What could make us regret this decision? - Is there any information we don’t have that would help us be sure of this? Again, these seem as really annoying questions, but if a team never challenges itself you can use your leadership to start asking these and see who “bites” and answers these questions, thereby creating some disagreement or challenging the current decision, leading to a discussion that might be very productive leading to a better solution. Some people might find all this very irrelevant. “you’re the team lead” they’d say. “Why don’t you just **tell them** what should be the right decision?” Ah, good question. Because as a team lead your main job is twofold: grow the people in your team, and deliver product. You can’t just focus on one. That’s why you [should not automatically give solutions to questions](https://www.5whys.com/articles/growing-developers-ask-for-solutions-instead-of-giving-them.html). Other possible ways of dealing: - Introduce a new team member into the team with much more experience, power etc. - Ask hard questions to make sure different points of view have been met - Change the team’s decision making style - Encourage Dissenting viewpoints --- title: "Be more approachable in five minutes" url: "https://www.5whys.com/articles/be-more-approachable-in-five-minutes.md" canonical: "https://www.5whys.com/articles/be-more-approachable-in-five-minutes.html" published: "2009-10-28T14:28:22+00:00" updated: "2009-10-28T14:38:10.343000+00:00" tags: ["Self Improvement", "people patterns"] author: "Roy Osherove" description: "I found this blog post interesting because it starts out with a simple premise: you are not as \"approachable\" as you think. It also introduces the concept of \" Daily Five Minutes \". That article is pretty long, but this post sums it up…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Be more approachable in five minutes I found [this blog post](http://talkingstory.org/2009/10/so-you-think-you-are-approachable/) interesting because it starts out with a simple premise: you are not as "approachable" as you think. It also introduces the concept of "[Daily Five Minutes](http://joyfuljubilantlearning.com/2009/07/learning-to-listen-with-d5m/)". That article is pretty long, but [this post sums it up](http://www.sayleadershipcoaching.com/mwacoaching/2008/02/whats-the-skinn.html) rather nicely: > Very briefly, **the D5M is a simple habit**. Each day, without fail, managers are to give five minutes of no-agenda time to at least one of their employees. > > Your time is one of the most precious resources you have, and to give it as a gift to someone in the form of the _Daily Five Minutes®_ just may be one of the best work-expressions of [_unconditional aloha_](http://www.managingwithaloha.com/2006/02/articulating_al.html) there is. There are also several sets of questions that can be involved (read "[Daily Five Minutes](http://joyfuljubilantlearning.com/2009/07/learning-to-listen-with-d5m/)" for the full thing) but the idea is simple and powerful. I intend to give it a try. Do you already do this? --- title: "Video - Pair Programming with a Guitar" url: "https://www.5whys.com/articles/video-pair-programming-with-a-guitar.md" canonical: "https://www.5whys.com/articles/video-pair-programming-with-a-guitar.html" published: "2009-10-27T07:10:56+00:00" updated: "2009-10-27T07:13:18.613000+00:00" tags: ["Pair Programming", "Video"] author: "Roy Osherove" description: "Sure, Pair programming sounds a bit weird at first, but just show this video to those who aren't yet inspired to do it. via Naresh , living proof that pair programming can work beautifully in many areas :) A video was embedded here. It is…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video - Pair Programming with a Guitar Sure, Pair programming sounds a bit weird at first, but just show this video to those who aren't yet inspired to do it. [via Naresh](http://blogs.agilefaqs.com/2009/10/26/want-to-pair-program-and-concerned-about-productivity/), living proof that pair programming can work beautifully in many areas :) A video was embedded here. It is no longer publicly available on YouTube. --- title: "Dev Anti Pattern: Unworkable Machine" url: "https://www.5whys.com/articles/dev-anti-pattern-unworkable-machine.md" canonical: "https://www.5whys.com/articles/dev-anti-pattern-unworkable-machine.html" published: "2009-10-24T13:01:29+00:00" updated: "2011-04-04T22:44:37.313000+00:00" tags: ["Anti Patterns", "Growing People", "Learning Phase", "people patterns"] author: "Roy Osherove" description: "Summary: A developer in your team always has problems with their machine, to the point where they are less productive, and always trying to fix something before they can get things done. Usually this gets noticed during stressful times in…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Dev Anti Pattern: Unworkable Machine ### Summary:  ![](https://www.5whys.com/img/posts/453bbc30-broken-computer.jpg) A developer in your team always has problems with their machine, to the point where they are less productive, and always trying to fix something before they can get things done. Usually this gets noticed during stressful times in the project's life. **Common Phrases:** - "It's happening again" - "Yeah I'm just waiting for my editor to stop hanging" - "I think \[software\] doesn't like me anymore" - "Have you seen this cool thing?" - "Ever come across this error?" ### Possible Reasons: - **Boredom**. The developer keeps installing **weird f&$ing s$%t** on their machine that has nothing to do with their work, that may have one or more collisions with the software they actually need to get things done with. Usually common with developers that have a very low threshold for boredom, who always seek things to install on their machine. - **Bug Recreation.** The developer, in their attempt to recreate a hard to find bug, have turned their machine into a testing machine, so as to bring it to just the right circumstances for that bug to appear.  - **Multiple developers using the same machine** (even with different users). Developers will f&$ck up a machine to fit just their needs. with no concern for any other user on that machine. ### How to fix it: ### Take them aside an explain the problem in productivity. Ask them to come up with a way where they will not screw up their machine due to this way of working. ### possibilities are endless, and may include among others: ### - Using a virtual machine - having a secondary trial machine - dual booting the machine  - etc. --- title: "Do Not Fear Confrontation" url: "https://www.5whys.com/articles/do-not-fear-confrontation.md" canonical: "https://www.5whys.com/articles/do-not-fear-confrontation.html" published: "2009-10-24T01:04:01+00:00" updated: "2009-10-24T01:05:35.147000+00:00" tags: ["First Steps during chaos", "Video"] author: "Roy Osherove" description: "hope the sound wasn't too weak... Watch on YouTube Team Leads: Do Not Fear Confrontation" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Do Not Fear Confrontation hope the sound wasn't too weak... [![](https://www.5whys.com/img/video/youtube-eqaYju7EU9s.jpg)Watch on YouTube](https://www.youtube.com/watch?v=eqaYju7EU9s) Team Leads: Do Not Fear Confrontation --- title: "Check-in: sharing emotions in an effective way" url: "https://www.5whys.com/articles/check-in-sharing-emotions-in-an-effective-way.md" canonical: "https://www.5whys.com/articles/check-in-sharing-emotions-in-an-effective-way.html" published: "2009-10-23T16:39:28+00:00" updated: "2009-10-23T17:13:09.076000+00:00" tags: ["Growing People", "Guest Post", "Self Improvement", "people patterns", "Afraid", "Check-in", "Emotions", "Empowerment", "Glad", "Leadership", "Mad", "Sad", "TheCoreProtocols"] author: "Roy Osherove" description: "In this blogpost I will cover “The Check-In Protocol” portion of The Core Protocols which are available for download at http://alturl.com/b9fn One of the most effective and, consequently, one of the most controversial protocols is…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Check-in: sharing emotions in an effective way In this blogpost I will cover “The Check-In Protocol” portion of [The Core Protocols](https://www.5whys.com/articles/the-core-protocols-introduction.html) which are available for download at [http://alturl.com/b9fn](http://alturl.com/b9fn) One of the most effective and, consequently, one of the most controversial protocols is Check-In. [![](https://www.5whys.com/img/posts/50d2cfd2-IMG_7557.JPG)](http://www.incentiveplus.co.uk/p/342-7834/Box-Full-of-Feelings.html)In presentations, when I ask the audience, “Who has worked with a colleague that hides emotions?” almost everyone raises his or her hand. When I then ask if this has hindered productivity at work, almost all the hands stay up. Yet a lot of people are still convinced that showing their emotions at work is not “professional.” I find that the Check-In Protocol offers a powerful way to show emotions in a mature way, both at work and in my personal life. In a Check-In, we state how we feel using 4 basic emotions: mad, glad, sad, and afraid. Let me give you an example: I’m checking in I’m GLAD that Roy has asked me to write these guest posts. I’m AFRAID to do so. I’m GLAD I can ask for help I’m AFRAID that the power of the protocols can only be understood by using them I’m AFRAID, SAD that people will turn away without trying them I’m GLAD to know that some will probably accept my invitation to try them I’m IN. This is an example where I used the protocol to the letter. When I use the protocols with people not familiar to The Core, I might say: Hello, welcome to this training, I’m Yves Hanoulle I’m glad to see so many people. I’m afraid that this puts pressure on me to make it great. That is ok, because I have done this a lot of times. I’m mad because my replacement phone does not work here in Canada I’m sad because delivering this workshop means I will miss my kids for 5 days. If you think that this won’t work \- in your company, \- in your country, \- with your spouse, etc. Then you are not alone. I had a similar reaction about using the protocol with my oldest son. I was having a chat with Michele (McCarthy). She asked me to try Check-In with him. I told her that he was three and a half years old and that I thought that was too young. We finished the conversation with my promise I would try it. (I was still convinced it would not work).  The next day Joppe came home with a card from school with these 4 emotions on it. I realized I was the reason it wasn’t working. He already knew about the four emotions. I’ve been using it with him ever since. Using Check-In with Joppe has taught me a lot. One night he said, “I’m MAD, SAD that the babysitter will be here. And you guys are going out.” At that time my partner and I went out to dinner every Thursday.  It was a Thursday, but that day we weren’t going to go, and we hadn’t told him. Typically, we only told him when we were going out on the day itself. He had already made the connection, though, Thursday è babysitter. I realized that evening that Joppe might only be 4 years old, but he was much more clever than I was giving him credit for. Now for a work story: One morning I had an argument with my partner before leaving for work. The discussion was stuck in my head as I drove. On top of that, a crazy truck driver almost drove me off the road. When I arrived at work, I realized I was not my rational self because of these two events. So when I came in, I told my colleagues, “Sorry if I overreact a little today, I had a discussion at home before leaving; I’m still puzzled about some of the things we said to each other.  I’m also mad about a crazy truck driver that drove me off the road.” Right then my colleague gave me 10 minutes of slack time. Also, because I had checked in, I immediately forgot about what had happened. I didn’t remember until I got back in my car that evening. Without checking in, I would have been stuck on those thoughts and feelings all day, and my productivity would have been a fraction of what it was. So I propose you try the Check-In Protocol at work and at home, and see how much more bandwidth you can create in your communication lines. As a bonus, once you are skilled at using it, it keeps working over e-mail, chat etc. ****I  am Yves Hanoulle, [your virtual Project coach](http://paircoaching.wordpress.com/) and you can reach me at blog at [my training company](http://www.paircoaching.net/) .net or follow me on [Twitter](http://twitter.com/yveshanoulle/)**** --- title: "The hidden leadership lessons we can learn from music conductors" url: "https://www.5whys.com/articles/the-hidden-leadership-lessons-we-can-learn-from-music-conduc.md" canonical: "https://www.5whys.com/articles/the-hidden-leadership-lessons-we-can-learn-from-music-conduc.html" published: "2009-10-21T22:20:20+00:00" updated: "2009-10-21T22:28:16.563000+00:00" tags: ["Growing People", "Video", "people patterns", "TED"] author: "Roy Osherove" description: "This very inspiring video raises many questions and analogies to our technical world of leadership: Watch the talk on TED.com (Itay Talgam: Lead like the great conductors) I'd sure love to sit with Itay (the presenter) for a few tough…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The hidden leadership lessons we can learn from music conductors This very inspiring video raises many questions and analogies to our technical world of leadership: [Watch the talk on TED.com](https://www.ted.com/talks/itay_talgam_lead_like_the_great_conductors) (Itay Talgam: Lead like the great conductors) I'd sure love to sit with [Itay (the presenter)](http://www.talgam.com/appfiles/default.asp) for a few tough questions. things I learned from this video: - Enabling a team to be self directing is the true essence of leadership - letting people grow - control without control a lot of the things this blog talks about, though, are about the state of a team **before** it is even possible to achieve these things (the team is not read). The state of software today, put in music orchestra terms is like having an orchestra with players who sometimes don't really want to be there, or don't really care about music, most of the time. We are not true professionals, yet. --- title: "A Possible Job Description: Team Leader" url: "https://www.5whys.com/articles/a-possible-job-description-team-leader.md" canonical: "https://www.5whys.com/articles/a-possible-job-description-team-leader.html" published: "2009-10-16T23:52:56+00:00" updated: "2009-10-16T23:56:55.687000+00:00" tags: ["Guest Post", "people patterns"] author: "Roy Osherove" description: "Editor's Note: This is a guest post by Kevin Stevens. Kevin Stevens is a Senior Software Engineer at Ecology & Environment in Buffalo, NY. He claims to be the only person who has a B.A. in acting, a B.S. in Computer Science, and who has…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A Possible Job Description: Team Leader > Editor's Note: This is a guest post by Kevin Stevens. Kevin Stevens is a Senior Software Engineer at Ecology & Environment in Buffalo, NY. He claims to be the only person who has a B.A. in acting, a B.S. in Computer Science, and who has worked for Siegfried and Roy. He has a PMP, but thinks it was a giant waste of time. I’ve been thinking a lot about what qualities make a good team leader. We’ve been trying to hire a senior developer for the last few months without a lot of luck. Our job description is, like most, strong on technical skills. But when we do the post-mortem on an interview, that isn’t what we talk about. What we talk about are things like, “Would he be able to lead a design meeting?”, “Is he going to be able to mentor the juniors?”. All of which makes me think that the job description needs a rewrite. So, even though HR would never approve of a listing written like this, here’s what I’ve been thinking. > > You’ve proven you can wield application code like a lightsaber, but you know there’s more to software engineering than that. You write unit tests, integrate continuously, program in pairs and rock it Agile-style three ways from Sunday. You have shown what you can do and now want to show that you can lead. Here’s what you need to do: > Remember what it was like to be a junior programmer > Teach others to avoid the mistakes you made so they don’t stay junior for long > Know about the next generation of technology coming down the pike > Have enough sense to adopt new things because they’re the right tools for the job and not because they’re new > Ship applications that reflect the hard work and integrity of your team > Care for your team’s code like it is the piece of craftsman ship it truly is > If you can do this and more, lots more, it’s time for you to step up and lead. --- title: "Video: Influence Strategies" url: "https://www.5whys.com/articles/video-influence-strategies.md" canonical: "https://www.5whys.com/articles/video-influence-strategies.html" published: "2009-10-16T13:12:59+00:00" updated: "2009-11-30T18:15:06.037000+00:00" tags: ["Influence", "Video", "people patterns"] author: "Roy Osherove" description: "Richard banks posted what seems to be an interesting video about \"Influence Strategies\", based in Linda Rising 's work. I'd also recommend taking a look at his \"Management\" tag on his blog for some interesting gems. Teams leads can only…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Video: Influence Strategies Richard banks [posted what seems to be an interesting video](http://richardsbraindump.blogspot.com/2009/09/australian-virtual-altnet-influence.html) about "Influence Strategies", based in [Linda Rising](http://www.lindarising.org/)'s work. I'd also recommend taking a look at his "Management" tag on his blog for some interesting gems. Teams leads can only succeed if they can influence other people to believe and act based on the best interested of the team and customer.  A video was embedded here. Its host (Viddler) has shut down, so it is no longer available. --- title: "The Core Protocols Introduction" url: "https://www.5whys.com/articles/the-core-protocols-introduction.md" canonical: "https://www.5whys.com/articles/the-core-protocols-introduction.html" published: "2009-10-16T12:56:41+00:00" updated: "2009-10-16T15:40:19.637000+00:00" tags: ["Growing People", "Self Improvement", "people patterns", "Empowerment", "Leadership", "TheCoreProtocols"] author: "Roy Osherove" description: "Roy has asked me if I wanted to write a few guest posts on the 5 Why’s about The Core Protocols. I will start by explaining where these rules came from. This story starts in 1995. Jim McCarthy wrote Dynamics of Software Development . After…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Core Protocols Introduction Roy has asked me if I wanted to write a few guest posts on the 5 Why’s about The Core Protocols. I will start by explaining where these rules came from. ![](https://www.5whys.com/img/posts/152c648e-courage.jpg)This story starts in 1995. Jim McCarthy wrote [Dynamics of Software Development](http://www.librarything.com/work/84233/book/11105120). After this book was very well received in the software community,  (I see it as one of the predecessors of agile) Jim and his wife, Michele, decided to leave Microsoft to hold workshops about building teams. They designed these workshops to be experimental. The course was not presented like a usual class: It was a simulated one week project. Part of the assignment of the project was for the students to come up with their own team rules.  After a year or so, Jim and Michele realized that some team patterns kept getting great results. So they decided to write these rules down and give them to the students attending the next workshop. They have done that for the last 13 years.  These patterns are now called The Core Protocols. This series of guest posts will be about these protocols. Some…heck, most of these rules feel strange at first.  You might think, “This will never work.” \-          In my company \-          In my country \-          With my wife \-          With my kids \-          In my team I’m asking you to suspend your disbelief, and instead, try a few of these out in a safe environment. You don’t have to believe in the sea to get wet. You only have to get in. ** I  am Yves Hanoulle, [your virtual Project coach](http://paircoaching.wordpress.com/) and you can reach me at blog at [my training company](http://www.paircoaching.net/) .net or follow me on [Twitter](http://twitter.com/yveshanoulle/)** --- title: "Leadership Conference coming up" url: "https://www.5whys.com/articles/leadership-conference-coming-up.md" canonical: "https://www.5whys.com/articles/leadership-conference-coming-up.html" published: "2009-10-16T00:21:22+00:00" updated: "2009-10-16T00:24:05.513000+00:00" tags: ["Conference"] author: "Roy Osherove" description: "I'm in the stages of planning a team leadership conference. Chances are it will be held in the UK, week of January 25th (don't hold me to that yet!) I'm still looking for a good name for it. and I bet you can help. Select your favorite…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Leadership Conference coming up I'm in the stages of planning a team leadership conference. Chances are it will be held in the UK, week of January 25th (don't hold me to that yet!) I'm still looking for a good name for it. and I bet you can help.  Select your favorite names in the poll below (here is a [direct link](http://answers.polldaddy.com/poll/2126114/) to the poll if you don't see it) --- title: "How to squeeze a decision out of a sleepy meeting" url: "https://www.5whys.com/articles/how-to-squeeze-a-decision-out-of-a-sleepy-meeting.md" canonical: "https://www.5whys.com/articles/how-to-squeeze-a-decision-out-of-a-sleepy-meeting.html" published: "2009-10-15T08:34:21+00:00" updated: "2009-10-15T08:36:31.953000+00:00" tags: ["Decision Making", "people patterns"] author: "Roy Osherove" description: "Yves has a short and to the point post - There's a simple protocol you can try for that." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to squeeze a decision out of a sleepy meeting [Yves](http://paircoaching.wordpress.com/) has [a short and to the point post](http://paircoaching.wordpress.com/2009/10/15/tired-of-long-meetings-without-decisions/)  - There's a simple protocol you can try for that. --- title: "A simple way to know you're missing some leadership skills" url: "https://www.5whys.com/articles/a-simple-way-to-know-youre-missing-some-leadership-skills.md" canonical: "https://www.5whys.com/articles/a-simple-way-to-know-youre-missing-some-leadership-skills.html" published: "2009-10-15T00:08:59+00:00" updated: "2009-10-15T00:49:49.697000+00:00" tags: ["First Steps during chaos"] author: "Roy Osherove" description: "how often does this happen to you as a team lead: You believe in some great practices that the team needs to follow, but you can't convince or get the team to follow them - even the simplest ones. If that happens to you - it's time to…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A simple way to know you're missing some leadership skills how often does this happen to you as a team lead: > You believe in some great practices that the team needs to follow, but you can't convince or get the team to follow them - even the simplest ones. If that happens to you - it's time to visit the idea that you may be lacking some core people skills, and leadership skills. It's not your fault - we've all be taught as technical people that the only thing that matters is technical knowledge. not people knowledge. technical knowledge drives you to the top - and will also bring you down. but if you can't translate that knowledge into meaningful actions by your team - it is as worthless as that 14 inch monitor you have lying around in your garage. Leadership in software means helping the team achieve goals you believe in, even if they may not be convinced about them when you start out your quest. it's about making the team drive to that vision, at some point, without needing your help to do it. but that takes, time, and patience, and sometimes - it takes a strong ego to not break during this long path. I hope we all find that missing link soon. --- title: "How to measure programmer productivity using TDD Katas" url: "https://www.5whys.com/articles/how-to-measure-programmer-productivity-using-tdd-katas.md" canonical: "https://www.5whys.com/articles/how-to-measure-programmer-productivity-using-tdd-katas.html" published: "2009-09-30T22:12:12+00:00" updated: "2009-09-30T22:34:19.011000+00:00" tags: ["Growing People", "Self Improvement"] author: "Roy Osherove" description: "A TDD Kata is an exercise in writing code, test first, which one repeats once or more a day. Here's an example of one . I make students that take my TDD course do this kata each morning, in the space of 30 minutes. Near the end of the…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to measure programmer productivity using TDD Katas A TDD Kata is an exercise in writing code, test first, which one repeats once or more a day. [Here's an example of one](http://osherove.com/tdd-kata-1/). I make students that take my TDD course do this kata each morning, in the space of 30 minutes. Near the end of the course, they become more and more skilled with the tools and can actually get to finish it in 30 minutes, and they get faster and faster. The point about the Kata is that you should know it **by heart**. you should not be thinking about the solution, your fingers should by typing it "blind", including all the refactoring work, the renaming and whatever else you do. A Kata is about muscle memory - so that we feel comfortable doing that something in the real work, without needing to think about it. If you know it well enough, you can start timing how long it takes you to finish it. THe faster you finish it (with same results, clean code and working implementation) the more it means you are productive. Why? Because at some point, the only things that take the time in the kata are those darn keyboard keys and mouse! The more shortcuts, snippets and key combinations you learn to get your job done, the more you have minimized those things in your developement writing that take the time. So a kata is about muscle memory, but  you can use it to measure how well you are mastering your tools, or how productive you are as a programmer. what's fascinating, is that if you look hard enough you'll find that there's always something that can be done even faster eithout hurting the end consequances. here are some examples: 1. No need to type that whole Setup method with attributes on the code. Create and use a live code snippet to generate it in a click or a key press. 2. No need to select a whole line before removing it - learn to use shortcut keys to do that in one action. 3. No need to manually go to a code finle when you can navigate to the last edit location in a blink of an eye with your tools and there are a million more. it's about mastering your craft. and now there's a way to measure it. --- title: "Leading Through Learning: The Responsibilities of a Team Leader" url: "https://www.5whys.com/articles/leading-through-learning-the-responsibilities-of-a-team-lead.md" canonical: "https://www.5whys.com/articles/leading-through-learning-the-responsibilities-of-a-team-lead.html" published: "2009-09-30T20:51:36+00:00" updated: "2009-09-30T21:04:16.113000+00:00" tags: ["Growing People", "Guest Post", "Self Improvement"] author: "Roy Osherove" description: "Editor's note: The following is a guest post from Cory Foy . Cory Foy is an agile coach and developer living in Bayonet Point, FL. He is currently helping product teams become much more lean in their approaches to building product through…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Leading Through Learning: The Responsibilities of a Team Leader > **Editor's note:** The following is a guest post from [Cory Foy](http://www.cornetdesign.com/). Cory Foy is an agile coach and developer living in Bayonet Point, FL. He is currently helping product teams become much more lean in their approaches to building product through the focused use of both craftsmanship and agile practices and principles. Prior to his current role, Cory worked with teams around the globe bringing agile and development best practices to Microsoft customers as a Senior PFE. He has also been involved in several start-up organizations where delivering high value while keeping the code clean is vital. When not spending time with his wife and 2 girls, Cory enjoys working as the global community liaison for the Scrum Alliance, speaking at conferences and user groups, and playing guitar, drums, or whatever he can get his hands on. He can be found at [http://www.cornetdesign.com](http://www.cornetdesign.com/) or on Twitter at[http://twitter.com/cory\_foy](http://twitter.com/cory_foy) (@cory\_foy) I was honored when Roy asked me to explore the topic of Team Leadership for the Five Whys blog. And it's an interesting topic too since it can cover such a broad array of things. And while we could cover the normal things (Servant Leadership, Impediment Removal, Motivation) there is one thing I think intrinsically sets great leaders apart from mediocre ones. To get there, we first should discuss the responsibility of a team member. One of the things that has excited me the most about the Software Craftsmanship movement is a shift of responsibility. So many times we as developers have set out with the ingrained feeling that it is our organization's responsibility to help us grow and succeed. And this was true to some extent in the early days - great programmers stayed with great companies for a long time. Growth was something you expected when you got hired in. You could look forward to being somewhere, putting in your best, and getting rewarded by retiring with them and being taken care of in return. But, by and large, those days are gone. I don't know of any colleagues who have gotten hired with a company thinking that they would be there for 20 or 30 years. Which seemingly coincides with the mantra of "Here Today, Gone Tomorrow" some organizations practice. Which further means that if we can't even be sure that our jobs are still going to be here, we can't certainly expect that organizations will help us grow as a matter of normalcy. So, as a part of the Craftsmanship Movement, we've declared that one shouldn't expect to be getting knowledge from organizational initiatives, or in the course of their role on a team. In fact, the core of the movement is that developers need to be taking responsibility for their own careers - learning, teaching, mentoring, speaking. So what does that have to do with team leadership? Back in June, Roy posted an article called [Questions every team and dev lead should ask themselves](http://weblogs.asp.net/rosherove/archive/2009/06/16/questions-every-team-and-dev-lead-should-ask-themselves.aspx). In it, there was one key question that is perhaps the hardest question for many leads: > Will my developers be better in a month or two than they were before? If not, how do I make that happen? This question, above all others, is what has set the leads I lift up above others. It doesn't matter the industry - I saw it from software team leads as much as Fire Captains and other industries I've been involved in. How do I create learning opportunities that enable my team to grow? This past weekend I went to [BarCamp Tampa Bay](http://barcamptampabay.org/) and got to see [Steven Bristol](http://b.lesseverything.com/) talk about starting up a company. In it, he mentioned how feedback loops affect growth. If you are single, and go up to someone and ask them out, one of three things will happen: 1. They'll say yes 2. They'll say no (or some variant, like slapping you upside the head) 3. They'll turn around and walk away without saying a word Out of the three, which will you learn the most from? Which will cause you to grow the most? Which will leave you scratching your head? Imagine now that you are a developer on a team. You email your team lead and ask about taking on a new initiative for the team. The next afternoon an announcement is made that one of the senior developers is going to be working on the initiative you just emailed about. Baffling, huh? Imagine if, instead, the team lead emailed you back and told you that she had concerns because you hadn't been involved with FooBar, and so for this initiative Senior Joe was going to take it, but to work closely with Joe so that you can jump on the next one. Or imagine the team lead replied and said go for it. And offered guidelines so you could know what kind of progress you were making. And let's say you took that and failed miserably. But, because of the team involvement, others were able to pick up the ball with you and help get it done. That's what you want from a team lead. This, in many ways, is the essence of leadership. Providing opportunities for people to fall, but always within the context of the safety net of the team. Motivating not by fear, or by money, but by passion that the team is always greater than any one developer can be. It is turning your day to day interactions into chances for growth and learning, and ultimately building a [Learning Organization](http://blog.scottbellware.com/2008/12/learning-organization.html). It also means setting aside one's ego, one's pride to be able to go out and help others. Effective team leads aren't generally the rockstar developers who put in 70 hour weeks because they are Hard Core. They are solid technical leaders - and solid _people_ leaders. For example, Scott Bellware had an article on [the Chief Engineer role](http://blog.scottbellware.com/2008/12/chief-engineer.html) in which he described the responsibilities and qualities of the Chief Engineer at Toyota. These included: - Voice of the customer - Architecture - Exceptional engineering skills - A hard-driving teacher, motivator, and disciplinarian, yet a patient listener - An exceptional communicator - Always ready to get his or her hands dirty So if you are thinking about leading a team, or finding yourself thrust into that role, ask yourself - are you growing? Are you seeking opportunities for yourself? For the team? Are you listening - truly listening - to what your team is telling you? Or are you constantly impatient for them to finish so you can tell them the _right_ answer? And, most importantly, what actions am I taking today to make my developers - my team - better one week, one month, one year from now? In the answers to those questions lie the growth path for you as a leader. Keep growing, keep questioning and keep learning - so that your team does too. --- title: "A bunch of (old) audio interviews on management and agile methodologies" url: "https://www.5whys.com/articles/a-bunch-of-old-audio-interviews-on-management-and-agile-meth.md" canonical: "https://www.5whys.com/articles/a-bunch-of-old-audio-interviews-on-management-and-agile-meth.html" published: "2009-09-29T23:19:25+00:00" updated: "2009-09-29T23:27:57.004000+00:00" tags: ["Audio"] author: "Roy Osherove" description: "Here are a bunch of audio interviews I did a loong while ago, but I feel that at least some of them still hold true today. Johanna Rothman - Secrets of great management (01/12/05) Johanna Rothman keeps coming back to Israel to teach…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A bunch of (old) audio interviews on management and agile methodologies Here are a bunch of audio interviews I did a loong while ago, but I feel that at least some of them still hold true today. **Johanna Rothman - Secrets of great management (01/12/05)** [Johanna Rothman](http://www.jrothman.com/) keeps coming back to Israel to teach management courses and consult and, well , I just love talking to her so much I keep asking her to do more and more interviews with me. Amazingly, she agrees every time. This time Johanna talks about topics from her new book out with Esther Derby - "[Behind Closed Doors : Secrets of Great Management](http://www.amazon.com/exec/obidos/ASIN/0976694026/iserializable-20)": Learning to delegate, coaching effectively, giving effective feedback, what makes for effective meetings, Solving problems and some planning tips. If you've listened to any of the other interviews with Johanna (listed lower on this page) this is a nice take off from some of the topics Johanna has talked about in the past. This time we are concentrating more on the managerial side of things - things any new team lead or project lead needs to hear and read about.

Language - English.

Part I Download  - 49 min., MP3 (23 MB)

Part II Download  - 48 min., MP3 (22 MB)


                               
[](http://www.amazon.com/exec/obidos/ASIN/0321278658/iserializable-20) Johanna has written over 100 articles and papers and is now a columnist for Fast Company’s online career center, Software Development, Computerworld.com, and StickyMinds.com. Johanna is the author of the highly acclaimed [**Hiring the Best Knowledge Workers, Techies & Nerds**](http://www.amazon.com/exec/obidos/ASIN/0932633595/ref=nosim/rds-20), and is the coauthor of [**Corrective Action for the Software Industry**](http://www.amazon.com/exec/obidos/ASIN//0971323194/ref=nosim/rds-20). Johanna is also a host and session leader at the Amplifying Your Effectiveness (AYE) conference. --- **Kent Beck - An Agile conversation  (01/02/06)** After almost 8 months of scheduling nightmare, I've finally had the pleasure of having a great conversation with noted author and speaker, Kent Beck. This is more of a conversation rather than an interview. The conversation revolves around (but not limited to) the following subjects: Kent's upcoming book, "Implementation Patterns", Is Agile just another fad? What is Appreciative Inquiry? Why is the 1st edition of "XP Explained" totally wrong and misleading in its attitude, and what makes the 2nd Edition better? When does Pair Programming break and how does Kent feel about the book "XP Refactored"? All these and more topics in this intriguing conversation. There is much more we wanted to talk about, but Kent felt this would make for a nice "first iteration". Post your comments on this interview in [this blog post](http://weblogs.asp.net/rosherove/archive/2006/02/01/437077.aspx) and let us know what you'd like to hear about, or whether you agree or disagree with the topics in this conversation. We'll take all these into account during a future conversation we will record.

Language - English.

Download  - 76 min., MP3 (35 MB)

         Extreme Programming Explained : Embrace Change (2nd Edition)
[](http://www.amazon.com/exec/obidos/ASIN/0321278658/iserializable-20)

KENT BECK
Kent is the founder and director of Three Rivers Institute. He has pioneered patterns for software development, the xUnit family of testing frameworks, the HotDraw drawing editor framework, CRC cards, refactoring, and most recently Extreme Programming. He is the author of Extreme Programming Explained, Planning Extreme Programming, and The Smalltalk Best Practice Patterns. He lives on 20 acres in rural southern Oregon with his wife, five children (one sadly now gone to college), four dogs, two sheeps, and a variable number of domestic fowl.
**[](http://images.google.com/imgres?imgurl=http://www.agileuniverse.com/images/speakersPictures/kb&imgrefurl=http://www.agileuniverse.com/2003/speakers&h=357&w=300&sz=24&tbnid=oowfbux6Jud0fM:&tbnh=117&tbnw=98&hl=en&ei=uM7gQ6WMN8O6QqrOiNgJ&sig2=OhReIW1ohE6DnKjp8vquuw&start=5&prev=/images%3Fq%3Dkent%2Bbeck%26svnum%3D10%26hl%3Den%26lr%3D)** --- **David Platt and Juval Lowy - Why Software Sucks And Other Architectural Insights**    What do you ask when you get two software legends in one place? High level, world shattering questions, of course. Listen to this semi-serious chat mostly between Juval and David as they discuss matters such as Why software today sucks, Rich Client Vs. the browser, ClickOnce and unprotected sex (you heard correctly), the anthology of TLAs, how to know you're a geek, their upcoming books, top things to watch out for in .NET 2.0, where is software architecture heading, top 3 things every .NET developer should have done by now, Platt's laws of the universe and much more discussion, jokes and good ol' geeky fun. Truly a one of kind human experiment, is all I can say about this one.

Language - English.

Download  - 61 minutes, MP3 (28 MB)

                                       
**David S. Platt** teaches Programming .NET at Harvard University and at companies all over the world. He was selected by Microsoft as one of their Software Legends, which you can read about at [www.softwarelegends.com](http://www.softwarelegends.com/). He has taught classes on ACORD insurance standards since the very first OLifE class in 1995. He is the author of eight programming books, most recently _Introducing Microsoft .NET, 3rd Edition_ from Microsoft Press, with three more on the way. It is currently outselling Tom Clancy's _Every Man a Tiger_ on Amazon.com, which tells you what kind of geeks buy their books there. "He's the only guy I know that can actually make an article on COM's apartment threading model funny," said Tana Sabatino. Dave holds the Master of Engineering degree from Dartmouth College. He did his undergraduate work at Colgate University. When he finishes working, he spends his free time working some more. He wonders whether he should tape down two of his daughter's fingers so she learns how to count in octal. (Check them, has he done it yet?) He lives in Ipswich, MA. --- **Juval Lowy   - Project Planning and Tracking (24/8/05)** Juval was invited to speak to the Israeli .NET Fight Club, a special group of .NET Insiders in Israel, many of them MVPs and community leaders. Juval's visit was sponsored by Gadi Meir, of [Idag](http://www.idag.co.il/) Israel. Juval spent 2 hours talking about something he usually does not address in public conferences and such, not even in his books - the issues of software development process and project management. In these two hours he presents his vision and way of work in projects he managed (when he had both an architect and a project lead role) and the things he believes bring on the best result. The outcome is "Staged Delivery" which he outlines in broad strokes, yet specific enough to gain some good understanding of the concepts behind it. Some of the issues addressed include: Staffing, the product life cycle, component integration plan and the component life cycle, component testing, Estimation and estimation tools, Earned Value tracking and more. The talk ends 5 minutes prematurely due to technical difficulties, but let me assure you that you don't miss anything terribly important (no "surprise ending" :) )

Language - English.

Part I Download  - 60 minutes, MP3 (28 MB)

Part II Download  - 59 minutes, MP3 (27 MB)

                                       

Juval Löwy is the founder of IDesign and its Chief Architect. Juval is a seasoned software architect specializing in system architecture and large applications design. Juval helps IDesign customers design scaleable, robust, reusable, and extensible Enterprise applications, verifying that the customer has the design it takes to achieve the required quality, scalability, security, availability and throughput goals. Juval is Microsoft’s Regional Director for the Silicon Valley, working with Microsoft on on helping the industry adopt .NET. Juval also participates in the Microsoft internal design reviews for future versions of .NET. Juval is a frequent speaker at the major international software development conferences, where he talks about .NET, component-oriented design and development process. Click here for complete list of conference talks by Juval. Juval authored Programming .NET Components by O’Reilly. The book is dedicated to component-oriented programming and design using .NET, as well as the related system issues, such as remoting, threading and security. Juval also authored COM and .NET Component Services: Mastering COM+ a book which talks at length about the challenging topic of .NET Enterprise Services. Juval published numerous articles, regarding almost every aspect of developing with .NET. Click here for complete article list by Juval, as well as links to the articles. Microsoft recognized Juval as a Software Legend as one of the world top .NET experts and industry leaders.

  ---  **Randy Miller -MSF Agile and modeling techniques in software(TechEd Europe - July 2005)** I chatted with  [Randy Miller](http://blogs.msdn.com/randymiller), the guy who practically _wrote_ MSF,  for a very interesting half hour (due to technical difficulties we had to stop early). The interview revolves around MSF-  the Microsoft Solution Framework for creating software processes, its origins, its main goals and benefits and how it fits in with Microsoft Team System. We also talk a little about how it compares to other processes such as the Rational Unified Process. The conversation also turns into the fascinating topic of software modeling today and the use of "Personas" to capture design requirements. more stuff: MSF vs. CMMI, empowering developers in the development process, and the future of MSF.

Language - English.

Download  - 36 minutes, MP3 (16 MB)

                                     
Randy Miller (also known as Granville Miller) is author of Advanced Use Case Modeling and A Practical Guide to Extreme Programming.  He has spoken at many national events including OOPSLA, Web Services Edge, Software Development West, Microsoft TechEd and others.  He has also spoken for SPIN in the past ([http://www.rtpspin.org](http://www.rtpspin.org/)). You can find out more about Randy's work from his blog at: [http://blogs.msdn.com/randymiller](http://blogs.msdn.com/randymiller).  You can learn more about Visual Studio 2005 Team System at: [http://lab.msdn.microsoft.com/teamsystem](http://lab.msdn.microsoft.com/teamsystem).  And specifically about its plans to support the Agile methodology at: [http://blogs.msdn.com/team\_foundation/archive/2005/02/07/368599.aspx](http://blogs.msdn.com/team_foundation/archive/2005/02/07/368599.aspx) .   --- **Kieran Mockford-  Program manager for MSBuild, Microsoft -** **Building MSBuild, Test Driven Development style (February 28, 2005)** Length: 67 minutes. Language: English. [**Download**](https://www.5whys.com/audio/GeekSpeak_with_Kieran_Mockford.mp3) (48 MB, zipped Mp3) [Audio](https://www.5whys.com/audio/GeekSpeak_with_Kieran_Mockford.mp3) **Summary** Roy Talks with  Kieran Mockford, the program manager for MSBuild, Microsoft's brand new build tool offering. Kieran spills the beans that MSBuild was developed using Test Driven Development methodologies with tools such as [NUnit](http://nunit.org/). Kieran tells about the various problems and solutions they encountered trying to learn TDD, then the talk moves to MSBuild and the need for "real" incremental build abilities and the Microsoft internal build process. It's a Fascinating look behind the scenes of Microsoft's internal tools for source control and continuous integration automation tools. --- **Johanna Rothman at Agile Israel user group** **9 Steps to becoming Agile(March 23, 2005)** Length: 1 hour 26 minutes. Language: English. **Download** [**Part 1**](https://www.5whys.com/audio/JRothman_AgileIsrael_part_one.mp3) (50 minutes, 32 MB zipped MP3) [Audio](https://www.5whys.com/audio/JRothman_AgileIsrael_part_one.mp3) [**Part 2**](https://www.5whys.com/audio/JRothman_AgileIsrael_part_two.mp3) (36 minutes, 23 MB zipped MP3) [Audio](https://www.5whys.com/audio/JRothman_AgileIsrael_part_two.mp3) **Summary** [Johanna](http://jrothman.com/) Discusses the 9 steps each organization might want to consider as they start to move toward a more Agile development process. An interesting and funny speaker, Johanna discusses Daily builds, Automated smoke tests, Implementing by slice, Testing early and often, Timeboxing requirements work, ranking the requirements, Rolling wave planning, defining milestones based on deliverables -  not functions,and  creating cross-functional project teams. Johanna has written over 100 articles and papers and is now a columnist for Fast Company’s online career center, Software Development, Computerworld.com, and StickyMinds.com. Johanna is the author of the highly acclaimed [**Hiring the Best Knowledge Workers, Techies & Nerds**](http://www.amazon.com/exec/obidos/ASIN/0932633595/ref=nosim/rds-20), and is the coauthor of [**Corrective Action for the Software Industry**](http://www.amazon.com/exec/obidos/ASIN//0971323194/ref=nosim/rds-20). Johanna is also a host and session leader at the Amplifying Your Effectiveness (AYE) conference --- **Charlie Poole, Lead Developer, NUnit** **Test Driven Development, XP, NUnit and more (March 14, 2005)** Length: 1 hour 45 minutes. Language: English. **Download** [**Part 1**](https://www.5whys.com/audio/Charlie_Poole_Part1.mp3) (1 hour 11 minutes, 49 MB zipped MP3) [Audio](https://www.5whys.com/audio/Charlie_Poole_Part1.mp3) [**Part 2**](https://www.5whys.com/audio/Charlie_Poole_Part2.mp3) (34 minutes, 22 MB zipped MP3) [Audio](https://www.5whys.com/audio/Charlie_Poole_Part2.mp3) **Summary** Roy Talks with [Charlie Poole](http://www.charliepoole.org/), the lead developer of NUnit on various Agile topics. These include Upcoming NUnit features, Test Driven Development best practices, implementing XP in an organization, testing GUIs, threads, mock objects and much much more. Charlie also spills the beans about the upcoming NUnit blogs. Charlie has spent more than 30 years as a software developer, designer, project manager, trainer and coach. He works through his own company, [Poole Consulting](http://www.pooleconsulting.com/), in the US and recently joined Dublin-based [Exoftware](http://www.exoftware.com/CharliePooleJoining.htm) to provide mentoring and training to clients in Europe. --- **Juval Lowy - Great architects and management, January 18, 2005**
 

       Length: 73 minutes.

       Language: English.

       Download (58 MB, zipped Mp3)

**Summary** Roy Talks with  Juval Lowy, the principal of [IDesign](http://www.idesign.net/) and one of the industry's leading software architects. The topics include: Project management and the IDesign process, staged delivery and what's missing in today's Agile methdologies, the makings of a good software architect, details about his upcoming book and on the one to follow after that, the future of modeling tools, Longhorn, Indigo, SOA and interoperability and more. The interview also takes a more personal tone when Juval talks about his strategy for managing his busy schedule, how IDesign came to be and the people working there, the biggest mistake he's done and more tidbits. A feature packed 73 minute interview, is all I can say. --- **Natty Gur - Organizational Enterprise Architecture. January 16, 2005** Length: 72 minutes. Language: Hebrew. [**Download**](https://www.5whys.com/audio/Roy_Talks_with_Natty_Gur_160105.mp3) (55 MB, zipped Mp3) [Audio](https://www.5whys.com/audio/Roy_Talks_with_Natty_Gur_160105.mp3) **Summary** Roy Talks with [Natty Gur](http://weblogs.asp.net/NGur) - An independent software consultant specializing in Enterprise architecture - in the organizational level. In this interview we'll explore what organizational architecture really means and why its needed. More topics in the interview include Natty's open source project, [NWAF](http://nwaf.sf.net/), Service oriented architecture, organizational patterns such as [TOGAF](http://theopengroup.org/) and DODAF, the problems with layered architecture (N-Tier), Agile development, learning from past mistakes and Naked objects. Good stuff. --- **Johanna Rothman - Hiring Techies and Nerds  December 10, 2004** Length: 60 minutes. Language: English. \[[**Listen**](http://www.itconversations.com/shows/detail392.html) on ITConversations.com\] **Summary** Roy Osherove speaks with [**Johanna Rothman**](http://www.jrothman.com/) about everyday problems in project management, software delivery and the hiring of technical people. They discuss interviewing strategies, and some bad examples of interviewing technique. Also: How do I improve myself as a project manager?. How do I deal with unrealistic project deadlines? What's wrong with running multiple projects at the same time? What is the most common management mistake? Then, the topic shifts to the problems of project management as Johanna tries to answer a tough question such as, "What is the greatest mistake you see project managers do most often?" which leads into an interesting discussion about multi-projecting and why it can pose a problem for your projects. Also, more interesting advice from Johanna emerges when asked to give advice for new team-leaders/managers. Johanna also talks about her new book: Hiring The Best Knowledge Workers, Techies & Nerds. And why she wrote it in the first place. To finish it all off Johanna answers one of the questions each project manager should ask themselves every once in a while: "What is the worst mistake you’ve done as a manager?" Johanna has written over 100 articles and papers and is now a columnist for Fast Company’s online career center, Software Development, Computerworld.com, and StickyMinds.com. Johanna is the author of the highly acclaimed [**Hiring the Best Knowledge Workers, Techies & Nerds**](http://www.amazon.com/exec/obidos/ASIN/0932633595/ref=nosim/rds-20), and is the coauthor of [**Corrective Action for the Software Industry**](http://www.amazon.com/exec/obidos/ASIN//0971323194/ref=nosim/rds-20). Johanna is also a host and session leader at the Amplifying Your Effectiveness (AYE) conference. --- title: "Be Productive and Go Mouseless" url: "https://www.5whys.com/articles/be-productive-and-go-mouseless.md" canonical: "https://www.5whys.com/articles/be-productive-and-go-mouseless.html" published: "2009-09-25T08:00:21+00:00" updated: "2009-09-25T08:01:44.079000+00:00" tags: ["Growing People", "Self Improvement", "Video"] author: "Roy Osherove" description: "Watch on YouTube Go Mouseless" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Be Productive and Go Mouseless [![](https://www.5whys.com/img/video/youtube-yMnUtQ7E7Rc.jpg)Watch on YouTube](https://www.youtube.com/watch?v=yMnUtQ7E7Rc) Go Mouseless --- title: "Be Productive and Stop Using XML" url: "https://www.5whys.com/articles/be-productive-and-stop-using-xml.md" canonical: "https://www.5whys.com/articles/be-productive-and-stop-using-xml.html" published: "2009-09-25T05:37:24+00:00" updated: "2009-09-25T05:40:29.091000+00:00" tags: ["Video"] author: "Roy Osherove" description: "Watch on YouTube Stop using XML" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Be Productive and Stop Using XML [![](https://www.5whys.com/img/video/youtube-wMdxtjeY3QI.jpg)Watch on YouTube](https://www.youtube.com/watch?v=wMdxtjeY3QI) Stop using XML --- title: "Why managing a software team can be more effective than \"regular\" management" url: "https://www.5whys.com/articles/why-managing-a-software-team-can-be-more-effective-than-regu.md" canonical: "https://www.5whys.com/articles/why-managing-a-software-team-can-be-more-effective-than-regu.html" published: "2009-09-24T17:50:24+00:00" updated: "2009-09-24T18:17:24.327000+00:00" tags: ["people patterns"] author: "Roy Osherove" description: "Over on the team leadership mailing list , Yves claimed: \"Is leading a software team different then leading another team? No it's not. Can it help to know about writing software? yes if you can also let go of control. (which you would have…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Why managing a software team can be more effective than "regular" management Over on [the team leadership mailing list](http://groups.google.com/group/leading-teams/msg/4a7858dfabe0174b), [Yves](http://paircoaching.wordpress.com/) claimed: > "Is leading a software team different then leading another team? No  > it's not. Can it help to know about writing software?  > yes if you can also let go of control.  > (which you would have o do if you did not know software) " I disagree. Managing a software team **is** different than managing a non software team, in that _software_ by definition is a _soft_ thing - it rotates, mutates and changes form, and with proper automation, we can break down many time "barriers" which are not possible to break in the real world. I touched a little bit on this in a previous post, where I said that [in software, you can achieve immediate satisfaction,](https://www.5whys.com/articles/immediate-and-delayed-satisfaction-in-software-development.html) vs. life, where immediate satisfaction is _wanted_ but is many times un-achievable. ### The hidden skill: Automation In software, you can teach and demand that a team break down many such "fake" barriers to be more productive, wheas in real life, there are things that as a manager you might accept as final truth ("mail always needs to be opened manually"). As a software lead, you have many more options to come in and change the flow of things by changing how the underlying team's infrastructure works (automated builds, deployments, tests etc..) What other things are different in managing software teams? --- title: "Manifesto for Continuous Improvement" url: "https://www.5whys.com/articles/manifesto-for-continuous-improvement.md" canonical: "https://www.5whys.com/articles/manifesto-for-continuous-improvement.html" published: "2009-09-24T17:40:34+00:00" updated: "2009-09-24T17:49:38.207000+00:00" tags: ["Ri", "Self Improvement"] author: "Roy Osherove" description: "thanks for the picture, Andrew . the difference between the picture above and continuous improvement? The answer to \"Are you Happy\" is always \"No\"." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Manifesto for Continuous Improvement thanks for the picture, [Andrew](http://www.21apps.com/blog/). ![](https://www.5whys.com/img/posts/3d83e5c2-Areyouhappy.jpg) the difference between the picture above and **continuous** improvement? > The answer to "Are you Happy" is always "No". --- title: "Growing developers: Ask for solutions instead of giving them" url: "https://www.5whys.com/articles/growing-developers-ask-for-solutions-instead-of-giving-them.md" canonical: "https://www.5whys.com/articles/growing-developers-ask-for-solutions-instead-of-giving-them.html" published: "2009-09-18T00:38:51+00:00" updated: "2014-05-22T22:16:57.015000+00:00" tags: ["Decision Making", "Growing People"] author: "Roy Osherove" description: "This post is part of the \" Growing Developers \" guidance. One of the best things you can do for the developers on your team is to stop giving them the solutions to problems they are facing, and instead ask them to find the solution on…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Growing developers: Ask for solutions instead of giving them This post is part of the "[Growing Developers](https://www.5whys.com/articles/5-ways-to-grow-great-developers-instead-of-desperately-looki.html)" guidance. One of the best things you can do for the developers on your team is to stop giving them the solutions to problems they are facing, and instead ask them to find the solution on their own. I'm talking of course about problems that are under their control, not things which require you to make it happen. A few examples: - If a developer comes to you asking about what a specific API of the application infrastructure might look like - don't follow your initial feeling. Don't give them your idea of what a good API for that part of the app might look like.  Instead, ask them to come up with 3 different possible designs, and show them to you. Give them a time frame for coming up with the designs. They can use a peer or the whole team to help get the design of the API right, or they can do it alone. It's their choice.  When they come to you with the API you might be pleasantly surprised by what they have. If you don't like what they came up with, you can explain why you don't like their solutions, and ask why they came up with that solution in the first place. This would be a great place to ask them what values they were thinking of when they designed the API (maybe none!). This might be a good time to gather the team and ask them to come up with guidelines for an API (short? single point of entry? no singletons?) and then ask the person who came up with the initial problem to go back to the drawing board and come up with another three solutions for the API, and choose the one that best fits the design guidelines the team has chosen. All this process may take a bit of time at first (instead of 10 minutes of you giving them an API, they might spend half a day working on it if they've never had guidelines before). But this is time **well spent**.  ### What do you get from this? - The team is honing its skills - they become better at what they do - The team comes up with shared knowledge about how things might looks in specific scenarios - The team can now come up with its own solutions to a specific set of problems, using very simple guidelines - You will be less of a bottleneck next time such a problem occurs It's important to not only ask for one solution, but to ask for multiple solutions. At the very least, the team is open minded and not dead set on a specific choice from the get go. But there is an added benefit to multiple solutions: Multiple solutions allow the company to "select' the solution that best fits the current status of the company in the marketplace. For example, one API design could be beautiful, but would take far too long to implement, when you have urgent things to do and get ready for a version. Another API might be great for the short term but very risky in technical terms as it relies on a third party product that the company maybe disconnecting its ties with next month. In short, not only are you growing your team and giving them tools to solve their own problems, you are also making the company more adaptable to changes (in the small, but that's something!). ### What if they can't decide? If your team can't come up with a good solution of can't agree on the best one you can help them in several ways:  - Give them a time-box: "in 15 minutes you should choose one of these and that's it" - Ask them if they want to add another "value" to decide against to make deciding easier - Give them hints as to what they may have forgotten to discuss - Make the choice for them (not recommended) ### What if they don't know enough to decide? You can ask them to learn the subject matter before deciding. It might lengthen the decision but you will lower the technical risk of using something you don't understand. It could also be sign that they are way our of their comfort zone (a team of infrastructure doing UI for the first time for example) - you can ask them to do a small "spike" - a simple proof of concept for a couple of ways to achieve the solution for a problem. should not take more than a day or two. After the spike they will know more. ### This whole idea is just adding lots of time to our schedule! Like it or not - learning takes time. Things slow down a bit at first. You need to be confident in yourself and your team that you will all be better for this. This scares you? good. Means you're our of your comfort zone as well! That's not a bad place to be - this is the place where you actually learn something. treat it as an experiment - see what happens. --- title: "5 ways to grow great developers instead of desperately looking for them" url: "https://www.5whys.com/articles/5-ways-to-grow-great-developers-instead-of-desperately-looki.md" canonical: "https://www.5whys.com/articles/5-ways-to-grow-great-developers-instead-of-desperately-looki.html" published: "2009-09-16T20:13:47+00:00" updated: "2014-05-22T22:37:16.017000+00:00" tags: ["Growing People", "Ha"] author: "Roy Osherove" description: "One of the most common phrases you hear from managers about lack of agile adoption in their team is We don't have that kind of 'super' developer here. We just have ordinary day folks - they can't handle it. And We can't seem to find anyone…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 5 ways to grow great developers instead of desperately looking for them One of the most common phrases you hear from managers about lack of agile adoption in their team is  > We don't have that kind of 'super' developer here. We just have ordinary day folks - they can't handle it. And We can't seem to find anyone who can fit what we look for. The real key to being a great leader is that if you do your job right, than you'll make your developers better and better  - you **will grow them** until they become the developers _you wish you had_.  > Grow your developers into their full potential and you won't have to [seek anyone](http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html) from the outside I'm not saying it's easy. As a team lead, helping people grow was one of the toughest things I've had to do. It got me way out of my comfort zone, and i had to do things I'd never imagined doing, but that means that I also  _grew personally as a lead_ while growing other people. Today I feel more confident than ever that given a team I can start my way to making the team a better team, instead of always looking to the outside. ### How do you grow people?  Here are the the headlines (i'll blog about each separately) 1. Give them "Homework" about things that will make them better 2. Take them (and yourself) out of their comfort zone 3. Ask them to [come up with multiple solutions to problems](https://www.5whys.com/articles/growing-developers-ask-for-solutions-instead-of-giving-them.html) 4. If you're not happy with someone's current state, be assertive about not accepting it and ask them to commit to be better (management by integrity) 5. [Implement code reviews](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html) and teach them to do them on their own Of course, to get all these things going there are several simple conditions that have to be met first: - You should be s[pending enough time with your team, at least 50%](https://www.5whys.com/articles/spend-at-least-50-of-your-time-with-your-team.html) - You should have full [control of the dev team territory](https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.html) - You should be fully committed to doing this - this is hard work and will add more tasks to your day --- title: "Announcing the Team Leadership Google Group" url: "https://www.5whys.com/articles/announcing-the-team-leadership-google-group.md" canonical: "https://www.5whys.com/articles/announcing-the-team-leadership-google-group.html" published: "2009-09-16T14:04:29+00:00" updated: "2009-09-16T14:20:50.833000+00:00" tags: ["From the mailing list"] author: "Roy Osherove" description: "I believe the next wave of issues that we will need to start solving is that of software leadership. We may all believe in the stuff that agile, tdd and the like bring to the company, but we often have problems following through on these…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Announcing the Team Leadership Google Group I believe the next wave of issues that we will need to start solving is that of software leadership. We may all believe in the stuff that agile, tdd and the like bring to the company, but we often have problems following through on these, since we can't find a way to drive the people in our teams to "get" these things. Team leadership is the essential skill that binds together the will do be better and the ability to drive a team to be better, and to eventually truly become a self directing group of people.   I think most software leads suck at people skills, at driving their team and getting things ready to be more agile. and I think that's one of the main reasons some agile adoptions fail so badly. But I have not found a place to get anwers on leading teams at the people level, or even at the basic skill level that would target exactly this role.   I started [/](https://www.5whys.com/) for that reason, but I believe that many of us will benefit from a more open and honest dialog about managing people, the problems we deal with, and ways to solve them. I invite you to join the group at [http://groups.google.com/group/leading-teams](http://groups.google.com/group/leading-teams) I'll be posting interesting discussions from that group here as well. --- title: "9 Articles from Joel On software for Tech Leads" url: "https://www.5whys.com/articles/9-articles-from-joel-on-software-for-tech-leads.md" canonical: "https://www.5whys.com/articles/9-articles-from-joel-on-software-for-tech-leads.html" published: "2009-09-15T22:02:29+00:00" updated: "2009-09-15T22:08:04.063000+00:00" tags: ["Link Love", "JoelOnSoftware", "schedule"] author: "Roy Osherove" description: "JoelOnSoftware has a bunch of links under the heading of \"Tech Lead\". I've read some of them, but for future reference I'll post them here as well: Two Stories Human Task Switches Considered Harmful Lord Palmerston on Programming The…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 9 Articles from Joel On software for Tech Leads [JoelOnSoftware](http://www.joelonsoftware.com/) has a bunch of links under the heading of "Tech Lead". I've read some of them, but for future reference I'll post them here as well: - [Two Stories](http://www.joelonsoftware.com/articles/TwoStories.html) - [Human Task Switches Considered Harmful](http://www.joelonsoftware.com/articles/fog0000000022.html) - [Lord Palmerston on Programming](http://www.joelonsoftware.com/articles/LordPalmerston.html) - [The Development Abstraction Layer](http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html) - [Three Management Methods (Introduction)](http://www.joelonsoftware.com/items/2006/08/07.html) - [The Command and Control Management Method](http://www.joelonsoftware.com/items/2006/08/08.html) - [The Econ 101 Management Method](http://www.joelonsoftware.com/items/2006/08/09.html) - [The Identity Management Method](http://www.joelonsoftware.com/items/2006/08/10.html) - [Evidence Based Scheduling](http://www.joelonsoftware.com/items/2007/10/26.html) > Hey Joel, if you ever read trackbacks, I want a guest post from you here! The thing about Joel is simple: It's not like he's the world's perfect manager, and I wouldn't recommentd that you follow blindly anything he says. I **woud** however recvommend that you read some of the things he writes about this topic because 1. He writes really well 2. He makes good points 3. He challenges you to think so even if you don't agree, at least you came out a but more invigorated about what you do. --- title: "IDCC talk: Beautiful teams and code leaders is online" url: "https://www.5whys.com/articles/idcc-talk-beautiful-teams-and-code-leaders-is-online.md" canonical: "https://www.5whys.com/articles/idcc-talk-beautiful-teams-and-code-leaders-is-online.html" published: "2009-09-15T21:05:14+00:00" updated: "2009-09-15T21:08:49.403000+00:00" tags: ["Shu", "Video"] author: "Roy Osherove" description: "yesterday the first IDCC conference took place - it is a grass roots community driven conference and it was great! My talk on beautiful teams and code leaders is online here (in Hebrew). The list of questions every team lead should ask…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # IDCC talk: Beautiful teams and code leaders is online yesterday the [first IDCC conference](http://www.idcc.co.il/) took place - it is a grass roots community driven conference and it was great! My talk on beautiful teams and code leaders [is online here](http://iwebcast1web.you-niversity.com/SLVideoPLayer/Player.aspx?ID=ed499188-3a17-4f7c-8bca-7a9632d6ec81) (in Hebrew).  The list of questions  every team lead should ask themselves I showed at the end [can be found here](http://weblogs.asp.net/rosherove/archive/2009/06/16/questions-every-team-and-dev-lead-should-ask-themselves.aspx). I will post a better one on this blog soon. --- title: "Poll: Would you join a team leadership forum on this site?" url: "https://www.5whys.com/articles/poll-would-you-join-a-team-leadership-forum-on-this-site.md" canonical: "https://www.5whys.com/articles/poll-would-you-join-a-team-leadership-forum-on-this-site.html" published: "2009-09-15T20:34:17+00:00" updated: "2009-09-15T20:38:14.041000+00:00" tags: ["Poll"] author: "Roy Osherove" description: "Please answer this quick poll, so I can decide if I should spend time on creating a forum for team leadership on this site. A forum will only work if there is a critical mass of people watching it, and I want to make sure it doesn't wither…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Poll: Would you join a team leadership forum on this site? Please answer this quick poll, so I can decide if I should spend time on creating a forum for team leadership on this site. A forum will only work if there is a critical mass of people watching it, and I want to make sure it doesn't wither and die in a week. if you said "no", I'd love to know why, in the comments. Maybe there already is a good one somewhere out there that I don't know about. Maybe there's a mailing list already filled with great people. who knows! --- title: "How to say NO by saying YES" url: "https://www.5whys.com/articles/how-to-say-no-by-saying-yes-1.md" canonical: "https://www.5whys.com/articles/how-to-say-no-by-saying-yes-1.html" published: "2009-09-14T20:01:57+00:00" updated: "2009-09-14T20:15:15.056000+00:00" tags: ["Decision Making", "Shu", "Visual Task Board"] author: "Roy Osherove" description: "Johanna Rothman, a dear friend and one of the most excellent management consultants I've seen, has a post about managers who won't take no for an answer . Read it, it's interesting! But I'd like to approach the same issue from a different…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to say NO by saying YES Johanna Rothman, a dear friend and one of the most excellent management consultants I've seen,  [has a post about managers who won't take no for an answer](http://jrothman.com/blog/mpd/2009/09/when-managers-cant-hear-no.html). Read it, it's interesting! But I'd like to approach the same issue from a different angle - Instead of looking at why the manager wants something, let's try and look on why we say "No" to that something (This is a good place to try the [five whys technique](http://en.wikipedia.org/wiki/5_Whys)).  Usually we'll find that we say no because the requested item might be of lower priority and could interfere with much more pressing items. Sometimes we'll just feel like the manager is asking fomr something just because he\\she can - and we don't like people wasting our time. Instead of saying no, let's let the manager figure out if a "No" is indeed in order. WHat you'd need for this is at the very least [a Visual Task board](https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.html) or an excel file with the list of tasks you're doing and backlog of items to be done, **ordered by priority**. Next time the manager comes in and asks for something  in the middle of something else, drag them over to look at the task board. Now, create a new post it note with the task at hand, and ask thema simple question: > How important is this? If they say "I'd love to have it today", ask them : > OK, that means we will have to stop working on one of these following tasks (point to the "in progress" column).  Are you OK with us stopping to work on \[pick one of the cards in progress\]? If they say yes - great. Not only did you find an important feature to work on, you've also let the manager know the cost of doing that feature: Stopping to work on another feature. But what usually happens is that the manager soon realizes that this cost exists, and may not want to replace an existing in progress task  - since these are all pretty important as well. The manager might say "well, no, it's not **that** important".  This is the point where you ask them to actually place the card in the "TODO" column just above one of the other tasks in it. They get to **choose** which is more important. More often than not, the task at hand will not be important enough to trump any of the existing "TODO" cards, so it will be at the bottom. Now you've gained something else - the manager has agreed knowingly to delay that feature request, since they know its true cost. Visual Task boards help you teach your manager when to say "NO' all on their own. --- title: "Document Your Air, Food, and Water" url: "https://www.5whys.com/articles/document-your-air-food-and-water.md" canonical: "https://www.5whys.com/articles/document-your-air-food-and-water.html" published: "2009-09-14T19:49:49+00:00" updated: "2009-09-14T21:00:08.583000+00:00" tags: ["Guest Post", "Shu", "Documentation", "Travis Illig"] author: "Roy Osherove" description: "Editor's note: The following is a guest post by Travis Illig . Travis Illig is a .NET developer who enjoys the art of solving problems with technology. He is currently a Senior Software Developer with Fiserv, working on next-generation…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Document Your Air, Food, and Water > **_Editor's note:_** _The following is a guest post by [Travis Illig](https://www.5whys.com/contact). Travis Illig is a .NET developer who enjoys the art of solving problems with technology. He is currently a Senior Software Developer with Fiserv, working on next-generation online banking products. He holds a BS in Computer Science from Portland State University and is a Microsoft Certified Solutions Developer (MCSD) for .NET. Travis can be contacted through his blog at [http://www.paraesthesia.com](http://www.paraesthesia.com/)._ > > - _If you'd like to submit your own guest post, [contact me](https://www.5whys.com/contact)._ Think about all of the things you need to know when you're new to a team. There are a lot of things, right? - Where is the source code repository? - Which tools need to be installed on your developer environment? - What are the steps to build the product? - Is there a pattern for how the code is laid out in the repository? - How are tasks tracked? - What is the task branch pattern in the repository? - Where is the continuous integration server? - Are there any specific development methodologies that should be followed? ...And so on. This is, from a [peer mentoring perspective](http://www.peermentoring.com/), the "Air, Food, and Water" for the group. It's the stuff you need to know in order to basically get around. Many times, the answers to these questions aren't actually documented anywhere. It's "tribal knowledge." People just sort of "know" what needs to be done, and if you don't know, you ask the group. That sort of approach might work well in a small group that doesn't change a lot... but what about in a larger group? Does everyone actually know? Or is there a slightly different understanding of how things work from person to person? And what about new team members? It's a good idea to **document your air, food, and water** in a central location that's accessible to everyone. Keep sort of a "team FAQ" that has the answers to all of these questions and make sure everyone knows where it is. It doesn't have to be reams of heavy documentation, but it should contain enough to clearly answer the questions. **Why document?** - **Enable team members to help themselves.** [It's generally understood](http://www.codinghorror.com/blog/archives/000691.html) that "quick questions" causing team members to task switch [are actually not as "free" as one might think](http://www.fastcompany.com/articles/2008/07/interview-gloria-mark.html). If there's a place that folks can go to answer simple questions, it reduces context switches, particularly when there are newer members on the team. - **Give new team members confidence in the team.** Last time you joined a team, how was the experience? Did it seem a little jarring or was it really smooth? When you're new to a team it's like meeting a person for the first time... and you only get one chance for a first impression. Wouldn't it be nice to join a team and have the reassurance that there's a plan and a simple document that lays out everything you need to know to get going? If you saw that, wouldn't you gain a little confidence in the team? - **Add visibility into your team.** If there are other people or teams in your company that are interested in seeing how you're doing things (maybe to learn something from your team?), having a document makes it easy for them to see how things are done and understand what they're looking at. **How do you get started? How do you maintain it?** 1. **Find a location.** Find a central place on your company's network that you can store the document such that everyone has access to it. Maybe it's a wiki. Maybe it's a SharePoint site. Maybe it's a simple file share. As long as everyone has access to it, it's perfect. 2. **Document as you get asked questions.** As people have questions about how the team works - where the source code is, etc. - Refer them to the document. If the answer isn't there, consider adding the answer to the document and providing the document to the person asking the question. Eventually you'll have a document with the answers to the most frequently asked questions about the team. 3. **Pass it by exiting team members.** Team members come in, and team members move on. Before a team member moves on from the team, part of the knowledge transfer should be having them review the document and fill in applicable answers. There may be some things that team member was responsible for that no one else really knows about. 4. **Give it to new team members.** When a new member comes on board, give them the document as a way to get them set up. It will quickly become apparent if the information on the document is incomplete. When incomplete/incorrect information is encountered, have the new team member work with the team to find out the correct information and update the document. 5. **Update as changes occur.** As changes are made in the way the team works, update the document to reflect them. There shouldn't be so much information there that it's overwhelming to maintain, but the doc does need to be a living entity, just as your team is. Make sure to **keep your document fairly lightweight and easy to maintain**. If it's too thick or complex, if information is repeated in multiple places throughout, people will skip updating it and eventually it will become stale. You don't want that - you want it to be easy so when it's time to update, it's _simple, simple, simple_. It doesn't take much and it pays off in spades. Why not start today? --- title: "Immediate and delayed satisfaction in software development" url: "https://www.5whys.com/articles/immediate-and-delayed-satisfaction-in-software-development.md" canonical: "https://www.5whys.com/articles/immediate-and-delayed-satisfaction-in-software-development.html" published: "2009-09-10T23:34:44+00:00" updated: "2009-09-13T22:10:32.027000+00:00" tags: ["Decision Making", "Ri", "people patterns"] author: "Roy Osherove" description: "All our lives we're told a mantra that keeps repeating itself. We hear it as children when we want an ice cream, and we hear it as adults when we want that brand new car, or that holiday vacation: Have some patience But in the software…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Immediate and delayed satisfaction in software development All our lives we're told a mantra that keeps repeating itself. We hear it as children when we want an ice cream, and we hear it as adults when we want that brand new car, or that holiday vacation: > Have some patience But in the software world - things become a bit chaotic. Your boos wants things done **now**. The customer wants things done **now**. Not later, not tomorrow.  So what do we tell our customer? > Have some patience (and these changes you wanted tomorrow can wait 6 months) What do we tell our boss, though? > Um, OK. I think we might be able to do that! That's right. We succumb to our own feelings that we _want_ to be able to do anything quickly, so we say we will (but we never do, do we?) ### Why don't we ever get to that point where things can be done **now** in software?  There's a simple answer: We are letting ourselves be patient with our development process and tools. We allow **waste of time** when we build the things that we promised our boss we'll deliver **now.** - When we want to release a product we get told that it will take 3 weeks to make sure everything works - so what do we tell ourselves? > Have patience - When our machine has bluescreened for the 3rd time today, our source control takes 10 minutes to get the latest version of 2 files and our team keeps finding bugs manually by debugging - we say one thing to ourselves: > Have patience Somehow, we have convinced ourselves that in software, like real like, there are certain things you must take for granted (death and taxes). things you can't fight, so you shouldn't even try. We fail to realize that in software, like in The Matrix, rules can be bent. Things that take a long time can be automated. Things that are hard to do can be made easier with tools (or by removing tooling!) People who cannot live with delayed satisfaction in the real world, suffer from the environment, since some things, they learn, are simply going to have to wait. they may feel more negative about things, they may seem pushy, abrasive and ill mannered, but they are just troubled by a built in lack of what psychologists call "Optimal Frustration" - the ability to wait for what you really want, and still feel OK about it. Funnily enough, in Software, those same people can be tremendously successful team lead, due to that exact lack of ability to endure delayed satisfaction. Thos eare the people that keeps asking qustions like these: 1. "Why can't I have a working build with installer at the push of a damn button?" 2. "Is there a reason you invited me to this meeting? you're wasting my time" 3. "Why do I have to login to my computer to see how the team is doing?" 4. "WHy are we still doing this manually?" and so on. eventually, what these people drive is the ability for an organization to not delay its satisfactions - when they want to release something, they can do it on a whim. When they want to fix a bug and send a patch to a customer, they can do it without a hassle. if they really want to, they can fix something that just came in as high priority in the **middle** of an iteration and not even flinch. --- title: "The three stages of learning team leadership" url: "https://www.5whys.com/articles/the-three-stages-of-learning-team-leadership.md" canonical: "https://www.5whys.com/articles/the-three-stages-of-learning-team-leadership.html" published: "2009-09-10T23:11:49+00:00" updated: "2009-09-13T22:10:10.197000+00:00" tags: ["Meta", "Ri", "ShuHaRi", "cockburn"] author: "Roy Osherove" description: "or anything else, for that matter: Shu-Ha-Ri : Practices Principles Values *see related to this: Source: ShuHaRi and competence Cockburn on ShuHaRi This blog is right now at the \"Practices\" stage: Lots of \"Do this\" and \"Don't do that\"…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The three stages of learning team leadership or anything else, for that matter: **Shu-Ha-Ri** : - Practices - Principles - Values \*see related to this: - Source: [ShuHaRi and competence](http://blog.shino.de/2009/08/20/shu-ha-ri-related-to-competence/) - [Cockburn on ShuHaRi](http://alistair.cockburn.us/Shu+Ha+Ri+to+Practices+Principles+Values) This blog is right now at the "Practices" stage: Lots of "Do this" and "Don't do that", with just a little "Principles" thrown into the mix. The values? Those take time to develop. It's those "Values" that will make people write comments on these blog posts that don't agree with the post's sentiment, as they talk about a practice, instead of a value (when they coexist nicely). For example, on my "Own your team and territory" post, i got quite a few comments that say "You must let the team learn how to do these things etc, which is more in terms of a "value" system. But in the context of a "Learn initial practices" system, it does make sense, since that person has not yet masterd and feels comfortable with the accompanying princinples and values attached. when they will (and they will eventually) they can (and should!) start questioning their tactics - for at this point, in this context, those initial practices are the right thing: \= they are easy to follow \= they will bring some peace to the team and the lead so they can start focusing on more principles \= the values will have to be "earned" during time. Test Driven Development is the same way: 1. you start out with the 3 rules of TDD (practices - failing test, code to pass, refactor) 2. you learn why they matter (the principles - test the test, think small, have partial work etc..) 3. you learn the values of a SOLID designed system, and the ability to take and get quick feedback, and start aiming how and when you use TDD within those values. --- title: "One-Liners a new team lead should and shouldn't read" url: "https://www.5whys.com/articles/one-liners-a-new-team-lead-should-and-shouldnt-read.md" canonical: "https://www.5whys.com/articles/one-liners-a-new-team-lead-should-and-shouldnt-read.html" published: "2009-09-10T20:37:24+00:00" updated: "2009-09-13T22:09:22.237000+00:00" tags: ["Ha", "advice", "cockburn", "one liners"] author: "Roy Osherove" description: "Alistair's blog\\wiki has a set of specific one liners from programmers - to newly minted team leads. The whole list is here. My 3 favorites were: Whatever their job is, help them be better at it. You are now a junior person in a brand new…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # One-Liners a new team lead should and shouldn't read Alistair's blog\\wiki has a set of specific one liners from programmers - to newly minted team leads. [The whole list is here.](http://alistair.cockburn.us/Advice+to+a+new+team+lead) My 3 favorites were: Whatever their job is, help them be better at it. You are now a junior person in a brand new career that you never were trained for – and keep in mind that the medium you are working in is PEOPLE. People will bring you their issues with teammates – it will help to give your people some training in how to deal with those issues themselves. Notice that they all talk about the idea that you are working with people, and that driving people to be better, and caching them to solve their own problems is important. Now, here are a couple that I **didn't** like: YOU ARE THE ABSTRACTION LAYER – you provide the Bubble of Happiness. Only to a certain point. Once your team is ready to face challenges, it's OK, and even welcome to start letting them deal with real world stuff  - how do they handle outside interference? what happens when a higherup asks for a small feature really quickly?  A mature agiel team should be able to handle these, but don't try to let them handle it if you're all still learning the territory. It's OK to have an "incubator" where the team lead only gets all the "heat" from the outside, but that doesn't mean that a team can't go and face their real customer and see what their all about. --- title: "Generating Internal vs. commercial value" url: "https://www.5whys.com/articles/generating-internal-vs-commercial-value.md" canonical: "https://www.5whys.com/articles/generating-internal-vs-commercial-value.html" published: "2009-09-10T20:15:14+00:00" updated: "2009-09-13T22:09:03.057000+00:00" tags: ["Lean", "Ri"] author: "Roy Osherove" description: "Alistair writes about something which I've only thought about in small glimpses, moving on to my daily business: One of the basic ideas behind lean development is that you narrow the amount of process that is done at the company to only…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Generating Internal vs. commercial value [Alistair writes](http://alistair.cockburn.us/Internal+versus+commercial+value) about something which I've only thought about in small glimpses, moving on to my daily business:  One of the basic ideas behind lean development is that you narrow the amount of process that is done at the company to only those things that add value. Continually trying to remove "waste" from your process is a key learning. The big question is "What is value". If your manager is big into "lean" they can say "Don't work on refactoring - it doesn't add any value to the customer" "Don't work on making the build faster - there is no customer value in that" but we all know there certainly is. It's internal value - that makes sure things are kept at the highest quality. In "Lean Software Development" the toyota way is introduced. What I've gleaned from it, among other things, is that you "remove waste - but keep the things you cannot do without" It is those things that make "internal value": - a constantly trimmed and refactored build process - constant refactoring of code base - code churning for readability - teaching people - coaching about problems - having fun at work There is indeed internal value in these things, but as alistair says = there is the danger of saying that anything brings internal value.  For an agile team - it is those things "you can't do without" that you take from more specific techniques like TDD, XP, Continues automation etc... --- title: "Spend at least 50% of your time with your team" url: "https://www.5whys.com/articles/spend-at-least-50-of-your-time-with-your-team.md" canonical: "https://www.5whys.com/articles/spend-at-least-50-of-your-time-with-your-team.html" published: "2009-09-10T06:36:37+00:00" updated: "2014-05-22T22:18:48.003000+00:00" tags: ["First Steps during chaos", "Shu", "meetings", "schedule"] author: "Roy Osherove" description: "To be an effective team lead, you need to actually spend time with your team. Otherwise, you won't be able to do daily stand-ups , do code reviews , or sit down and pair with a team member every once in a while. And no, \"I have too many…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Spend at least 50% of your time with your team To be an _effective_ team lead, you need to actually spend time with your team. Otherwise, you won't be able to [do daily stand-ups](https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.html), do [code reviews](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html), or sit down and pair with a team member every once in a while. And no, "I have too many meetings" is _not_ a good excuse. ### "But I _do_ have too many meetings to attend each day!" Then it's time to stand up for your team's rights  - their basic right is to have a team lead present to help solve problems and bottlenecks that the team can't figure out alone, and to have a lead that helps them learn how to overcome problems. - Go to your outlook schedule and _book_ 50 % of each work day during the week under "team time". Make this a recurring meeting that no one can override. - Look at the list of current meetings you attend and start trimming them down to meetings you really do need to attend, and ones where the team or you are not getting any value out of. It's sometimes valuable to start asking the Five Whys for each meeting, and see whether you can find a way to solve the problem that the meeting is trying to solve. For example: -   - Meeting: "Daily meeting of department heads" - Length: 1-2 hours - Time I actively participate in the meeting: 5-10 minutes - Time I actively listen in the meeting: 30-40 minutes - Why do I have to be in this meeting? _I'm not sure_ - What do people usually ask me in this meeting? _general questions about my projects progress._ - _Why? Because they don't have any other way to know_ - _Why? because **there is no clear and visible progress on my projects**_ - _Why? Because I haven't made this a reality yet_ Do you know what you should do now to avoid this meeting? ### Be assertive at the very least you could take these actions about various meetings where you only need part of the time to be inside or none at all: - Tell (don't ask!) who ever is running the meeting that you will no longer be available to be in it If they ask "But then how will **I**..." then you know what it is you need to deliver in terms of knowledge so as to make the meeting unneeded. If they ask "But then how will **YOU**..." then you will realize that you may not need that information, or are getting it in a different way, or that you may indeed need to be in this meeting, but for a shorter  period of time. - Tell (don't ask!) who ever is running the meeting that you will only be available for 30 minutes during the meeting (otherwise development will suffer). After 30 minutes - leave the meeting. Stand up for your decisions. See what happens. --- title: "Is face to face pairing better?" url: "https://www.5whys.com/articles/is-face-to-face-pairing-better.md" canonical: "https://www.5whys.com/articles/is-face-to-face-pairing-better.html" published: "2009-09-09T11:37:42+00:00" updated: "2009-09-13T22:08:22.065000+00:00" tags: ["Ha", "Pair Programming"] author: "Roy Osherove" description: "Two people working on the same machine at the same time? crazy! only, not really. But i'll touch on why pair programming works so great in a different post. This post is about showing a wholly different style of pairing with someone than…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Is face to face pairing better? Two people working on the same machine at the same time? crazy! only, not really. But i'll touch on why pair programming works so great in a different post. This post is about showing a wholly different style of pairing with someone than I'm used to: [Face to face to pairing](http://www.exampler.com/blog/2008/12/10/screen-pairing/) (they call it screen pairing) In the post, Brian gives several reasons why he likes this sort of pairing to "traditional" pairing: > The work is more free-flowing and conversational. It’s easier to note the other person’s body language. It’s easier to stop coding, look up, and talk to each other. I found the switching between people more fluid, with fewer episodes where we were both going for the cursor at the same time. Working on windows, what sort of software would you need to make this kind of pairing work, though? Is it better than "normal" pairing? I can't say until I've tried, but I can see the upsides, indeed. One downside could be that you could easily not pay attention to the other person. I also like to point to pieces of code using my finger rather than the mouse - it feels more natural and phisycal. So I'm not sure yet. How do you pair today? have you tried this? --- title: "Step #4 - Start doing code reviews – Seriously" url: "https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.md" canonical: "https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html" published: "2009-09-08T21:00:59.804000+00:00" updated: "2019-03-07T16:40:51.027000+00:00" tags: ["First Steps during chaos", "Shu"] author: "Roy Osherove" description: "2009, Sep 9 As one team lead to another, as someone who has actually done this with a real team, I can tell you that this is one of the few effective techniques to maintain a high quality bar in your code base, and to keep your people…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Step \#4 - Start doing code reviews – Seriously 2009, Sep 9 As one team lead to another, as someone who has actually **done this** with a real team, I can tell you that this is one of the few effective techniques to maintain a high quality bar in your code base, and to keep your people learning. It is also one of the best ways to stay in touch with the codebase even though you are a team lead, and have much less time for real coding. ``` Whatever you do, don’t listen to others or even your own inner voice telling you that it’s a waste of time. ``` ``` Code reviews are nothing short of a magical process of growing people, code quality and confidence at the same time, and it has changed the way we work at Typemock immensely. ``` ## What's a code review? One developer looking at another developer's source code - _thoroughly._ ## What do you look for in a code review? - Logical bugs - stupid bugs - Unreadable code - Ugly code that should be refactored ## What is _really_ the purpose of code reviews? - Besides catching bugs really early on, you mean? - Keep code at a much higher quality - share knowledge of new feature, requirements and code between people in the team (the reviewer learns about code they did not write) - Raise skill of both reviewer and review-ee ("oh I'll show you a much more elegant way than doing this ugly for-loop - see?", "That looks great - what do you call this pattern?") - Let the team know that you, the team lead, **care** - about them, about the code, about quality ## Who should do the code review? - At first – Just you. Everything has to start somewhere - and as a team lead, I expect you to know good code, and to recognize bad code (here's a [good book about this subject](http://www.amazon.com/exec/obidos/ASIN/0132350882/iserializable-20) or even better - [a whole bunch](http://osherove.com/recommended-books/)) - Other team members (when you feel comfortable with it) ## How and when should you do a code review? There are two phases to this. The first one is the one where you bring the team up to par with what you consider quality code - You will be the only one doing code reviews - and no code is checked in before passing your code review. _seriously_. This is serious business and you should stand your ground. I cannot begin to tell you how much good this will do to the team - but you _must stand your ground_ and give this a try. - Sit down with the team, or explain this at the end of the next daily standup - > **From now on, every code being checked in has to pass a code review first.** That's right - _every check in_ will be reviewed by you personally. - Wait for the next time someone is about to check in their code - Sit with the, and find the changed code. You can use the "show changes" tools from the various source control tools (aka sourceSafe, SVN, VSTS etc.). - Go through each file and read the code. Do this even if the file checked in is not code – a text file, a solution file – it’s amazing how many gems you can find) > many times when reviewing you’ll find classes that are not in use anymore, or fully commented out, code that is duplicated and forgotten to be removed and many more “gems”. - Ask important questions about every little thing that bothers you: - "Why are those comments there?" - "Can we make this more readable?" - "This needs refactoring to smaller methods" and so on. - “How could you make this code more readable” - “What do you think is wrong with this piece of code"?” - “What would be a better name for this method?” - As you comment on the code have the developer put a special “REVIEW” or “REFACTOR” comment on that piece code which is easy to find later. - do **not** hesitate to say it if you feel that they are not paying attention or that they are not writing down those comments. - When you finish the review ask them to make any changes and show you the code again before checking it in. - Do a quick pass on the changes that were made (you can pass on this step after a couple of days if you feel comfortable enough) ## Train the team to review its own code I’ve said this previously, but I’ll mention this again: > Your most important role in the team is to act as a coach – to teach them to solve their own problems. To that effect, it’s important that you not become the bottleneck for the team. The goal here is to make sure every checked in code is being reviews, without the team slowing down to wait for you every time. IN order to achieve that, have a **third** person sit with you and the review-ee (that’s 3 people on the same machine) and write down a list of what you are looking for in the code. That list will later be used to coach others on code reviews. Have that third person _change_ between reviews so everyone gets to learn. ## The next step When you’ve code code reviews for say- a week or two, it’s time to let the team start doing its own reviews.  In the next standup meeting, declare that from now on, everyone can review each other’s code, with your supervision. From now on **you** will be the third person sitting behind two team members as they review each other’s code. As a team member reviews the code, sit quietly and only speak when they prepare to move on to a different file. If you have something to say, that’s when you can say it: - “What about naming conventions in this file? have you looked at those?” - “I’m still seeing something in this code that I think you missed – care to try and find it?” - “Why did you choose to apply this refactoring instead of X?” - “Why would you name it X?” and so on. typically, within a couple of days you should feel comfortable with them reviewing each other’s code, and free you up for other things. ## What did we end up with? When all is said and done , 2 or 3 weeks later, you should be able to say: - My team knows how to write **better code** today than they did last month - My team learned a **new skill** this month - My team can raise the quality but still be **fully independent** in doing so - I feel that I know _exactly_ how out code looks - I know my team members better than I did last month Those are things that you should be very proud to say. These are the hope of any team lead – that their coaching actually makes a difference. You might still want to reviews code every now and again, and make sure the bar is still set to your standards. If it lowers again, you can repeat the exercise. You should also have a better understanding of the strengths and weaknesses of each team member in regards to coding, sharing information, pairing and overall attention to detail. These will help you a lot when it comes time to **grow people**. I’ll touch on this in a future post. --- title: "How to find hidden problems in your project before it’s too late" url: "https://www.5whys.com/articles/how-to-find-hidden-problems-in-your-project-before-its-too-l.md" canonical: "https://www.5whys.com/articles/how-to-find-hidden-problems-in-your-project-before-its-too-l.html" published: "2009-09-08T19:32:29+00:00" updated: "2009-09-13T22:07:12.663000+00:00" tags: ["Shu"] author: "Roy Osherove" description: "A team lead I met a couple of years ago told me of a very effective technique he used in new projects and teams where he didn’t yet know what’s really going on, the team members, or all of the things that needed to be taken care of. He…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How to find hidden problems in your project before it’s too late A team lead I met a couple of years ago told me of a very effective technique he used in new projects and teams where he didn’t yet know what’s really going on, the team members, or all of the things that needed to be taken care of. He told me what happened the first time he tried it: It was 5 months before the supposed release of the project he had just gotten into. everyone looked very busy but he didn’t really know where to start. So he gathered the team in one room, including one of the stakeholders (project lead) and the QA manager, and asked them all one simple question: > “Imagine it’s the end of the project – 5 months from now. We’re standing in this same room, and the project has totally and utterly **failed**. > > Why did it fail?” As he said that, people around the room started talking about various things that are currently holding the project down, risks that needed to be mitigated, and quality issues that needed to be resolved. The QA manager said he didn’t yet get anything to test, and that the way things looked he will get them waay too late, which means the release will surely be late. The developers said that they have been rewriting the software three times over so far since no one seems to really know what they want. One of the developers mentioned that they are only working on the project half time since they are also working on two other projects at the same time – so he didn’t see a way this ends well. The team lead wrote down all those risks and after 45 minutes he had a ready made list of things that really needed taking care of. He knew what he needed to do. ## What can you learn from this? If you are a new lead on an old project, there is no hard in trying out this technique. It is a smooth and brilliant way of getting people to think of obstacles, and fleshing out problems before they arose too late to take care of. Gather your team, and take a couple of stakeholders with you (stakeholders are the people in your company that will suffer greatly if your team fails to deliver the project). **ask them** the question. You might be surprised by what you find. Do you have your own cool technique? Share it in the comments! --- title: "Making Impossible Decisions Without Panicking" url: "https://www.5whys.com/articles/making-impossible-decisions-without-panicking.md" canonical: "https://www.5whys.com/articles/making-impossible-decisions-without-panicking.html" published: "2009-09-07T11:47:27+00:00" updated: "2009-09-13T22:06:58.163000+00:00" tags: ["Shu"] author: "Roy Osherove" description: "Sometimes you're faced with a question that only has bad answers. A while ago one of my friends was faced with exactly one of those: It turns out that the technology the team chose to use on the project was not scalable enough, 2 days…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Making Impossible Decisions Without Panicking Sometimes you're faced with a question that only has bad answers. A while ago one of my friends was faced with exactly one of those: It turns out that the technology the team chose to use on the project was not scalable enough, 2 days before going into production. They had several choices available: 1. Host the non scalable part on a separate server and hope for the best 2. Change the code behavior (requires lots of testing, in a rush, not a good idea!) 3. find a different technical solution (impossible at that time frame) All these solutions suck. but there is more you can do: - Consult with your whole team for other solutions. Explain them the situation and be _open to hearing other solutions_ without taking them down. - Consider each solution for the time it takes, amount of people needed and the risk involved - Consider combining two or more solutions if it makes sense ## Don't Panic Whatever you do, especially if you're in a time rush - **don't panic**. If you panic - chances are you will rush into a decision without thinking well about it, and might end up digging a bigger hole. in this case going for option #1 and changing the code in parallel could be a better option than just choosing one of them. ## I put out the fire - now what? Now it's time to make sure you learn something from this horrible experience (and we've **all**been there) so that it does not recur. Sit down with your team and try to gauge out the reasons why they think you came to this situation. For example - "We could have done something about this 2 months ago but didn't" - "We could have tested for scalability but didn't" - "We didn't really understand that the requirement was scalability of this magnitude" - "We wanted to do this early but never got to doing it due to lack of time" - "It was lower on our priority list" etc.. Make sure it does not turn into a blame fest - no names. always make sure people use the term "we" since as a team you are all responsible for this. If people try to be negative and say they had nothing to do with this failure remind them that as a team everyone is equally responsible to anything that comes out. After you're done making that list, sit down with the team and make a list of things that you commit to start doing starting today. It will be **your job** as a team lead to make sure the team has the time and permission to achieve these things. Try to not be the only one saying something. Always be the third or fourth person contributing to the ideas, to show people that you expect them to be part of the process. Here is what such a list can be: - "The team commit to doing performance testing of this application on a weekly basis" - "The team will always ask about scalability requirements for all applications from now on, and are they a must to go live" It could just be one item, but one that you can really commit to - make sure _you are not lying to yourself_. --- title: "Daily Standup Meetings - Introduction and 5 useful tips" url: "https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.md" canonical: "https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.html" published: "2009-09-06T20:50:09+00:00" updated: "2009-09-13T22:05:57.038000+00:00" tags: ["First Steps during chaos", "Shu"] author: "Roy Osherove" description: "A daily standup meeting is one of the easiest practices you can implement with your team. It only takes 10-15 minutes at the beginning of each day, and it increases the amount of communication and synchronization in the team immensely. The…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Daily Standup Meetings - Introduction and 5 useful tips ![](https://www.5whys.com/img/posts/334b543d-4655535-4075238-thumbnail.jpg) A daily standup meeting is one of the easiest practices you can implement with your team. It only takes 10-15 minutes at the beginning of each day, and it increases the amount of communication and synchronization in the team immensely. The idea is very simple The whole team (usually no more than 10 people) literally stands up in a sort of circle so everyone can see each other. then the team lead (or the "facilitator" that was chosen for the team) will go one by one and ask each team member three simple questions: 1. What did you do yesterday? 2. What are you going to do today? 3. Is there anything stopping you from getting your work done? Question #1 is important for several reasons: - Everyone hears what happened yesterday and know the current status on that part of the app that member worked on - The team lead understands the progress of  the team member and the overall status of the app - If the team member didn't get anything really done yesterday, it might mean [they are stuck - which is very important to know early](https://www.5whys.com/articles/4-ways-to-discover-a-stuck-team-member-and-what-you-can-do-a.html) as we've seen. Question #2 also has its uses: - The team member stands up in front of their own peers and says they will do something. They will feel more responsibility to make sure those things get accomplished. they are now accountable to the team. - If they do not know what to do today, that's also good since you've caught this early. make sure they know what to do. If [there is a task board](https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.html), they can grab the task with the highest priority, for example. - Other team members will know what is going on, can offer help or tips (maybe they worked on this just the other day?) Question #3 is very important to prevent bottlenecks in the team productivity - maybe someone's computer is overheating, or has low memory - maybe a team member needs to take half a day since some other project called them - maybe... you get the idea it is **your job** as a team lead to make sure _nothing_ is stopping team members from working on the things with the highest value to the project(s) they are working on. If they are not, find out why and solve it immediately after the meeting. ## 5 useful tips I learned the hard way 1. Make sure it does not take longer than 15 minutes (that's why standing up is important - people don't feel comfortable ranting on when they stand up so things finish up quickly) 2. Make sure that technical discussions do not ensue in the middle of the meeting. when one breaks out call it out as a "talk about this later, just the both of you" and ask people to move on 3. When all else fails, you can tell the person who won't stop talking - "you have  30 seconds to finish your overview" and then move on. 4. Don't be afraid to stop people in the middle of speaking. The rules must be clear and concise. 5. Once you have this meeting, try to see what meetings you can now _cancel_for the whole team. For example, in our company we have only two meetings a week where the whole dev team needs to be in: daily standup, and once a week a company meeting. besides those they are just _at work, working_. --- title: "4 ways to discover a stuck team member, and what you can do about it" url: "https://www.5whys.com/articles/4-ways-to-discover-a-stuck-team-member-and-what-you-can-do-a.md" canonical: "https://www.5whys.com/articles/4-ways-to-discover-a-stuck-team-member-and-what-you-can-do-a.html" published: "2009-09-06T19:29:10+00:00" updated: "2011-04-04T22:40:55.237000+00:00" tags: ["Learning Phase", "Shu"] author: "Roy Osherove" description: "More than five years ago I wrote on my .NET blog a little sad story about how I got fired from my job as a developer. You can read the full story here . Here is my summary in the context of five or so years ago: “As developers, we all make…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 4 ways to discover a stuck team member, and what you can do about it More than five years ago I wrote on my .NET blog a little sad story about how I got fired from my job as a developer. [You can read the full story here](http://weblogs.asp.net/rosherove/pages/DonKihote.aspx). Here is my summary in the context of five or so years ago: > “As developers, we all make mistakes. It's the natural and human thing you can always count on. As a developer, it is **your** responsibility to make sure that at any given time, your team lead knows what you are facing and if you're having **any** problems. If you don't communicate this well using scheduled short meetings or even hall small talk, you're not giving your team lead a chance to help you. You're also setting yourself up to be the scapegoat if anything goes wrong since you are the only person that could have known and fixed any problems you are encountering. > > As a team lead it is **your** responsibility to make sure that at any given time you know what every person on your team is working on ,if they are having any problems doing it and how long it is supposed to take. You should do **at least** a daily morning meeting with your team to review today's objective for each person, to leverage any problems anyone might have and to basically make sure that everyone is on the same page. Forget to do this basic thing and you're setting yourself up for big surprises down the line. Doing code reviews is also a great way to keep tabs on what's going and the quality of it. Harder to do, this should be done on weekly basis, or milestone basis (some even do it before any code check-in of any developer). forget to do this and you could wind up with code who's quality you are unsure of.” Wow. Re-reading this, I still like all the advice I’ve given. and these words were written with a lot of pain behind them, so this was a lesson that was really hard to learn. I’ll reiterate the final situation that happened: - I ended up with a team lead who didn’t trust me, and actually went (almost) behind my back to solve a problem I’ve been working on for a long time. - I was afraid to go to work because I couldn’t face not accomplishing my work anymore - I was afraid to talk to my team lead - I was working hard and overtime - I was feeling lonely because I had too much ego to share anyone with my problems - My work was crappy. Never finished. - I was eventually fired. ## What can I do to find this early? As a team lead you can easily prevent such a severe case of mistrust and anxiety by following a few simple practices (which I will blog about in the days to come) - Have daily standup meetings - Do a code review - If you team writes tests, review them - Don’t be afraid to “ping” people or to pair with them on tasks Daily standup meetings will find the problem of non-progress very early on. within a day or two any lack of progress will surface like a smelly apple in a bunch, but the point is that you found it early and you can take care of it. During standup meetings, when finding lack of progress for more than 1 or 2 days (you set the max limit but I don’t recommend any more than 2 days) – it’s a definite sign of “stuck”. Code reviews are there to make sure the code quality passes your quality bar – you should only pass code you can stand behind. Reviewing tests will reveal the intent behind the code people write and let you find problems with people’s understanding of requirements much faster than a regular code review. “Pinging” people is alert you to any bottlenecks you can help solve during the work day. The point of all these practices is that you are _fully engaged_ with your team members, and gain their trust. By being there with them through think and thin, they will also feel better about telling about about things that aren’t working that great, since at the point you find them they are still really really small. ## What should I do once I find a stuck team member? Make sure a person will pair on that task with a peer or with you for at least one day, or hopefully until the end of the task. Pair programming actually works, but if you’re not ready for that yet, just make sure that stuck team member will have at least 8 hours of thought sharing and coding with someone else. it does a world of good to both of them. Whatever you do _do not_ let the situation continue. Team members are often silent but they expect you to help them, even without realizing it. It is **your job** to make sure that person is productive again. Pairing ont he task with someone else will unblock some brain waves, and creative thought can then resume. ## What not to do Don’t try to solve the problem yourself – at least, try to resist the urge. As a team lead, it is **your job** to empower the people in the team – to help them learn and get better. Solving their problems for them will not get them better, instead it will only get them more dependent on you. Instead, try to ask them for several possible options of how to continue from here, and then you can choose one, or let them choose one that you have no problem with. YOu can give them hints, clues, or you can leave them alone and just say “there is a solution – take X hours and find it with one of your peers”. But this is a subject of a future blog post as well. --- title: "If you don’t own your team, Someone else will" url: "https://www.5whys.com/articles/if-you-dont-own-your-team-someone-else-will.md" canonical: "https://www.5whys.com/articles/if-you-dont-own-your-team-someone-else-will.html" published: "2009-09-06T18:53:51+00:00" updated: "2009-09-13T22:05:15.113000+00:00" tags: ["First Steps during chaos", "Ha"] author: "Roy Osherove" description: "One of the first steps I suggest new team leads do is to take ownership of their team and territory . There were a couple of comments, both on the blog and on twitter that questioned whether this was the right thing to do. More…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # If you don’t own your team, Someone else will One of the first steps I suggest new team leads do is to [take ownership of their team and territory](https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.html). There were a couple of comments,  both on the blog and on twitter that questioned whether this was the right thing to do. More specifically, [Lior](http://imistaken.blogspot.com/) mentioned in the comments that > “It's the job of the team to define its boundaries its the job of the team to resist outside interference. > You as the team leader is just the tool for achieving this.” as I replied to lior that most teams don’t have people willing to start doing something like this, Lior said > “I would say in this case, that this is exactly your first responsibility as the lead. To teach the team how to do that. > Which starts by saying to the team, I expect YOU to do that. (of course in the meantime if its a big issue you should help) > > I just really dont like the tilte of the post. "own the team" is such a bad term for me.” So let me be clear: As a team lead, “owning the team” means that you are fully responsible for the actions and outpus of the team members inside it, and that includes giving the the freedom to work in an environment where they are not constantly hassled from out side interference. It is **your job** to make sure they know that they have your back to tell someone to talk to you whenever someone approaches them, and it’s **your job** to make it clear to other people in the company that you’ve defined the boundaries in which the team operates. Agile development books will tell you that the team needs to set its own course, and that they need to make their own decisions, and I fully sipport that, but chances are, most teams are far from this situation. To even get to the beginning of a world what that is possible, a team lead needs to **take charge** and be **assertive** and demand those rights. Otherwise no one will bestow them on the team. Team leadership is **taken** and when there is none, the company feels free to interfere  with a team’s work habits to the point of no real work getting done, or work slowing to a halt due to constant interruption and direction changes. For a team to be self-directing, there needs to be a leader that gives it the higher-up support it needs  - the autonomy to make those decisions. That’s your job. --- title: "Call for content – what do new team leads need to know on the first day?" url: "https://www.5whys.com/articles/call-for-content-ndash-what-do-new-team-leads-to-know-on-the.md" canonical: "https://www.5whys.com/articles/call-for-content-ndash-what-do-new-team-leads-to-know-on-the.html" published: "2009-09-05T22:43:33.247000+00:00" updated: "2009-09-05T22:43:33.247000+00:00" tags: [] author: "Roy Osherove" description: "About 5 minutes after I posted about eh existence of this blog on twitter, I’ve gotten lots of great feedback (and various little nitpickings) about the content, what I shoudl talk about and things that I might cover. This is your chance…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Call for content – what do new team leads need to know on the first day? About 5 minutes after I posted about eh existence of this blog on twitter, I’ve gotten lots of great feedback (and various little nitpickings) about the content, what I shoudl talk about and things that I might cover. This is your chance to influence the topics this blog covers : What topics do you think are **essential** for new team leads to learn if they’ve never done it before? What tips or tricks would you give them? What topics would you make sure they learn? What topics have you learned about leading teams that are not covered in \*any\* book? --- title: "Don’t despair in the face of nitpickers" url: "https://www.5whys.com/articles/donrsquot-despair-in-the-face-of-nitpickers.md" canonical: "https://www.5whys.com/articles/donrsquot-despair-in-the-face-of-nitpickers.html" published: "2009-09-05T22:05:58.977000+00:00" updated: "2009-09-05T22:05:58.977000+00:00" tags: [] author: "Roy Osherove" description: "as you start up your quest to get better, you’ll find lots of gentle souls who want to help you on your journey to become better. They wil try to help you by trying to point out all the places where you haven’t been 100% accurate, or the…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Don’t despair in the face of nitpickers as you start up your quest to get better, you’ll find lots of gentle souls who want to help you on your journey to become better. They wil try to help you by trying to point out all the places where you haven’t been 100% accurate, or the things that you forgot, or the fact that you said “9 AM” but the daily meeting started at 9.45 AM or the fact that your cool whiteboard  is not really what Scrum, or XP or Kanban boards are like, or many other things that just stand there and look you in the face every time to raise your head in pride over the things you’re trying to accomplish or what you’ve already accomplished. **Don’t despair in the face of nitpickers!** I’m here to tell you that there will **always** be nitpickers. It is absolutely necessary that you: 1. stay away from any kind of confrontation with them – it will only frustrate you. 2. suck it up and write down what they said and learn it. But do it **later**, when you have time, and are not busy driving home your original task. The point is this: There are two kinds of people in this world at any one point: Talkers and doers. You are now a **doer** you are actually doing things which change the environment in which you work, change the behavior of people around you, change your own approach to things, and sticking your neck out to take risks. All the talkers int he company will have much to say about what you did – but just take it as a compliment. there is always something to talk about, but how often to they talk about something **you did?** **People nitpick** because they either really care about the subject (so you need to learn from them) or they really wish they would have been involved with it in the first place (maybe you can find a way to involve them?) but don’t let that distract you from your main task. whatever it is – getting a new task board up and running, or getting a daily meeting together  - keep focused on the task. **it’s OK** if it’s not right on the money. You get better by trying, and repeatedly trying again. --- title: "Step #2 – Use a big visible board with post it notes" url: "https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.md" canonical: "https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.html" published: "2009-09-05T19:37:25+00:00" updated: "2009-09-13T22:04:49.022000+00:00" tags: ["First Steps during chaos", "Shu"] author: "Roy Osherove" description: "Most team leads really have no idea how many things their developers are doing at the same time. There is a very simple tools that you can use starting today . Take a white board and place it in an area where your whole team can take a…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Step \#2 – Use a big visible board with post it notes Most team leads really have no idea how many things their developers are doing at the same time. There is a very simple tools that you can use starting **today**. Take a white board and place it in an area where your whole team can take a look at it. It's **not supposed to be in a computer** so don't try to use software for this. It's supposed to be a **big visible board**. Give it columns for pending tasks, tasks in progress, tasks done (waiting for approval) and tasks approved as done. In the case down below “Accepted” means that a customer has seen a demo of this functionality and said it’s OK. [![image](https://www.5whys.com/img/posts/7c9e3870-WindowsLiveWriter-Step2Useabigvisibleboardwithpostitnotesk_13E0C.jpg)](https://www.5whys.com/files/WindowsLiveWriter-Step2Useabigvisibleboardwithpostitnotesk_13E0C) Next, you can start out by placing post it notes or index cards with small tasks. you fill the left most side with tasks that you are planning for this week. This is not an “iteration”. it’s just the amount you think you can make in a week. Any tasks that don’t fit in this board belong on an excel document [![image](https://www.5whys.com/img/posts/c237cbb8-WindowsLiveWriter-Step2Useabigvisibleboardwithpostitnotesk_13E0C.jpg)](https://www.5whys.com/files/WindowsLiveWriter-Step2Useabigvisibleboardwithpostitnotesk_13E0C) Once you’ve done this, ask team members to put on the “in progress” column any tasks they are currently doing, or to add any cards which do not exist that represent work they are currently doing. Ask them to put names on cards they are working on, or, assign the in progress part in the groups by the team names: what ends up happening in a lot of teams is something like this: [![image](https://www.5whys.com/img/posts/fa622a8e-WindowsLiveWriter-Step2Useabigvisibleboardwithpostitnotesk_13E0C.jpg)](https://www.5whys.com/files/WindowsLiveWriter-Step2Useabigvisibleboardwithpostitnotesk_13E0C) this board represents the fact that you have people working on multiple things at the same time. [That’s not a great thing](http://www.ayeconference.com/convincing-management-that-context-switching-is-a-bad-idea/). the good thing is that at least you’ve found out about this and can do something about it! you an also use this board to show management just  how busy your team really is. Try to have no more than one concurrent task for developers on your team, as a thumb rule. --- title: "The first five Whys" url: "https://www.5whys.com/articles/the-first-five-whys.md" canonical: "https://www.5whys.com/articles/the-first-five-whys.html" published: "2009-09-05T16:02:14+00:00" updated: "2014-05-22T22:34:02.887000+00:00" tags: [] author: "Roy Osherove" description: "You might also like to: Read about the three team phases your team might be in. Read posts on the chaos phase , the learning phase , or the self-leading phase . 1) Why create this blog in the first place? Because I wanted new team leads…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The first five Whys You might also like to: - Read about [the three team phases](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) your team might be in. - Read posts on [the chaos phase](https://www.5whys.com/articles/category/First+Steps+during+chaos), the [learning phase](https://www.5whys.com/articles/category/Learning+Phase), or the [self-leading phase](https://www.5whys.com/articles/category/Self-Leading+Phase).  **1) Why create this blog in the first place?** Because I wanted new team leads and want-to-be team leads (as well as existing want-to-learn team leads) to have a good blog to go to and find out some great techniques for managing and driving software people. **2) Why?** Because 99% of team leads I’ve seen in the wild seem to have no idea what it is that drives people, or how to drive the things that **they** believe in inside the company. **3) Why?** Because lots of people seem to give no importance to the human-to-human techniques it takes to lead a great team, not just technical practices. **4) Why?** Because no one has ever put a great deal of emphasis on this in the software industry. What they did do is put emphasis on the technical emphasis of software leadership. **5) Why?** Because software is a pretty new profession, and we are all learning as we go. We tried to learn from other industries and only in the past few years are the successful practices from manufacturing and production starting to cross over into the software business. And those practices (the successful ones, at least) give high value to coaching and driving people, as opposed to “resources”. **What to do now:** - Read about [the three team phases](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) your team might be in. - Read posts on [the chaos phase](https://www.5whys.com/articles/category/First+Steps+during+chaos), the [learning phase](https://www.5whys.com/articles/category/Learning+Phase), or the [self-leading phase](https://www.5whys.com/articles/category/Self-Leading+Phase). --- title: "Step #1 – Claim Your Territory, Own your team" url: "https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.md" canonical: "https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.html" published: "2009-09-05T15:54:31+00:00" updated: "2009-09-13T22:04:24.001000+00:00" tags: ["First Steps during chaos", "Shu"] author: "Roy Osherove" description: "Many dev leads don’t seem to easily see that their territory is constantly compromised by people from the outside. Compromising territory can be in many simple forms, but they all hurt the leadership and ownership aspect you have as a…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Step \#1 – Claim Your Territory, Own your team Many dev leads don’t seem to easily see that their territory is constantly compromised by people from the outside. Compromising territory can be in many simple forms, but they all hurt the leadership and ownership aspect you have as a lead. as yourself these questions: - **Do you get to choose the way you implement the features requested by customers, or do you get told how to implement them?** > Internal team implementation decisions that weren’t specifically asked by a customer or have nothing to do with a feature’s integration with other technologies usually should stay fully internal to the dev team. Things like _what technology or language to use_, _what type of database to use_ and others are things the dev team needs to figure out for themselves. > > It’s up to you to go up to whoever is doing this and say “The way we implement features is not your problem. Just tell us _what_ you need, don’t tell us _how to build it”._ > > A good technique to see why this is happening is to ask yourself and whoever is telling you this, _why_ they feel compelled to tell you how to do your job. you’ll find that most times there is a deeper issue underneath that needs to be solved. > > this is where [the five whys](http://en.wikipedia.org/wiki/5_Whys) technique helps a lot. - **Do people feel the need to come by and tell specific team members what to do instead of going through you?** > You should be the only entry point to your team. Your team depends **on you** to make sure they get as least distractions as possible from the outside. > > Go up to whoever keeps asking them things find a way to make sure you are the one asking people to do things, and not anyone else. In fact, if you are using [some sort of a kanban system](http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html), such a thing will not even be necessary. The key takeaway is that you must be in charge of the boundaries that your team operates within, or you quickly lose control of what is really going on, and find yourself mostly running around trying to see what people are actually doing instead of making sure that the right things get done. --- title: "5 Whys: There are no experts. There is only us." url: "https://www.5whys.com/index.md" canonical: "https://www.5whys.com/" tags: [] author: "Roy Osherove" description: "Roy Osherove on software team leadership: growing self-organizing teams, surviving chaos, learning mode, and the Elastic Leadership model. Articles, interviews and videos." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # 5 Whys > 5 Whys is Roy Osherove's blog about leading software teams: the Elastic Leadership model (survival, learning and self-organizing modes), growing people, and team-leader anti-patterns. HTML: https://www.5whys.com/ · Guide for AI systems: [llms.txt](https://www.5whys.com/llms.txt) · Full text: [llms-full.txt](https://www.5whys.com/llms-full.txt) ## On the home page ### [There are no experts. There is only us.](https://www.5whys.com/noexperts) 5 Whys is a blog about technical leadership in the software world. [![Cover of Elastic Leadership by Roy Osherove](https://www.5whys.com/img/cover-400.jpg) Based on the book “Elastic Leadership” by Roy Osherove (a.k.a “Notes to a Software Team Leader”)](https://www.elasticleadership.com/) #### Start here - [First Steps During Chaos](https://www.5whys.com/articles/category/First+Steps+during+chaos) Your team is in survival mode. What to do first. - [Utilizing Learning Mode](https://www.5whys.com/articles/category/Learning+Phase) Your team has some slack. How to grow people with it. - [Team Leader Manifesto](https://www.5whys.com/articles/team-leader-manifesto-take-4.html) Great teams are grown, not hired. #### Featured [All 166 articles →](https://www.5whys.com/articles) June 15, 2020 ##### [Possible Anti Pattern: A Remote Team Member is Never Ever Visible in Video Chat (Zoom, Teams)](https://www.5whys.com/articles/2020/6/15/possible-anti-pattern-a-remote-team-member-is-never-ever-visible-in-video-chat-zoom-teams) Team members that don’t show their face ever, or 99% of the time when video chatting with the team used to be OK, before COVID. But in the age of COVID this shouldn’t be the new normal. Team facilitation and communication with people’s… May 30, 2019 ##### [InfoQ Book Q&A on Elastic Leadership](https://www.5whys.com/articles/2019/5/30/infoq-book-qampa-on-elastic-leadership) I had the privilege of being interviewed by Ben Linders over at InfoQ regarding my book on Elastic Leadership. You can read the article over here. Some of the main takeaways from it: A team can be either in survival mode, learning mode, or… March 22, 2019 ##### [The Elastic Leadership Model in a picture](https://www.5whys.com/articles/2019/3/22/the-elastic-leadership-model-in-a-picture) I realized that there isn’t one picture that shows the entire elastic leadership model with the right amount of details out there. So I made one. Would love any feedback in the comments! - [Johanna Rothman Interview - Agile, a Decade Later](https://www.5whys.com/articles/2019/2/16/johanna-rothman-interview-agile-a-decade-later)February 16, 2019 - [A Critical Chain of Bus Factors](https://www.5whys.com/articles/a-critical-chain-of-bus-factors.html)February 22, 2017 - [Elastic Leadership Book Published](https://www.5whys.com/articles/elastic-leadership-book-published.html)February 22, 2017 The newest article is from June 15, 2020. #### Archived Interviews [All audio interviews →](https://www.5whys.com/archived-interviews) - [**Kent Beck: an agile conversation**](https://www.5whys.com/archived-interviews#kent-beck)Audio · February 2006 - [**James Bach: the role of the tester**](https://www.5whys.com/articles/interview-james-bach-the-role-of-the-tester.html)Audio · April 2010 - [**Johanna Rothman: agile, a decade later**](https://www.5whys.com/articles/2019/2/16/johanna-rothman-interview-agile-a-decade-later)Audio · February 2019 #### More ##### Elastic Leadership Videos [Watch the videos](https://www.5whys.com/videos) ##### Recommended books [See the reading list](https://www.5whys.com/recommended-books) ## Pages - [There are no experts](https://www.5whys.com/noexperts.md): Roy Osherove on why there are no experts in software teams, only us, and what a team leader should do about it. - [There is only us](https://www.5whys.com/thereisonlyus.md): Roy Osherove on why there are no experts in software teams, only us. - [Archived interviews](https://www.5whys.com/archived-interviews.md): Audio interviews by Roy Osherove with Johanna Rothman, Kent Beck, Juval Lowy, David Platt, Charlie Poole and others on management and agile development, 2005 to 2006. - [Elastic Leadership videos](https://www.5whys.com/videos.md): Talks and videos by Roy Osherove about Elastic Leadership and software team leadership. - [Recommended books](https://www.5whys.com/recommended-books.md): Roy Osherove's reading list for software team leaders: Peopleware, The Five Dysfunctions of a Team, Behind Closed Doors and more. - [Courses](https://www.5whys.com/courses.md): Leadership and engineering courses by Roy Osherove. - [Contact](https://www.5whys.com/contact.md): Send Roy Osherove a message about team leadership, talks or workshops. ## Posts (166) ### First Steps during chaos - [Team Bus Factors: How to Reduce Them and How to Prevent Them](https://www.5whys.com/articles/team-bus-factors-how-to-reduce-them-and-how-to-prevent-them.md) (2015-10-16): There was a discussion on HN asking about good tips for team leaders. So I thought I'd chime in a bit more deeply. The following is a new chapter from the upcoming second edition of my book for software team leaders… - [A Value System for Code Reviews, and How to Scale Them for a Large Project](https://www.5whys.com/articles/a-value-system-for-code-reviews-and-how-to-scale-them-for-a.md) (2014-09-18): One of my customers wanted my help is increasing their code quality. When I spoke with the developers the following conversation happened several times: Me: "Wow, this code... how many lines long is this method?" Dev… - [Signs you might be in survival mode](https://www.5whys.com/articles/signs-you-might-be-in-survival-mode.md) (2014-03-27): We had an interesting discussion in class on how one can detect you might be in survival mode. Here are some possible early warning signs: There is a perception or feeling of continuous urgency There is lack of context… - [Definition: Survival Mode](https://www.5whys.com/articles/definition-survival-mode.md) (2013-10-20): A team is in "Survival" mode if they do not have time to learn and slowly practice new skills. Such a team is usually over committed and is too busy chasing fires instead of having enough time to hone and practice the… - [Elastic Leadership in Devops Survival Mode](https://www.5whys.com/articles/elastic-leadership-in-devops-survival-mode.md) (2013-02-24): This blog post from the devops guys , shows that the idea of “survival mode ” or chaos can exist in many different places. and a command and control leadership can help buy valuable time that you can then use for… - [Team Leader Manifesto - Take #4](https://www.5whys.com/articles/team-leader-manifesto-take-4.md) (2012-06-06): Here's what I have, before speaking at NDC next morning: - [Team Leader Manifesto - Take #3](https://www.5whys.com/articles/team-leader-manifesto-take-3.md) (2012-06-06): As team leaders our goal, and the way we measure our work, is the overall growth in skills of self organization and self maintenance of each person of our team, and the team as a whole. To that end: We accept that the… - [On time, with quality - why is this mostly failing?](https://www.5whys.com/articles/on-time-with-quality-why-is-this-mostly-failing.md) (2012-05-06): Everyone in the software industry seems to be talking about the quality mantra lately. Agile, XP and kanban brought this issue to full front, but I see many team leads failing with the quality part. Many of us keep… - [Middle Management or puppet management?](https://www.5whys.com/articles/middle-management-or-puppet-management.md) (2012-05-06): Most team leaders I've seen in lead roles usually feel quite helpless. Someone put them in their position, and no one taught them how to do their jobs. So they are mostly developers who are just trying to keep the… - [What should a good code review look and feel like?](https://www.5whys.com/articles/what-should-a-good-code-review-look-and-feel-like.md) (2012-05-02): The way I see code reviews, is that they are a great cover for learning, mentoring _and_ finding interesting quality issues in your code. If our main goal as leaders is to grow our teams, then code reviews are a great… - [Do new startup leaders need to grow their teams?](https://www.5whys.com/articles/do-new-startup-leaders-need-to-grow-their-teams.md) (2012-05-01): I've been involved with several small startups. My feeling is that in the first few weeks or months of a startup's life, your main goal is to make sure you're running in the right direction. You're about to release… - [The Chaos Addiction](https://www.5whys.com/articles/the-chaos-addiction.md) (2011-08-07): I'm convinced more than ever these days, that being in chaos is a self perpetuating state of being, unless drastic measures are taken. It is a pattern of addiction , in that it reinforces the bad habits that lead to… - [Video: How to manage a person who is always late to a standup meeting](https://www.5whys.com/articles/video-how-to-manage-a-person-who-is-always-late-to-a-standup.md) (2011-07-30): I came across this common question on LinkedIn: How do you manage a person who is always late to a standup meeting? My thoughts on it are below, and the answer of course, depends on the three stages of software team… - [Video: Mistake #1 - Not Understanding Team Maturity](https://www.5whys.com/articles/video-mistake-1-not-understanding-team-maturity.md) (2011-07-28): I recently posted my slides about ten mistakes team leaders make. I thought I'd take some time for each mistake and do a short video on it. Here's the first one: Watch on YouTube Team Leader Mistakes #1 - Not… - [Video: Ten Mistakes Software Team Leaders Make](https://www.5whys.com/articles/video-ten-mistakes-software-team-leaders-make.md) (2011-07-20): I've just finished a two day Elastic Leadership course - Essential Skills for software team leaders, in London. I'll be doing another one in November. During that time, I've also spoken at an "in the brain" session at… - [The Fear Of Failure And What To Do About It](https://www.5whys.com/articles/the-fear-of-failure-and-what-to-do-about-it.md) (2011-06-30): I'm embedding this very inspiring video of Milton Glaser talking about The Fear Of Failure, because it has so much to do with your own personal development as a leader in your organization. Most team leaders are really… - [What to do if some people in the team just don't want to take a task?](https://www.5whys.com/articles/what-to-do-if-some-people-in-the-team-just-dont-want-to-take.md) (2011-06-06): Recently I found this question on LinkedIn: We just started using Scrum in our organization and today is the last day of our first sprint. In the beginning, after the second part of the sprint planning the tasks were… - [Video: Elastic Leadership in software - InfoQ interview](https://www.5whys.com/articles/video-elastic-leadership-in-software-infoq-interview.md) (2011-04-15): during the recent QCON London 2011 Conference, Michael Hunger of Infoq interviewed me about what I later started describing as “ Elastic Leadership ” – The team leader changes her leadership style (dictator all the way… - [12 Behavior Anti Patterns You Will Face As a Software Team Leader](https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.md) (2011-04-11): Most of these, we covered today on the 1st day of my Lead Better course that is taking place in Oslo , with live simulations. The purpose was to see how a team lead deals with these anti patterns when going through team… - [Slides: Team Leadership In the Age of Agile](https://www.5whys.com/articles/slides-team-leadership-in-the-age-of-agile.md) (2011-03-19): Here are the slides I've used during my latest talk at QCON london 2011 : In this talk I explore the three maturity stages of a software team, and how a team leader can adjust their leadership type based on the current… - [Video – Code Leaders and Beautiful Teams](https://www.5whys.com/articles/video-ndash-code-leaders-and-beautiful-teams.md) (2010-05-24): Here’s the video of a talk about team leadership and beautiful teams I gave at QCON London this year. You can download the slides for this presentation here. This talk is mainly about the first stage (out of the three… - [The 3 maturity stages of a software team and how scrum fails to identify them](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.md) (2010-05-17): Many so called ‘Agile’ teams fail so miserably to deliver for the simple fact that the teams simply are not mature enough to be part of an agile process that requires self managing teams. I’ve learned to recognize three… - [Do Not Fear Confrontation](https://www.5whys.com/articles/do-not-fear-confrontation.md) (2009-10-24): hope the sound wasn't too weak... Watch on YouTube Team Leads: Do Not Fear Confrontation - [A simple way to know you're missing some leadership skills](https://www.5whys.com/articles/a-simple-way-to-know-youre-missing-some-leadership-skills.md) (2009-10-15): how often does this happen to you as a team lead: You believe in some great practices that the team needs to follow, but you can't convince or get the team to follow them - even the simplest ones. If that happens to you… - [Spend at least 50% of your time with your team](https://www.5whys.com/articles/spend-at-least-50-of-your-time-with-your-team.md) (2009-09-10): To be an effective team lead, you need to actually spend time with your team. Otherwise, you won't be able to do daily stand-ups , do code reviews , or sit down and pair with a team member every once in a while. And no… - [Step #4 - Start doing code reviews – Seriously](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.md) (2009-09-08): 2009, Sep 9 As one team lead to another, as someone who has actually done this with a real team, I can tell you that this is one of the few effective techniques to maintain a high quality bar in your code base, and to… - [Daily Standup Meetings - Introduction and 5 useful tips](https://www.5whys.com/articles/daily-standup-meetings-introduction-and-5-useful-tips.md) (2009-09-06): A daily standup meeting is one of the easiest practices you can implement with your team. It only takes 10-15 minutes at the beginning of each day, and it increases the amount of communication and synchronization in the… - [If you don’t own your team, Someone else will](https://www.5whys.com/articles/if-you-dont-own-your-team-someone-else-will.md) (2009-09-06): One of the first steps I suggest new team leads do is to take ownership of their team and territory . There were a couple of comments, both on the blog and on twitter that questioned whether this was the right thing to… - [Step #2 – Use a big visible board with post it notes](https://www.5whys.com/articles/step-2-use-a-big-visible-board-with-post-it-notes.md) (2009-09-05): Most team leads really have no idea how many things their developers are doing at the same time. There is a very simple tools that you can use starting today . Take a white board and place it in an area where your whole… - [Step #1 – Claim Your Territory, Own your team](https://www.5whys.com/articles/step-1-claim-your-territory-own-your-team.md) (2009-09-05): Many dev leads don’t seem to easily see that their territory is constantly compromised by people from the outside. Compromising territory can be in many simple forms, but they all hurt the leadership and ownership… ### Learning Phase - [Two Techniques to Avoid the Bus Factor In your Teams: Push and Pull](https://www.5whys.com/articles/two-techniques-to-avoid-the-bus-factor-in-your-teams-push-an.md) (2013-09-06): I spoke before on this blog about BUS FACTORS and how to get rid of them . A bus factor is calculated the the amount of people on your team or project who need to get hit by a bus before the project comes to a halt… - [Should you grow even a short-term consultant in your team?](https://www.5whys.com/articles/should-you-grow-even-a-short-term-consultant-in-your-team.md) (2012-05-06): What if you have a short-term consultant on your team? What if you're the team lead for just this project, and there will be a new team lead in the next project? Should you work on growing people even in those… - [If you're looking for a QA to automate your tests, you've started to fail](https://www.5whys.com/articles/if-youre-looking-for-a-qa-to-automate-your-tests-youve-start.md) (2012-05-06): If you are looking for someone to join the QA team to automate tests, the failure is in the way the system is built. Your *developers* should be proficient (or start learning how to) in automating the tests, creating… - [Chapter four - commitment language - is online](https://www.5whys.com/articles/chapter-four-commitment-language-is-online.md) (2012-05-02): I've just released a new chapter to my team leader book. Chapter 4 is about commitment language, as the first step as part of the learning stage. It's about bringing your team closer into Integrity thinking, and an… - [Grow your "feature teams" into just "teams"](https://www.5whys.com/articles/grow-your-feature-teams-into-just-teams.md) (2012-05-01): A feature team, as I see it, is a team consisting of all the people needed to accomplish a released specific feature. So on such a team you might have an architect, a DBA, a coder, a UI guy, a frontend guy etc.. In that… - [You're not self organizing if you have a go-to architect](https://www.5whys.com/articles/youre-not-self-organizing-if-you-have-a-go-to-architect.md) (2012-05-01): I realized that while I was writing the previous post , I came up with another simple way to tell if your team is self organizing or not, In my courses , people always ask me, how to tell if I'm in chaos, learning or… - [The architect as a leader, and other specialists](https://www.5whys.com/articles/the-architect-as-a-leader-and-other-specialists.md) (2012-05-01): To me, if you have an architect on your team, their role should be To act as an unofficial leader in the team that mentors and teaches people on the team about architecture To make themselves unneeded - that their… - [How to be an effective code coach](https://www.5whys.com/articles/how-to-be-an-effective-code-coach.md) (2011-12-12): As a technical team leader, you might expect others to become better coders. You can also be a coach for them by pairing with each person for a few hours each week. Being an effective code coach means that you pair with… - [Video: The Mistake at the heart of Agile - Michael Feathers, NDC 2011](https://www.5whys.com/articles/video-the-mistake-at-the-heart-of-agile-michael-feathers-ndc.md) (2011-06-17): A video was embedded here. Its host (Viddler) has shut down, so it is no longer available. I think this video, recorded at NDC 2011 , goes well with this post I just finished writing , actually, about bursting your… - [Burst your team's bubble - stop protecting them from the surrounding organization](https://www.5whys.com/articles/burst-your-teams-bubble-stop-protecting-them-from-the-surrou.md) (2011-06-17): During the learning phase of your team , one of the nicest things you can do for your team members, is to stop protecting them from the surrounding organization. It was a great thing to do during the chaos phase, when… - [What are you going to do about it?](https://www.5whys.com/articles/what-are-you-going-to-do-about-it.md) (2011-02-03): A couple of Days ago I finished the first “Lead Better” course for software team leaders in Oslo. It was the first time I had done this course out of Israel. It was a great feeling to get the following email today from… - [Exclude a team member – and you’re an idiot](https://www.5whys.com/articles/exclude-a-team-member-and-youre-an-idiot.md) (2010-05-25): Don’t exclude people in your team. It’s important that all people in your team are treated as equals and with respect. It may feel like a “duh” moment, but people get offended, deeply if they are left out of the loop… - [The Bus Factor - Why your ‘best’ developer is your biggest problem](https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.md) (2010-05-17): From wikipedia , a “Bus Factor” is: an irreverent measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would need to be… - [My team keeps breaking their promises. What can I do?](https://www.5whys.com/articles/my-team-keeps-breaking-their-promises-what-can-i-do.md) (2010-05-09): Execution – actually having the team get things done– requires people to : Say what they will do Mean it (be committed) Do it Everyone likes to do #1. Only some do #2. Great teams also do #3. This post is about #2… - [Move-Around kata for team leaders](https://www.5whys.com/articles/move-around-kata-for-team-leaders.md) (2010-02-14): Here’s an experiment for software team leaders: a set of katas (things you repeat exactly the same way many times). Let’s try to do the following kata once a day: Move-Around Get out of your chair and lock your computer… - [Creating Team Trust](https://www.5whys.com/articles/creating-team-trust.md) (2009-12-13): Editor’s note: The following post was written by Johanna Rothman . Johanna helps managers and leaders solve problems and seize opportunities. She consults, speaks, and writes on managing high-technology product… - [The Five Dysfunctions of a Team](https://www.5whys.com/articles/the-five-dysfunctions-of-a-team.md) (2009-12-08): As part of my reading, one book i came across was The Five Dysfunctions of a Team: A Leadership Fable it’s a great book and i recommend that every team leader, at any level, read this. it connects very well to many… - [How to influence others](https://www.5whys.com/articles/how-to-influence-others.md) (2009-11-30): Two books I’ve been occupied with recently deal directly with a very problematic topic for most team leaders world wide – how do you influence people in your team and your organization to either change or help you… - [Dev Anti Pattern: Unworkable Machine](https://www.5whys.com/articles/dev-anti-pattern-unworkable-machine.md) (2009-10-24): Summary: A developer in your team always has problems with their machine, to the point where they are less productive, and always trying to fix something before they can get things done. Usually this gets noticed during… - [4 ways to discover a stuck team member, and what you can do about it](https://www.5whys.com/articles/4-ways-to-discover-a-stuck-team-member-and-what-you-can-do-a.md) (2009-09-06): More than five years ago I wrote on my .NET blog a little sad story about how I got fired from my job as a developer. You can read the full story here . Here is my summary in the context of five or so years ago: “As… ### Anti Patterns - [A Realistic HackerRank Developer Interview Question List](https://www.5whys.com/articles/a-realistic-hackerrank-developer-interview-question-list.md) (2015-07-09): When I was looking for a new job it always puzzled me that companies looking for senior developers, team leaders, architects and Dev managers were asking me to fill out silly hackerrank style questions such as : * How… - [Assume you are wrong](https://www.5whys.com/articles/assume-you-are-wrong.md) (2012-06-21): Here's a chat conversation that actually happened. See if you can find all the places where each person is telling themselves a story about the other person, and then assuming its true, and notice how volatile the… - [You Can't Fire Everyone](https://www.5whys.com/articles/you-cant-fire-everyone.md) (2011-12-09): If you go through your leadership career wondering "if only I'd been stuck with a better team of developers - we'd do much better" - you're doing it wrong. Management - done right, is a tough job. That's why you get… - [Don't be afraid to become management](https://www.5whys.com/articles/dont-be-afraid-to-become-management.md) (2011-12-08): If you do it right, your fears can mostly be wrong. If you do it wrong - your fears will mostly be right. So I just made this late night video to talk about that: Watch on YouTube Don't be afraid to become management - [Three reasons not to have your own private office](https://www.5whys.com/articles/three-reasons-not-to-have-your-own-private-office.md) (2011-10-02): When I was just starting out as a team lead, I remember bemoaning to myself how I wasn't being 'appreciated' enough to have my own office. For geeks like it is can often feel like a status symbol. But the more time goes… - [Technical Anti Patterns Arising from Social Inadequacy](https://www.5whys.com/articles/technical-anti-patterns-arising-from-social-inadequacy.md) (2011-09-19): The book Roundtable on Technical Leadership (SHAPE Forum Dialogues) by Jerry Weinberg is a treasure trove of interesting things that give words to feelings I've had during my work as a team leader and with other team… - [Distributed Team Evasion Tactic - Away or Offline](https://www.5whys.com/articles/distributed-team-evasion-tactic-away-or-offline.md) (2011-08-30): Evasion tactics make sure you as a manager don't have to confront employees, or even engage with them. Engaging with your team is part of your job as a manager. It's *supposed* to be difficult. That's why you get paid… - [Spread your workload](https://www.5whys.com/articles/spread-your-workload.md) (2011-08-27): The following is a guest post by John Hill . You can submit your own guest posts here. John is a .NET Team Leader / Senior Developer for a small Australian CMS software development company. During my many years of… - [Video: Team Leadership in the Age of Agile](https://www.5whys.com/articles/video-team-leadership-in-the-age-of-agile.md) (2011-07-08): during QCon 2011 in London, I gave a talk about the new qualities that team leaders need to make agile succeed. It's a very small fraction of what I cover and coach during my upcoming course. See the full video here… - [Yelling at team members](https://www.5whys.com/articles/yelling-at-team-members.md) (2011-06-17): This is perhaps one of the worst things a team leader could ever do with a team. Multiply that by 10 if that yelling is done in public. It does not matter *how much* frustration you feel. It does not matter *how* much… - [A good leader won't need to ask](https://www.5whys.com/articles/a-good-leader-wont-need-to-ask.md) (2011-06-06): A good team leader would not need to ask you about the good things you've done in the past year. They should be attentive enough to your personal progress, and helping you shape your learning, that they might actually… - [How to annoy your customer with usability problems](https://www.5whys.com/articles/how-to-annoy-your-customer-with-usability-problems.md) (2010-07-03): You can’t download the software. you have to buy it and ship it on a CD set. You HAVE to buy it with headphones, and you HAVE to pay extra taxes for the shipping. During the installation process, multiple DOS windows… - [my worst team leaders](https://www.5whys.com/articles/my-worst-team-leaders.md) (2010-02-14): my worst team leaders Didn’t bother to check or see if I was stuck on something Didn’t coach me or teach me to be a better developer or team mate Didn’t earn my trust in their technical skills Didn’t have a problem with… - [How to deal with bad decisions made by the team](https://www.5whys.com/articles/how-to-deal-with-bad-decisions-made-by-the-team.md) (2009-11-16): I’ve been going through the book “ Succeeding with Agile ” by Mike Cohn. I like what I see so far because it talks about the various failures that happen to us all when we try to implement change in our companies and… ### Meta - [Developing Critical Team Thinking](https://www.5whys.com/articles/developing-critical-team-thinking.md) (2013-02-25): Borrowing a few terms from critical thinking, this is another map, or model, of how I feel I need to guide my teams. When do I feel like I have successful gotten my team where they could have been all along? Here is a… - [Things to consider when building a new team](https://www.5whys.com/articles/things-to-consider-when-building-a-new-team.md) (2012-12-26): Look for inherent knowledge creating experts(leaders) A potential leader is someone who is a bottleneck. an expert. They can become a leader by coaching and sharing on that knowledge. Architects are a good example. If… - [Elastic Leadership Team Survival Vs. Team Chaos Vs. Cynefin](https://www.5whys.com/articles/elastic-leadership-team-survival-vs-team-chaos-vs-cynefin.md) (2012-07-30): I've decided that the word ' chaos ' isn't a good match to describe the phase where a team has no time to learn. Instead, the word 'survival' is going to be used from now on. There are several reasons for this: 1) The… - [Different ways to view organizational change](https://www.5whys.com/articles/different-ways-to-view-organizational-change.md) (2012-05-04): I've written about how to change your organization in a couple of places, but I also highly suggest you read this very interesting blog post referencing different models, some of which I've only had a glipse at uptil… - [Software Team Leader Manifesto - Take #2](https://www.5whys.com/articles/software-team-leader-manifesto-take-2.md) (2012-02-23): after the first one, here's what I have so far. Your comments are appreciated. We believe the role of a team leader is to also grow the people in their team, and themselves, and that this will create the most value for… - [A Manifesto For Software Team Leaders - Take 1](https://www.5whys.com/articles/a-manifesto-for-software-team-leaders-take-1.md) (2011-12-08): It occurs to me that a manifesto for a software team leader is not a bad idea. And, I intentionally not want it to be an "Agile" related manifesto, but more of a management/people/leadership manifesto that applies to… - [Five Questions to ask yourself when getting advice about team leadership](https://www.5whys.com/articles/five-questions-to-ask-yourself-when-getting-advice-about-tea.md) (2011-09-13): Go through each guest post in in this blog , and ask yourself the following questions about it: In what maturity stage does this suggestion make sense? What would happen if I exercise this suggestion during each of the… - [Elastic Leadership](https://www.5whys.com/articles/elastic-leadership.md) (2011-04-04): Elastic leadership is about team context . It is about understanding that you need to lead the team differently, based on which phase you discover the team is in . The phases can change from day to day or week to week… - [3 Quotes about Leadership we should listen to](https://www.5whys.com/articles/3-quotes-about-leadership-we-should-listen-to.md) (2010-07-18): Some inspiring words from twitterverse today: @WilnaMurphy: You can never cross the ocean unless you have the courage to lose sight of the shore. - Christopher Columbus. @leadershipcoach: "If I had asked people what… - [Scrum vs. Kanban attitudes](https://www.5whys.com/articles/scrum-vs-kanban-attitudes.md) (2010-06-13): If you’re wondering about choosing Kanban or Scrum for your team or organization, I’ve found this post to be very enlightening on the differences in attitude and change provocation between the two. I’ve also found that… - [Interview: Patrick Kua : Agile Coach](https://www.5whys.com/articles/interview-patrick-kua-agile-coach.md) (2010-04-21): This time, I talk with Patrick Kua , an Agile Coach living in the UK, about various subjects. Among them – the various types of tests, what is “Done”?, The difference between Team Leader and Team Manager and more… - [The three stages of learning team leadership](https://www.5whys.com/articles/the-three-stages-of-learning-team-leadership.md) (2009-09-10): or anything else, for that matter: Shu-Ha-Ri : Practices Principles Values *see related to this: Source: ShuHaRi and competence Cockburn on ShuHaRi This blog is right now at the "Practices" stage: Lots of "Do this" and… ### Growing People - [Feeling Stupid is Highly Recommended](https://www.5whys.com/articles/feeling-stupid-is-highly-recommended.md) (2013-02-10): So, to show you that the whole idea of taking risks and feeling stupid or frustrated is actually a good thing, because it's the only way to really learn a new skill, here are videos from my second day ever doing any… - [Video: Lejla Giske on Listening Modes and Techniques](https://www.5whys.com/articles/video-lejla-giske-on-listening-modes-and-techniques.md) (2012-09-14): while at bouvet here in Norway, I'm getting to meet lots of interesting new people. It's a shame for those conversations to go to waste, so if they are interesting, I record what they have to say (not my job… - [Video: The Team Leader Manifesto, Growing Effective Teams](https://www.5whys.com/articles/video-the-team-leader-manifesto-growing-effective-teams.md) (2012-06-15): Here is my talk from NDCOslo 2012 , two weeks ago. It details my current view and thoughts about the role of the team leader, and the manifesto is a good way to capture that. A video was embedded here. It is no longer… - [Check-in: sharing emotions in an effective way](https://www.5whys.com/articles/check-in-sharing-emotions-in-an-effective-way.md) (2009-10-23): In this blogpost I will cover “The Check-In Protocol” portion of The Core Protocols which are available for download at http://alturl.com/b9fn One of the most effective and, consequently, one of the most controversial… - [The hidden leadership lessons we can learn from music conductors](https://www.5whys.com/articles/the-hidden-leadership-lessons-we-can-learn-from-music-conduc.md) (2009-10-21): This very inspiring video raises many questions and analogies to our technical world of leadership: Watch the talk on TED.com (Itay Talgam: Lead like the great conductors) I'd sure love to sit with Itay (the presenter)… - [The Core Protocols Introduction](https://www.5whys.com/articles/the-core-protocols-introduction.md) (2009-10-16): Roy has asked me if I wanted to write a few guest posts on the 5 Why’s about The Core Protocols. I will start by explaining where these rules came from. This story starts in 1995. Jim McCarthy wrote Dynamics of Software… - [How to measure programmer productivity using TDD Katas](https://www.5whys.com/articles/how-to-measure-programmer-productivity-using-tdd-katas.md) (2009-09-30): A TDD Kata is an exercise in writing code, test first, which one repeats once or more a day. Here's an example of one . I make students that take my TDD course do this kata each morning, in the space of 30 minutes. Near… - [Leading Through Learning: The Responsibilities of a Team Leader](https://www.5whys.com/articles/leading-through-learning-the-responsibilities-of-a-team-lead.md) (2009-09-30): Editor's note: The following is a guest post from Cory Foy . Cory Foy is an agile coach and developer living in Bayonet Point, FL. He is currently helping product teams become much more lean in their approaches to… - [Be Productive and Go Mouseless](https://www.5whys.com/articles/be-productive-and-go-mouseless.md) (2009-09-25): Watch on YouTube Go Mouseless - [Growing developers: Ask for solutions instead of giving them](https://www.5whys.com/articles/growing-developers-ask-for-solutions-instead-of-giving-them.md) (2009-09-18): This post is part of the " Growing Developers " guidance. One of the best things you can do for the developers on your team is to stop giving them the solutions to problems they are facing, and instead ask them to find… - [5 ways to grow great developers instead of desperately looking for them](https://www.5whys.com/articles/5-ways-to-grow-great-developers-instead-of-desperately-looki.md) (2009-09-16): One of the most common phrases you hear from managers about lack of agile adoption in their team is We don't have that kind of 'super' developer here. We just have ordinary day folks - they can't handle it. And We can't… ### Video - [Ask Royo #1 - Team Leadership and Influence Edition](https://www.5whys.com/articles/ask-royo-1-team-leadership-and-influence-edition.md) (2014-11-03): A new experiment I'm making. Twieet me questions about anything relating to leadership or software dev, and I'll try to answer as best I can if I have any knowledge in the area. In this episode I answer the following… - [Video: The Coaching Architect](https://www.5whys.com/articles/video-the-coaching-architect.md) (2013-02-01): A few days ago I gave a talk at the Architect Meetup here in Oslo. It was about the role of the architect, and how to become a coaching architect. I hope you enjoy this video. Watch on YouTube The Coaching Leader &… - [Video (Hebrew): On Time, With Quality? Yeah Right.](https://www.5whys.com/articles/video-hebrew-on-time-with-quality-yeah-right.md) (2012-09-18): A few months ago I gave a talk at at secret military base in Israel. It was for some of the future tech leaders growing in the womb of Israel's technical military units. It talks about leadership, and how to make it… - [Leadership and management talk videos from NDC Oslo](https://www.5whys.com/articles/leadership-and-management-talk-videos-from-ndc-oslo.md) (2012-06-15): There weren't many of those, but here are some talks from NDC Oslo 2012 that you might find interesting: The Software Team Leader Manifesto (me) Panel - The State of Agile and the road ahead What does Self-Organizing… - [Choice](https://www.5whys.com/articles/choice.md) (2010-06-23): Maybe all Microsoft developers need to watch this http://66.29.219.11/conery_ndc_talk.mp4 - [Video - Pair Programming with a Guitar](https://www.5whys.com/articles/video-pair-programming-with-a-guitar.md) (2009-10-27): Sure, Pair programming sounds a bit weird at first, but just show this video to those who aren't yet inspired to do it. via Naresh , living proof that pair programming can work beautifully in many areas :) A video was… - [Video: Influence Strategies](https://www.5whys.com/articles/video-influence-strategies.md) (2009-10-16): Richard banks posted what seems to be an interesting video about "Influence Strategies", based in Linda Rising 's work. I'd also recommend taking a look at his "Management" tag on his blog for some interesting gems… - [Be Productive and Stop Using XML](https://www.5whys.com/articles/be-productive-and-stop-using-xml.md) (2009-09-25): Watch on YouTube Stop using XML - [IDCC talk: Beautiful teams and code leaders is online](https://www.5whys.com/articles/idcc-talk-beautiful-teams-and-code-leaders-is-online.md) (2009-09-15): yesterday the first IDCC conference took place - it is a grass roots community driven conference and it was great! My talk on beautiful teams and code leaders is online here (in Hebrew). The list of questions every team… ### Courses - [Two Day Leadership Workshop–London April 11-12](https://www.5whys.com/articles/two-day-leadership-workshopndashlondon-april-11-12.md) (2013-02-03): I would love to see you at my upcoming two day workshop in London . Place is limited to 20 participants. The workshop is for architects, team leaders, and managers of software people. The point? Learn how to make the… - [Elastic, Agile, Adaptive Leadership Workshop, January 31 2013, Oslo](https://www.5whys.com/articles/elastic-agile-adaptive-leadership-workshop-january-31-2013-o.md) (2013-01-16): This January, the 31st, I will be giving a two day Workshop for team leaders, architects, and scrum masters, titled Elastic, Agile, Adaptive Leadership. If you’re interested in joining, please contact me directly (or… - [Upcoming leadership 1 day courses in sweden](https://www.5whys.com/articles/upcoming-leadership-1-day-courses-in-sweden.md) (2012-06-20): I will be joining foo-cafe in sweden to do some one-day courses with them. If all goes well, this will be a continuous schedule every month : Stockholm, November 2. 2012 - Essential Skills and elastic leadership for… - [Elastic Leadership course in Amsterdam - July](https://www.5whys.com/articles/elastic-leadership-course-in-amsterdam-july.md) (2012-05-06): Join me this July for two days of elastic team leadership workshop. Learn new skills, get out of your comfort zone, and learn to lead better. We can tackle all the hard questions together. I'm also looking for a venue… - [Lead Better Bucharest Edition - This Month](https://www.5whys.com/articles/lead-better-bucharest-edition-this-month.md) (2012-03-03): I'm happy to say that I'll be visiting Bucharest on the 22-23 of this month. This is the first time ever I'm visiting there and I'm bringing my new course - Lead Better (which is based on this blog, and and the new book… - [Stavanger Norway Elastic Leadership Course](https://www.5whys.com/articles/stavanger-norway-elastic-leadership-course.md) (2011-11-29): This is very short notice, (which is why there is a surprise) - but During December 15-16, I'll be doing my Elastic Leadership Course "Lead Better" in Stavanger, Norway. It is based on my experiences blogged here at… - [Oslo Lead Better Workshop - August 8-9 2011](https://www.5whys.com/articles/oslo-lead-better-workshop-august-8-9-2011.md) (2011-07-24): This August, I will be running my two day workshop in Oslo , for new and experienced team leaders about elastic leadership of software teams - called "Lead Better". You can register here. Feel free to contact me… - [London Team Leader Course this July](https://www.5whys.com/articles/london-team-leader-course-this-july.md) (2011-06-17): I'll be in London next month, teaching my new two day "Lead Better" course - essential skills for team leaders. I hope you'll join me! Why should you care about this course? Have you ever come across these situations?… ### Guest Post - [12 Lessons Learned for a New Team Lead](https://www.5whys.com/articles/12-lessons-learned-for-a-new-team-lead.md) (2013-02-02): This guest post is by Oren Ellenbogen . I’ve personally known Oren for a few years, and he is one of those people that you just know you will be seeing on the cover of some tech newspaper sometime in a a few years. Oren… - [Go see, ask why, show respect](https://www.5whys.com/articles/go-see-ask-why-show-respect.md) (2011-09-13): The following is guest post by Horia Sluşanschi . Contribute your own here. About Horia: Horia is a passionate Agile Coach, serving as the leader of the HP Agile Mentoring Office, and the HP Software Engineering… - [Appraisals and Agile Don't Play Nicely](https://www.5whys.com/articles/appraisals-and-agile-dont-play-nicely.md) (2011-09-05): The following is a guest post by Gary Reynolds . Contribute your own here. Gary is a Development Manager for a global software company, with particular expertise in transitioning teams from 'traditional' software… - [Making your team manage their own work](https://www.5whys.com/articles/making-your-team-manage-their-own-work.md) (2011-09-02): The following is a guest post by Lior Friedman . Contribute your own here. About Lior: I’m an Agile coach and Software Craftsman with more than fifteen years of experience. In recent years I consult and train teams… - [Change your mind: your product is your team](https://www.5whys.com/articles/change-your-mind-your-product-is-your-team.md) (2011-08-13): The following is a guest post by Jose Ramón Díaz , Agile coach at Biko. About Jose: My experience has always been in software development in the Java world. I am currently in charge of a development team in Biko2. I am… - [Leadership and the mature team](https://www.5whys.com/articles/leadership-and-the-mature-team.md) (2010-05-18): The following is a guest post by Mike Burrows . Until last year a developer, project leader and development manager in investment banking, Mike is now an IT Director in the energy risk management industry, still leading… ### people patterns - [How to plan and influence change at your company](https://www.5whys.com/articles/how-to-plan-and-influence-change-at-your-company.md) (2009-12-10): In the book “Influencer” , the authors describe six forces that work together to influence any particular human behavior that we might want to change. The forces that influence behavior are: Personal Motivation : Why… - [Be more approachable in five minutes](https://www.5whys.com/articles/be-more-approachable-in-five-minutes.md) (2009-10-28): I found this blog post interesting because it starts out with a simple premise: you are not as "approachable" as you think. It also introduces the concept of " Daily Five Minutes ". That article is pretty long, but this… - [A Possible Job Description: Team Leader](https://www.5whys.com/articles/a-possible-job-description-team-leader.md) (2009-10-16): Editor's Note: This is a guest post by Kevin Stevens. Kevin Stevens is a Senior Software Engineer at Ecology & Environment in Buffalo, NY. He claims to be the only person who has a B.A. in acting, a B.S. in Computer… - [How to squeeze a decision out of a sleepy meeting](https://www.5whys.com/articles/how-to-squeeze-a-decision-out-of-a-sleepy-meeting.md) (2009-10-15): Yves has a short and to the point post - There's a simple protocol you can try for that. - [Why managing a software team can be more effective than "regular" management](https://www.5whys.com/articles/why-managing-a-software-team-can-be-more-effective-than-regu.md) (2009-09-24): Over on the team leadership mailing list , Yves claimed: "Is leading a software team different then leading another team? No it's not. Can it help to know about writing software? yes if you can also let go of control… - [Immediate and delayed satisfaction in software development](https://www.5whys.com/articles/immediate-and-delayed-satisfaction-in-software-development.md) (2009-09-10): All our lives we're told a mantra that keeps repeating itself. We hear it as children when we want an ice cream, and we hear it as adults when we want that brand new car, or that holiday vacation: Have some patience But… ### Audio - [Audio Book - Notes to a Software Team Leader, Now Available](https://www.5whys.com/articles/audio-book-notes-to-a-software-team-leader-now-available.md) (2013-08-15): Good news everyone ! After more than a year in the making, the text version of my book for team leaders is in final production stages, and the audio version is now already available. You can purchase the audio book in… - [Kevlin Henney – 3 things every programmer should know](https://www.5whys.com/articles/kevlin-henney-ndash-3-things-every-programmer-should-know.md) (2010-05-08): During the ACCU 2010 conference in London, I got to get on audio, several of the interesting people who attended and spoke at the conference. One of them was Kevlin Henney . I first got to see him speaking during NDC… - [Interview: James Bach – The role of the tester](https://www.5whys.com/articles/interview-james-bach-the-role-of-the-tester.md) (2010-04-19): During the ACCU 2010 conference in London (at which I am still stuck due to the ash cloud while writing this), I got to speak with many interesting people, and even recorded some of those conversations. One of the talks… - [A bunch of (old) audio interviews on management and agile methodologies](https://www.5whys.com/articles/a-bunch-of-old-audio-interviews-on-management-and-agile-meth.md) (2009-09-29): Here are a bunch of audio interviews I did a loong while ago, but I feel that at least some of them still hold true today. Johanna Rothman - Secrets of great management (01/12/05) Johanna Rothman keeps coming back to… ### Link Love - [The Clean Coder](https://www.5whys.com/articles/the-clean-coder.md) (2011-06-17): Robert Martin (uncle bob to many), released a new book - The Clean Coder : I had the honor of contributing a section to the book, called "A language of commitment", and it's based, in many ways, about this blog post… - [Confessions of a First Time Manager](https://www.5whys.com/articles/confessions-of-a-first-time-manager.md) (2009-12-14): Tim Barcz just became a manager of a large group of people. And he’s got some advice for you ! - [Other blogs on management and leadership](https://www.5whys.com/articles/other-blogs-on-management-and-leadership.md) (2009-12-01): Rands in Repose Noop Pawerl Brodzinski Scott Berkun Software by Rob podcast by David Meister Podcast: Manager tools got more? - [9 Articles from Joel On software for Tech Leads](https://www.5whys.com/articles/9-articles-from-joel-on-software-for-tech-leads.md) (2009-09-15): JoelOnSoftware has a bunch of links under the heading of "Tech Lead". I've read some of them, but for future reference I'll post them here as well: Two Stories Human Task Switches Considered Harmful Lord Palmerston on… ### Shu - [How to say NO by saying YES](https://www.5whys.com/articles/how-to-say-no-by-saying-yes-1.md) (2009-09-14): Johanna Rothman, a dear friend and one of the most excellent management consultants I've seen, has a post about managers who won't take no for an answer . Read it, it's interesting! But I'd like to approach the same… - [Document Your Air, Food, and Water](https://www.5whys.com/articles/document-your-air-food-and-water.md) (2009-09-14): Editor's note: The following is a guest post by Travis Illig . Travis Illig is a .NET developer who enjoys the art of solving problems with technology. He is currently a Senior Software Developer with Fiserv, working on… - [How to find hidden problems in your project before it’s too late](https://www.5whys.com/articles/how-to-find-hidden-problems-in-your-project-before-its-too-l.md) (2009-09-08): A team lead I met a couple of years ago told me of a very effective technique he used in new projects and teams where he didn’t yet know what’s really going on, the team members, or all of the things that needed to be… - [Making Impossible Decisions Without Panicking](https://www.5whys.com/articles/making-impossible-decisions-without-panicking.md) (2009-09-07): Sometimes you're faced with a question that only has bad answers. A while ago one of my friends was faced with exactly one of those: It turns out that the technology the team chose to use on the project was not scalable… ### More posts from 2015–2020 - [Possible Anti Pattern: A Remote Team Member is Never Ever Visible in Video Chat (Zoom, Teams)](https://www.5whys.com/articles/2020/6/15/possible-anti-pattern-a-remote-team-member-is-never-ever-visible-in-video-chat-zoom-teams.md) (2020-06-15): Team members that don’t show their face ever, or 99% of the time when video chatting with the team used to be OK, before COVID. But in the age of COVID this shouldn’t be the new normal. Team facilitation and… - [InfoQ Book Q&A on Elastic Leadership](https://www.5whys.com/articles/2019/5/30/infoq-book-qampa-on-elastic-leadership.md) (2019-05-30): I had the privilege of being interviewed by Ben Linders over at InfoQ regarding my book on Elastic Leadership. You can read the article over here. Some of the main takeaways from it: A team can be either in survival… - [The Elastic Leadership Model in a picture](https://www.5whys.com/articles/2019/3/22/the-elastic-leadership-model-in-a-picture.md) (2019-03-22): I realized that there isn’t one picture that shows the entire elastic leadership model with the right amount of details out there. So I made one. Would love any feedback in the comments! - [Johanna Rothman Interview - Agile, a Decade Later](https://www.5whys.com/articles/2019/2/16/johanna-rothman-interview-agile-a-decade-later.md) (2019-02-16): 12 years ago I interviewed Johanna Rothman About Agile development and her then new book “Behind closed doors: secrets of great management”. A few weeks ago we ran again into each other on twitter and decided to see… - [A Critical Chain of Bus Factors](https://www.5whys.com/articles/a-critical-chain-of-bus-factors.md) (2017-02-21): I've spoken before about the meaning of a bus factor . It's basically the idea that if there is only one person in your team that can do a critical part of the work, and that person gets hit by a bus, the team stops… - [Elastic Leadership Book Published](https://www.5whys.com/articles/elastic-leadership-book-published.md) (2017-02-21): I'm happy (if a little late) to annoucne that "Elastic Leadership" has now been officially published by Manning. You can grab the book here - [Elastic Leadership Book: The re-publishing of "Notes to a Software Team Leader"](https://www.5whys.com/articles/elastic-leadership-book-the-re-publishing-of-notes-to-a-soft.md) (2015-10-21): I'm happy to announce that I am re-publishing the "Notes to a Software Team Leader" as a new book under Manning publishing, re-titled "Elastic Leadership". The new book will contain a couple of new chapters, regrouping… - [When I Want to Give Up](https://www.5whys.com/articles/when-i-want-to-give-up.md) (2015-06-11): When I'm at work and I suddenly feel like everything sucks and the world can just burn as far as I'm concerned, I take a look at this picture I found on the web a while ago, printed it and mounted it on my door: It… ### More posts from 2012–2014 - [Dangers of Survival Mode](https://www.5whys.com/articles/dangers-of-survival-mode.md) (2014-11-03): I have just finished teaching a two day elastic leadership class in Denmark. One of the exercises I ask leaders to do is to try and finish a time based LEGO building exercises while the world if crumbling around them… - [Scrum Master 2.0: A Scrum Master is Not](https://www.5whys.com/articles/scrum-master-20-a-scrum-master-is-not.md) (2014-07-21): I'm a big fan of the idea that you should grow your team to be self organizing . I also used to hold the idea e that a Scrum master is just another word for "team coach", that should grow their team. I felt that people… - [3 Reasons to stop solving other people's problems for them](https://www.5whys.com/articles/3-reasons-to-stop-solving-other-peoples-problems-for-them.md) (2014-05-23): If you re an expert in some field in your team (the DB guy, the UI gal, the search Guru.. you know), it also means you're a bottleneck, and people have to constantly wait for you to make decisions on important things… - [Technical Disobedience](https://www.5whys.com/articles/technical-disobedience.md) (2013-11-03): Rachel's Suffering In one of my first jobs as a programmer I joined a team working on a governmental project. The team was sitting at the code shop, not at the governmental place. The coding shop I was working for as a… - [What's your Position, Velocity, and Acceleration? by Neal Tibrewala](https://www.5whys.com/articles/whats-your-position-velocity-and-acceleration-by-neal-tibrew.md) (2013-09-05): About Neal: Neal Tibrewala is the head of software development at L5 Software Group in Austin, TX As a software consultant for 25 years, the thing that I've found the most useful is measuring to figure out where you are… - [Be a Book Reviewer for 'Notes to a Software Team Leader'](https://www.5whys.com/articles/be-a-book-reviewer-for-notes-to-a-software-team-leader.md) (2013-06-20): Want a free book ? Willing to review it on Amazon when it is published? Willing to give me valuable feedback? Fill out this form. Open the form (Google Forms) - [Audio: Preface–Notes to a Software Team Leader](https://www.5whys.com/articles/audio-prefacenotes-to-a-software-team-leader.md) (2013-06-18): Here is a little experiment. Below is the audio version of the Preface of my upcoming book “ Notes to a Software Team Leader ”. Listen on SoundCloud I am thinking of turning this into a saleable audio book. How much… - [Consulting and Leadership Courses in Scandinavia](https://www.5whys.com/articles/consulting-and-leadership-courses-in-scandinavia.md) (2012-09-05): My move to Norway is now almost complete (should be getting my id number mid September.) Bærum Kummune, I am in you. Yeah. And I have the Norwegian keyboard to prøve it. Now that I’m here I plan to do a lot more in… - [Submit your story about a team leader you had - good or bad](https://www.5whys.com/articles/submit-your-story-about-a-team-leader-you-had-good-or-bad.md) (2012-06-19): Have something really important to say to software team leaders out there? Why not publish it in my upcmoing book? It could be anything, as long as there is a PERSONAL story in it. Outline why you liked/disliked that… - [New chapter: "Learning" in the book "From chaos to self organization"](https://www.5whys.com/articles/new-chapter-learning-in-the-book-from-chaos-to-self-organiza.md) (2012-06-19): I just added a new chapter to "From Chaos to Self Organization " . You don't know that book? You would have known it by it's previous name "Elastic Leadership" , and before that it was part of " Notes to a software team… - [Free for Elastic Leadership Training in June/July](https://www.5whys.com/articles/free-for-elastic-leadership-training-in-junejuly.md) (2012-06-12): With all the work going on with our move to norway this august, I managed to not book anything for end of june, and all through july. If anyone wants me to come over and bring some TDD sense , or leadership techniques… - [Joining Forces with other leaders to make change happen](https://www.5whys.com/articles/joining-forces-with-other-leaders-to-make-change-happen.md) (2012-03-30): Let's say you're trying to make some real change happen. Maybe you've just finished doing a course on unit testing, and your development department devs are all excited about making this a reality. But some devs are… - [Contribute a note to my upcoming book - Notes to a software team leader](https://www.5whys.com/articles/contribute-a-note-to-my-upcoming-book-notes-to-a-software-te.md) (2012-03-04): Yesterday I published the first two chapters of my incrementally publishing book " Notes to a software team leader ". You can be part of it. I want you to. The first part of the book will contain concepts from this blog… - [New Book: Notes to a software team leader](https://www.5whys.com/articles/new-book-notes-to-a-software-team-leader.md) (2012-02-28): I've started to write my upcoming book titled " Notes to a software team leader " (hat tip to Kevlin Henney for the name idea). The book will combine many of the subjects this blog addresses, plus notes collected from… - [Stoos Gathering - Initial Thoughts](https://www.5whys.com/articles/stoos-gathering-initial-thoughts.md) (2012-01-08): This past weekend I was honored to be part of what I hope will be the beginning of a transformation in management culture. The start of a tipping point. It was the Stoos Gathering . that site contains a statement that… ### More posts from 2009–2011 - [Ten Things Distributed Team Leaders Should Do](https://www.5whys.com/articles/ten-things-distributed-team-leaders-should-do.md) (2011-10-03): This turned up in one of the LinkedIn groups I'm part of - what practices should you have as a team lead in a distributed team (assuming people work from home, for example)? Have a shared skype chat for the whole team… - [One Day Software Team Leader Skills Class - Lund, Sweden](https://www.5whys.com/articles/one-day-software-team-leader-skills-class-lund-sweden.md) (2011-09-02): FYI - This course has been canceled. I will be doing a one day class for new and experienced software team leaders about important skills you need to "make" it as a team leader. In the class you will learn how to… - [A week in Stockholm - Open for consulting or training](https://www.5whys.com/articles/a-week-in-stockholm-open-for-consulting-or-training.md) (2011-09-01): I'll be spending the week of September 12-16 in Stockholm, Sweden. While i'm there I will be doing consulting gigs and possibly training. If you're interested in me coming to your company for a day or two and teach Test… - [Lead Better - Skills for software team leads, Course next week in Oslo](https://www.5whys.com/articles/lead-better-skills-for-software-team-leads-course-next-week-1.md) (2011-04-07): I'll be doing my " Lead Better " course in Oslo next week . There are 3 places left if you want to join us. If you've ever tried to convince your team to do unit testing or TDD, but failed miserably at getting them to… - [Why XP’s influence is more effective than Scrum](https://www.5whys.com/articles/why-xps-influence-is-more-effective-than-scrum.md) (2009-12-09): in a previous post i explained what are the six forces that influence behavior. based on this, we can now begin to understand why some development methodologies are more effective when applying them at an organization… - [Leadership Conference coming up](https://www.5whys.com/articles/leadership-conference-coming-up.md) (2009-10-16): I'm in the stages of planning a team leadership conference. Chances are it will be held in the UK, week of January 25th (don't hold me to that yet!) I'm still looking for a good name for it. and I bet you can help… - [Manifesto for Continuous Improvement](https://www.5whys.com/articles/manifesto-for-continuous-improvement.md) (2009-09-24): thanks for the picture, Andrew . the difference between the picture above and continuous improvement? The answer to "Are you Happy" is always "No". - [Announcing the Team Leadership Google Group](https://www.5whys.com/articles/announcing-the-team-leadership-google-group.md) (2009-09-16): I believe the next wave of issues that we will need to start solving is that of software leadership. We may all believe in the stuff that agile, tdd and the like bring to the company, but we often have problems… - [Poll: Would you join a team leadership forum on this site?](https://www.5whys.com/articles/poll-would-you-join-a-team-leadership-forum-on-this-site.md) (2009-09-15): Please answer this quick poll, so I can decide if I should spend time on creating a forum for team leadership on this site. A forum will only work if there is a critical mass of people watching it, and I want to make… - [One-Liners a new team lead should and shouldn't read](https://www.5whys.com/articles/one-liners-a-new-team-lead-should-and-shouldnt-read.md) (2009-09-10): Alistair's blog\wiki has a set of specific one liners from programmers - to newly minted team leads. The whole list is here. My 3 favorites were: Whatever their job is, help them be better at it. You are now a junior… - [Generating Internal vs. commercial value](https://www.5whys.com/articles/generating-internal-vs-commercial-value.md) (2009-09-10): Alistair writes about something which I've only thought about in small glimpses, moving on to my daily business: One of the basic ideas behind lean development is that you narrow the amount of process that is done at… - [Is face to face pairing better?](https://www.5whys.com/articles/is-face-to-face-pairing-better.md) (2009-09-09): Two people working on the same machine at the same time? crazy! only, not really. But i'll touch on why pair programming works so great in a different post. This post is about showing a wholly different style of pairing… - [Call for content – what do new team leads need to know on the first day?](https://www.5whys.com/articles/call-for-content-ndash-what-do-new-team-leads-to-know-on-the.md) (2009-09-05): About 5 minutes after I posted about eh existence of this blog on twitter, I’ve gotten lots of great feedback (and various little nitpickings) about the content, what I shoudl talk about and things that I might cover… - [Don’t despair in the face of nitpickers](https://www.5whys.com/articles/donrsquot-despair-in-the-face-of-nitpickers.md) (2009-09-05): as you start up your quest to get better, you’ll find lots of gentle souls who want to help you on your journey to become better. They wil try to help you by trying to point out all the places where you haven’t been… - [The first five Whys](https://www.5whys.com/articles/the-first-five-whys.md) (2009-09-05): You might also like to: Read about the three team phases your team might be in. Read posts on the chaos phase , the learning phase , or the self-leading phase . 1) Why create this blog in the first place? Because I… --- title: "There are no experts" url: "https://www.5whys.com/noexperts.md" canonical: "https://www.5whys.com/noexperts" tags: [] author: "Roy Osherove" description: "Roy Osherove on why there are no experts in software teams, only us, and what a team leader should do about it." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # There are no experts An essay # There are no experts. There is only us. "There are no Experts. There is only us." These two simple sentences always make me feel lonely. They were uttered by Jeremy D. Miller, a developer I had come to appreciate during my years in the software industry. Those sentences makes me feel like there is nobody else to turn to, that I have to start trusting my own instincts, and that whoever tells you they are an expert is either lying or wrong. In my career, which is around 15 years in the IT business as of the time of this writing, I have come to realize that “There are no Experts. There is only us” is very true. In one of my first jobs ever as a programmer, I remember joining a team working on a governmental project; The project was all in Visual Basic 6.0, by the way. The team, including my team leader, really had no idea what they were doing, and, because I also didn’t know what I was doing, I assumed that whatever people were doing was the right way to do it. As time went by, I started to read more books about how software development could work. I read books like The Mythical Man-Month by Fred Brooks and PeopleWare by Tom Demarco and Timothy Lister. I looked around and I could see all of the problems that those books were talking about right there in front of me, in flesh and blood. And I could also see a big silence. Nobody around me seemed to say anything about the crap that we were building, the crap that we were taking from our managers and customers, and certainly nobody was saying anything about the crap we were giving to our customers and managers. Nobody was talking about careless, helpless programmers. It was all just fine for everybody. To paraphrase a comedian I heard: > "Everything was crappy and nobody cared." Now, these were good people. Some were my friends, and they did not intend to do any harm, for sure. They did their best, in the same way ants do their best to overcome raindrops along their path to the anthill. But they weren’t looking up. They weren’t trying to predict where from or why the rain falls and where to be more careful. They didn’t plan better ways to get to the anthill, or to get better helmets for the rain (ok this analogy is breaking down). They were just ... there doing their ant-like job. Project late? sure. That’s life. Quality sucks? Sure. That’s life. Debugging until 3AM? Sure, that’s life. Was I the only one reading books? No. Well, there weren’t many trade books, but there were definitely quite a few. But the books they were reading were not getting them anywhere, and, if they could get them somewhere, they never seemed to find time to finish the books and get there. There was no sense of craftsmanship. But there was also no sense of professionalism. There was just a big downward spiral for each new project, as far as the eye could see. This workplace was not unique by any means. Many places seemed to be like this, in variations, along the years. I hate working at places like that. I always want to make a difference. This book is about making a difference and getting other people to make a difference as well. It is the book for those who feel hopelessly trapped in their jobs, even though they are Architects, Scrum Masters, Team Leaders or Senior De- velopers. This book will try to be the book I wish I had when I first became a team leader. --- title: "There is only us" url: "https://www.5whys.com/thereisonlyus.md" canonical: "https://www.5whys.com/thereisonlyus" tags: [] author: "Roy Osherove" description: "Roy Osherove on why there are no experts in software teams, only us." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # There is only us An essay (updated version) # There are no experts. There is only us. > "There are no Experts. There is only us." --- These two simple sentences always make me feel lonely. They were uttered by [Jeremy D. Miller](https://twitter.com/jeremydmiller), a developer I had come to appreciate during my years in the software industry. Those sentences makes me feel like there is nobody else to turn to, that I have to start trusting my own instincts, and that whoever tells you they are an expert is either lying or wrong.  In my career, which is now just over 20 years in the IT business , I have come to realize that “There are no Experts. There is only us” is very true.  In one of my first jobs ever as a programmer, I remember joining a team working on a governmental project; The project was all in Visual Basic 6.0, by the way. The team, including my team leader, really had no idea what they were doing, and, because I also didn’t know what I was doing, I assumed that whatever people were doing was the right way to do it. As time went by, I started to read more books about how software development could work. I read books like The Mythical Man-Month by Fred Brooks and PeopleWare by Tom Demarco and Timothy Lister. I looked around and I could see all of the problems that those books were talking about right there in front of me, in flesh and blood. And I could also see a big silence. Nobody around me seemed to say anything about the crap that we were building, the crap that we were taking from our managers and customers, and certainly nobody was saying anything about the crap we were giving to our customers and managers. Nobody was talking about careless, helpless programmers. It was all just fine for everybody. To paraphrase a comedian I once heard.: Everything was crappy and nobody cared. Now, these were good people. Some were my friends, and they did not intend to do any harm, for sure. They did their best, in the same way ants do their best to overcome raindrops along their path to the anthill. But they weren’t looking up. They weren’t trying to predict where from or why the rain falls and where to be more careful. They didn’t plan better ways to get to the anthill, or to get better helmets for the rain (ok this analogy is breaking down). They were just ... there doing their ant-like job. Project late? sure. _That’s life._ Quality sucks? Yeah. _That’s life._ Debugging until 3AM? Sure, _that’s life_. Was I the only one reading books? No. Well, there weren’t many trade books, but there were definitely quite a few lying around the office. But the books they were reading were not getting them anywhere, and, if they could get them somewhere, they never seemed to find time to finish the books and get there. There was no sense of craftsmanship. But there was also no sense of professionalism. There was just a big downward spiral for each new project, as far as the eye could see. This workplace was not unique by any means. Many places seemed to be like this, in variations, along the years. I hate working at places like that. I always want to make a difference. This site, and the book that is based on it, are about making a difference and getting other people to make a difference as well. They are for those who feel hopelessly trapped in their jobs, even though they are Architects, Scrum Masters, Team Leaders or Senior Developers. This site will try to be the site I wish I had when I first became a team leader. --- title: "Archived interviews" url: "https://www.5whys.com/archived-interviews.md" canonical: "https://www.5whys.com/archived-interviews" tags: [] author: "Roy Osherove" description: "Audio interviews by Roy Osherove with Johanna Rothman, Kent Beck, Juval Lowy, David Platt, Charlie Poole and others on management and agile development, 2005 to 2006." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Archived interviews Listen # Archived agile audio interviews Here’s are a bunch of audio interviews I did a long while ago, but I feel that at least some of them still hold true today. The others will serve as nostalgic remnants of a past long gone. I’ll let you decide which are which. --- ## **Johanna Rothman Interview- Secrets of great management (December 2005)** [Johanna Rothman](http://www.jrothman.com/) keeps coming back to Israel to teach management courses and consult and, well , I just love talking to her so much I keep asking her to do more and more interviews with me. Amazingly, she agrees every time. This time Johanna talks about topics from her new book out with Esther Derby - "[Behind Closed Doors : Secrets of Great Management](http://www.amazon.com/exec/obidos/ASIN/0976694026/iserializable-20)": Learning to delegate, coaching effectively, giving effective feedback, what makes for effective meetings, Solving problems and some planning tips. If you've listened to any of the other interviews with Johanna (listed lower on this page) this is a nice take off from some of the topics Johanna has talked about in the past. This time we are concentrating more on the managerial side of things - things any new team lead or project lead needs to hear and read about. **Team Agile Talk - JRothman Part 1**49 min [Audio](https://www.5whys.com/audio/TeamAgileTalk_JRothman_011205_1.mp3) [Download the audio](https://www.5whys.com/audio/TeamAgileTalk_JRothman_011205_1.mp3) **Team Agile Talk - JRothman Part 2**49 min [Audio](https://www.5whys.com/audio/TeamAgileTalk_JRothman_011205_2.mp3) [Download the audio](https://www.5whys.com/audio/TeamAgileTalk_JRothman_011205_2.mp3) Johanna has written over 100 articles and papers and is now a columnist for Fast Company’s online career center, Software Development, Computerworld.com, and StickyMinds.com. Johanna is the author of the highly acclaimed [**Hiring the Best Knowledge Workers, Techies & Nerds**](http://www.amazon.com/exec/obidos/ASIN/0932633595/ref=nosim/rds-20), and is the coauthor of [**Corrective Action for the Software Industry**](http://www.amazon.com/exec/obidos/ASIN//0971323194/ref=nosim/rds-20). Johanna is also a host and session leader at the Amplifying Your Effectiveness (AYE) conference. --- --- ## **Kent Beck - An Agile conversation  (Feb 2006)** After almost 8 months of scheduling nightmare, I've finally had the pleasure of having a great conversation with noted author and speaker, Kent Beck. This is more of a conversation rather than an interview. The conversation revolves around (but not limited to) the following subjects: Kent's upcoming book, "Implementation Patterns", Is Agile just another fad? What is Appreciative Inquiry? Why is the 1st edition of "XP Explained" totally wrong and misleading in its attitude, and what makes the 2nd Edition better? When does Pair Programming break and how does Kent feel about the book "XP Refactored"? All these and more topics in this intriguing conversation. There is much more we wanted to talk about, but Kent felt this would make for a nice "first iteration". Post your comments on this interview in [this blog post](http://weblogs.asp.net/rosherove/archive/2006/02/01/437077.aspx) and let us know what you'd like to hear about, or whether you agree or disagree with the topics in this conversation. We'll take all these into account during a future conversation we will record. **Roy Osherove Interviews Kent Beck Feb 2006**76 min [Audio](https://www.5whys.com/audio/TeamAgileTalk_KentBeck_010206.mp3) [Download the audio](https://www.5whys.com/audio/TeamAgileTalk_KentBeck_010206.mp3) [Extreme Programming Explained : Embrace Change (2nd Edition)](http://www.amazon.com/exec/obidos/ASIN/0321278658/iserializable-20) **_KENT BECK_**  Kent is the founder and director of Three Rivers Institute. He has pioneered patterns for software development, the xUnit family of testing frameworks, the HotDraw drawing editor framework, CRC cards, refactoring, and most recently Extreme Programming. He is the author of Extreme Programming Explained, Planning Extreme Programming, and The Smalltalk Best Practice Patterns. He lives on 20 acres in rural southern Oregon with his wife, five children (one sadly now gone to college), four dogs, two sheeps, and a variable number of domestic fowl. --- --- ## **David Platt and Juval Lowy - Why Software Sucks And Other Architectural Insights (2015)**    What do you ask when you get two software legends in one place? High level, world shattering questions, of course. Listen to this semi-serious chat mostly between Juval and David as they discuss matters such as Why software today sucks, Rich Client Vs. the browser, ClickOnce and unprotected sex (you heard correctly), the anthology of TLAs, how to know you're a geek, their upcoming books, top things to watch out for in .NET 2.0, where is software architecture heading, top 3 things every .NET developer should have done by now, Platt's laws of the universe and much more discussion, jokes and good ol' geeky fun. Truly a one of kind human experiment, is all I can say about this one. **Roy Osherove Interview Juval Lowy and David Platt - Why Software Sucks**61 min [Audio](https://www.5whys.com/audio/TeamAgileTalk_JuvalAndDavid.mp3) [Download the audio](https://www.5whys.com/audio/TeamAgileTalk_JuvalAndDavid.mp3) **David S. Platt** teaches Programming .NET at Harvard University and at companies all over the world. He was selected by Microsoft as one of their Software Legends, which you can read about at [www.softwarelegends.com](http://www.softwarelegends.com/). He has taught classes on ACORD insurance standards since the very first OLifE class in 1995. He is the author of eight programming books, most recently _Introducing Microsoft .NET, 3rd Edition_ from Microsoft Press, with three more on the way. It is currently outselling Tom Clancy's_Every Man a Tiger_ on Amazon.com, which tells you what kind of geeks buy their books there. "He's the only guy I know that can actually make an article on COM's apartment threading model funny," said Tana Sabatino. Dave holds the Master of Engineering degree from Dartmouth College. He did his undergraduate work at Colgate University. When he finishes working, he spends his free time working some more. He wonders whether he should tape down two of his daughter's fingers so she learns how to count in octal. (Check them, has he done it yet?) He lives in Ipswich, MA. --- --- ## **Juval Lowy   - Project Planning and Tracking (24/8/05)** Juval was invited to speak to the Israeli .NET Fight Club, a special group of .NET Insiders in Israel, many of them MVPs and community leaders. Juval's visit was sponsored by Gadi Meir, of [Idag](http://www.idag.co.il/) Israel. Juval spent 2 hours talking about something he usually does not address in public conferences and such, not even in his books - the issues of software development process and project management. In these two hours he presents his vision and way of work in projects he managed (when he had both an architect and a project lead role) and the things he believes bring on the best result. The outcome is "Staged Delivery" which he outlines in broad strokes, yet specific enough to gain some good understanding of the concepts behind it. Some of the issues addressed include: Staffing, the product life cycle, component integration plan and the component life cycle, component testing, Estimation and estimation tools, Earned Value tracking and more. The talk ends 5 minutes prematurely due to technical difficulties, but let me assure you that you don't miss anything terribly important (no "surprise ending" :) ) **Team Agile Talk - Juval Lowy on Project Planning Part 1**60 min [Audio](https://www.5whys.com/audio/Juval_DNFC_1.mp3) [Download the audio](https://www.5whys.com/audio/Juval_DNFC_1.mp3) **Team Agile Talk - Juval Lowy on Project Planning Part 2**59 min [Audio](https://www.5whys.com/audio/Juval_DNFC_2.mp3) [Download the audio](https://www.5whys.com/audio/Juval_DNFC_2.mp3)  **Juval Löwy** is the founder of IDesign and its Chief Architect. Juval is a seasoned software architect specializing in system architecture and large applications design. Juval helps IDesign customers design scaleable, robust, reusable, and extensible Enterprise applications, verifying that the customer has the design it takes to achieve the required quality, scalability, security, availability and throughput goals. Juval is [Microsoft’s Regional Director](http://www.microsoft.com/rd) for the Silicon Valley, working with Microsoft on on helping the industry adopt .NET. Juval also participates in the Microsoft internal design reviews for future versions of .NET. Juval is a frequent speaker at the major international software development conferences, where he talks about .NET, component-oriented design and development process. Click [here](http://www.idesign.net/idesign/BAC/DesktopDefault.aspx?tabindex=4&tabid=22#lowy) for complete list of conference talks by Juval. Juval authored [Programming .NET Components](http://www.amazon.com/exec/obidos/tg/detail/-/0596003471/qid=1032142147/sr=8-2/ref=sr_8_2/104-2684363-4400768?v=glance&s=books&n=507846) by O’Reilly. The book is dedicated to component-oriented programming and design using .NET, as well as the related system issues, such as remoting, threading and security. Juval also authored [COM and .NET Component Services: Mastering COM+](http://www.oreilly.com/catalog/comdotnetsvs) a book which talks at length about the challenging topic of .NET Enterprise Services. Juval published numerous articles, regarding almost every aspect of developing with .NET. Click [here](http://www.idesign.net/idesign/BAC/DesktopDefault.aspx?tabindex=3&tabid=21#lowy) for complete article list by Juval, as well as links to the articles. Microsoft recognized Juval as a [Software Legend](http://www.softwarelegends.com/) as one of the world top .NET experts and industry leaders. --- --- ##  **Randy Miller -MSF Agile and modeling techniques in software(TechEd Europe - July 2005)** I chatted with  [Randy Miller](http://blogs.msdn.com/randymiller), the guy who practically _wrote_ MSF,  for a very interesting half hour (due to technical difficulties we had to stop early). The interview revolves around MSF-  the Microsoft Solution Framework for creating software processes, its origins, its main goals and benefits and how it fits in with Microsoft Team System. We also talk a little about how it compares to other processes such as the Rational Unified Process. The conversation also turns into the fascinating topic of software modeling today and the use of "Personas" to capture design requirements. more stuff: MSF vs. CMMI, empowering developers in the development process, and the future of MSF. **Randy Miller -MSF Agile and modeling techniques in software**36 min [Audio](https://www.5whys.com/audio/TeamAgileTalk_RandyMiller.mp3) [Download the audio](https://www.5whys.com/audio/TeamAgileTalk_RandyMiller.mp3) _Language - English._ Randy Miller (also known as Granville Miller) is author of Advanced Use Case Modeling and A Practical Guide to Extreme Programming.  He has spoken at many national events including OOPSLA, Web Services Edge, Software Development West, Microsoft TechEd and others.  He has also spoken for SPIN in the past ([http://www.rtpspin.org](http://www.rtpspin.org/)). You can find out more about Randy's work from his blog at: [http://blogs.msdn.com/randymiller](http://blogs.msdn.com/randymiller).  You can learn more about Visual Studio 2005 Team System at: [http://lab.msdn.microsoft.com/teamsystem](http://lab.msdn.microsoft.com/teamsystem).  And specifically about its plans to support the Agile methodology at: [http://blogs.msdn.com/team\_foundation/archive/2005/02/07/368599.aspx](http://blogs.msdn.com/team_foundation/archive/2005/02/07/368599.aspx) . --- ## **Kieran Mockford-  Program manager for MSBuild, Microsoft -Building MSBuild, Test Driven Development style (February 28, 2005)** **Kieran Mockford-  Program manager for MSBuild, Microsoft -Building MSBuild, Test Driven Development**67 min [Audio](https://www.5whys.com/audio/GeekSpeak_with_Kieran_Mockford.mp3) [Download the audio](https://www.5whys.com/audio/GeekSpeak_with_Kieran_Mockford.mp3) Roy Talks with  Kieran Mockford, the program manager for MSBuild, Microsoft's brand new build tool offering. Kieran spills the beans that MSBuild was developed using Test Driven Development methodologies with tools such as [NUnit](http://nunit.org/). Kieran tells about the various problems and solutions they encountered trying to learn TDD, then the talk moves to MSBuild and the need for "real" incremental build abilities and the Microsoft internal build process. It's a Fascinating look behind the scenes of Microsoft's internal tools for source control and continuous integration automation tools. --- --- ## **Johanna Rothman at Agile Israel user group: Nine Steps to becoming Agile(March 23, 2005)** **Johanna Rothman at Agile Israel UG 2005 part 1**51 min [Audio](https://www.5whys.com/audio/JRothman_AgileIsrael_part_one.mp3) [Download the audio](https://www.5whys.com/audio/JRothman_AgileIsrael_part_one.mp3) **Johanna Rothman at Agile Israel UG 2005 part 2**37 min [Audio](https://www.5whys.com/audio/JRothman_AgileIsrael_part_two.mp3) [Download the audio](https://www.5whys.com/audio/JRothman_AgileIsrael_part_two.mp3) **Summary** [Johanna](http://jrothman.com/) Discusses the 9 steps each organization might want to consider as they start to move toward a more Agile development process. An interesting and funny speaker, Johanna discusses Daily builds, Automated smoke tests, Implementing by slice, Testing early and often, Timeboxing requirements work, ranking the requirements, Rolling wave planning, defining milestones based on deliverables -  not functions,and  creating cross-functional project teams. Johanna has written over 100 articles and papers and is now a columnist for Fast Company’s online career center, Software Development, Computerworld.com, and StickyMinds.com. Johanna is the author of the highly acclaimed [**Hiring the Best Knowledge Workers, Techies & Nerds**](http://www.amazon.com/exec/obidos/ASIN/0932633595/ref=nosim/rds-20), and is the coauthor of [**Corrective Action for the Software Industry**](http://www.amazon.com/exec/obidos/ASIN//0971323194/ref=nosim/rds-20). Johanna is also a host and session leader at the Amplifying Your Effectiveness (AYE) conference --- --- ## **Charlie Poole, Lead Developer, NUnit: Test Driven Development, XP, NUnit and more (March 14, 2005)** **Charlie Poole Interview Part 1**71 min [Audio](https://www.5whys.com/audio/Charlie_Poole_Part1.mp3) [Download the audio](https://www.5whys.com/audio/Charlie_Poole_Part1.mp3) **Charlie Poole Interview Part 2**35 min [Audio](https://www.5whys.com/audio/Charlie_Poole_Part2.mp3) [Download the audio](https://www.5whys.com/audio/Charlie_Poole_Part2.mp3) **Summary** Roy Talks with [Charlie Poole](http://www.charliepoole.org/), the lead developer of NUnit on various Agile topics. These include Upcoming NUnit features, Test Driven Development best practices, implementing XP in an organization, testing GUIs, threads, mock objects and much much more. Charlie also spills the beans about the upcoming NUnit blogs. Charlie has spent more than 30 years as a software developer, designer, project manager, trainer and coach. He works through his own company, [Poole Consulting](http://www.pooleconsulting.com/), in the US and recently joined Dublin-based [Exoftware](http://www.exoftware.com/CharliePooleJoining.htm) to provide mentoring and training to clients in Europe. --- --- ## **Juval Lowy - Great architects and management, January 18, 2005** **Juval Lowy on Great Architects and Management**73 min [Audio](https://www.5whys.com/audio/Roy_Talks_with_Juval_Lowy_180105.mp3) [Download the audio](https://www.5whys.com/audio/Roy_Talks_with_Juval_Lowy_180105.mp3) **Summary** Roy Talks with  Juval Lowy, the principal of [IDesign](http://www.idesign.net/) and one of the industry's leading software architects. The topics include: Project management and the IDesign process, staged delivery and what's missing in today's Agile methdologies, the makings of a good software architect, details about his upcoming book and on the one to follow after that, the future of modeling tools, Longhorn, Indigo, SOA and interoperability and more. The interview also takes a more personal tone when Juval talks about his strategy for managing his busy schedule, how IDesign came to be and the people working there, the biggest mistake he's done and more tidbits. A feature packed 73 minute interview, is all I can say. --- --- ## **Natty Gur - Organizational Enterprise Architecture. January 16, 2005** **Natty Gur - Organizational Enterprise Architecture**72 min [Audio](https://www.5whys.com/audio/Roy_Talks_with_Natty_Gur_160105.mp3) [Download the audio](https://www.5whys.com/audio/Roy_Talks_with_Natty_Gur_160105.mp3) **Summary** Roy Talks with [Natty Gur](http://weblogs.asp.net/NGur) - An independent software consultant specializing in Enterprise architecture - in the organizational level. In this interview we'll explore what organizational architecture really means and why its needed. More topics in the interview include Natty's open source project, [NWAF](http://nwaf.sf.net/), Service oriented architecture, organizational patterns such as [TOGAF](http://theopengroup.org/) and DODAF, the problems with layered architecture (N-Tier), Agile development, learning from past mistakes and Naked objects. Good stuff. --- title: "Elastic Leadership videos" url: "https://www.5whys.com/videos.md" canonical: "https://www.5whys.com/videos" tags: [] author: "Roy Osherove" description: "Talks and videos by Roy Osherove about Elastic Leadership and software team leadership." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Elastic Leadership videos Watch Talks by Roy on team leadership. They open on YouTube. [![](https://www.5whys.com/img/video/youtube-jHCUIgP_p8Q.jpg)Watch on YouTube](https://www.youtube.com/watch?v=jHCUIgP_p8Q) CLOSING KEYNOTE: Elastic Leadership for Testers by Roy Osherove Video: CTO Universe Leadership Series: Team Leadership in the Age of Agile. It is no longer publicly available on Vimeo. Video: Roy Osherove - Growing great teams and adopting new processes through Elastic Leadership. It is no longer publicly available on Vimeo. [![](https://www.5whys.com/img/video/youtube-3_UX8Kqb3aU.jpg)Watch on YouTube](https://www.youtube.com/watch?v=3_UX8Kqb3aU) Unit Testing and TDD: Why you should care and how to make it happen [![](https://www.5whys.com/img/video/youtube-uvwW_CRmWmo.jpg)Watch on YouTube](https://www.youtube.com/watch?v=uvwW_CRmWmo) The Coaching Leader & Architect - Roy Osherove Video: Roy Osherove - The Software Team Leader Manifesto. It is no longer publicly available on Vimeo. --- title: "Recommended books" url: "https://www.5whys.com/recommended-books.md" canonical: "https://www.5whys.com/recommended-books" tags: [] author: "Roy Osherove" description: "Roy Osherove's reading list for software team leaders: Peopleware, The Five Dysfunctions of a Team, Behind Closed Doors and more." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Recommended books Read 27 books every software team leader should read. 1. [Peopleware: Productive Projects and Teams (Second Edition)](http://www.amazon.com/exec/obidos/ASIN/0932633439/?tag=iserializable-20) by Tom DeMarco, Timothy Lister 2. [Influencer: The Power to Change Anything](http://www.amazon.com/exec/obidos/ASIN/007148499X/?tag=iserializable-20) by Kerry Patterson, Joseph Grenny, David Maxfield, Ron McMillan, Al Switzler 3. [The Five Dysfunctions of a Team: A Leadership Fable (J-B Lencioni Series)](http://www.amazon.com/exec/obidos/ASIN/0787960756/?tag=iserializable-20) by Patrick Lencioni 4. [Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers)](http://www.amazon.com/exec/obidos/ASIN/0976694026/?tag=iserializable-20) by Johanna Rothman, Esther Derby 5. [Hiring Geeks That Fit](http://www.amazon.com/exec/obidos/ASIN/B00AUYNM38/?tag=iserializable-20) by Johanna Rothman 6. [Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))](http://www.amazon.com/exec/obidos/ASIN/0321712471/?tag=iserializable-20) by Jurgen Appelo 7. [How to Win Friends & Influence People](http://www.amazon.com/exec/obidos/ASIN/0671027034/?tag=iserializable-20) by Dale Carnegie 8. [Becoming a Technical Leader: An Organic Problem-Solving Approach](http://www.amazon.com/exec/obidos/ASIN/0932633021/?tag=iserializable-20) by Gerald M. Weinberg 9. [Secrets of Consulting: A Guide to Giving and Getting Advice Successfully](http://www.amazon.com/exec/obidos/ASIN/0932633013/?tag=iserializable-20) by Gerald M. Weinberg 10. [Are Your Lights On?: How to Figure Out What the Problem Really Is](http://www.amazon.com/exec/obidos/ASIN/0932633161/?tag=iserializable-20) by Donald C. Gause; Gerald M. Weinberg 11. [Agile Estimating and Planning](http://www.amazon.com/exec/obidos/ASIN/0131479415/?tag=iserializable-20) by Mike Cohn 12. [Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))](http://www.amazon.com/exec/obidos/ASIN/0735605351/?tag=iserializable-20) by Steve McConnell 13. [The One Minute Manager](http://www.amazon.com/exec/obidos/ASIN/0688014291/?tag=iserializable-20) by Kenneth H. Blanchard, Spencer Johnson 14. [The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)](http://www.amazon.com/exec/obidos/ASIN/0201835959/?tag=iserializable-20) by Frederick P. Brooks 15. [Perfect Software: And Other Illusions about Testing](http://www.amazon.com/exec/obidos/ASIN/0932633692/?tag=iserializable-20) by Gerald M. Weinberg 16. [Understanding the Professional Programmer](http://www.amazon.com/exec/obidos/ASIN/0932633099/?tag=iserializable-20) by Gerald M. Weinberg 17. [Managing Humans: Biting and Humorous Tales of a Software Engineering Manager](http://www.amazon.com/exec/obidos/ASIN/159059844X/?tag=iserializable-20) by Michael Lopp 18. [Flawless Consulting: A Guide to Getting Your Expertise Used](http://www.amazon.com/exec/obidos/ASIN/0787948039/?tag=iserializable-20) by Peter Block 19. [Agile Coaching](http://www.amazon.com/exec/obidos/ASIN/1934356433/?tag=iserializable-20) by Rachel Davies, Liz Sedley 20. [Instant Manager, The: More Than 100 Quick Tips and Techniques for Great Results](http://www.amazon.com/exec/obidos/ASIN/0814472133/?tag=iserializable-20) by Cy Charney 21. [Code Leader: Using People, Tools, and Processes to Build Successful Software (Programmer to Programmer)](http://www.amazon.com/exec/obidos/ASIN/0470259248/?tag=iserializable-20) by Patrick Cauldwell 22. [Growing Object-Oriented Software, Guided by Tests](http://www.amazon.com/exec/obidos/ASIN/0321503627/?tag=iserializable-20) by Steve Freeman, Nat Pryce 23. [Manage It!: Your Guide to Modern, Pragmatic Project Management](http://www.amazon.com/exec/obidos/ASIN/0978739248/?tag=iserializable-20) by Johanna Rothman 24. [Succeeding with Agile: Software Development Using Scrum](http://www.amazon.com/exec/obidos/ASIN/0321579364/?tag=iserializable-20) by Mike Cohn 25. [Building Trust: In Business, Politics, Relationships, and Life](http://www.amazon.com/exec/obidos/ASIN/0195161114/?tag=iserializable-20) by Robert C. Solomon, Fernando Flores 26. [Integrity: The Courage to Meet the Demands of Reality](http://www.amazon.com/exec/obidos/ASIN/006084969X/?tag=iserializable-20) by Henry Cloud 27. [Corrective Action for the Software Industry](http://www.amazon.com/exec/obidos/ASIN/0971323194/?tag=iserializable-20) by Denise E. Robitaille, Johanna Rothman Links go to Amazon. --- title: "Courses" url: "https://www.5whys.com/courses.md" canonical: "https://www.5whys.com/courses" tags: [] author: "Roy Osherove" description: "Leadership and engineering courses by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Courses # Courses and training Roy runs leadership and engineering workshops for teams. Please [see the full course offerings here](http://osherove.com/trainingoptions). --- title: "Contact" url: "https://www.5whys.com/contact.md" canonical: "https://www.5whys.com/contact" tags: [] author: "Roy Osherove" description: "Send Roy Osherove a message about team leadership, talks or workshops." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Contact # Contact Roy Questions about leading your team, a talk, or a workshop? Send a note. Roy reads every message. Messages go through a short contact form (Google Forms). [Open the contact form (opens in a new tab)](https://forms.gle/jQSx5KoXvrVA1JCK7) Looking for training? See [courses](https://www.5whys.com/courses). On social media: [LinkedIn](https://www.linkedin.com/in/osherove), [YouTube](https://www.youtube.com/channel/UCM9Jz0z1IXlgGy_CY3wGRWA), [Twitter / X](https://x.com/royosherove).