Agile Weekly Podcast

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 have in my own picture and I’m trying to fill in my opinion of what an ideal team looks like has change over time, is that telling me that’s always emotion and therefore unattainable? Jade:  I think it’s a reflection of your own maturity, what you think the ideal team is. Derek:  I think if you’re in search of excellence and search of constantly improving, yes. There is no destination called perfect team. There is a journey to perfect team. Jade:  I’ve seen glimpses of some of these things that we’ve talked about, all throughout my career in different groups and different teams that I’ve worked with, but never the whole picture. Because my expectations are constantly rising. My expectations for myself and the people that I chose to work with, they’re always getting higher and higher and harder to reach, but I think that’s what makes it the ideal. Roy:  How does a team on the road to perfection deal with poisonous elements on that team? Jade:  You got to turn them or get rid of them. Derek:  Yeah, I think if… Jade:  There’s no easy answer to that. Derek:  I think if you’re really talking of accountability from that stand point. A, are they on the bus? Do they agree with the things that they have been agreed upon? If the answer is no, that’s probably a pretty good sign that either you’re on the wrong team, or they’re on the wrong team. If the majority of the team is saying, “Hey, we’re going in this direction.” and you’ve got somebody that says, “I refuse to go that direction. I want to go to this direction.” From a philosophy or accord of value, vision, mission kind of thing, somebody has to either re?calibrate and put the line in his mind, like “We’re headed to New to Mexico. If you’re headed to California, get off and get on the California bus.” Those become pretty cut and dry. I think it’s kind of dry for everybody. If you’re the person that wants to go to California, you’ve realized the bus is going in that direction, it’s pretty easy to get off the bus because you know. I think there are the ones where it’s, “Hey I’m not necessarily disagreeing with where we are going there,” but maybe there’s personality involved, maybe that implementation. “I think we should be going on a plane, not on a bus.” I think those, you’ve got to deal with through the kind of accountability, the conflict all of the steps it takes to really form within a team and deal with those issues. It’s just like you go get married right away. You might, “Hey, we both have the same dream of where we want to be when we grow old, have kids and everything else,” but in there we realize, “You like to put the toilet paper rolled down, I like to put it roll up, and, we need a box that out and figure out how we’re going to [inaudible 12:22] Roy:  It’s roll up by the way. [laughter] Derek:  Put the roll up in the thing. It doesn’t mean we should go get divorced because we just [inaudible 12:29] We got to figure it out. I think that exist in teams too. Roy:  It seems to me though that those start becoming some really dangerous questions to ask as you may find that you’re on the wrong bus, so to speak. Derek:  Yeah. I’d like to say that, earlier you can have conflict, and the better you get in dealing with that or getting results from it, the better you’re going to get to a better team. Because either you’re going… Roy:  I don’t want to be half way to California before I find out I’m headed to New York. I’d rather find out while I’m still Texas so I can… Derek:  Yes. A, it’s much less painful for everybody from a stand point of, “I’m not now stranded somewhere halfway in between,” but it also makes the ride so much more enjoyable. If I can get the distractors off the bus 10 miles in, now I’ve got a thousand miles of much more fun travel. Jade:  It’s easier to say it, but to actually do it. There’s a whole human element that gets involved that makes it very difficult. Derek:  If you’re not doing this right now, you are a bad human being. [laughter] Jade:  [laughs] What’s the first step that somebody should take? If they say that, “I know that I want to reach whatever my perceived ideal is.” Roy:  I think that is the first step… [crosstalk] Derek:  First step of self awareness. Roy:  I don’t think many people know where they actually want to go. Derek:  I’ll say that’s the biggest problem with teams I’ve encountered lately. Is team members who don’t really know what they want. Or they say, “I want X,” but in reality none of their actions match X. You’re sitting there… Roy:  They probably really believe they want X too. Derek:  I think they haven’t really thought about it. It’s the classic case of, “The world has told me I should be an accountant. Secretly I want to be the lead guitarist for whatever, but I just know that’s not possible.” “When people asked me every year for the last five years what do I want to be, I’d say I want to be an accountant. Then I say ‘OK, I want to be an accountant.’ I spend all of my time playing guitar in the garage and I never pick up a financial journal, never go talk to any other accountants.” It’s like, “I’m not believing you want to be the best accountant in the world. I think your interest lies elsewhere.” Jade:  That is very hard to be honest with yourself. I think that goes all the way full circle to the only person that you can change is yourself. If you want to influence people, you need to start acting in the way that you want the rest of your team to behave. That’s going to be hard when you’re not in sync, not the band, but yeah. [laughs] Roy:  Nsync, it was easy for them. Jade:  Yeah. Derek:  Backstreet Boys was way better. Jade:  On that note, I think that’s all the time we have. Thanks for listening. We’ll catch you next time. [music] [background music] Announcer 1:  If there’s something you’d like to hear in a future episode? Head over to integramtech.com/podcast where you can suggest a topic or a guest. Announcer 2 Looking for an easy way to stay up to date with the latest news, techniques and events in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content delivered weekly for free. Announcer 3:  The agileweekly podcast is brought to you by Integram Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integram.com or subscribe on iTunes. Announcer 4:  Need help with your Agile transition, have a question and need to phone a friend? Try calling the Agile hotline It’s free. Call 866?244?8656 The post Episode #140 – Our Ideal Team appeared first on Integrum.

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 together. And as a part of that, we are going to come out way more unified about that thing than trying to coerce you to do the thing that I wanted to do.” Jade:  I think there’s an important step that needs to happen before that, that will make that journey a lot easier is understanding what everybody’s hopes and desires are, for being together. We are creating this new family, what do we want out of this? It eases the burden of negotiating some of those practices. Clayton:  In the team example, take you are in a corporation and you get reorged, now you have this team of 5 people, and now it’s 10 people because this is a reorg. Those people probably don’t have any hopes and dreams being on that team, other than, “I am glad I didn’t get fired.” How do you solve that problem? Or how would you have that conversation when it may be not voluntary. Roy:  Even when the team formation is not voluntary, it doesn’t take away from the fact that every single human being has hopes and dreams about their life in general. And those are the ones that are valuable because those are the basis for which every single decision they make comes into play. And it becomes a lot of easier to understand why, even if I don’t agree with it Derek might want to use .NET if I understand what he hoping to obtain from that. Derek:  I want to use Cobol. [laughter] Roy:  I’m sorry, but you understand what I am saying. But if I know the why he’s making that decision it makes it a lot easier to understand and it helps make it a lot easier to find a solution that might would work for the both of us. Clayton:  So, there is some empathy aspect to it? Roy:  Yes. Jade:  We’ve become human. We understand our hopes and dreams. We’ve figured out the non?negotiables. We’ve created new traditions, et cetera, et cetera. Roy:  It’s time to start getting to work. Jade:  Now you’ve got to get something done. So now what? Roy:  Start working. Just do it. Jump right in. Jade:  What does that look like? Clayton:  Does it ever look a certain way? I mean isn’t that… Jade:  There is a huge temptation to put that off as long as possible. Roy:  Or to go back to your old teams and work in two siloed groups. Derek:  There is something to be said just for having to deal with that stuff and then to reflect on it. Those are the two important things. You just have to step forward. Going back to marriage example I am so nervous about going to your family’s house on New Year’s Eve and whatever that tradition is. But the longer that I put it off and the more I mop about it and the more I freak out about it. That doesn’t help me. Just going and then recapping. And then either going, “That really wasn’t that bad. I really ended up and your brother was really cool and we hung out and like that was really cool and I can’t wait to go back next year.” Or maybe, “Oh my God, that was so miserable. Your sister hates my guts. Let’s figure out how do we deal with this going forward.” But like the only way you are going to know that is to do it and I think that the other thing just do the things you need to do together as a team so that you can figure them out and make them better for the next time. Jade:  So making it real as soon as possible… Derek:  Make it real as soon as possible Jade:  …and fully engaging. Derek:  Yep. Rip the Band?Aid off. [laughs] Clayton:  I guess at that point are you in the storming, forming, norming. You going to be in that pattern? Roy:  Yeah, you are going to be in storming. Jade:  You’re still really in forming. Right? Roy:  That’s true, but I mean… Jade:  There’s still a lot of politeness at this point. Roy:  When you start working together is when the storming is going to start happening because that’s when like first you were negotiated but now that shit becomes real. Jade:  Does it happen right away? Roy:  Probably not. I don’t think that all of those decisions are going to surface and it’s probably going to have to. All the little things are going to have to build up to a point where it exceeds a threshold and then all of a sudden somebody is going to explode. Clayton:  Or say there is some contentious issue. We were able to get by pretending like everything was fine but now there is this actual fork in the road that we have to deal with. Roy:  Like a single big issue that all of a sudden becomes the thing? Clayton:  Right. That’s maybe were people would want to go back to bad behaviors or go back to their “old team,” whatever that kind of thing. Jade:  You’re not going to see those kind of things right away. Everyone is on their best behavior usually at this point Roy:  I don’t even know what the time line for that is going to be. Jade:  It’s like you said there is going to be a bunch of little things that build up until somebody losses it. Clayton:  And it depends on how much of the actual real work you are doing. The more real work you can actually do the probably faster it would happen. Roy:  That makes sense. Clayton:  But the more time you spend kind of dancing around that or taking it easy. Derek:  I also think sometimes you just have to wait for the right event to happen going back to the marriage example. Thanksgiving was great. Both of our traditions didn’t conflict and Christmas was great they didn’t conflict and then we get to Easter and there is a massive conflict on this. Fireworks are going to happen because… Roy:  It almost makes it worse because you were so complacent the last two holidays, why can’t you just give in on this one. Derek:  You fall into the illusion of the last holidays all worked fine what’s wrong with us now that all of a sudden we have this problem. And so teams can fall into that same thing where they feel like they’ve maybe are more into the norming stage just because they feel like they haven’t encountered… Jade:  Because they are actually in the forming. Derek:  …they haven’t encountered real conflict together. Like, “Hey, we all got together and we agreed all on the same language,” and “Hey, we got together and we agreed on 95 percent of the practice,” and it’s not like until that first thing there is a violent disagreement on until that it’s like whoa shit we haven’t learned how to deal with conflict together. And now we’re going to have to do that. Roy:  …and we were going to spend the rest of our lives together. [laughter] Jade:  What about the expectations? Especially, external expectations of this team. Like if you are managing this team or are responsible for their output in some way do you say like, “It’s going to be rough for them for a while so maybe we shouldn’t expect too much”? Roy:  No, I think you should expect more because that is what makes it happen quicker. Like get that shit over with. Derek:  I think that if you are true to yourself you should not expect nearly as much from them. The problem is, in reality, most people completely minimize the amount of pain that is introduced by doing that. I am not saying don’t expect anything from them. And I am not saying that lower your expectations to them. But you have to be real to yourself that even if you tell them that hey I am still expecting a lot out of you to help motivate them to move through that conflict. Roy:  That’s the big difference. Don’t tell them that you’ve lowered your expectations but realistically lower your expectations. Jade:  Don’t abuse them when they don’t hit your expectations. Roy:  What we’re saying is lie to the team about your expectations. Derek:  I don’t think it’s lying. You could say, “I know this is really hard stuff, but I am not going to just give you a free pass for this,” and then if they sit there and do nothing and don’t actually try to form and they don’t try to do that you should beat them with a stick and say, “This is crap. You’re not even trying,” but if they are trying really hard and are dealing with conflict. There is all sort of problems you shouldn’t beat them because they’re trying to do the right thing. You should do it accordingly. You shouldn’t beat anyone anyways. Your accountability should match the results they’re attempting to get. Clayton:  All right. That is all the time we have so thanks for listening. [music] Announcer:  Is there is something you would like to hear in a future episode? Head over to intergrumtech.com/podcast where you can suggest a topic or a guest. Looking for an easy way to stay up to date with the latest news techniques and events in the agile community. Sign up today at agileweekly.com It’s the best agile content delivered weekly for free. The agile weekly podcast is brought to you by Intergrum Technologies and recorded in Gangplank Studios in Chandelier, Arizona. For old episodes check out intergramtech.com or subscribe on iTunes. Need help with your agile transition. Have a question and need to phone a friend. Try calling the agile hotline. It’s free. Call (866) 244?8656. The post Episode #139 – Rapid Team Growth appeared first on Integrum.

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.” If the team were doing more pairing this would be less of a problem or it would help them come to a better solution on their own. Having that experience to be able to suggest those things and having a time boxed length of time that people could try new things. I think that goes a long way. I don’t know how that works with principles though. Roy:  You can’t time box principles forever? Clayton:  Well I think they are so abstract, they are too high level. Roy:  We were going to have collective code ownership for the next two weeks and then maybe we won’t collectively own the program anymore. Clayton:  Yeah, but that feels wired right? Roy:  Right Jade:  What happens if you only see the practices and you don’t understand the philosophy that is driving those things? Clayton:  At a certain point you probably start cargo?culting and if you don’t understand the philosophy. I don’t know any off the top of my head, but there are times where there practices that frequently work towards a particular philosophy or principle will work against it when applied incorrectly. We see that all the time when you throw out the baby with the bath water. Derek:  I don’t know if I fully agree with that. More often than not even when people do a fair amount of cargo culting their still way better off than they were doing nothing or doing what they were before. What you tend to see is you either see a plateau. If I cargo?cult something like a stand?up or something, it’s still way better that I spend 10 minutes talking with the team rather than never ever talking to the team. I’m going to hit a plateau that only takes me…I only get so much benefit for that and then it flattens off. It feels like I might be doing more damage even though in reality it’s still better than it was, or what you’ll see is you’ll see practices get abandoned fairly quick because they don’t understand the benefit or the reasons for it. Jade:  We’ve dealt with some teams recently that have adopted many of the surface?level “Agile practices” but are lacking in the philosophy of that. Agile has become their weapon to use against other people who want things from them. Derek:  I think that’s a good example of when you don’t understand the principles you can’t introspect. You can’t have self?awareness about how effectively you are using them. You can’t improve those things. That’s a big thing. If it’s only a practice that you know or you only know the practice, then it’s only going to take you so far. You can’t ever look and say, “The principle of why I’m doing this is to achieve some end goal or end state or whatever other philosophy.” How could I change my practice or improve my practice or alter it somehow and have a different…? You don’t have that. Roy:  I think the big thing in the practice is that each of these practices when applied, especially initially, cause some amount of pain. If you don’t understand the philosophy of what you are trying to accomplish with the practice, you start altering the practice and minimize the pain. You bastardize the practice to a form where it no longer delivers the value that was originally intended. Derek:  I would say in the example you’re giving that the people having to work with that team or that organization that is adopting those practices are in as much pain as they were before that team adopted those practices. While people could make fun of the practices right now, the reality is people were not happy with the way it worked before those practices came in. If you went to those teams, they’ve seen some benefit internally to themselves. They’ve seen a lot of detriment to themselves as well, but Roy you’re absolutely right. What happens is they adopt the practices at a base level, a cargo?culting level. They get a minor bump in a lot of things that they didn’t have before, but it’s really painful. Then they start to bastardize the practices in ways that violate the principles to reduce the pain. That’s the danger of not having the principles at all. When it gets painful, if you can look back to the principle and say, “Oh, I want to turn the dial back the other direction or change gears in a way that violates the principle,” the principle will tell you, “Don’t do that.” If you don’t understand the principles at all, you end up with these crazy things. It started off with a stand?up that looked great, and it turned into this crazy six?hour meeting three days a week because, whatever was painful. Clayton:  It reminds a lot. I remember taking calculus and, Roy will probably correct me, but we were doing something with differentials or integrals or something where the example… Roy:  Because I’m a math whiz? Clayton:  I don’t know. You know the factorials. [laughter] Clayton:  The examples that we did in homework and in the class, we did literally hundreds of these examples. There was always a boat living in a dock. You have to figure out where the path of the boat will be, and then we take the test. The two things on the test, one was a finance question like price forecasting, and the other one was a physics question. I think everyone was like, “What the fuck?” Roy:  Where’s the boat? Clayton:  There’s no boat. [laughter] Roy:  I can only do calculus for boats. Clayton:  Exactly, right? [laughter] Clayton:  We did all this stuff where we are practicing this thing. Even the variables turned into features of the boat. Then when it got to, “Wow. You can really apply this to anything,” it’s like, “Well, it doesn’t fit the boat requirement.” I feel like that happens a lot. We didn’t understand the principle of what we were actually trying to do. All we understood was the practice of the boat. Peer programming, I think a lot of people that do the practice view it as like two coders writing code together side by side with a keyboard or two keyboards. I think if you understand the principles of maybe why you’re doing that, you can expand that into other things, or maybe there’s not two coders, or maybe there’s people that aren’t doing any code whatsoever but they can still pair on something. Roy:  Absolutely. Jade:  Real quick, looking back on your Agile journey, what do you think was most important to you? The principles or the practices? Clayton:  Like I said at the beginning, I am a principles person by nature, so I would say the principles. Roy:  I think the principles are what attracted me to it but I think the practices are what kept me going long enough to stick with it. Derek:  I think it was the opposite for me where I didn’t know about any of the principles before I started the practices. I was very interested, especially with some of the XP practices, where I only knew them by name and a basic idea of how it was supposed to work. I was very much focused on the how and got very into that. It took me a lot of time before I started caring about the why. I would say the principles over time have become way more important. Jade:  That’s all the time we have for today. Thanks for listening. [music] Announcer 1:  Is there something you’d like to hear in a future episode? Head over to integrumtech.com/podcast where you can suggest a topic or a guest. Announcer 2:  Looking for an easy way to stay up?to?date with the latest news, techniques, and events in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content delivered weekly for free. Announcer 1:  The Agile Weekly Podcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com or subscribe on iTunes. Roy:  Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free. Call 866?244?8656… The post Episode #138 – Principles or Practices appeared first on Integrum.

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 make this decision? You’re letting them do that? I can’t believe that”! Now, not only do I have to feel like maybe my boss doesn’t trust me, but now I have to go deliver that news to a whole group of people to say, “Hey guys, even though I said that this was probably the right thing to do, as it turns out, the Grand Czar does not agree with me.” What does that got to feel like? Clayton:  You lose face with the other people. I know that I told you that it was good, or that we agreed that it was good, but it turns out that it’s not. So either I can play that off as, “The czar guy is a real jerk. Man, what an asshole! I hate that guy too.” Or you would have to just hope that people aren’t thinking, “This person is really stupid. They don’t understand what their boss wants. Man, I’m not going to bother asking their opinion anymore.” Roy:  Right. Even the boss is probably getting frustrated with them. They’re coming back with ideas representing the team. It’s probably not what the boss wants in the first place. They’re never going to think the same way. So this person is probably just getting shit on from both sides. Derek:  So we’ve got the hypothetical. We’ve got some of maybe how it feels to be all of the roles in the hypothetical. How would you go about fixing it? Roy:  In my opinion, if you can figure out some way to have the team earn the Czar’s trust and rid the organization of the Czar, not rid of the person but rid of the role, I think that will go a long way. Somebody who is insistent on all of these best practices, good coding styles, good design, or whatever, they should be going out and championing all of those things and explaining why it’s so important and really convincing people and winning them over rather than telling them what to do. Jade:  A lot of times they do have a lot of really great knowledge and sometimes even some special insight that other people don’t have, but you’re right. They should be going out and helping those other people to gain that skill and also experience things from the other side of the fence. The things that are changing during planning or the real complexities on the ground of dealing with this on the fly, those type of things so that there is some empathy for what the people are going through while they’re out dealing with these situations. But again, it comes back to building trust with those people. You believe that they’re doing the best thing that they can. Roy:  It gets tough though when you set up a system like that in which you’re like, “I’m the one who is going to decide on the design, so Clayton don’t even bother wasting time coming up with designs or whatever.” “Don’t even bother coming up with the method definitions because I’m going to shoot it down and give my own implementation anyway.” Now all of a sudden Clayton hates me, and it’s going to be really difficult for Clayton to earn my trust because he is going to be trying to get away as much as he can to please the people that are breathing down his neck without getting my ire. He is going to be subverting me, which is going to cause me to trust him even less like that’s just going to be a feedback loop. Clayton:  There are definitely cases where people get in this situation like what Jade described like no trust and I don’t think most people would want to be in that, but there are some people who do enjoy the aspect of controlling everything. They want to be the hero and they want to be seen as the smartest guy in the room and all that stuff. I would say that probably is a pretty big component in a lot of these cases compared to the person who really doesn’t want it to be that way all the time, but it’s just like, “Oh, woe is me,” it just happened to be that way. There is some aspect to that. I think unwinding some of that desire for control where they don’t feel like all of their self?worth at their job is based on whether or not they got all the answers right all the time. I think that could go a long way. Derek:  When I look at it, Steve Jobs might be a good example. I didn’t know Steve and I certainly didn’t see him work, but I would… Roy:  Me and old buddy Steve, yeah. Derek:  I think that if I were to… Roy:  I call him Steve. Derek:  …guess how he operated, he trusted his people. Because I don’t think he could get the results he got without trusting them. What he wanted to control was the essence of the spirit of the products that were put out. Not necessarily how they were built and so to me the difference is you come back from a planning meeting and I say, “Oh my God, you’re doing all the stuff wrong and this is how you should have done it.” I don’t think that’s how Steve operated. He probably operated in a “I’m going to let you do whatever and when you show it to me, if it’s crap, I’m going to say it’s crap, but I’m not going to ship that and fuck you go do it right, and when you get it right, we will ship it. Until then, leave me alone, don’t waste my time.” “Why did you call me to this fucking demo that sucks this bad”? What I think is very, very different than saying, “I’m going to tell you exactly how to do every little thing.” I might tell you at the demo to say like “I’m not doing that and I had expected this.” And I think that’s a subtle difference, but that’s very different than trying to control how everybody does their job. Instead of saying here’s the bar of expectation and I’m going to make you live up to that, I’m not going to tell you how to live up to it. Jade:  I think that’s right. Derek:  How do you get somebody to get to the point where they’re allowed to let the essence of what their standard is hold but not have total mistrust. Jade:  I think there are some systemic problems in that as well that that person is probably being held accountable for those decisions by their people. Getting some understanding put in place there is a big help. To help their boss see that like they don’t need to be held to that. They need to be held to the standard of they’re making everyone around them better and helping them achieve that essence and not being a control freak. Because usually it’s people that don’t want to do that. They end up in that situation because of some externality. Derek:  Right, fear usually, they’re afraid of something. Roy:  I wonder if people that are successful at it and managed to climb their way to the top might not be the ones that enjoy it though. Jade:  There are people that enjoy having that control like Clayton said, and those people might not be able to help them. Derek:  All right. See you next month. [music] Announcer:  Is there’s something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest. Looking for an easy way to stay up?to?date with the latest news, techniques, and events in the Agile community? Sign up today at AgileWeekley.com. It’s the best Agile content, delivered weekly for free. The Agile Weekly Podcast is brought to you by Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes. Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free. Call 866?244?8656. The post Episode #137 – Central Control appeared first on Integrum.

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 can’t do that because you didn’t tell us.” In reality, what they do is increase their risk exponentially, because they make it so it becomes almost impossible to deliver what they’re asking for. Jade:  The cognitive load becomes much more to deal with and “grok” all of those additional features when they’re not needed. Derek:  It sounds to me like then you’re going to try to build a system that’s overly architected just in case you have to build any of the number of features you’re told you have to support. Roy:  One thing recently that clarified this a bit more for me was that we had a situation where we wanted to deliver some features that would have been nice to have a database. Having a database was a non?trivial thing, so we used the file?system. We had a table with a row and a column in it. That’s all there was. Derek:  A folder with files in it? Roy:  Yeah. We had a folder with files. That was sufficiently complex for what we wanted to do. I think some people hear that, and they think, “What are you, f?ing crazy? You can’t use the file?system…” [laughter] Roy:  “…Use a database, that’s crazy.” What we understood was, right now, for what we’re trying to do, for this little slice, that’s what we need right now. We acknowledged that that is not a long?term solution, but it’s going to be as long?term as it needs to be for what we want to do with it. Jade:  It was very simple to replace. Roy:  Exactly. Derek:  I think where this started to come and play for me was when we started to cross the chasm, so to speak, in doing a lot more mobile development. So things that we thought were pretty trick and pretty sleek and pretty simple and pretty small started to fall down really quick when a customer would say, “hey by the way, I need an android version or an iPhone version of this.” and I was like, “oh shit, like dude like how in the, man!” And so when it got to the point like “OK, let’s make everything like API and we’ll have the front end consumed of the web version consume that API and hey now we can have the iPhone version.” Jade:  Anything can use this API Derek:  API right like it started to like I think click a little bit more just even in that that you could kind of separate this concerns a little bit better. Then you can start to say “OK how about make perhaps even smaller and smaller,” and keep slicing those so that they are easier and easier to replace, so when you do find something new you might not have to rewrite the whole system to do something. You might be able to rewrite a little piece of the system to do something which is a lot less risk and a lot easier to do. Jade:  That’s kind of where [indecipherable 11:27] and I got into writing these micro?applications that had very discreet functionality. We were having trouble, even with that simplified view of things of just having an API and a web service that was still wasn’t good enough. There was still too much co?mingling of functionality between different classes and you know, the abstractions were good enough. We took a crazy stance and tried to work on like how can we build the smallest possible thing to do this one job, and then chain all of those things together as needed? Roy:  I felt like that worked for those instances I am curious to try more places and see how well it runs across the board. In that case it was a project that only ended up being a collection of five or six of these smaller apps, but when you start to build a more complex user experience where you have a whole store form or something where the user [indecipherable 12:24] component you try to keep all of those pieces separate. I wonder how well that’s going to play together. Clayton:  I feel pretty confident in it from the next example like; pick any five UNIX commands. It could probably do a bunch of stuff. If you chose wisely. Derek:  Yeah, It does fall down at certain point though. What I mean by that is, there’s a whole lot of things people do, they don’t do with Unix commands any more. You could use “set OK” and “grip” to do a whole lot of things. Jade:  Everything Derrck:  But you probably open up “vi” or “sublime” to do it instead because the interface is easier even though its [indecipherable 13:00] all mashed into an application than a whole lot more than those simple things. I think there are this kind of. It is nice to assemble them small?ly. Into small little apps that interact but when you have to chain too many interactions together, the complexity of remembering what and how to chain things starts to become cumbersome. Clayton:  That and when there’s like a whole bunch of apps that you don’t even know existed. Roy:  Yeah Clayton:  So you start rewriting them yourself Derek:  Yeah. What tends to happen is when you have things that have common things you start to see those assembled into other apps. I would say that OK and grip get used within most editors the developers use today. Because they make sense to kind of bundle natively into an editor rather than a drop out to a shell and do them. I think the work that those things did and put in place are straight up stolen and re?used inside of those editors. Jade:  It’s like when we talked about, we built a simple app but at some point it became too complicated. It was simpler to take a different approach of writing smaller, more complicated apps. Think this is the contrary example of at some point that becomes absurd. The interactions are too complicated. Derek:  Right. Jade:  Now you find a simpler way to merge those things together. Derek:  It goes back to; it’s always easier to get more complex. If we’ve got the set the OK, the grip, and we need to put them all together like we know those things really well now and so we know how to assemble them into an interface or into certain things a lot better than if we would have tried to build those things as part of the bigger complicated thing to start with. Jade:  I think that’s where some of the ideas around, like hexagonal design can come into play. Where you’re composing complex systems out of simpler modules and simpler pieces. Clayton:  We’ve been talking a lot about in terms of software, but this same stuff applies to process things. You can take the components and do them very well and you can build some sort of process that works and maybe it gets too big sometimes or maybe you decompose or whatever, but it’s not just whole scale, you know. From a coding example, jumping straight into some massive java architecture thing and that’s the same thing as like what you’re going to get on the juror train and see if this mother app… [laughter] Clayton:  …Or it’s like trying to get a good user story. I am like “let’s try and get good at talking to each other as a team first.” Derek:  Let’s get good at working together. Jade:  Yeah, let’s try those things first and then you know, you can juror me to death. Roy:  Hey I will see you next month [music] Presenter 1:  Is there something you would like to hear in the future episodes, head over to inagram.com/podcasts or you can suggest a topic or guest. Presenter 2:  Looking for an easy way to stay up to date with the latest news, techniques and events in the agile community? Sign up today at agileweekly.com. It’s the best agile?content delivered weekly for free. The agile weekly podcast is brought to you by inagram technologies and recorded in gangplank studios in Chandler, Arizona. For old episodes check out inagramtech.com or subscribe on iTunes. Presenter 3:  Need help with your agile transition? Have a question and need to phone a friend? Try calling the agile hotline. It’s free, call 866?2448656. The post Episode #136 – Simple appeared first on Integrum.

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 conversation. If it started out as a conversation then it would stay a conversation longer. The second it goes into the tool, it’s just like tractable task. I think that’s how they get treated, like, “Do the task.” The person doing the work, especially if it was command and control and other “doing agile,” they’re just being told what to do. They don’t even think about it. They might say that this seems dumb, I don’t know why I’m doing this. I did this four times last week, we probably shouldn’t do it again. But “Whatever, it’s a ticket in my queue I got to do it.” Jade:  Imagine, we’ve started with great intentions. We really cared about agility and somehow it’s evolved in ticket?driven agile inside the organization. How do you change it? How do you escape that? If you’re in an organization at some scale… Derek:  Throw the tool away immediately. Stop relying on the tool. That’s the easiest way to force you to deal with those issues. Usually, what people say is, “There’s no way we can scale if we don’t have like this.” If you have more demand coming in you, then your throughput can handle. That’s the real problem not the tool. If you say, “We can just put it down in a quick little spreadsheet or something that’s real basic, a piece of paper or something.” The minute that you have more stuff to do than fits on the back of your neck and to?do list, that’s probably a pretty reasonable smell that you’ve got other problems other than the tool. That you’ve got a team that can’t work fast enough for the demand that’s being created by them. What can you start to do to fix that problem? Clayton:  It’s like if someone wants to start eating healthy. The easiest thing is if you just say, only eat things that are whole foods, that came out of the ground looking like that. Or not processed. If I want a pizza, and I had to make that from things that were whole foods, that’s a lot of effort and work. Jade:  What if I go to Whole Foods? [laughs] Clayton:  OK. Go to Whole Foods…No. If I want that stuff, and I had to make it all myself, that would really suck. I would think, maybe there’s some other way I could get this craving for what I have. Every time I told someone, “submit a ticket,” I actually had to write a card and put it on a board and look at it all the time? I would be like, crap, is there some other way we could not put this stuff on the board? Which I think the ideas of, maybe someone else could do this work. Or, I don’t know, is there some way we could automate this? Or more than one person looking at it at the same time. Like, oh hey, I did that last week. I have a script for it that I have never told anyone about. Because I don’t talk to anyone, ever. Derek:  The other thing is that it forces you to deal with the truths that are there, that you want to lie about. If we’ve got a product that’s say, really shitty. A whole bunch of defects are getting submitted all the time, and that’s what people are coming to us with. We’re saying, just throw it in the ticket. Just throw it in the ticket. We don’t have to experience any of that pain. Even if the pain is simply having to write it down and put it on a board, or do something. We can tell ourselves a lie of, “Our product’s really not that bad. It doesn’t really have that many problems.” Because, basically, we’re just throwing everything in the corner. Nobody goes in that closet where everything’s being thrown except for one person, who’s the person that opens the closet and takes stuff out and throws it at the developers to do. Where if you start to expose that, you start to go, I don’t like living in this filth. This filth sucks. Why are we adding new features, why don’t we clean some of this filth up? It starts to expose some of that. Jade:  I know we’ve covered this in other podcasts. What does the ideal look like? If we want to get away from this, we’re moving toward something that is more about agility and less about Agile Tools. What does that look and feel like? If we’re in a company of 1,000 people, how do people work together? How does cross?team collaboration work? Derek:  In a product you have end?to?end ownership. Again, one of the big reasons you have a whole lot of this ticketing, throwing back and forth, is you’ve got a product that spans multiple teams, instead of having the product be succinct enough that a single team can own everything from end?to?end. When you get end?to?end ownership on a product, that prevents a lot of, “I have to hand part of my product off to you, everything I do.” That minimizes it. If you have more of a zero defect type of mentality that says, we consume the trash as soon as it comes in. As soon as we eat a meal and we have a wrapper, we throw it in the trash. We don’t throw it in the corner and then someday later take out the trash. That starts to minimize that process. If you do those two things, that goes a long way. You still are going to have to deal with other teams in a big organization. If you can be more API?driven in those interactions instead of a monolithic, your code depends too much on my code but we can do APIs or versioned APIs. Are those things that helps made it so that you don’t have as much of the ticket request type of behavior happening. Your design is more contained to a product team, and there’s just some communication about hey, what does this thing look like, and we can do it? The problem is, most organizations don’t have any of those things to start with. My question would be how do you start to get those things into organizations? Jake:  Another big part of it is the prioritization thing. Priority stuff is always so hard. Everyone has such a hang?up about it. If you had some better way to make more sane choices when you were doing prioritizations so that it wasn’t based on politics, or something negative like that. It was more based on what’s the shortest quickest thing we can do to get some feedback, or whatever the case is. Or based on something the customer said. Getting that stuff figured out, I know, is very difficult. I think everyone I’ve ever worked with that had anything to do with prioritization always had a really hard time with it. I think that goes a long way. The concept, like Derek mentioned, of having smaller teams. Where I think right now, there’s lots of big organizations where no one…If I were a developer on a team that was working with something, and I was dependent on another team. The idea of maybe me and someone else on the team approaching two other people on this team and spending some time coming up with some solution together in a collaborative sense, and contributing that back to both projects? When you live in the ticket?driven Agile world, you don’t do that because it’s not a ticket. It’s not how you do it. Derek:  Our sprints aren’t in sync, how could we do that? Jake:  Yeah, exactly. Jade:  We’re really talking about following Conway’s law. We’re talking about reducing unnecessary communication pathways, streamlining everything, and reducing dependencies, so that the product reflects our communication. Derek:  Yeah. I think a heavy amount of autonomy is in there. A team could go to another team and say, hey, can we bear on this? Even though we’re not on the same team, let’s do this. We get too rigid in our process. Then that would prevent it. I’d like to do that with you, but I’m in the middle of sprint. Your sprint starts are different from our sprint. Not possible. We have to schedule it four weeks ahead of time. The other thing that you said that really resonated for me is most companies that have this problem are not close enough to their customers. When you have trouble prioritizing, what that means to me is you do not have a connection with your customer. Or you’re absolutely guessing what your customer wants. If you’re close to your customer and are actually listening to them, you probably have a much better idea of what your priority is. Jade:  Great. Thanks for listening to the Agile Weekly Podcast. We’ll get you next time. [music] Announcer:  Is there’s something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest. Looking for an easy way to stay up?to?date with the latest news, techniques, and events in the Agile community? Sign up today at AgileWeekley.com. It’s the best Agile content, delivered weekly for free. The Agile Weekly Podcast is brought to you by Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes. Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free. Call 866?244?8656. The post Episode #135 – Ticket Driven Agile appeared first on Integrum.

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 opportunity to change everything.” For whatever reason, they’re unhappy with what the status quo is, and they want to change everything. I agree. It seems reckless. I’m not sure where we’re going, but we’re not here anymore. Jade:  We’re not stopping to find out. Clayton:  Yeah, exactly. We’re going as fast as we can. Roy:  Doesn’t that sound fun? Jade:  Sometimes, maybe. Roy:  You don’t know where you’re going to end up, that sounds like a great time. Clayton:  Yeah, I guess it depends where you end up. Roy:  No, it doesn’t. It’s not about the destination. It’s about how you get there. Clayton:  I would have a lot of fun going on some adventure, but then if we ended up in the middle of nowhere, I’d be like, “Hmm. The honeymoon’s over, I don’t want to be in the middle of nowhere any more.” Jade:  Yeah, I’m the same. Roy:  That makes you lame. [laughter] Jade:  We have an interesting mix on our little group. Derek’s not here with us tonight, but Roy and Derek are much more on the aggressive side. I’m definitely on the more conservative side. I think you’re there with me, too, Clayton. Clayton:  I would say I’m more concerned about I want to go somewhere. I’d go on an adventure, as long as it’s the one I want to go on. Roy:  I’m the exact opposite. Your thing of, “I don’t know where I’m going to end up, but if I end up in the middle of nowhere, I’m going to be upset,” that’s every weekend for me and I’m not upset. Clayton:  Right, that is true. Jade:  Then we’ve had some good experience in our past of changing rapidly, trying new things, doing things. Why does it work for us? Clayton:  There is something about the fact that we really actually believe in iterative approach to things beyond building software. You had started out by saying we’re OK with changing because we know that’s not the end state. It’s just the next thing and it will help us change faster. I think that’s a big part of it. Also, the fact that we’re willing to call a duck a duck and say, “Hey, look, we tried this thing and it failed. That doesn’t mean we’re failures.” Maybe the actions we took or the outcome we had was a failure. It wasn’t what we expected or what we wanted, but that’s OK. Let’s try a new thing. Those are two things that have made it much easier for us to be successful, but I would argue that maybe starting out early on, it was super painful, probably had a lot of fallout and wasn’t as successful as maybe we remember it, so. Jade:  I remember the early days being terrible, going home so frustrated and upset every might. Yeah, it definitely wasn’t an overnight thing that happened. It took years for us to get to that point. Clayton:  I would say also, having multiple perspectives. Coaching a client that is going slow and watching it unfold at a certain pace, maybe a pace that you’ve already spent a lot of time going, it’s much easier to see it happen. To them, it’s happening at 80 miles an hour, but we’re watching it at 8 miles an hour and so it seems like a slow?mo. Roy:  I’ve seen this racecourse. I know every turn. Let’s beat this up and get to the end. Clayton:  Well even if from a cooking perspective, you’re not really concerned about getting to the end, but you are interested. At least you have different perspectives on, “There’s this corner coming up. How are they going to handle that? I remember that and I remember it being precarious.” Roy:  It doesn’t strike me as, “Nobody cares, get over there.” Clayton:  Yeah. Jade:  How would we help people who have realized that they need some level of change in their organization at some part of their organization? How are we going to help them find that right speed that they need to be going, not too fast, not too slow, being effective, but not reckless? Clayton:  I think there’s just course correction that probably has to happen. I don’t think that you’re ever going to get it right. It’s really hard to dial it in the first go. Roy:  It’s really hard to dial it in on any go. Clayton:  Right, so I would say chances are, if things seem like they’re going well, then maybe that means you’re going too slow. If things start feeling like they’re totally out of control, maybe you need to slow down a little bit. There’s probably something. A big component is probably just having the self?awareness of, “Am I being afraid or is this actually working?” Or, “Am I out of my comfort zone or am I just telling myself that?” Roy:  I think it’s like that, being wary of and aware of the idea of recoil, as well. Like that feeling you get when things are going successful and it’s almost creepily successful, where you want to back off because all of a sudden… Jade:  You start becoming negative about it, just because something in you is forcing you to deny it that it’s happening. Roy:  It’s almost like emotionally hedging your bet in case it doesn’t actually end up being as successful as you think it is. Jade:  Yeah, I’ve seen that a lot. We still do that a lot. Clayton:  I would say, for me, a phrase that I had read a long time ago that I like is, “If you want something that you don’t have, go do something that you haven’t done before.” If I want some outcome where I think that my organization needs to change and this is the way we need to go, I probably can’t do that if I’m going to do the same thing I’ve always been doing. I’m going to have to do something different. Chances are that something different means being uncomfortable to some degree. My rule of thumb is, I know I’m not improving or excelling, or maybe going as fast as I know I should be, if I’m not uncomfortable. If I’m pretty comfortable every day, going into the office kind of thing, I’m probably not getting any better. That’s like a self?awareness check of, “Am I uncomfortable today? No, not really.” Jade:  I think one of the key ingredients is getting a small group of people who trust each other, who have different perspectives to be able to work together. That’s one thing that’s worked very well for us is, we are very different and we look at things differently. When things are happening, we’re all bringing a different way of perceiving what’s happening to the table. Then we can argue and yell at each other, and get passionate and emotional about those things, but it’s not personal because we trust each other. We know that we’re trying to do something together, something better. Ultimately, the best ideas tend to surface out of that, because it’s not just one person’s idea or perspective that is being dictated out to everybody else. That’s a key ingredient, finding that right speed. We can meter ourselves because some people are going to be pulling, some people are going to be pushing, some people are going to be holding back. We’ll find that right speed as we go. Clayton:  I agree with that. Roy:  Cool. Yeah. Jade:  All right, well, thanks for listening. We’ll catch you next time on the “Agile Weekly Podcast.” [music] Jade:  If there’s something you’d like to hear in a future episode, head over to integrumtech.com/podcast, where you can suggest a topic or a guest. Looking for a way to stay up to date with the latest news, techniques in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content, delivered weekly, for free. The “Agile Weekly Podcast” is brought to you by Integrum Technologies and recorded in Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com or subscribe on iTunes. Announcer:  Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile hotline. It’s free. Call 866?244?8656. The post Episode #133 – Changing too fast or too slow appeared first on Integrum.

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 surprised. Clayton:  That’s kind of like a “By the way…” Derek:  By the way, don’t be surprised, I ate your lunch. Clayton:  I’m trying to think of other scenarios. I think Derek you mentioned the team scenario about not surprising other people on the team by doing your hero power coding session. The more I thought about it, and I think talking to other people on the team, the no surprises thing really does have a lot of…Doing some action that impacts a lot of people and has ripple effects, when you think about no surprises in that context, you really have to be strategic about thinking about all the different people. That might be, like you said, your boss. I might go make this person upset and they go complain to somebody. I think we’ve had a discussion about not wanting to flood the inbox of your boss with a whole bunch of useless messages, but you wanted to make sure at least that if they couldn’t know ahead of time, at least they knew at the same time as someone else. That kind of thing. Derek:  I think, there’s a couple of key principles or philosophies around this. One of the things is A, if you really believe that surprises are bad and hurt you, you have to put yourself in full disclosure mode all the time. It becomes like your natural behavior starts to become to disclose what you’re doing to the people that are around you on a regular basis. So that by default, you know you’re not surprising people. If you have to sit there and think every time I do something, “Should I disclose this to other people? May they be pissed off”? You are going to fuck up a whole lot and always be surprising people. If instead, your default behavior is, “I’m doing this. I don’t care,” this time I’m surprising them. Jade:  That’s broadcasting your intentions. Derek:  Broadcast intentions a lot. The other part of that is if you want to be in that type of culture you have to be OK with saying, I am OK with having a flood of broadcast of intentions coming at me. And I will filter what I think is important. If I’m the boss, I work in a non?profit organization where one of the defaults are, I would rather you include me on a mail so that I never surprised by any of this non?profit works with a ton of mayors and council members and people of influence. I never want to go to a dinner party or a mixer, and have somebody of influence come up to me, and ask me something and me go I have no idea of what you’re talking about. I ask Executive Director, please include me on anything that you think will impact me. I would come up as something like this. I would choose the whether it’s important to me or not. I’m not going to respond to it. I’m not going to say yes or no. I’m not asking you to ask for permission to do anything. I just want to be informed of what’s going on around me so I don’t look stupid. I think good bosses and leaders are OK with that. Go ahead send it to me. If I don’t like it, I’ll just start devnulling what I don’t care about. When I’m mad at you, I can go back and go, I can’t really be mad at you because you let me know about that. But that’s a huge cultural shift to do those kinds of things. Jade:  It really leads to very thoughtful, intentional action. You really aren’t acting off the cuff. You’re being considerate and thoughtful before you take any sort of action. How does that slow things down or speed things up? How does that affect how the team might accomplish its goals? Clayton:  I would say that in theory you wouldn’t necessarily be slowed down because you’re not saying that you’re not going to do things just because someone might say no, or be upset, or not want you to. I think you are probably saving yourself a lot of grief and probably future time in having to deal with the fall out of not being transparent in broadcasting your intent. There might be times you get away with it. You might be able to do something and no one’s going to listen and its all fine. Maybe, the 1 out of 10 times that you get caught will slow you down way more. You lose all the trust. Now you have to be so explicit in the future. I think that you take so many steps back when you do that. Derek:  I think of it like this “karma bank.” There’s this trust bank or vulnerability bank so all of the times that I am spinning effort and doing that, the one time that I forget and I do surprise somebody. If I got a whole bunch of currency over here in the saved column, it buys me a whole heck of a lot. If all the time you’re disclosing stuff and for once, you don’t, I’m like, “Oh man, we’re in the heat of the moment, I totally forgot to say it.” It’s a heck of lot easy for me not to have horrible intentions about what it was because I know the… Jade:  I can assume it’s an honest mistake. Derek:  Yeah. We were all human and stuff happens. The one time that you’re able to cash that in is almost invaluable in terms of time wasted. I guess, you said, Clayton ?? we’re not having to do damage control. We’re not having do all of this. We’re not having to have a meeting ?? to have a meeting, to have an action meeting. The first time you have to call 10 people and a team or an organization on a room to review something because somebody was surprised, you probably made up for that instantly the first time you don’t have to have one of those meetings. Jade:  We talked about the perfect boss. How does the perfect teammate work in this type of no surprises idea? Derek:  It goes back to perfect teammate to me discloses when they think it’s going to impact people in meaningful ways. Clayton:  Meaning broadcasting your intention and being mindful of not surprising. Jade:  So not just externally to other people but internally to your team? Clayton:  Yeah. I think you have more touch points on the team. I would rather fill up my marble jar, karma bank for people on the team. Like us probably something I want to focus on more than external people. Those are the people that I’m going to be working with every day and I have to have alignment with. Trust for me on the people on the team was probably more valuable in a long run. It helps me more successful than some random people in the organization. Derek:  I would also say that the depth of impact should be equal to the depth of broadcast. There’s something like nobody’s going to be really ticked off about this and Clayton and I are only two in the room, I might say, “Hey Clayton, I’m going to do this and that’s fine.” If Jade found out about it and he wasn’t there, he’s not going to be too pissed off that he didn’t know about it because the impact wasn’t a default. If it’s something really impactful then I should make sure that I broadcast it to everybody. I think your signal should be equal to the impact that it will have around the people that are doing it. Jade:  That’s great. With that, that wraps it up for today. Thanks for listening. We’ll catch you next time. The post Episode #132 – No Surprises! appeared first on Integrum.

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 said, but what we’re doing is now we’re moving the accountability to you. Now once the accountability is yours, the problem is, now you’re going to want to control more and more things, because you’re the one that’s going to be held responsible when somebody comes to Jade and I, we go, “It’s not our fault. Roy’s the one who told us…” Roy:  I’m incentivized to start micromanaging the crap out of you guys, because now I’m on the hook. Derek:  If you flatten that structure, or eliminate some of that authority chain, it takes away the human nature to try to push the accountability to somebody else. Jade:  That’s the flip side of the coin for autonomous teams, is, they are highly accountable teams. Derek:  That is correct. Roy:  That forces you guys, in the hypothetical scenario, you guys would be forced to make better decisions because you are being held responsible for it. You cannot just…even though you think something is the right, thing like you might chose not to do it. Like characterization. Derek:  It at least gives us the opportunity to make better decision. Jade:  You might be still dumb on purpose [crosstalk] Jade:  Well that’s your problem. Derek:  It’s hard not to care anymore because whatever the result it we are responsible for that so even if we are not super passionate about it whatever it is we are doing we probably care about what the result is because there is something else that we care about, like I do. If I need to bring a pay check home to pay my mortgage I care about that I get a pay check so maybe I am not super passionate about this particular thing but I am passionate about pay check. I can no longer just say “I don’t really care”. The day if it goes wrong Roy is going to get fired not me and know if it goes wrong I have got to start to care about this thing at a different level. Jade:  So the simple definition of autonomy is self?governance within a limit. What does it look like in an organization made up of autonomous teams? How does that even function? Derek:  How does it scale? Jade:  Yeah. I didn’t say that how does it function? Roy:  When you have more than one autonomous team Derek:  Some of it depends on how much of these teams need to interact with each other right I mean I think where we have seen it go fairly well is when they are able to break them down kind of by product so you have got some product and it’s you know something where you can get a result available. If I am going to go bring on this product I can kind of own the resorts for whether this product is well or not and so I should be given a fairly high level of autonomy on things that pertain directly to the product I am working on, right, because I should own that resort as much as possible. Jade:  Sure Derek:  But then there are other parts systems other parts of the organization that I probably don’t have a ton of autonomy on because I don’t really own the resources but I should probably have influence or have some ability to interact with that. Roy:  So in the past we have talked about the importance of members of the team being aligned with each other, I think in this case you refer two teams to work effectively, they must also have some form of alignment where they are headed in the same direction. If were to compete products it going to be pretty difficult to get us to cooperate but if we are trying to make both each other better it will be a lot easier. Derek:  Yeah. I tend to say to me the answer is probably leadership and culture. If you have got strong leadership in an organization and they can set the vision and the direction and the alignment and get all of the teams to align to them and have influence to them, which is not the same as control, or micromanaging everything teams do. Instead, say we are team for this goal so everything you should be doing you should be moving that ball forward in some way. Should be helping us achieve that vision and I think from a culture perspective that kind of sets tone for behavior. Right, if we say our culture is kind of manifestation of behaviors within an organization good leadership should be trying to model the culture that they want to have exist. Right, people have an aligned culture and aligned vision and it should be pretty easy to talk to each other. [Background noises] Jade:  What we recommend for a team that finds itself in this challenge they have realized that there lack of autonomy is preventing them from being as successful as they could be what do they do? Roy:  The first thing that the team starts doing is as a team start taking responsibility for their behavior as a team. As soon as you start taking responsibility that’s when you start building trust and more trust you gain the more autonomy you are going to be given. Derek:  Yeah definitely. You get results by doing what you say you are going to do. I think the second thing I would really encourage is look at the vision of the company and look at the culture of the company is trying to put forward and see if you can start to align to that. The other big one is find somebody to give you support or to help you write so whether that be the direct boss of the current team or whether that be the boss’s boss or whether that be lateral boss. Somebody who can help camp you in, when you run on the things you know. If you do the things you are going to do you can probably do some of that without necessarily a ton of autonomy. Jade Sure Derek:  Somebody else said what I am going to do actually to get it done, I build some good reporteir… Roy:  Earn autonomy that way Derek:  So I earn the ability to say “Will you take a risk on me on this on this next thing I have idea and I know it is really hard for you to support it but I have done everything that I said I am going to do and I have been getting results with it. Would you entertain letting me do this giving me an hour, two hours a week?” Jade:  Sure Derek:  …Something to do that. Then, it’s also building that relationship little bit up the food chain say like “Hey, this is what I am trying to do and I think this is really getting some of that support.” So when you start to hit those road blocks, you have somebody can say “Hey, you should give them a try, you really should.” You know maybe let this happen. “Hey I have done that.” So its building those relationships too. Roy:  I don’t want to say be careful, but I was going to say something along the lines of beware that there are tons of companies that are that have a stated company culture that nobody in the company lives and if you truly try to live by the companies stated culture you’re going to rub almost everybody the wrong way, even all the way to the top and have a huge amount of problems. If you feel like that’s the right thing to do you should absolutely do it but there might be consequences. Derek:  If you are trying to hit those things the nice thing is that you can ask, “Hey I am just trying and do what the value said. ” Or “Hey, I am just trying to achieve this vision.” If that cascades up usually middle man does not like that very much but the higher you get those people really do want those values. It might be hard for them to do them as well but they do want to see them. Jade:  It would be hard for them to digest your tactics. [crosstalk] Derek:  You might be willing to take it further than they imagine possible. Jade:  Well that’s all the time we have for today. We will catch you next time on agility podcast. [music] Presenter 1:  If there is something you would like to hear in future episodes get logged into future .com/podcast or where you can suggest a topic or guest looking for an easy way to stay up to date with latest news techniques and events in the agile community, sign up today at agileweekly.com. It’s the best agile content delivered weekly for free. The agile weekly podcast is brought to you by Integrum technologies and recorded in game plank studios in channel Arizona. For all the episodes check out integrumtech.com or subscribe on iTunes. Presenter 2:  Need help with your agile transition, have a question and need to phone a friend try calling the agile hotline. It’s free. Call 866?244?865?6.   The post Episode #131 – Autonomy, autonomy, autonomy. appeared first on Integrum.

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. It’s not necessarily trying to say we need a role, a title, somebody to own this and nobody else can do it. Roy:  In some cases, there are though. Alan:  Yes because we twist that. Roy:  Right, exactly. The product owner is often times called the “single ring of a neck.” Right? Alan:  Right, which I don’t agree with. Derek:  I think some of that is like a Dreyfus model type of problem. Like you said, most software development teams, especially 10 years ago, didn’t have the concept of a product person. Didn’t have the concept to someone hoping and deal with organization on impediments or impediments outside of the team. Scrum was very prescriptive and said, “Hey, every high?performing team we’ve seen has people that do these things.” We should probably say that every team should have this behavior happening in it. The easiest way to do that in introducing that the corporate America is say make a job title around it that you can fill the position then it will guaranteed that somebody will get it done. Roy:  I think that’s an important part of why those exist too is that there’s a whole existing workforce of people that filled similar roles in the old organization that now need a new roles. Just provide an easy way to slide them over horizontally to like, “OK. You used to be a product manager, now you’re a product owner. You used to be a whatever, now you’re a scrum master.” Derek:  And as you see teams evolve that adapt say strict scrum and have those roles, over time they start to realize that those roles don’t make a ton of sense. Some of this is their organization starts to evolve, developers become more in?tuned to doing product work and it’s not just about development. And an organization has less impediments, because they are learning how to organize in ways that have less road blocks. So you start to see those maybe dissolve its roles and just become traits of teams. The teams have a trait that they know how to do a product, and the teams have trait that they know how to get rid of impediments. It’s not a one person’s job to do these things. Alan:  I think it’s fabulous. The concept of a cross?functional team is what helps to dissolve those boundaries. Even if we have a traditionally siloed organization and traditionally “I am always a tester and will never be anything else.” Once you tell me, and require me, to work a year with people with other skills, if I truly am working with them every day, and we’re doing stories that are focused on the user instead of focused on technical tasks. Now, suddenly by the end of that year, I am familiar with other skills, I am familiar with how other things work and I begin to break down those barriers. Roy:  It’s interesting though, because people at first have very much difficulty with the concept of being cross?functional in a technical sense, so the same person touches a database, touches the front?end, touches the back?end, touches the UI that the user sees… Jade:  It’s with the customers… Roy:  …and does testing. But doesn’t meet with the customers. [laughter] Roy:  People are OK with that first jump and even that’s a big jump for them, but then to make the jump from “OK, now I’m cross?functional technically, but I’m going to jump out of my technical comfort zone and into the murky area of dealing with customers and thinking about product.” People are not ready for that, most people are not very willing to make that jump, by themselves. Clayton:  One thing I think it’s interesting is with teams that have been doing Scrum for a while maybe they would have started with of prescriptive approach of “We have this one person and they are the Scrum Master, they do the Scrum Master things.” Over time they usually ?? not for the right reasons ?? but they will start blending those roles and be “Well, let the Scrum Master allowed to go do some other thing and we didn’t really want to hire someone else because it’s hard to justify that job now, the lead developer, they’re kind of the Scrum Master too and they just do both things”. Under the guise of “Oh, the roles aren’t really important” they just blend all that stuff together and you end up with a bad experience, where you don’t get great outcomes because you don’t have somebody that is dedicated to doing certain things. Usually those teams are mature enough to make that choice, and that’s immature teams usually don’t make that choice, but that’s something that I’ve seen on some teams that maybe would consider themselves a little bit more mature from an Agile perspectives is that they’re blending all that stuff together, as if roles don’t mean anything. Alan:  If you blend too soon you become…It’s Scrum Master the role that gets blended the most, right? Clayton:  Yeah. Alan:  I certainly can agree that certain mature teams, high?performing teams, can get to a point where they don’t need a Scrum Master because all of them are so good, are looking for improvements, and they just do it as a team. That’s great, but so often teams go four months, five months and they say, “We’re under pressure now, so the Scrum Master used to be a developer, he’ll just start writing code.” In that focus, and I like to talk about it as focus as opposed to saying “This is your role at the team you have to do,” that focus on improvement, it gets diluted and… [crosstalk] Roy:  “We don’t have time to get better, we got to deliver now.” Alan:  One of the things that I’ve seen done with teams, and I haven’t done it yet, I’m very anxious to do it again with another team, is where…I’m a big fan of teamwork agreements but I’ve seen it done where you get down to a team member agreements. In other words the product owner has a priority of the things that he can do, the things that he agrees to do, and so when something outside of the product owner role and a product owner thing compete with each other, he has a priority of how to choose which action he should take. That keeps him in focus in that role. Roy:  I like the idea of a team being properly aligned in a direction and anybody stepping up into that product role, so there isn’t one guy whose number one priority is product. There may be a guy who has the most experience in it, he might be the guy to go to for help first, but you pull a task off the board and you go and do it. You don’t save it for the product guy because he happens to be better at it. Jade:  If you’re putting together a brand new team and you had your choice of how to organize it, how to assemble it, how would you do this? How would you lay out the roles and responsibilities? Alan:  It would be something that the team builds together themselves. Each of the team members, even when they’re starting out anew, each one knows where the strengths are and where there are not. They’ll have to build it together, the same way they would build a teamwork agreement together, where we expect a user acceptance testing. These people will attend that and there’s different things to do that they could help to find each other and figure out where the roles are, so they don’t neglect one or another of the focuses that they should have. Focus on product, focus on improvement. Clayton:  All right, on that note I think we are all out of time. Thanks. Alan:  Thank you. [music] Announcer:  If there’s something you’d like to hear in a future episode, head over to integrumtech.com/podcast where you can suggest a topic or a guest. Looking for an easy way to stay up to date with the latest news, techniques and events in the Agile community? Sign up today at agileweekly.com, it’s the best Agile content delivered weekly, for free. The Agile Weekly Podcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For old episodes check out integrumtech.com or subscribe on iTunes. Need help with you Agile transition? Have a question and need to phone a friend? Try calling the Agile hotline, it’s free. Call 866?244?8656. The post Episode #130 – Roles, huh, yeah. What are they good for? appeared first on Integrum.

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 you walk.” That that is something that exposes very quickly when you get small teams. It is so hard to hide when you’re on a team of five people. Clayton:  Yeah, with the 10?person team, that 1 person, their negative impact, I think, relatively speaking, is the drop in the ocean. But when you’re half the team…when you’re one?fourth of the team and you have a negative impact, you could do half a day’s work that is bad, and that really impacts everybody. You can’t avoid that anymore. Derek:  And we tell lies to ourselves. If we’ve got 10 people, and we’ve got some work to do, and it’s like, “Technically, Clayton really can’t do anything [inaudible 08:56] .” But we’ve got this stuff that none of us really want to do, so we can dump it on…maybe we’ve got some manual tasks we need to do, or maybe we need to do whatever. “So we’ll keep you around even though, push comes to shove, we don’t even count your capacity in what we’re doing, but we know we can give you some stuff we don’t want to do.” When it’s four people and its, “You have to do four people’s worth of work,” you can’t go, “But, Clayton doesn’t count. It’s only the three of us.” Roy:  That’s part of the problem though, is if you have a team that isn’t lazy enough. Because I’ve worked on a team where, I think there were four or five people on there, and we did it…that exact thing happened a lot because the team wasn’t lazy enough to automate all of that stuff. They never got around to it because they could just always give it…it was actually easier for them not to automate it, because it gave the fifth team member something to do. That cycle just kept going over, there was no reason to ever automate, there was no reason to ever [inaudible 09:51] this guy up. Clayton:  Pro?tip, if your team’s slack is the same number as your capacity… [laughter] Clayton:  …there might be a problem. Derek:  I think there was probably other issues going on there. My point is that it becomes a lot harder to hide that. If you’re doing your capacity?based planning, and you’ve got 400 hours, and you’re only hiding 20 hours, you could explain away that slack pretty easily. If you’ve only got 80 hours, and you’ve got 20 hours of slack in the way, I think pretty quick the product owners will go “Man, that seems like an awful lot of time for the amount of people here.” It becomes much more difficult to explain that away. Jade:  We’re saying that 10?person teams are a little large for us. I think that’s a radically small team size for a lot of people, to say 10 people, and we’re saying “That’s too big.” How do people deal with this if they’re in large organizations with pretty large teams, what do they do to start changing the way that their teams operate to get more lean and mean, to get more exposure, to get all these things that we’re talking about. Roy:  I think it has to start with modeling view on in yourself. Start off by saying “I’m going to go do X over here, whoever is interested is welcome to join me.” If all 30, 40, whatever people in your team join you, that’s great, then you can immediately say “Now I’m going to go B,” whatever, and keep doing that until enough people drop off that you have a reasonable?sized team. Derek:  One thing that happens a lot is that people do everything by project. Everything is matrixed, everybody is a resource, everybody sliced 10,000 ways from Sunday and you’ve got 6,000 projects that you’re doing. One of the things that you can do is start to say, from a from functional perspective, “What products do we really offer”? Or “What services do we really offer”? And get those narrowed down as probably not to 6,000 projects that you have. You probably have a much more finite number of actual projects. Then you can start to say “OK, we’ve got 30 projects and we’ve got 100 people, how do we start to break that down”? You can even start to say, if the teams are still a little too big, if you divide that number and it’s still 20 people per product, you’re going to start to say “Can we slice that product even smaller”? Amazon probably did this pass. You’ve got this nice commerce shop going on, at some point it gets too big and they say “How can we split it? What if we had all the server provisioning and management, what if that was a different team”? That became a new product called the EC2. What if your provisioning managing team starts to get too big? We’re going to take the storage part of that and that’s going to be a new product called S3. Can you take a product and can you look at it, can you slice it in a different way? Maybe you can’t do it as a full?on product that’s consumable by somebody else, but maybe you’re able to do it as a component of a product. Maybe you’re ebaying and you say “Our search bar is kind of like its own little product.” So that’s going to be a component that’s got its own team. All they do is continue to optimize and refine, make the search component really awesome and provide API to iPhone clients and other things to make searching really well. If you can start to do that, then it becomes easier and easier, and you can start by saying “Maybe we go from 30?person teams, or 50?person teams, to 10?person teams” and then maybe go from 10?person teams to 8. You don’t have to make that jump all at once, you can make it in chunks. Jade:  What I hear you saying is really Conway’s Law is going to kick in here and the products that you develop are going to be a reflection of those communication paths. You’re going to get smaller simpler tools and products and things like that, that will build on each other to build a more complex organization and a more complex set of products. Derek:  It makes you much more adaptable. What starts to happen is, if you have smaller products, you have the UNIX mentality where you start to say “We’re going to do everything via APIs, we’re going to do everything where the products [inaudible 13:42] to something really, really good and then it will take inputs from other places and it will provide outputs to other places. Once all of your products start to line up and start to do that, it becomes easier and easier to fracture projects, or a product. If you’ve got a product and you split it in two and everything is an API, it becomes really easy, once it’s split it can still talk to other products, no problem. When it’s a monolithic code base, you say “Let’s split this thing,” that’s panic for everybody, because how do you even pull it out of the source control? It’s so intertwined with everything else. I think it’s a whole mindset that then makes everything way more nimble. Some third party comes off and does it better than you do it? Awesome, throw that product away and adopt their product. Or you need some new product that’s out there to bolt on to your thing, it’s easy to bolt on. It gives you all these other advantages, other than just team size as well. Jade:  What about an non?software world, non?software contacts, how does this apply? Clayton:  As far as breaking the teams down or…? Jade:  I mean, having small teams, keeping things simple, how does that work when you’re not talking about software? Derek:  Give me an example of a non?software? Jade:  I’m a marketing team. Derek:  I think you can do the same thing. Think of it as products. Your products might be services or maybe there’s the logo team from the marketing group and maybe there’s the brand standard team, maybe there’s the marketing collateral group, maybe there’s the social media. Maybe you think of your service offerings as products. We offer this service as a product, it doesn’t have to be a digital thing. I can’t remember the gentleman’s name, he’s a publisher…I’ll try to put it in the show notes, that’s really good talking about “everything you do should be a product.” Whether you’re an author or a speaker…If you’re a speaker, you should have pre?canned talks that you’re able to give that people are going to buy as a product. They can dial you up and say “Jade, I want your talk on small teams. What does that cost? Can I buy it, can I click a button, can I book you”? Just because you’re not doing software, it doesn’t mean you can’t do products. We buy non?software products all the time. If somebody comes to clean my house, that is a service that they’re providing me, but I can call up and say “I’ve got a 2,000 square foot house, how much is it going to cost to come have it cleaned”? And I buy that product. They probably are able to upsell me and add value add?ons and everything else. You should do the same thing with your teams, even if they’re not software. Jade:  Great. Thanks for listening, we’ll catch you next time. [music] Announcer:  If there’s something you’d like to hear in a future episode, get over to integrumtech.com/podcasts where you can suggest a topic or a guest. Looking for an easy way to stay up?to?date with the latest news, techniques and advance in the Agile community? Sign up today at agileweekly.com. It’s the best Agile content delivered weekly, for free. The Agile weekly podcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com or subscribe in iTunes. Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline, it’s free. Call 866?244?8656.     The post Episode #128 – Smaller Teams appeared first on Integrum.