Listen Now

Derek, Clayton and Chris slowly remember what they were talking about… Oh ya! Culture Fit! Including mono-cultures, hiring, diversity of ideas and behaviors enforcing culture. The post Episode #148 – What’s a Culture Fit? appeared first on Integrum.

Derek, Clayton and Chris discuss the idea of how difficult it is to work in an agile environment, embrace agile methodologies and do the right thing. The post Episode #147 – Agile: It’s Supposed to Hurt! appeared first on Integrum.

Derek, Clayton and Chris answer a listener question about technical side projects and how they fit into the bigger picture. The post Episode #146 – Listener Question: Technical Projects appeared first on Integrum.

Derek, Clayton and Mark do a Lean Coffee episode and discuss: Retrospectives, Visualizing flows across teams, Backlogs and more. The post Episode #145 – Lean Coffee with Mark Ng appeared first on Integrum.

Derek and Clayton talk about presence. How do you indicate presence? What does presence look like for distributed teams? What happens when there is little or no presence? The post Episode #144 – Presence appeared first on Integrum.

Clayton and Derek discuss feedback loops. The post Episode #143 – Feedback Loops appeared first on Integrum.

Derek Neighbors, Jade Meskill, and Clayton Lengel-Zigich discuss: the state of Agile today. The post Episode #141 – WTF is Wrong With Agile? appeared first on Integrum.

Derek Neighbors, Jade Meskill, and Roy van de Water discuss: Our ideal team. Transcript Jade Meskill:  Hello, welcome to the “Agile Weekly Podcast,” I’m Jade Meskill. Roy van de Water:  I’m Roy van de Water. Derek Neighbors:  I’m Derek Neighbors. Jade:  We were talking about some of the common problems that we’ve run into on different teams. I was wondering, what is the ideal team, that you would want to work with? Roy:  I think for me, the ideal team that I would want to work with, is a bunch of people that I trust implicitly. They should be people I trust with my life, let alone a software project. I think that’d be huge. Derek:  If there’s all sorts of traits, I definitely think I want to be with people that can be vulnerable with me, and that I can be vulnerable with them on a deeper level than just the work. I want to work with people that are highly passionate about the work they’re doing. I want to work with people that are interested in learning new things. I want to work with people that want to have fun. I want to work with people who want to get results, and they’re able to balance all of those things. They’re able to balance, there’s a time to learn, there’s a time to have fun. Ultimately, that has to be balanced with what that deliverable is, whatever that is, and is willing to have conflict to balance those things. I look at it as if you look at Aristotle or Socrates, or any of them, and you need to talk about virtue. There’s, you go too far to the right, it’s bad. If you go too far to the left, it’s bad. There’s this constant tension of trying to keep that needle or keep the guitar in tune, so to speak, as we have a guitar on the table here. I want to be on a team that understands those types of things and is having the conversation about, “How do we keep in tune?” Opposed to being stupid and focused on one thing and not understanding the ramifications of other things. I guess depth, a team that has philosophical depth about the work that they’re doing. Jade:  Those are really awesome things. How do you get to a team that functions like that? You can’t just assemble it out of box and magically you’ve got that. [laughs] Roy:  You hire a project manager, and he says that everybody is required to be all of those things that Derek just listed and that they all have to trust each other. Jade:  Post them up on the wall. Roy:  A good way to make people trust each other is trust falls in all courses, all that stuff. Derek:  I don’t know. I [inaudible 02:47] . I don’t know if I’ve seen it. I think that that’s hard because part of the only way to get some of the trust…Some other way to get that depth is to have that vulnerability. That path to getting that vulnerability requires exploring all of the edges and doing all of the things which a lot of times ends up in no results or results without any meaning or without a whole lot of fun. You know, “Hey, great. We got all the results we wanted, but nobody wants to do the work anymore. Because we had to slave and drive, and it was miserable to get there, but we had some success.” Or, “Hey we had a total blast, but it sucked because it couldn’t last because we didn’t get there.” I think it’s hard to get that flavor and that character with the same group of people. You almost have to have some runway. It’s not like, “Hey, boom, this is going to happen.” “Do these 10 steps and by Monday…” You’re going to be a team that is rocking and rolling. Roy:  Let’s say I have a team of a certain number of individuals and they either know each other or don’t, or whatever. They’re not this team yet. I have the time to give them runway to form. How do I get them to actually become that ideal team and not become a collection of individuals that are only caring what their self‑interests are? How do I make sure that the team is progressing towards that ideal vision you described? Jade:  You can’t make them do anything. You can only… Roy:  Influence. [crosstalk] Jade:  You can only act the way that you would want them to act. It seems silly and basic, but that’s really all that you have control over. If you exhibit integrity… Roy:  That means you have to be a member of the team in order to model that behavior, right? Jade:  I think so. I don’t know how you can…I think you can lead by example, but it’s difficult if you’re removed from the team itself. You can do it if you have some interaction with them, but you can’t do it from afar. Derek:  I don’t think you can do it from a total afar. I don’t know if you can do it if you are on the team per say. Maybe. Roy:  From what I heard Jade say, he was saying in order to get the best results, you should be…It’s easiest if you’re on the team and I think I’m hearing you say it’s easy if you’re not on the team? Derek:  I think some of it might depend on how you define “on the team” for me. The way that I look at that, the more I…I like metaphors. I think they’re a good way to explore ideas. If I look at successful teams, whether it be sports or successful results, the two things that come to mind immediately for me recently are…If you look it like Chris Powell’s “Extreme weight loss” which you guys may or may not be familiar with. This guy who takes people that are 300 pounds and get some to 150 pounds in 365 days. It’s like hardcore stuff. He can’t lose the weight for them, but what he can do is he can say, “Are you committed to losing weight? If you’re committed to losing weight, I can help teach you ways to lose that weight to get healthy and I can help hold you accountable for it.” I think that’s part of it. If you have that mix of people, do all of those people agree on those things? Do they all agree that what’s a good team looks like? If they do, are they willing to let somebody, including each other, lift them up to that accountability and coach them towards the practices that will get them there? Roy:  In that metaphor, I’m just picturing it in my head and it seems to me, if this Chris weight loss guy was also large and said like, “Hey, we’re going to do this together and we’re both going to lose 200 pounds”, I feel like his job would be easier. He’d have more credibility. Derek:  Yes and no. The downside, he would have the… Jade:  You’re going to get more empathy. Derek:  He would have the empathy side, but part of what he would lose is the, “Who are you to tell me that running 10 miles a day helps me lose weight when your fat ass still weights 300 pounds?” You lose some of the credibility there. I think also you potentially lose some of the accountability. Because it’s like, “If I see you eat a candy bar, then maybe it’s OK for me to eat a candy bar, because I’m a fat, can I do want to eat the…” It becomes easier, and I see that is probably the one of biggest things I see on teams, is, let’s say two people, “I totally want a pair program, I’m totally committed to it,” and the other person, “Yeah‑yeah.” It’s like the first time the other person is like, “I’m going over here and work on this real quick for a second, and then the person is like, “OK.” Then pretty soon it’s like, “You guys haven’t paired in a month.” It’s like, “Oh yeah, but we still really want to.” They were both complicit in it because it was easy to do, where if you had somebody who said, “Hey, you guys said you were pairing today and I haven’t seen you pair all day. What’s going on?” They don’t have to be on the team or be one of the people that is pairing in order to hold that accountability there. Jade:  I think in that case like in your example, that person is part of their team. Even if he’s in a coaching role, he’s still part of…They’ve decided to come together to achieve some outcome. They might not be doing the same work or doing whatever. I’m saying, “I’m willing to accept your influence on me.” Derek:  That’s why I said it depends on what you consider on the team. If we’re going after a shared result together and we’ve both got vested interest in that result, I would say we’re on the same team. Our roles on that team might be different. Maybe the role of Chris Powell is to be that coach and that mentor and that accountability person and that ability to motivate, and do those things, and get to the bottom whatever facilitate doing that. I think they’re still part of that weight loss team together. I would say that when the people got to the end of it, they didn’t go, “I did this all on my own.” I assume my other analogy would be Phil Jackson. Somebody who’s repeatedly won at the highest level with multiple teams, multiple different players. This is somebody that was able to get a collective group of people to believe… Roy:  What sport are we talking about? Derek:  It’s basketball. Jade:  [laughs] Derek:  …In a style or a system or something around that and then hold them accountable to executing against that. Again, I would say, “Hey, he got a championship ring right along with the teams that won championships form. Was he part of the team? Yeah, but he wasn’t a guy on the court necessarily putting the ball in the net. Roy:  The definition of an ideal team change over time, like I heard you describe, and I hav

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss: How to deal with a rapidly expanding team. Transcript Clayton Lengel‑Zigich:  Welcome to another episode of the Agile Weekly Podcast. I am Clayton Lengel‑Zigich. Jade Meskill:  I’m Jade Meskill. Roy van de Water:  I’m Roy van de Water. Derek Neighbors:  I’m Derek Neighbors. Clayton:  Today, we’re going to talk about what are some impacts and how do you handle or how do you deal with taking the team and growing it, doubling in size, or onboarding a bunch of new people. Jade:  All at once? Clayton:  Yeah, exactly. Not over time, but like, “Hey, there might be some people joining the team soon” and then, “Hey, these are the people that are joining the team now,” that kind of thing. We probably talked in the past about what happens to teams when members change. Is anything exaggerated or are there worse problems when you have higher numbers? Roy:  Every time, we’re doubling the size of the team overnight? Clayton:  Yeah, basically. Roy:  Because I feel like that’s where the biggest problems comes. When you have one team that’s about the same size of the first team, now they’re one team. Because now you have two worrying cultures or as if like let’s say the four of us are a team and the fifth person comes in. The four of us can dominate the other person’s culture just through sheer force of numbers. That’s going to make it a lot harder because now all of a sudden there’s a clear majority. Jade:  But even changing one member of the team, you start over as a team like you’ve got to figure things out. Things are different. Roy:  Absolutely, but it might not take us long. It might go a lot faster. Clayton:  What if we got put in a team? Jade:  [laughs] Please, I feel bad for those people. Clayton:  And from people we can talk to about then. Jade:  I think some of the risks are like we’re saying you have two very different cultures colliding and you’ve got to sort through all that. You’re definitely starting over and both teams are starting over from a culture perspective. Roy:  The danger to have is the assumption that one of the teams is getting bigger. When in reality, two teams are stopping to be teams and a new team that is completely its own unique thing is now starting. Derek:  A lot of it too is, I mean if we look at…Trust is a big part of things being successful. That is a huge part of it. If we say that the only way to have trust is to be vulnerable and we know that when you’re with strangers, it’s hard to be vulnerable. Some of that stuff just takes time. It’s like you have to kind of posture up, sniff each other out like two dogs at the dog park. You got to do little butt sniffing. You got to check it out… Jade:  Maybe 14 dogs at the dog park. Derek:  …go around and there’s a fair amount of crazy sauce that happens before you can even settle in to then, “OK, I’m going to let the guard down slowly.” It only takes one offense to then well back up and put those hands back in front of your face, and say, “Oop.” Jade:  And for everybody. Derek:  And it’s for everybody. There’s a song and dance that takes a while to get that trust mojo going. I’d say my only recommendation is whatever you can do to get that trust mojo happening as soon as possible and as quick as possible and reinforce it as much as possible, the better your results are going to be. But that’s hard to do, man. Jade:  What are some tricks to start that off well? Derek:  Valium, I don’t know. [laughter] Roy:  The opposite of valium is don’t shy away from conflicts. Meet that shit head on. Don’t try to put off discussions for…don’t try to put it off forever. Clayton:  The first thing that comes to mind for me is eating together, sharing a meal. That’s a pretty good one. Getting to know people beyond their work role, their persona. When you’re in the bureaucracy, you want to talk about, “Oh, where’d you come from? Who’d you used to work for? Who do you report to”? All that kind of stuff. But when you’re eating dinner and someone mentions something about having kids, “Oh, you have kids? Oh, you’re married? How long have you been married? Who all here is married”? Roy:  That’s when people become human beings. Clayton:  Right, it’s like now I’m talking to you as a person, rather than someone in the [inaudible 04:15] . Jade:  That’s a very important point, Roy, is becoming human beings as fast as possible. Derek:  I’d say human beings like things that are similar to them, so that’s a big part of the “Do you have kids”? Going beyond the weather questions, getting to know somebody ‑‑ the quicker that you can crack that shell and find out what your commonalities are, the easier it is to become vulnerable. Whatever that is. Maybe it’s you ride motorcycles. Maybe it’s that you own a bulldog. Maybe it’s that you like music. Maybe it’s that you are the same denomination of religion. Whatever that common ground is, the faster that you can discover that with everybody on the team, the easier anchor point you have to say, “That person is like me. Therefore they’re human like me. Therefore I can connect with them.” If you can get to that quick, that helps. Jade:  Imagine that you’ve broken through that part of it. We’ve become humans to each other. What’s next? Clayton:  I think some of that goes back to what Roy mentioned of the warring cultures. Everyone’s got their own maybe practices or things that they’re used to or cultural norms, really. Some of those things are pretty easy to merge. They’re not too different. Some of them, it feels like you have to make…feels like people get really…Machiavellian’ words like, “I am going to make a peace offering and let you keep this thing that I think is trivial because, I am expecting you are going to cave on these other things and give them up.” Roy:  Social manipulation? Clayton:  Yeah. I don’t think it’s intentional that way but it seems like it shakes out that way, from a cultural perspective. Roy:  It’s like new team information should not be a contract negotiation. Derek:  It’s interesting, I think of it as similar to a marriage. Roy:  Which is a contract negotiation. [laughter] Derek:  Can be, especially in our present age. You have two people come together but in reality, you tend to have two extended families come together. With that, you have the culture of those families, you have the…not necessarily the practices, but some of the values, some of the traditions, maybe tradition is a better word than practices. I see a ton of people getting married, one of the biggest fights are, “Oh crap! Now we have to figure out Christmas and Thanksgiving.” It’s really easy if my family celebrates on Christmas Eve and yours is on Christmas Day. [hoots] We dodged that bullet, no big deal. We are all happy. But what happens when the tradition for both of us is Christmas Day? One of the things I see in families that do things well, is they figure out how to preserve the traditions that are the most important where people can do the best, to preserve what they need to out of that. The other thing is they create new traditions together, that are separate from either one of their extended families’ traditions. Teams have to do the same thing where they are going to be certain practices and certain things that are just too emotional to let go of, and finding, how do I give you enough of your practices, so you don’t feel like you are losing everything. I have enough of my practices so I don’t feel like I am losing everything, and how do we create some new practices together? Where we can own those together and we are setting those new practices as a team we collectively built. It wasn’t through negotiation, it was truly, how do we make a new practice better than neither one of us has ever seen? Clayton:  What if one of the practices or traditions is completely egregious to the other team? Roy:  File for divorce. Clayton:  My wife’s family, they get together every Easter and sacrifice a goat in a pentagon. Or code example, the other team wants you to quit. [laughter] Clayton:  How do you reconcile those things? Jade:  You sacrifice those people. [laughter] Clayton:  You have to fight about that, right? Derek:  Well, some of those are ones where you might have to do the new tradition. I want Dart, you want Godel, whatever the case would be. Jade:  Good God! We’ll have Christma‑Kwanzaa. Derek:  You want .NET, I want COBOL, so, we are going to have to learn Ruby together because that’s the only… Roy:  If I can’t get my way, then you can’t get your way, then dammit, neither one of us going to get our way. We are going to discover a new way to get… [crosstalk] Derek:  There are things where you don’t want to compromise just for the sake of compromise or everybody walks away pissed off. If I just compromised and say, “Fine, we’ll use .NET.” I am just going to always be bitter and angry, and pissed off that we did that… Roy:  Yeah. You used .NET. [laughter] Clayton:  Well, the option was COBOL. [crosstalk] Derek:  The point being is, sometimes you are going to have to let go, if nothing else to say like, “I am vulnerable to have to do something totally new and you are vulnerable to have to do something totally new, and we are going o have to discover that together, and go through all of that pain

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss: What is more important, principles or practices? Transcript Jade Meskill:  Hello welcome to another episode of Agile weekly podcast. I am Jade Meskill. Roy van de Water:  I am Roy van de Water. Derek Neighbors:  I am Derek Neighbors. Clayton Lengel‑Zigich:  I am Clayton Lengel‑Zigich. Jade:  Guys, I wanted to talk today on what is more important, principles or practices? Roy:  Explain? Derek:  Or use it in a sentence. [laughter] Jade:  What is more important, principles or practices? Dealing with a lot of teams, I’ve seen Agile presented in many different ways. Sometimes it is very process focused and practice focused, sometimes it’s about the principles without a lot of either prescriptive ideas of how process or practices would work like how do you get the best results from a team? What’s more important focusing on the principles or focusing on the practices? Derek:  This is a faith versus works question ‑‑ and loaded. Jade:  It sure is. Clayton:  I view myself as a principles kind of guy. In this context, the practices are something that you could do probably quick, but for them to have long‑lasting impact or to make more sense so people understand why they might be doing these practices, you do need the principles. To answer your question, you need both of them. Jade:  It depends. Is that right? [laughs] Roy:  Yes. It depends on the level of team you’re applying them to. It is extremely important to have principles from the very beginning. If you rely only on principles, it’s very difficult for novices to be able to do much with raw principles. If I say, “Lying is bad. Don’t lie.” But you have no experience with what lying even is. Is a white lie OK? ‑‑ all of these nuanced things. You might be able to say, ”I know lying’s bad, but I got put in this situation. I don’t know what to do with it.” I do the wrong thing even though I have the principle, because I don’t understand how the principle works. I tend to find that principles are very short, concrete things that have a lot of nuance. The only way to develop the skill of what is in that nuance is to have a whole lot of practice. With novices, it’s very important to put the guide rails on. To say like do this thing, almost cargo cult it to a certain degree like do this thing, but reinforce the principle behind why you’re doing that thing. Once you understand the classic Miyagi’s son like wax the car, wax on, wax off. I don’t know why I’m waxing on. I don’t know why I wax off. I don’t know why I’m painting the fence. It seems kind of frustrating. You tell me that I’m going to be this really great karate fighter someday but I don’t get it because it doesn’t make a whole lot of sense. Then at that one moment that you know that I have enough practice under my boat, you can show me how it relates to the principle in a meaningful way and it kind of clicks. From that point forward, I can let the practice be more dynamic to the situation. I think a lot of it depends of what level you’re at. It’s very difficult to teach principles without introducing some form of practice. It’s very dangerous to only focus on practice and not have people understand the principles behind the practices. Jade:  It sounds to me like you’re describing a balance or attention between those two. How do you know when is the right…what’s the right balance for the right team? How do you gauge that? Derek:  Let me give you the answer that will work for everybody. I don’t have it. [laughter] Derek:  That’s going to be something that is worn out of experience, but that’s the troubles. You don’t have the experience to make that call yet. Jade:  If you’re a coach or you’re a score master, you’re performing some role with that team and expected to guide them in some way. How do you figure out where to push and where to pull? Derek:  One of the metrics that we’ve used is kind of what we have mentioned in the past. We’ve always said like a team should always insist on pairing on production code. We’d be prescriptive to say that all code is paired. As soon as you stop getting pushed back from the team when they are insisting that all coach to be prepared and they want to do it that way. It’s like when they’re ready to start breaking the rules. It’s when they don’t want to break the rules anymore is an indicator that they may be mature enough to start thinking about the rules. Clayton:  In that example…I had this exact scenario where there was some problem with the team where some people maybe new something about the system or someone broke something about the system and never understood. The principle there might be collective code ownership. You can’t just say that and say “OK, you now collectively own the code.” Jade:  We all own the code, what are you talking about? Clayton:  Yes, exactly. It’s just that doesn’t make sense. I think pretty easy go to like a great way to get that, to apply that principle is pair‑programming. That’s a practice. The way that I’ve seen pairing and to be introduced without the principles behind it, if the people in the team aren’t very open to try new things or maybe change in the way they work or not used to that sort of thing then they want to throw it away. I feel once they throw their practices away even if you come back with the principle and say, “No, you don’t understand. See this is why we’re doing this.” It’s kind of like, “Yeah I don’t want to do that anymore.” Roy:  Right. That worked for Danielson in the movies but that doesn’t work so well in real life. Derek:  Like a good example, I saw even though this is weak in some interactions, pairing is good in all but we don’t feel a need to pair on the easy stuff. It’s like that’s an easy trap to fall into. It’s not that hard so why are you pairing? We were pairing because when we’re doing hard stuff we want more than one person because two minds are better than one. I don’t anywhere see kind of the two minds are better than one. Maybe in doing things in teams but sort of that I am not seeing the technical practice as of two people is better as one is like an over‑arching principle per say. I think doing working teams is kind of is. Maybe there’s a false in that a bit but my question would be is it about everybody owning the code. In which case shouldn’t everybody own the simple code too? If we start to look at what does automation look like? If it’s so simple that anybody can do it could you automate it? I think it starts when you have a little bit more depth into the principle of like why do we pair? We pair because we want to work in teams and we pair because we want collective code ownership, we pair because and you list off five or six principals. Then when somebody says, “Hey I don’t want to pair on the hard stuff.” It’s like, “OK.” Well maybe that solves the “We do difficult work in small teams.” Maybe that applies but then how do we still have collective code ownership if we’re doing that. I think its understanding that there is depth to principles. It’s not one practice aligned to a single principle more often than not it’s a practice might aligned to three or four different principles. When people try to tweak them, it’s like, “Well I’m tweaking at this because I don’t really…” Tweaking it this way doesn’t invalidate that principle but it might invalidate some other principle. I think that’s why it’s important to know those. I think that when people know them that’s why they don’t want to throw their practices away because they know they are getting more than just the surface bang for the buck. Jade:  How do you get teams to understand that? We’ve seen a lot. We’ve seen a lot of people reject a lot of practices that we know are good for them but they don’t understand it yet. Derek:  I think sometimes you have to…I don’t want to say enforce them to do the practice, but I think you have to strongly encourage them to do the practice for some length of time so that they can start to see the benefits and start to see the depth of it. When they throw them away they come back to them because they realize what their losing. If I’m pairing all the time and I get all the benefits of pairing all the time. I decide to lax out and not pair on the hard stuff or not pair. I start to get bit by bit those other things and somebody from an outside view point can say, “Man it doesn’t look like this is working out so well for you.” Then somebody’s like, “Oh well, that’s because so and so did that in the corner and blah blab and I didn’t like the way they implement it.” It’s like, “How come you didn’t know the way they implemented it?” “We don’t pair on the hard stuff.” “Oh.” “In the easy stuff.” “Oh.” Tell me more about that right? It gets to be able to re‑frame that but if you say, “I don’t like paring so I’m not going to pair.” You never are going to understand the values of the principles for that practice. Clayton:  There’s a lot to be said for having the ability and I think a lot of it comes from experience to be able to identify some particular patters or problems that the team might be having and say, “OK, well he’s pairing again.” I

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss: What happens when someone has central control Transcript Derek Neighbors:  Hello, and welcome to another episode of Agile Weekly Podcast. I’m Derek Neighbors. Roy van de Water:  I’m Roy van de Water. Jade Meskill:  I’m Jade Meskill Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich Derek:  We’ve got another fantastic, hypothetical situation. [laughter] Derek:  You may spot this in the wild, I don’t know. We’re talking about things that could potentially maybe happen, someday, to some teams. Say you had a czar of a department, or a unit, or a job function. Roy:  Like a real Russian Tsar? Derek:  Yeah, like an architect… [laughter] Jade:  I’m a Marxist, sorry. Derek:  In the hypothetical situation, we would probably see this as being an architect, or maybe be a designer of some kind. When I say designer, I mean the chief of the companies, the [inaudible 00:55] top guy. Jade:  Or the head programmer? Derek:  The head jock honcho. Jade:  On the team, the technical lead or something? Derek:  Not even that. Above the technical lead, the top of the food chain. They have this stance that says, “The only thing that can done can only go to production if I have approved it.” Roy:  You’re saying everything has to go through this guy? Derek:  Everything has to go through this gal. She is totally 100 percent, “The design, every pixel has to be done by me,” or “Every single method has to be approved by me if we’re writing code.” This person works in a large organization, thousands of people per se, and lo and behold, they can’t go to every planning meeting. The good news is they have some mini‑czars that they can send out to these planning meetings. They can go to these planning meetings, and help the developers and the designers do things. Then what happens is all sorts of decisions happen in a planning meeting. When these mini‑czars come back to the big honcho, the big honcho says, “Nope, I don’t like it. It needs to be this way.” Now they go back to the team and have to tell the team, “Sorry.'” [crosstalk] Derek:  …What does that look like? What happens? How do you fix that? How do you rectify that situation? What are the downsides to that stuff? Roy:  First off, is there anything wrong with that? Clayton:  Yeah, I’ll take the devil’s advocate approach. The reason that all the design has to go through that one person is because if you want to maintain a consistent brand experience for the end‑user, you can’t just let people ‑‑ especially developers who don’t have any design sense ‑‑ to go off and do a bunch of crazy stuff. Roy:  There’s a bunch of awesome examples where I’ve seen exactly that with Google. In fact, I’ve heard, Derek, you complained about this specifically that Google has all of these products out there of totally different experiences, that are totally not integrating because they’re all being developed in isolation. Derek:  Ever since their designs are [inaudible 02:56] left… [laughter] Derek:  They have not been on‑brand. Jade:  I’ve seen these on the development side, too, where you’ve got all these dumb programmers that we hired that are up there writing a bunch of crap. If they could just do it like me, everything would be so much better. Derek:  Yeah, where do you think our tech‑level of that comes from? Jade:  Yeah. [laughs] Clayton:  I suppose we pay these people six figure to be morons. Derek:  The dumbest, highest paid people, we have. [laughter] Roy:  I get that. The guy at the top, his neck is on the line if should go south, he wants to make sure that everything goes north. Right? Derek:  Yeah, it’s pretty scalable, they are able to ship a lot of production software this way. Clayton:  That’s a trade‑off. If you go through this bottleneck where one person has to approve everything, obviously everything goes very slowly, and you don’t ship very often. Jade:  And you redo a lot. Clayton:  Yeah, you probably use a lot of rework, as obviously the market’s going to change, and you’re going to have to go back and fix things and change your strategy. But theoretically, everything looks pretty good, and it’s pretty close to being “perfect” when it does ship. Roy:  I guess that depends on their value system then. Do you value the ability to move fast, to make changes and respond to changing requirements in the changing world? Or do you prefer to have a perfect experience? Because I could see value in both of those. Derek:  Yeah, if a lot of people really applaud Apple and Steve Jobs and what he did ‑‑ he certainly was not interested in shipping on a very tight schedule and going very fast. He was much more concerned about shipping perfect products than he was shipping bad products more frequently. Roy:  Right. Another example is like Rolls‑Royce or something, where, I don’t care if it has the latest and greatest features, but…Hold on, let’s be clear here. I’m not buying a Rolls‑Royce. [laughter] Roy:  I could see people don’t really care about [inaudible 04:46] features, they care about every product being extremely high quality. I don’t know if they actually have this, but I could see them having a philosophy like the CEO hand‑checks every single car before it leaves the factory, because they insist on having that premium experience, and that everything is perfect. Jade:  Apple’s an interesting case, because they’ve shipped a lot of great hardware. They shipped a lot of really poor software that is not consistent and not very good. Derek:  You’ve obviously used their online store before. Jade:  [laughs] Yeah. Clayton:  I’ve always had a tough time with the Apple comparison. I think that’s the first one that people jump to, but no one ever really acknowledges the difference in hardware. Jade:  It’s much harder to fix hardware once it’s gone up the book. Clayton:  Yeah, so that’s different. That’s something that we should clarify. Derek:  When I look at this hypothetical situation, the thing that I think is the biggest pain for me or the biggest thing that I see that people aren’t talking about, is what does it feel like being a team member who goes through a planning meeting with a group of people and comes up with a solution and an idea only to, an hour later or a day later or two days later, say, “Uhh, what you’re doing is really stupid and really dumb. This is the right way to do it. Throw away everything you’ve done and go do this other thing instead.” What does that feel like as a team member, do you think? Roy:  I can see two parts to that. First off, we talked a lot about autonomous teams. I would feel like, as a team member, a large part of your autonomy gets taken away if someone comes back and says, “You have to do it my way.” If it’s taken from the standpoint of, “Hey, have you considered using other options”? And they are truly better ideas. If you follow the core commitments and you choose to always seek to better an idea and to accept any idea no matter where it comes from, then that sounds like it would only be a positive experience. I think that how that interaction takes place, and the attitude of both parties, has a huge impact on how that’s going to go down. Clayton:  I would feel pretty useless and like my time was being wasted. I would probably not even bother attending. Or if I did attend, it would just be for show. I would probably not even be paying attention because, really, what difference does it make? Roy:  But there is a difference. Clayton, if I came to you. Let’s say you plan on a Monday and I come to you on a Wednesday. I say, “Hey, I saw what you guys planned out on Monday. Have you considered using other possibilities”? Would you have that same reaction? Clayton:  If you said, “Had you considered these other possibilities”? We had some dialog, and I said, “OK, let’s talk about it next Monday.” I think that would be one thing. If you said, “Put the brakes on. Really think hard about these other choices, because you’re doing them no matter what.” Then I would feel like, “What’s the point. Why did I waste that time”? Jade:  I can tell you what it’s like to be on the other side of that. I’ve been that person. It sucks. You can’t trust anybody. You are paranoid and you need to be… Roy:  Just to be clear, what side are you talking about? Jade:  The person who’s the bottleneck. Who… Roy:  Oh, I see. Jade:  …is changing things for everybody. Roy:  And insisting that your rules be followed? Jade:  Yeah. It’s a very crappy position to be in. You don’t sleep well. You’re not relaxed. You’re always stressed out because everything is going wrong around you all the time. You don’t trust anybody. I think that’s really where…that’s the core of the issue. You don’t trust anybody. Derek:  In this particular hypothetical, there’s also a middle person. We’ve not talked about that middle person. Not only is the person that is doing the work probably leaving frustrated… Roy:  So you’re talking about the Vice Czar in this, right? Derek:  The Vice Czar goes into this thing thinking, “Oh, I totally represent the attitudes and the patterns and the thinking of my boss.” We go in and I walk out thinking, “Man, this is all going to be really good.” Then I go back and they say, “Why did you

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss: Simplicity Transcript [laughter] Clayton Lengel‑Zigich:  It is hard doing that every week. [laughter] Derek Neighbors:  You don’t do it quite as good as Jade does. Jade Meskill:  All right, go Roy. Roy van de Water:  Hello and welcome to another episode of the Agile Weekly Monthly Podcast. I’m Roy van de Water. Jade:  I’m Jade Meskill. Clayton:  I’m Clayton Lengel‑Zigich. Derek:  I’m Derek Neighbors and joining us today is the improv group. Roy:  In the room next door. [laughter] Jade:  Yelling very loudly. Roy:  Today we are talking about thinking simply, instead of thinking complexly. Jade, you and I have been… Jade:  Accused of being simple? Roy:  Accused of being simple. [laughter] Roy:  Can you tell me a little about what that idea means? Jade:  Sure. We’ve been trying to… [shouting in background] Jade:  These guys are really… [laughs] yelling in there. [laughter] Roy:  I’d like to denote that they were entirely quite for the last 45 minutes before we walked into this studio. Derek:  It’s like they’re Chicago trading for [indecipherable 1:10] . [laughter] Jade:  Buy! Buy! Sell! Sell! [laughs] Derek:  You do the savings, I’ll do it. [laughter] Jade:  We’ve been working on some concepts of trying to write very, very small, simple applications, taking the UNIX philosophy and applying it to web applications to avoid the over‑complication that tends to arise in larger systems. Roy:  What does an over‑complication look like? Jade:  Usually a system where the responsibility is not very well delineated between either modules or different parts of the application. It tends to be very messy and sloppy, where it’s hard to tell where something…There’s no discrete functionality, I guess is the best way to say it. Derek:  The way that I think about it is, if you had a web application where the code that displays the page where you enter in the details about a job is in the same place as the code that makes the…Say the job in a database in the same place in the code that schedules the job, in the same place in the code that runs the schedule of job, in the same place in the code that…They’re all in the same place. Roy:  It sounds like everything is in the same place, it sounds pretty simple to me. [laughter] Derek:  Right, until you get everything in the same place, and then something goes wrong, or you want to change something. We have this problem with the Agile Weekly podcast or Agile Weekly website, where we had a bunch of things that were all clinched together. If I took the approach of a normal, say, Rails application, like the standard Rails way of doing things. When certain pieces of the system got a little too big, or too unwieldy, it was hard to…it seemed like it was simple because it was all in the same place, but the real simplicity came when we broke those out into little pieces. Then you have these…you’re going back to [indecipherable 3:08] sampler, mentioning the UNIX philosophy, with these little teeny pieces that all did their one little thing really well. They all just worked together. Roy:  So why wasn’t it obvious to be that way in the first place? Jade:  Because in the beginning that would have actually been more complex. Roy:  So how do you know when you are doing something complexly instead of simply? Jade:  I think when it becomes hard to explain, it’s probably too complicated. Roy:  Is that like the metaphor ideal, like you should be able to describe whatever you’re building as a metaphor, and as soon as your metaphor circuit is breaking down that means that you’re putting too much in there? Is that… Jade:  I think that’s a good way of putting it. If it’s not something that you can explain in a simple, conceptual way, it’s probably gotten a little bit out of control. Roy:  Is this idea of complexity versus simplicity something that is on the overall project, or is it something that you see replicating down to the individual components of a method, or a class, or something like that? Jade:  It’s an important recursive idea that happens. If you are being simple with the very small parts of your system, it’s easier to be simple at the larger scale as well. Derek:  I think developers in general…they find it easier to think in these terms when they’re maybe down in the class with the [indecipherable 4:31] methods. I think that’s where they live, and all that stuff. Then you go up a few levels and even talking about what features you’re delivering. I think a lot of developers might understand that concept at that level, but then it gets in the features and it’s like, “Well, the product guy said just build this stuff, and like well, OK, whatever, I don’t care.” Where I think that’s the even more important part, that’s an equally important part to be having this discussion about simple… The planning meetings that we’ve been involved in lately for sure. I think we’re constantly driving towards trying to find something that’s simple, but not too simple, or not too simplistic. That’s a really hard thing to do. Jade:  Yeah, I think being simple is hard. Roy:  So this is the type of thing that I might solve using design patterns, like, “Can I just throw those at this problem?” [laughter] Jade:  We have an observer. Let’s find out… [crosstalk] Clayton:  I think the interesting thing to me, it’s always easier to add complexity that it is to remove complexity. When you start to get that Zen peace, it’s way easier to say, “Let’s start super simple and we can add what we need to add,” which is a very hard discipline to build. Even if you’re talking product. That struck it for me. Can’t say how many times you’re talking about a feature and you’re up there at a whiteboard drawing it out, and somebody’s like, “Well that’s just too simple.” At the end of the day, if you give this to the developers, it might turn into a two‑week feature request even though it sounds so simple right now, on the surface. As human beings we like to overcomplicate everything all the time. Roy:  What drives that, though? Why do we want to overcomplicate things? Clayton:  Some of it is uncertainty, or, we have this need for completeness. If we only say we’re going to show X, it’s like, “Yeah, but Y and Z and A and B are all available to us, too. We have to show them.” “Why? What if we just showed X? What if X is enough? That is all that feature needs, why do we need the…” “Because those other things exist, so we have to show them.” There’s very much this, because we can, we should, mentality. Derek:  Another thing we see in our work is that people have an aversion or misunderstanding of iterative development. It’s like, if we don’t do this now, we’re… Jade:  You mean incremental development? Derek:  Yeah. If we don’t do this now, we’re never going to do it. If you guys don’t plan every single thing that we think we know, then we’re totally screwed. You guys are going to forget it. To be fair, I bet you there’s a lot of product people out there who have teams that maybe aren’t the most reliable and don’t deliver what they say they’re going to deliver, and all those things. When someone were to come in and say, “Hey, we’re going to do some really simple thing and ship it real soon,” it’s like, “Yeah…I don’t believe you.” Like, I’m not going to take that risk. Clayton:  To me, it sounds like there’s a little bit of the 85‑15 rule, where you can deliver 85 percent of the value with 15 percent of the effort. Then you spend the other 85 percent of your time delivering the last 15 percent of the value. I have worked with different product people, designers and architects in the past, where they want to get all 100 percent, because they know that if you spend 15 percent of the effort now to deliver 85 percent of the value, you’re never going to spend the other 85 percent to deliver the last 15 percent. Which may be a really awesome business decision, but you’ll never be 100 percent as good as it could be. Roy:  Some of it is, building off Clayton’s response there, is, there are a lot of teams where if you say, “OK, fine, let’s just do X.” You say, “OK, let’s do Y.” “OK, let’s do Z.” Then you say, “OK, let’s do A.” Then they’re like, “We’re going to have to re‑evaluate the whole thing. If you would have told us up front that we had to do A, we would have totally built this in a different way. Now that you want A, we just have to throw away the last six months’ worth of work, and start all over, and if only you would’ve told us.” Once they get trained for that it becomes, if I know anything I must disclose it now and tell you that you have to build it into the app, because if I disclose it later you may come back and tell me, “Oh man, we have to throw everything out and start again.” Clayton:  By disclosing everything up front and insisting that it all gets done, the product owner is really trying to maximize his choice later on down the road. His ability to choose later on. Roy:  They’re trying to mitigate their risk, I believe. If they disclose all that and say we need to do all of that, then they think they’re mitigating the risk of somebody coming back later and saying, “Oh, we

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Jake Plains discuss: Ticket Driven Agile Cross team collaboration Transcript Jade Meskill:  Hello. Welcome to another episode of the Agile weekly podcast. I’m Jade Meskill. Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich. Derek Neighbors:  I’m Derek Neighbors. Jake Plains:  I’m Jake Plains. Jade:  Clayton, I wanted to let you know that I submitted a ticket to your backlog to record of this podcast, but I never heard back. Clayton:  If you would have attended the prioritization meeting on the third Tuesday of the month, which may or may not have passed. I’m not sure what week of the month it is. You would have known that it has been assigned to a BA and they are currently tasking it for release in the next sprint, which may or may not get released to production in whatever two weeks the sprint length is. I’m not even sure, I’m just a BA. [laughs] Yeah, it’s getting done. Jade:  Awesome. [laughs] So what we want to talk about is, ticket‑driven Agile. We’ve been running into this a lot in some of the larger organizations that we’ve been working with. Where… Clayton:  If you have [inaudible 01:15] you may be suffering from… Jade:  Yes [crosstalk] Derek:  Our version one. Jade:  What’s the problem with this ticket‑driven Agile that we’re seeing? Clayton:  The big part is that, let’s talk to someone and come up with some solution for solving some problem that I have. Or we need something, let’s talk about it. There’s no interaction. There’s no conversation, its processes and tools. Derek:  So when we went back to this little thing called agile manifestos that had…Maybe two, three, maybe four top things we could look at and if the first one was individual interaction over process and tools. There’s a whole lot of interaction that doesn’t happen between actual people when… Jade:  I saw the log on that ticket. There was tons of interaction. There is like logging and services interacting. It was really cool. Derek:  One thing I found is, it’s very easy when communication happens be a tool to not seeing human being on another side of the tool, both ways. The persons submitting the ticket doesn’t see the human being on the other side who might have a bunch of other stuff that is actually higher priority, is under stress, or maybe on vacation, whatever they don’t see that. At the same time, the person on the other end isn’t able to feel the pain or have empathy for whatever the ticket is being supported to them. It escalates the frustration on both sides to the point where when our first interaction actually occurs outside of the tool is a, “Fuck you! Why aren’t you doing what I want.” and “Screw you! Why are you demanding stuff of me”? Tension is now, in an all time high, before anything’s ever even happened. There’s all sorts of assumptions that are made, all sorts of guesses and there’s no human empathy. I think that it just escalates more and more to the point where that becomes a default culture where it’s just like, “Don’t talk to my team.” Like “Just submit a ticket.” It also becomes, “Don’t bother talking to their team because they’re just going to tell you to submit a ticket.” It just completely dehumanizes work in a lot of ways. I think that’s a dangerous place to be. Clayton:  Yeah. I think to the honey do list. I think I’ve got this list of stuff that I haven’t done. It’s been in the list forever. It used to be where it’s like, “Hey, you need to do this.” It’s like, “Yeah, add it to the list.” or “I’d submit a ticket. Give me a ticket, my honey do list queue.” But now, when it’s more of a like, “Hey, will you help me solve this problem”? It’s like, “Yeah. OK or we can always talk about it.” “Well, I don’t want to do that because x, y, z or I can’t do that right now.” But when I just submit a ticket, it just goes to the list and it never gets looked at. That’s why we made a joke about the prioritization meeting. The stuff just goes in the list and then if you’re around you might get prioritized, like you were saying, Derek, just the level where you might get the work on this week. But the second that you don’t show up to the third Tuesday of the month prioritization rally, then you get bunked down the list and you’re forgotten about. Jade:  You forget to bring your lobbyist. Derek:  A lot of it too is ‑‑ I might go back to the game that I see people do a lot. They’ll do it a lot with kids where it is, “I want you to write down the instructions on a piece of paper, ‘How to make a paper airplane.’ Then, I want you to hand those instructions to your classmate and I want them to build the plane without asking any questions from you, only following your instructions.” This always fails spectacularly. We think it’s going to be totally different because we entered it the digital rules into the digital tool and handed them across. A lot of times a ticket comes across, or a work request, or whatever and it’s like, “This person is an idiot. They don’t even know it.” I’m reading some instructions that I’m probably completely misinterpreting and don’t have nearly any of the facts on and I’m making all decisions and judgments based on that. I think that is dangerous too. Jade:  So how do companies get there? Jake:  How do they get to that? Jade:  How do they end up in this position? Derek:  I think some of this is fire fighting culture. What happens is everybody just comes and attacks me with stuff. It’s really hard because the last person that screamed at me, I do their stuff than the person that came to me first gets pissed off because their stuff didn’t get done. Now, I’m in this dilemma and I don’t know how to solve this dilemma. Everybody’s mad at me all the time. Then along comes a magic tool. I can learn to say no. The way I can say no is, “No, I can’t do that, I’m busy. Go put it in the tool and we have an ability to do this.” We talk about this and scrum all the time. The sprint is sacred, it’s a commitment. Don’t interrupt the commitment. I think people are well intention when they start down this road and they say, “This is a way to shoot the team from people that come in and bugging them to do stuff and actually let them take a whole sprint to get something done before.” But it quickly turns into, “I don’t want to have a conversation with you, just go put the stuff in the bucket. Now, I’m teaching you to put the stuff in the bucket. Then the fire fighting culture still re‑emerges because we know that when we put something in the bucket, it’s going to take four sprints to get it done but this is really important. What we do is we learn these insidious little ways to go to your manager, go to another team or do something to basically force you to deal with the issue that’s in your bucket that is longer that I’m willing to do with which totally submarines the whole reason why you were telling people to go put things in the bucket. Now, you’re pissed and you’re right back your fire fighting culture yet you still pissed everybody off because you’re forcing them to go put stuff in the bucket. Clayton:  One of the other things that contributes to this is siloed work or siloed styles of doing things. Rather than saying, “Oh, can you do that”? Like “I know you want me to do it, I don’t have the [inaudible 07:11] with you. I can’t do it right now.” “Is there someone else that can do it”? “It’s putted in the queue because I want to be the only one that can still do it.” Or maybe I don’t even think on those terms but I know I am the only one. There’s no possible way anyone else can do it. It has to be me. Derek:  I would say that the way that I see this really creep up is in organization don’t know how to thin slice their work meaning that their taking really big increments of work that take almost entire sprint. Means that they have no ability to deal with anything else coming in. Then teams that are not cross‑functional in a highly siloed where only one team in the whole organization can do a certain type of work. When I have problem with my product but I’m dependent on your DBA for it, I’m blocked. I’m really stressed out and I want to get you to do the work for me. I’m not allowed to do it. Now, you create queuing for whatever team has the lowest throughput and the most request are the longest cycle time is the team that starts to get backed up and starts to have the behavior of, “We’ll go create a ticket for it.” “I can’t deal with this. My throughput’s not in. I’m so slow at what I’m doing.” Instead of saying, “Hey, can I teach you how to do it so that next time you don’t have to wait for me.” That doesn’t exist in this organizations or the team that doesn’t want to let go of that magic keys and teach somebody else. Jake:  I think the convenient thing is that when you have the non‑agile or commenting control style especially with the developers. The developers get the work from their project manager and tells them what to do, I think the stuff just fits in so nicely. A ticket can come in and then you have this nice little package this task item that you can just give to people. There’s no co

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Jake Plains discuss: How to get more cross functional How to overcome the challenges of working with very different skill sets Asking not listening The post Episode #134 – Cross Functional? appeared first on Integrum.

Roy van de Water, Jade Meskill, and Clayton Lengel-Zigich discuss: What is the right pace for change in an organization Transcript Jade Meskill:  Hello, welcome to another episode of “Agile Weekly Podcast.” I’m Jade Meskill. Roy van de Water:  I’m Roy van de Water. Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich. Jade:  Today we wanted to talk about, when you’re making change inside of an organization, whether it’s at the team level or the management level, the organization structure, change takes some time. Regardless of how fast or slow, it takes some time to happen. How long is a reasonable amount of time to wait for change to happen? Clayton:  What if we start with this scenario? What if we changed as fast as possible so that no one is uncomfortable? Jade:  That’s going to be pretty slow. Roy:  Yeah, I’m not cool with that. Jade:  I feel like I’m OK with a lot of change, but it certainly makes me uncomfortable, a lot. If I waited for myself to be comfortable, I know that I would never change. Clayton:  What is it about being uncomfortable? If you’re saying that change makes you uncomfortable, you maybe get uncomfortable when there’s some change. What is it about that make you OK with being uncomfortable in that context? Jade:  I’d say for me is knowing, based on my previous experiences, that there is probably something better on the other side of that change, even though there is discomfort in the midst of that change. Clayton:  Yeah, I think I would say that I am probably in the same boat. I have past experiences where being uncomfortable, and going through some change is how I got some result I wanted. Roy:  You think that maybe if you don’t have that experience or that knowledge, that the end result is going to be better. The harder you push to try to make things go faster, the more pain or uncomfortableness you experience. It’s like, “I don’t want to push any harder, because then it will just make it worse, and it will get more and more painful, and there is no ceiling.” Clayton:  I like Indiana Jones in the “Last Crusade.” I am willing to step off that ledge where it looks like I’m going to fall in the ravine, because I know that the invisible ledge is actually there. I’m going to be able to walk across the chasm. Jade:  The chasm. The first time you did that…? Clayton:  The first time I did that, it was like in the movie, where I was like, “I’m going to fall my death.” Jade:  Somebody had to get the sand for you and throw it across? Clayton:  Yeah, there you go. Jade:  A prerequisite to this episode, “Go watch the movie.” No spoilers, we won’t tell you how it ends. [laughter] Clayton:  There’s something from that. I know from experience that I probably discount this in others. At some point in time I went through the pain and suffering of being very uncomfortable and changing in it. It worked out OK. I’ve done that multiple times. I’ve got great results from that. I’m totally on board and I’m happy to do that. Other people who have not gone through that experience, I don’t think I give enough credit to how hard that is. I know that I’m very willing to do lots of changing and maybe change very fast. I get frustrated when other people aren’t willing to go. Not even the same space, I understand that. They’re not even, to me it feels like, willing to go half as fast or a quarter as fast. Jade:  Something I’ve noticed that’s interesting is people that are uncomfortable with change, they think of change as the change. If we’re going to do something different or try something different, we’re moving from one state to another, then that’s it. I find myself being very comfortable with knowing that, the faster we change, the faster we’re going to change. If we change and it’s not working out, I know that we’re going to change quickly to something else. Do you think that factors into people’s comfort level with being afraid to experience that change because they feel it’s going to be a permanent situation on the other side? Clayton:  I would say so, yeah, especially if you’ve been doing the same thing or something similar for a long time. That’s maybe how you got to where you are now. That makes it even harder. I read a good article where people were talking about how in the Agile community, we can’t just go discounting managers and say that managers are stupid people, and they’re so dumb and why don’t they get it? Obviously, they did something. They work inside some system and they’ve gone to some level in that system using whatever they had to do. That’s the world they know. Obviously, they’re not dumb people. They didn’t just stumble upon being a manager, but they did something to get there, based on the rules in that context. Roy:  Like being born to the present. Clayton:  The management class? Roy:  Yeah. [laughter] Clayton:  I guess I can’t talk about that. There’s a whole swath of people out there who are managers of Agile teams that got there somehow. Maybe you disagree with that system and you think it’s an antiquated way to work. Whatever, but they did something. They’re not totally stupid. To go in as an Agilest and say, “We’re going to change everything, and change is good, and you need to accept it,” blah, blah, blah, that’s so foreign. That’s not how everything has worked before and it’s like you’re discounting everything that these people have done so far as if it’s just throwaway. Jade:  The complexity of the reality that they live in. Clayton:  Right, exactly. I think that’s another factor that we don’t consider with change. That’s one of the reasons why people go slow, is that you’re having to do this whole context switch. I think some of it’s a mindset thing, too. If you’re a fixed‑mindset person, the world is the way it is, for whatever reason. You shouldn’t change because it wouldn’t work. You’re not meant to be that person. Roy:  In fact, you desperately try to hold on to the old way because that’s the only world in which you can survive and thrive. Clayton:  Yeah, that’s the one that you’re good at. You want more of the thing you’re good at. I would say that people that have more of a growth mindset are probably more willing to say, “OK, you want to do something that sounds totally radical? I’ll try that for a while,” because to them, it’s not the end state. Jade:  What happens if we turn this scenario around and say, we change as fast as the most aggressive person? What happens then? Roy:  All right, now we’re talking. [laughter] Clayton:  I don’t know. Why does that appeal to you, Roy? Roy:  It goes fast. Clayton:  For the sake of going fast? Roy:  Well, you get there faster. Jade:  Do you? Roy:  I don’t know, maybe you don’t. I got a feeling that that would make the majority of people extremely uncomfortable, probably beyond whatever their limits are. Jade:  Would they be completely dysfunctional at that point? Roy:  I don’t know. They’d either be completely dysfunctional, or maybe just totally leave, or even mentally check out and just not be able to cope. Jade:  Just reject the reality that’s happening around them? Roy:  That’s what’s interesting. If you took an individual that worked for some backwards organization and threw them into a completely different organization, even if he didn’t choose that, I feel like that individual would adapt very quickly. There would be some uncomfortableness, but it would be relatively minor. Now, if you were to do the opposite case, where you have one person going to an organization and radically changing that organization, everybody has to change. That is way more painful, if you try to do that at speed. Clayton:  I think going as fast as the most aggressive person, I would say there’s probably a good chance that you’re going to throw the baby out with the bath water. Jade:  It feels reckless, to me. Clayton:  Yeah, exactly. If I’m doing it just for the thrill of speed, I want to get to whatever the next state is, in my opinion, as fast as possible. I think you probably risk losing people, insights or whatever, that would be beneficial to the whole group, because you’re trying to go so fast. I would also say it’s a two‑way street. The person that wants to go super slow and be comfortable, the Agile community is very good at trying to analyze that problem of why is this person wanting to go slow, what are they afraid of? Blah, blah, blah. Then the people who want to go as fast as possible, there’s fears on that side, too, that we don’t address. I would say the people that want to go as fast as possible are probably not very common. Roy:  They’re probably afraid, too. They’re afraid that the change that they want will never happen, so if they don’t go fast enough… Clayton:  There’s some reason that they want to go so fast. Roy:  It would be like “Speed,” where if they drop below 50 miles per hour, the bus explodes. Clayton:  I haven’t seen that yet, Roy. [laughter] Jade:  We’ll save you the trouble. Clayton:  I’m trying to go through Sandra Bullock’s entire catalog. [laughter] Clayton:  I think we probably ignore the fact that there are a lot of reasons why people want to go super fast. I’ve seen that in organizations where people get the bug to change something and they say, “Oh, cool. This is an opport

Roy van de Water, Jade Meskill, Clayton Lengel-Zigich, and Derek Neighbors discuss: No Surprises Transcript Jade Meskill:  Hello. Welcome to another episode of the Agile Weekly Podcast. I’m Jade Meskill. Roy van de Water:  I’m Roy van de Water. Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich. Derek Neighbors:  And I’m Derek Neighbors. Jade:  We wanted to talk about a recent situation that’s come up with a team that we’ve been working with. Some unexpected things happened to the organization and the team got their hands slapped. And took a look back at how they found themselves in this situation and came up with a really interesting working agreement around “no surprises.” The idea was that anybody who was impacted by their actions would understand what they’re doing before take action. Let’s give a little bit of background about how they got there. Clayton:  The 30‑second version is the opposite of what their agreement was. There were some actions that were taken by the team that surprised the absolute crap out of a lot of people. Derek:  The thing that is interesting is if something feels obfuscated, it can elicit feelings that are much more exaggerated than they really are. In this particular instance, a team was working towards doing something, and they were talking to multiple members of other teams to get this done within the organization. However, they released what they were doing into production without telling the other teams they had been talking to that they were going to do that. When that happened, not only was there a surprise of, “Whoa, how did this get into production”? But there was this feeling that, clearly the team that did it must have been lying, hiding, and doing a bunch of things behind everybody’s back. They didn’t take the time to let them know, which even exaggerated the emotions of “not only am I surprised, now I feel I’ve been lied to, and I feel you tried to hide this from me.” I take it personal, and it’s very angry, and this caused all sorts of ripple effects. So I think, when you surprise people, there’s more than the surprise ‑‑ it’s the emotional reaction that I tend to imply all sorts of intentions on your part. Clearly because you surprise me, you must have been hiding something from me, lying to me, or doing something. Because if you weren’t, you would have been forthcoming about it. Jade:  So is it fair to say that when you find yourself surprised you by default assume the worst intention. Derek:  Absolutely. Clayton:  Yeah. I think that’s fair. Roy:  I think that’s probably a safety mechanism. That allows you to prepare for the worst. Derek:  I think it’s just kind of human nature. Why wouldn’t you share something with me, unless you had some malintention. Clayton:  Right. You have something to hide. That’s obviously, why he didn’t say anything. Roy:  Right. If you had share with me, I could have offered all sorts of help like, “Derek, why did you surprise me”? I could have made your life so much easier if you just told me. Jade:  I could have just thought you know, and then it would have been real simple. Derek:  And then the other thing that it goes to is ‑‑ it goes to trust building. When you get surprised and you feel that their intent was probably malintent because you were surprised, it erodes trust. This can go from the littlest of things to the biggest things. When a team makes a commitment as, “We’re going to get this to you by the end of the week, or by the end of the sprint, or by the end of the day,” and they don’t do it, that erodes trust. In the same way, if you do something and you don’t tell somebody that it’s going to happen and that’s a surprise. Or a new feature shows up and they didn’t know about it, it’s a surprise. It could be a customer could be surprised, your own team could be surprised. I mean, how many times have you been maybe out there…If you’re a developer and somebody on a team basically power‑coded all weekend and added all these fantastic features. You show up the work on Monday, all the stuff is there and a bunch of the crap is broken. And you’re totally pissed off at them even though you like all of the features that they have gone and put it. Because you didn’t talk to anybody, about any of those things, they just dump them and they’re not in Monday morning when you come in. And there’s all these problems that you don’t know how it works. Jade:  Even when there’s not problems. You have that feeling that maybe, yeah, it’s cool that they did that but you just don’t like the way that that happened. How you were shocked by those things just magically appearing. Clayton:  What does it say and what can you do if you’re an organization where you want to do something. If you were to adapt the “no surprises” mentality and you said, “OK, I don’t want to surprises these people or just person.” But when you went and said, “Hey, I’m planning on doing this later today or I’d made a commitment and I in order to fulfill my commitment I need to do XYZ.” That person says, “Oh, no, you cannot do that under any circumstances, I am telling you no, right now.” How do you deal with that? Roy:  If you’re in alignment and headed towards the same goal, that shouldn’t be an issue, right? Clayton:  Let’s say that you’re not in alignment. Derek:  Are they bigger or smaller than me? [laughter] Clayton:  I think that’s some conflict. If you didn’t have “no surprises,” and you went and did it anyway, you’d piss that person off, but if you think it’s the right thing to do and it’s the thing that’s going to help you be successful with getting your outcome, but for whatever reason this person is saying no. Let’s say that they’re saying no for the wrong reasons. That’s probably a typical example. There’s someone that’s the gatekeeper for something and everything must flow through them, and maybe they don’t have the bandwidth for you right now, or they just don’t like you, or they don’t think you’re important. They’re going to tell you “No,” no matter what. At what point do you say, “Hey, I’m planning on doing this,” and you do it anyway? You’re not violating the “no surprises” because you’ve told them you’re going to do it, you’re just defying them. Derek:  I think that’s a good example of ‑‑ who else would be surprised by that? If I’ve got a boss, and I go to another person and I say, “Hey, I plan on doing XYZ,” and they say, “No, you can’t do that,” and I say “OK, great, I’m going to do it anyways.” I didn’t surprise them, but when they go tell their boss, and their boss calls my boss, and now my boss goes “What the hell is going on”? He’s surprised, or she’s surprised. In that situation one of the things I would make sure I do is, who’s going to be impacted by my behavior that may be surprised, and maybe I should let them know so that they’re not surprised. Jade:  I think that’s the challenge. Understanding what that really means. The people that would be impacted by my actions ‑‑ there are usually a lot more people than you think that are indirectly impacted by the actions that you’re going to take. That’s an interesting thing about the way that the team came up with the idea that whoever’s impacted, understands. Doesn’t necessarily have to agree, or give permission, but that they understand what you are about to do. Roy:  They understand they will be impacted, that does not mean that they will like it. Clayton:  For me, a lot of that part of it goes back to the difference between honesty and transparency. That example of ‑‑ tell my wife, like “I went and had drinks with the guys.” I might be very honest about that. But if I’m transparent I might say “We went to Babes Cabaret,” right? [laughter] Clayton:  That’s a very different story to tell. I’m being very honest. I had drinks with the guys. That is a 100 percent truthful statement, but I am not being transparent. Where, the no surprises thing would make me think in those terms. If I go over to someone and say “I’m planning on doing this, here’s why I’m doing it, I don’t even care if you think it’s a good idea or not. I’m doing this, and if you tell me no, I’m still doing it anyway, but I’m not surprising you.” I think that’s different than walking over and saying “How would you go about this to do this”? “I don’t think you should be doing that.” “Oh yeah, I’m not saying that, just hypothetical.” Those are very different things. You’re sort of telling that person that maybe this might be happening, whereas “no surprises” really is, “I’m going to be 100 percent transparent that I plan on doing this and I’m telling you that I’m going to do it. Sorry if you don’t like it.” Derek:  Some of those, too, you have to be careful. You can’t be transparent after the fact, either. “Hey, I just went into the refrigerator and I ate your lunch.” 10 minutes before your lunch time, I come to you and say, “Hey, by the way Jade, I ate your lunch today. You’re going to be impacted. Ha ha ha.” Jade:  No surprises. You didn’t go to lunch and were surpr

Roy van de Water, Jade Meskill, and Derek Neighbors discuss: Autonomy Autonomy Even more autonomy Transcript Jade Meskill:  Hello, and welcome to the Agile Weekly Podcast. I’m Jade Meskill. Roy van de Water:  I’m Roy van de Water. Derek Neighbors:  I’m Derek Neighbors. Jade:  We wanted to talk today about the power that autonomy can give to a team. We’ve worked with some teams where their autonomy has been severely restricted and not seen good results. We’ve worked with teams that have been given autonomy and seen some good results. We wanted to talk about why is autonomy so important to high performing teams and what are some ways that you can get it? Roy:  Cool. Jade:  Let’s start with…what are some of the problems that we’ve seen where…or what are some signs that a team is lacking autonomy? Roy:  First off, the sign where somebody proposes an idea and they get shot down because somebody may not like it or you’d have to ask somebody else, first. Jade:  Somebody on the team? Somebody in authority? Roy:  Yeah, just in general, like if I were to propose an idea and they’re response would be, “Oh, I don’t know if we can do that. We should be careful.” Like that tells me… [crosstalk] Derek:  We might upset somebody. Jade:  So, fear? Roy:  Right. Derek:  Yeah, I think a lot of fear. I think a lot of, when you see the like, “It’s not really my problem.” No, not that “That’s not my problem” but the hopelessness like a victim goes… Roy:  We’d really like to do that but… Derek:  Yeah, sounds great or just the apathy. When I see low autonomy, I see low motivation, like no passion, no motivation, because it’s like, “Hey”… [crosstalk] Jade:  Which one’s a symptom of which? Is the “no motivation” the symptom of not having autonomy or is having “no autonomy” a result of having no motivation? Derek:  I think that if you have high autonomy, you tend to be more motivated because you know whatever you put into it, you’re able to reap that, where if you have no autonomy, you’re implementing somebody else’s way to do it. If I think that your way is not the best way to do it and I think I have a better way, how am I going to get excited about doing a way that I don’t think is a better way? Jade:  Sure. That’s an important part of motivation, is like owning your outcomes because otherwise, it doesn’t matter how much effort you put into it, it doesn’t make a difference anyway? Derek:  Yeah, I think just doing work to be work‑sake is somewhat soul‑sucking, right? If you’re able… [crosstalk] Roy:  In a way Derek. Derek:  Yes, it is. [laughs] Derek:  If you’re able to do work the way that you feel is the best way to do work, that covers a multitude of sins, maybe is the right way to say it. Because you have autonomy, will you have a ton of motivation and be passionate? No. You have to have purpose, too. You can have purpose, but if you’re not able to do the things you feel are right things to do, that drive is going to drop pretty quick, right? It’s almost like yeah, I’m really excited about why we’re doing this, but then everything you want to do to make it happen, get shot down, or you have to do a different way, like that’s going to erode that passion and that drive pretty quickly. Roy:  I agree with that. I think some people are good at pretending. If they don’t have the autonomy, they still pretend about the passion. I would almost say that…I will say that if you had people that don’t have autonomy and they still act like good people should be unmotivated unless they have autonomy. You know what I mean? Jade:  They’re going to lose their motivation quickly if they realize they don’t have that autonomy, you were saying? Roy:  Right. I would consider the smell if somebody didn’t have autonomy but they were still super passionate about what they’re doing. It may not be an immediate indicator that something is wrong, but I would be concerned. Derek:  I think for most people, it’s not until they’re not able to get the results. I don’t think it’s not so much like you don’t have autonomy that that’s the problem but the first time that you think that there is a better way to do something or that you have a better idea or that there’s a better way to solve a problem and you get shot down in the answers because I’m the parent and I said so, that is totally will suck the life right out of a team or an individual. Jade:  That’s the defining moment where you wake up, right? Because a lot of people in a lot of teams don’t have any sort of control over their own destiny, but they’re blissfully ignorant, right? If I’m working solo or if I’m kind of just doing tasks… Derek:  That’s true. Roy:  A lot of times I don’t even see that I don’t have that thing. Derek:  I will revise what I said earlier. Just because somebody may still be able to feign passion from not having autonomy, they may just be ignorant because they don’t know how good they could have it. Man:  Right. Man:  Yeah. Roy:  I see a lot of motivation go away sometimes when those teams wake up and realize that they are being held back. Derek:  I think that is Roy, you bring up a really good point. As I think from kindergarten pretty much, we have our autonomy stripped out of us in school. Roy:  Sure. Derek:  …and, I think, a lot of parenting styles strip a lot of autonomy away from children. It’s a heck of a lot easier to deal with a kid that’s compliant rather than a kid that is inquisitive, and doing things. I think a lot of people don’t even know what that reality looks like, any more. What I see is, on teams that we tend to work with and we give them a taste of that, it gets hard to put them back in the cage. Once you experience a little bit of freedom, it’s really, difficult to go back. If you’re in a cage all the time and somebody opens the door, you probably won’t leave the cage. Jade:  It’s like being a tame tiger. Derek:  Once you’re let out of the cage and you’re able to run freely over a multitude of places and do a bunch of things, and then somebody says, “OK, it’s time to go back in the cage?” That’s demoralizing. Roy:  Right, but you can have the opposite too. It reminds me of this great picture I saw one time of a guy in a cage and he’s got all the locks on the inside, and he’s got all the keys, but he’s hiding there because it’s safe. I feel that’s what a lot of these people that are in their cages have. Like, “Yeah, I know I’m not free, and I know I don’t know how good I could have it, but it might also be really scary and difficult and I don’t want to deal with that.” “I’d much rather stay in here where it’s safe and I’ll just come to work from nine to five, do what I’m told, go home, and I can be my true self the rest of the time.” Derek:  It’s pretty crazy because if you look at some of the best companies in the world, they switched from trying to hire the brightest people to hiring the most impassioned, autonomous people. Meaning, good companies learned that one of the easiest ways to scale is to hire people who are capable of knowing the right things to do and doing them, and not needing a whole lot of management. Needing some leadership to push them along. What you’re seeing is some key areas around the world that are attracting the most people like that, because, again, once you realize that freedom and you see what that looks like and you’re attracted to it, people that are interested in that are flocking to those areas. You’re starting to see other areas be able to not compete nearly as much. The big Fortune 500 companies are having a harder time getting and keeping good people. They’re losing them to the five person company that’s becoming a 100 person company all the time. I think that that’s hard. A massive culture change has to take place. What we see in most companies we go into is their middle management and upper management got to where they were at because they were really good at removing autonomy. To come in and say, “Nope, you need to go the other way and let people be autonomous,” that is just not in the nature of the people that are there. Jade:  What does autonomy look like in an organization, on a team? Roy:  I think on a team, by definition, if a team is autonomous, the team itself has to be very flat. Having any form of hierarchy within the team kills the autonomy, because then, really, you only have autonomy at the top of the team. The entire team is not autonomous. You know what I mean? Derek:  Right. I think the more authority structure you have, the more easy it is for people to defer accountability. Roy:  Hide behind authority figures. Derek:  I think they can hide behind the accountability. It becomes, if Jade and I need to make this decision and you’re the boss, and we’re not really sure on it… Roy:  Or you making the decision’s going to hurt Jade’s feelings even though you know it’s the right thing to do. Derek:  Whatever the case is, there’s contention of some kind around, and is this the right decision? We could be wrong. If there’s a boss, we can go and say, “We’re not really sure, what do you think?” [crosstalk] Derek:  We’ve removed the autonomy away from ourselves and put it into your hands, which would sound bad compared to everything we just sai

Clayton Lengel-Zigich, Roy van de Water, Jade Meskill, Derek Neighbors and Alan Dayley discuss: Roles Collective Ownership Transcript Clayton Lengel‑Zigich:  Welcome to another episode of the Agile whenever you feel like it podcast. [laughter] Clayton:  My name is Clayton Lengel‑Zigich. Roy van de Water:  I’m Roy van de Water. Derek Neighbors:  I’m Derek Neighbors. Jade Meskill:  Sometimes I’m Jade Meskill. Alan Dayley:  I’m Alan Dayley. Clayton:  Today, we have our special guest, Alan, and Alan wanted to talk about roles versus collective ownership. Alan:  It’s been fascinating to me recently that I’ve had lots of discussions with people and have been seeing lots of discussions online and in real life about people trying to define roles. It’s your job to do this and your job to do that. The product owner should be the one grooming the backlog therefore the development team doesn’t have to do that. So and so should be deciding who’s on the teams. This is a problem, it’s not mine to solve because that’s somebody else’s role, or somebody else’s power. It seems like we spend so much time defining roles and boundaries of authority that we could use that time to actually solve stuff. I wanted to talk about the usefulness of roles and I think they are useful in certain situations but we’re also roles versus collective ownership. How do we come to the point where we all realize we’re on the same boat and we can all do whatever it takes to get that boat where it needs to go? Jade:  I saw an interesting definition of what differentiates a group from a team and the definition was, “a group becomes a team when they accept responsibility for their actions.” Roy:  Like collective responsibility? Jade:  Yeah, as a whole unit, we accept the consequences of our actions. That’s a defining moment when a group becomes a team. Roy:  If you were to overhear a team talking, you’d hear it in their language. Somebody would start saying, “Oh, we messed it up here.” Even if that person was not necessarily… [crosstalk] Jade:  Had nothing to do with actually doing the doing. Alan:  In other words, you’re saying, in the retrospective, I could say, “Jade, you let us down,” but when I’m outside the retrospective, I’m going to say, “The team failed. We failed.” Jade:  Yeah. Derek:  I think go straight to these personalities because I like them. [laughter] Roy:  I don’t understand them. Derek:  I know, you’ll get this one right and… [laughter] Derek:  Soccer is my favorite example of this and every team that’s won the world cup, probably, since the late ’70s has been influenced by a style of Dutch football. It will be called “total football” here and it was something that was a radical transformation going from positional play where you had, “Hey, you’re a forward, you play forward, you attack. You’re a mid‑fielder, you possess the ball. You’re a defender, you defend.” to basically training children from a very young age all aspects of football, so that when they would step on a pitch there were no real positions. You might start in one particular position, but throughout the game you just went wherever you needed to go. All of the people were interchangeable, short of the goalie, or the keeper. That that style was so successful that almost every program has adopted that mentality of, “You no longer just train for one thing, you have to be a complete player regardless of where the position is.” We’re starting to see that mentality happen in software teams, where you no longer can have the database person, or the designer person, or the front‑end person, or the developer person. You really want people that are well‑rounded. You might have people that start in a certain position and have a strength towards that, or a role, and have a strength towards that role. But teams that are like “I can’t do that because that’s not my…the scrum master left and I’m not the scrum master, so I can’t do it,” they’re doomed. The teams are like, “Hey, the scrum master is gone this week, somebody else will step in and we’ll just do it, and keep rolling.” Those are the teams that are adaptable. I think that that starts to reinforce the “It’s everybody’s job to score a goal, it’s everybody’s job to stop a goal.” Same sort of thing. If our results are owned together, there is no “Well, it’s the defense’s fault that we lost.” Clayton:  That’s a good point. I was going to say that the time that I hear people talking about roles the most are when blame is happening, when someone is trying to blame somebody… Jade:  It’s when blame is important. Clayton:  Huh? Jade:  When blame is important. Clayton:  Right, yeah. I don’t think I’ve ever really seen a team where they did something that was successful, and they singled people out in that regard. Everyone’s OK with sharing some of the credit, but when someone needs to be in trouble, or we need to blame somebody, that’s when the role stuff comes up. A lot of like, dealing with conflict, like management type stuff comes up, especially the old hierarchies. Like having teams where they have been trying to be, maybe, a cross‑functional team. Maybe they’re trying to be, like, having collective ownership. But the second something bad happens or someone needs to assert power about how a situation should happen, they revert to the two‑year‑old way of doing things where it’s like, “I know that you’re part of this team and everything, but like, you are from the QA organization. Even though you haven’t done that for two years, but I’m a developer.” That used to mean something two years ago. “But I’m still going to go all the way back to that issue, so that I can assert this thing over and say that we’re going to do it this way.” It’s always the negative stuff when the roles come up. Alan:  So let me flip that around a little bit. I’ve been in environments where people defend their roles because that’s what has always made them valuable. So, “I am a valuable tester,” or “I am a valuable manager,” project manager, or just a dev manager. Just take the dev manager for example. I’m a valuable dev manager, I need to know what’s wrong in the team therefore I must attend the retrospectives. That may be a positive thing, depending on the relationship of the manager. But to me, sometimes, it feels like people are trying to hang on to what they know from 20 years of working that way so that they can hang on to what they see as the way that they contribute value. Clayton:  I think people that have got to a certain point in the organization or their career by specializing in being something to come in and say, “Hey, we’re pretending that’s not super important.” What really matters is that the whole team is responsible for the outcome and has to own whatever happens. That’s a hard pill to swallow, I think, for those people. Derek:  I’m not going to hijack the conversation but this is largely because that’s how we do performance. We do individual performance reviews that say, “You’re good developers. We’re going to promote you to a developer leader.” “You’re a really good developer leader. We’re going to promote you to a developer manager.” Their whole career, they’ve been trained that their individual results are what they get rewarded on. When we talk about sharing the outcome, why the whole should I share the outcome because how I get compensated isn’t shared. If how I get compensated isn’t shared, what benefit is there for me to share? When you start to change the conversation away from individual performance and start to put it towards team results or product results, people get scared really quick because, now, the next thing that you’re going to say is that reward is based on results. Damn it, for 20 years, nobody’s ever made me get results. I don’t know how to do that. I’m afraid that maybe Jade doesn’t know how to do that, Clayton doesn’t know how to do that. Now, all these accolades, benefits, and everything that I’ve gotten from effort are going away, I’m scared. That’s what they’re really saying is, “I’m afraid of losing the title because there’s something tied to that title that’s so much deeper.” There’s authority tied into it. There’s reward tied into it. There’s so much tied into it that the unknown is just too scary to let go of. Jade:  Why are roles important then? What’s good about them? Alan:  I wanted to swing back around to that. Roy:  In one case where, I think, roles are important is in the finding a clear path of authority. We’ve talked about the idea of a perfect manager who comes in, drops an end result on a team and then goes off into the background until the task is done. You have to have somebody that define role and they can’t be a member of that team. That just doesn’t work. Jade:  Why are scrum have roles then? Why are they defined that way? Alan:  My answer to that would be to say that scrum, scrum using term as an example, XP has some similar roles but, I think, the roles that are defined in these frameworks so that you know there are certain areas to focus on. There needs to be somebody defining what the product does. There needs to be somebody paying attention to how the process works.

Roy van de Water, Clayton Lengel-Zigich, and Jade Meskill discuss refactoring your Ask For Help to get better results. The post Episode #129 – Ask For Help Refactoring appeared first on Integrum.

Roy van de Water, Derek Neighbors, Clayton Lengel-Zigich, and Jade Meskill discuss the benefits of smaller teams.   Transcript Jade Meskill:  Hello, welcome to the Agile weekly podcast. I’m Jade Meskill. Roy van de Water:  I’m Roy van de Water. Derek Neighbors:  I’m Derek Neighbors. Clayton Lengal‑Zigich:  Clayton Lengal‑Zigich. Jade:  [laughs] We’re a little eager. We want to talk about team size today. We don’t necessarily want to talk about what is the exact right size for a team, but what are the advantages and disadvantages of teams of certain sizes. Derek:  I’ve seen a lot, in a group that I’m working with, where the teams aren’t obnoxiously large, you’re not talking of 30‑person team. There’s been a lot of change, the teams in a lot of ways would be acceptable team size, they might be between 8 and 12 people, which is not abnormally large, but not on the smaller side either. And some of the things that people are asking are can we really improve more if we continue to have these size teams, or if we were to go to smaller teams, could we actually do things better than we’re currently doing now? Would that make a difference? Would it make a difference if we…and some of this is because they have more products that they want to introduce and so they really can’t go hire more people. Product owner or product manager says we really need this other additional product, but we don’t have people to put on that team because they no longer do the project madness. They actually line people up to products and they belong to a product and they stay with the product, and they really own it which is awesome, but now, hey we’ve got this new product that we want to start. We’re not allowed to hire people right now. How do we staff that product? They’re talking about what if we had formed a new team, but that would mean some of the other teams would get smaller. Would we get a better result from that or do we get worse result from that and that’s kind of the discussion that’s been happening. Clayton:  Yeah, I would say I think something akin with a small team, it’s amazing how much easier it is for them to make decisions and get alignment on things and have like a shared set of values and I’ve seen the same people work in larger teams that are probably close to the six, like six, seven, eight people and nine people, whatever. Maybe more like a traditional scrum size and I’ve never really have seen those people or those teams of that size be able to make decisions as fast as this team of effectively four people as fast as they can make choices. They can move so fast on things. They can get information and decide to do something. They don’t have that feeling of, “We need to have a meeting, because some people aren’t here. We need to involve everyone.” Roy:  So does that ability to make quick decisions…how does that compare against a team’s ability to produce so much value? Does that mean that they can’t produce as much value, but they can produce more of the right value, or what? How does… Clayton:  I would guess that most organizations are in the boat, where, if they took a team of 12 people and they got rid of 4 people, I don’t know that they would see a huge drop in “productivity.” Roy:  Maybe even a gain. Clayton:  Yeah. I think, you eliminate some of those extra communication paths and some of the extra overhead of having to deal with that many people trying to make choices, or, decide what to do and all that stuff. Roy:  And you get rid of some of the assholes. Clayton:  Exactly. A lot of times it might seem on the surface like, “If we have a team of 12 and they’re doing…” If they were trying to use the philosophy, like “We’re a team of 12 and they can do 20 points a week. If we give it to four people, they’re going to go down.” But I don’t know that that’s always the case. Derek:  I think some of it is the communication pathways problem, or the decision trees problem. I heard an analogy today I really liked, about learning, and it was an analogy towards video games. It was “Try, die, try, die, try, die, level up. Try, die, try, die, try, die, level up again.” One of the things that happens when you have a lot of people and decisions go slower, it means, “Decide what to do. Wait, wait, wait, wait, try, die. Wait, wait, wait, wait, wait, try, die. Wait, wait, wait, try, die, try die, level up.” Whereas if you’re able to do that much smarter and take out those “wait, wait, wait, wait, wait,” you actually “level up” much quicker. I when I say “level up” that’s where the people and the team are “leveling up,” but the product is improving at a much greater rate, not because the decisions are better because there’s less people, but you’re able to fail on the decisions you make much quicker to get to the right decision, than if you sit around for hours trying to hash it out between eight people what the right decision is. I can’t tell you how many meetings I’ve sat in where there was eight people, and seven of the people were like, “Yeah, let’s totally do this,” and you’ve got one person that drags it for three days to try to make a decision. Jade:  That can happen in a small four person team too… Derek:  Right, it just happens quicker. For the most part it tends to happen quicker. Jade:  But, there’s something more to it than just size. It comes down to a lot of trust and alignment, and things like that, which are easier to attain when there’s 4 of us, versus when there’s 12 of us. Clayton:  I think you get an overlap, because if you have a team of 10. The team is supposed to be doing some collaborative effort. I might only interact with one or two people a day, let’s say we’re all pairing. It would take me two to three weeks before I would pair with everybody. We’d have to go out of our way to make that happen. But in a smaller team you have no choice. You have to do more stuff with the same people over and over and over again, so I think you speed that process up. Derek:  Yeah, you have more trust quickly because you’re more connected, because you’re doing stuff more often. The other thing is, if I’m on a team of eight people, there might be large parts of the code base that I’m not even really that familiar with, even if I’m pairing all the time, just because, by circumstance we’ve been through a few sprints and a lot of code has been created, and I’ve not been pairing a lot. Now if somebody wants to make some decision, the two or three people, or four people, that have paired on that and are really familiar with it, are like, “Come on, let’s make the decision,” and the four people that are like, “Um, I’m not really sure.” It’s really hard to keep that sense of ownership, and that sense of collective being. Where if you’ve only got four people, or five people tops, it’s really easy to be in a much more shared state of trust because you’re never very far removed from whatever it is you’re talking about. It’s very rare that you’re like, “Oh, man, people have been talking about what we’re going to do about this for days, and I haven’t been included in it.” If you’re in a team of for people, it’s hard to not be part of almost every conversation on [inaudible 06:37] Roy:  Unless you choose to be… Derek:  The other thing that I have been talking a lot about, and I think this is a big part of mediocrity for a lot of teams, is, if you’ve got 10‑12 people, even 9 people sometimes, on a team, and you have one or two really strong people and one really weak person on the team, that weak person can really hide. Because what happens is that the strong people can just pull harder, or work harder, or put more effort… Roy:  Or shuffle the weak person around a lot. Derek:  Shuffle the weak person around, whatever. What happens is if you ask them, “Why aren’t you doing something about it”? Their answer becomes, “It’s more effort for me to deal with trying to make the person that is hiding be exposed, than it is just for the…” If there’s the four of us, and there’s five other people on the team, and one of them is really weak, we just say, “Hey, the four of us will cover what the other person’s not doing.” That’s easier than having all of the emotional stress of dealing with somebody who’s not performing. But you get on a four‑person team, it’s no longer OK, “I’m sorry, the two of us are not going to pull the slow guy.” It’s just not happening, because now it’s a Herculean effort instead of, “Eh, it’s kind of painful, but…” So two things happen. Either the guy that’s hiding figures out really quick, “I can’t hide,” and decides to go somewhere else, transfer somewhere else in the company, go to another team, leave the company. Or they have to fess up and say, “Look, I don’t know, I’m lost. I don’t know how to do this kind of stuff, I need help.” Usually what will happen is the team will embrace that, and say, “OK, if you want help I’ll help you, but I’m not going to carry you anymore. When we were in a 10‑person team, we all carried you around, but now that there’s only one or two of us to carry you around, we’re not going to carry you anymore. But if you want help, we’ll help