Clayton Lengel‑Zigich: Welcome to another episode of the Agile Monthly podcast, I’m Clayton Lengel‑Zigich. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Clayton: I tried to think of all the reasons why we didn’t record a podcast, but they were all excuses. Roy: The real reason is we went to the bar and went drinking instead. My Boss Told Me To Do This Driven Development Clayton: That sounds like an excuse. Today we’re going to talk about a common pattern that we have observed in a few different places, and it goes something like this. You’ve got maybe some direction from the product side of the fence where the product owner’s got a boss, and they’ve got a boss, and somebody comes down and someone’s boss’s boss says, “The team should do this.” So the product owner comes in and says “OK here’s what we’re doing, because my boss told me to do this.” Maybe that gets going a little bit, gets some traction and there’s some idea of what the team’s supposed to be doing, but then maybe someone on the technical side of the fence, like the dev manager or the dev manager’s boss, might say “Well, I want something to be done on the team and I don’t want to go in the backlog to get that stuff done. That might take too long.” They force the dev manager to direct the team to do something. And since the team reports to the dev manager, the team feels obligated to do that. It’s like a bunch of different parties in the organization playing puppet master with the team. And the team never really gets a whole lot of traction. Would you say that’s a fair assessment, Derek? Development Managers Undermining Product Owner Authority Derek: Yeah, I mean, the first pattern is that usually the product manager, product person has trouble a extending…The pattern I tend to see is the product owner has trouble establishing authority and priority in the backlog because of stakeholders that they report to. About the time they figure out how to get that done and they actually start to get the team baked a little bit and get going, what happens is the dev management side starts to realize that they’re no longer in control of their team, which was probably an illusion to begin with. And so to reassert control or authority back over their team, they tend to start asking their team to do things that aren’t part of that prioritized backlog. Then the team a gets confused and there’s all sorts of tension between the product owner and the dev manager and the team doesn’t know what to do because they want to do what product wants them to do but they don’t want to be fired and they report to the dev manager. And so there’s just this crazy alpha thing that starts to happen and then the team generally starts to go fairly batshit about that time and all productivity goes out the window. Clayton: Yes, I’ve always wondered when we see that if it’s a situation where the team feels obligated to do what the product owner says because they feel like, I read the Scrum book, or someone told me about Scrum and that’s how it’s supposed to work. But, the fact that they all report to the dev manager, if the dev manager can instill a certain control, I wonder maybe it’s because usually the product owner is not at the same level or above the dev manager in the organization. So, they don’t really have the authority to go tell this person, “Too bad. You have to do things through the backlog.” Mis-Alignment Within The Organization Around Product Owner Authority Derek: What tends to happen is they tend to report usually to different tree structures. Then their bosses tend to report to different people. Often time in an organization they don’t report…their tree structures don’t cross paths, until you’re at the top tier of the organization. What happens is the struggle goes up a level or two, and then at that level it’s like, I don’t want to bring this to my boss. Clayton, you and I report to the CEO, and I’m the VP of project management and you’re the CTO. Our underlings are having this out a little bit, which really we’re having it out, we’re just doing it through our direct reports. But we don’t want to go to our boss and have it out because our boss is going to say, “Are you being a bunch of stupid little children? Why can’t you get along”? Clayton: No, we can’t solve this pithy little problem on our own. Roy: I think that’s the answer. It sounds like the development manager and the product owner just need to talk, and be like, “Hey, this isn’t working.” I like the idea of the development manager being organizationally apart from the product owner. I feel like one shouldn’t be above the other. Loss Of Perceived Control Derek: The trouble that you run into is when you start to go, at least on the Scrum side, you start to do something that’s more Scrum‑oriented, you start to give a lot of power to the team through empowerment, so the direct dev manager feels like they’re losing a lot of authority that they probably never really had anyway, because they don’t feel in control. From a product perspective the product owner starts to take a lot more authority about the direction of the product. A lot of times the CTO or the senior dev manager or the dev director or the program director, or whatever you want to call it on the dev side, usually used to have a ton of influence in how the product was developed. They start to feel like their control, or their influence, is going away. I think a lot of it is insecurity of, “Wait a minute product, you don’t actually need me and my management structure, you just need my developers.” Now a lot of times what you then see is it’s almost like the product owner is almost like the manager or the developers because the developers have respect for the product owner and are listening to the product owner and doing work for the product owner. I think what happens is you get panic and the panic is like, “I have this urge that I still have control over these people. I’m going to ask them to do something and if they do it I know I still have control.” If they don’t do it and they refer to the product side of the fence then I know I’m losing my control and then that creates blowback upstream. Clayton: Yeah, we’ve seen teams that have been fractured along those lines where there have been some people on the team who have the allegiance to the dev manager and not the whole structure. Then some of them they just don’t like that person or don’t get along with their manager. They gravitate on the other person that has somewhat resemblance to the manager who is usually the product owner at this position of authority. You get this kind of fractured team. Even if the two people aren’t trying to do it purposefully as a power struggle, maybe the dev manager overhears some conversation from the product owner or the product group saying, “I wish the teams would go faster.” Maybe they’re not even trying to be malicious about it, but they think, “Oh I need to jump in there and make the teams faster. That’s my job, I manage the teams.” Those are the things that you could accidentally cause a rift in the team when you don’t even mean to. Roy: I think it’s just a matter of making a mental switch from commander/control manager to more of a servant leader, right. Whereas a development manager you start to think more in line of like, “How can I help the team”? Rather than “How can I get the team to do what I want”? With the product owner that’s a pretty common thing I’ve seen on multiple scrum teams, where the product owner start to take up the role of like the manager of the developers rather than being a member of the team. I think that’s a mistake, it’s very important to make the distinction between like, “You’re the product owner, not the team owner.” The Product Owner As Part Of The Delivery Team Clayton: Derek you were sharing some drawings that you had about how you’ve seen some team structure where the product owner is also the manager and they’re outside the team or sometimes they’re inside the team and sometimes they’re also the scrum master and all these different things. I thought that was pretty interesting, I think in my experience. There are so many product owners that don’t ever treat themselves like a team. Most of the time they don’t, except when it behooves them. If there’s a decision to be made or they’re involved somehow and what the team is going to do next or something like that, then they’re definitely a part of the team. When it comes to maybe being responsible for everything or like the not special treatment scenarios, they always view themselves as like, “Oh, I know I’m just separate, I’m not part of the team. I’m this product person throughout the organization. I report to the different tree.” Derek: Yeah, I think it’s difficult. I go back‑and‑forth between where I think the product owner really…I definitely think the team should not be reporting to the product owner from an organizational structure or perspective. I definitely don’t see a ton of value in that or any value in that, I see a lot of conflict. I go back‑and‑forth between whether they’re part of the team or not part of the team. Certainly they’re not part of this, the development team or the product team or whatever you want to call, the people doing the work… Roy: Right, like they’re not going to pair with one of the developers. Derek: Yeah, but I get a lot of questions. Should the product owner be a stand‑up? Should the product owner be part of the retrospective? A number of [inaudible 08:48] and I get really indecisive because on one hand I really think they are the customer. If we really think about it they are a proxy for the customer. I don’t think the customer should be part of the team but I think they should be in damn close proximity interacting with the team and collaborating with the team a ton. When it comes to stand‑ups, yeah they should probably be there just so that if the team has questions there can be some dialogue that happens. When it comes to retrospective, I don’t know, I’m a little more at horn. [crosstalk] Clayton: …retrospective because that’s one pattern I’ve seen a lot, is the product owner will treat the retrospectives as optional. Where when they think they want to be there or there’s something that’s on their mind then they’re definitely going to be there and they’re going to be the loudest voice in the room. When there’s some other conflicting meeting or maybe they don’t have anything to say to that particular retrospective they treat it like, “Yeah, I don’t really need to be there.” I have seen where the team will make some decision about something that affects the product owner when they’re not there and then they get all up in arms like, “Well, hold on, you guys can’t make choices without me.” “Well you optionally decided not to come to the meeting, so what do you want”? Roy: I feel like it is important for the product owner to be present at the retrospectives for exactly what you mentioned. Just because they don’t have a problem, like the rest of the team might still, so they want to bring up with them. They probably should be bringing that up throughout the week, but I totally think they should be part of the retrospectives. They should be sitting with the team, and participating in stand‑ups. Other than having the authority to choose the priority of the work, they should be a team member. I agree they shouldn’t be pairing on any of the work because there’s a conflict of interest there, but they should be involved in all the other ceremonies. Too Much Familiarity Can Lead To Lack Of Candor Derek: One of the things I see as a problem with that is there becomes too much familiarity, and then they actually do not do the product ownership role well enough. If I’m the customer of a service, when I’m no longer happy with the service I can voice very strongly that I’m not happy. I can even say, “I’m so unhappy that I’m willing to go get my service somewhere else.” I’m sorry, Target, if you piss me off, Wal‑Mart is more than willing to take my money and they’re pretty close to the same thing. Where if I work at Target, it becomes very difficult for me to say, “Hey Target, if I have a bad experience I’m going to stop working here,” because I have a bunch of friends. If I’m negative about it, then people stop shopping there, and maybe I lose my job. I see that happen with product owners, they consider themselves too integrated into the team. The benefit is there’s more, “Hey, we’re all in this together,” which I think is really good, but they lose their objectivity with the team to say, “Ultimately…” Clayton: Maybe they would get to a point where they’re too comfortable? They spend so much time with the team, and they think the team’s doing a good job, they know they’re trying really hard, all those kinds of things. If I’m the Target consumer, do I think everybody at Target’s trying really hard? I guess, but I don’t really care. If they piss me off enough I’m going to go somewhere else. Roy: I think that’s bad product ownership. It shouldn’t matter. I feel that that is not having the courage to say what you think, not being honest with yourself about how you really feel. Clayton: Does it make it easier to get in that position if you spend too much time with the team, or you treat yourself like you’re in it with the team? Roy: I agree that that definitely makes it easier, but I don’t think that excuses that behavior. Living In A No Product Owner World Derek: In a perfect world, there is no product owner. The team is the product owner, or they’re sitting with the customer who is guiding the product, or you’re doing something that is lean start‑up enough that you are getting instant feedback and everybody is providing value to team. The problem is, we don’t live in that world. Most of these organizations that are trying to do an agile adoption are so far from that, I don’t think they can jump right into that. In the same way, I don’t think they’re adult enough to be like that. You’re absolutely right, I should be able to say, “No hurt feelings.” It doesn’t matter how much Clayton and I are friends. If I believe the work we’re doing is not quality I should be able to have that discussion. I shouldn’t have to worry about his hurt feelings. The reality is, that’s not the case of most people in corporate America going through transformation. Roy: But it is what they should be striving for. That’s why we use the core protocols. We have that kind of atmosphere within Integrum. It’s not that I don’t want to hurt your feelings, it’s because I respect you and appreciate the work that I’m going to give you this feedback, tell you the truth. Derek: This is why I struggle with Agile a lot. If we really look at the ideal, Scrum is bullshit. Creating this big schedule, doing all these burn‑downs, doing a lot of this stuff ‑‑ to me, if we’re all adults, we’re all acting in the right way, we’re all part of the product ‑‑ why do we need a Scrum Master? Why do we need product owner? Why do we need any of this to begin with? Some of the process is there just as tools to help us build discipline. Once we have some of that discipline and we’re mature enough to do that, all that stuff becomes optional at that point. Roy: Like bootstrapping the team and then letting it run on its own? The Product Owner’s Authority Clayton: I think that’s fair. Most people that think they’re at that level [inaudible 14:30] if you think you’re an expert programmer, you’re probably not an expert programmer. If you think you don’t need any discipline reinforcing process, you probably aren’t disciplined enough to go without it. I wanted to go back to one thing you mentioned at the beginning, Derek, about the scenario where the product owner is giving some stakeholder feedback, for instance the scenario of, “The product manager told me that the next thing we’re doing is this, so we’re doing that,” and comparing that with what they’re supposed to be doing, which is being the customer. I think those two things are misaligned. Do you think that takes away from the product owner’s credibility? They’re not representing the customer, they’re representing some other person… Derek: Yes. I had this conversation today in spades. A common thing that I hear all the time is that if Clayton is the boss, I am the product owner, Roy is part of the development team, and I come in and say, “Hey Roy, we’re going to switch this sprint and we’re going to do this big project X,” and you feel like this is just the dumbest thing. We always try to do it, we never really do it. You don’t understand it. You ask me, “Why are we doing that? Why are we not doing the big thing that you said was so important last week”? My answer is, “Because Clayton said we need to do it, so we just need to do it. Mom said we need to do it.” I become the barking dog with no teeth that has no bite, because I have now told Roy I have no authority at all. I just do what Clayton tells me. From that point forward, everything I say is utter BS. Roy’s going, “Why am I even listening to Derek”? Roy: I should just listen to Clayton. Derek: Two seconds later, Clayton is going to walk in here and tell us whatever he told us was crap anyway. Clayton: You seem expendable at that point. Derek: Right. Clayton: OK. I just wanted to cover that real quick… Derek: If you’re in that position ‑‑ this is what I’ve been coaching… Clayton: It’s the real world follow‑up. Understand The Why If You Want To Be A Product Owner With Authority Derek: …The real world follow‑up, because I want to make sure that people understand, is never ever say, “Somebody upstream told me.” It is your responsibility as a product owner, if Clayton tells me, “Our new priority is X,” I need to ask Clayton why. I need to understand why, so that when Roy asks, “Why are we doing this”? I don’t say, “Because Clayton says.” I say, “Because as a business, we need to do X‑Y‑Z, we need to achieve this, we need to do that.” When I’m able to do that, I have the respect and authority necessary to guide the team in the future. Even though I’m not the one who came up with the idea. I’m not taking credit for the idea. I’m basically shielding…You don’t need to understand what every part of the business is doing, Roy. As a team, you just need to trust me that I’m doing the right thing for the product and the team. Clayton: All right. I think we’re out of time, so thanks.

Jade Meskill: Hello, and welcome to another episode of the Agile Weekly Podcast, I’m Jade Meskill. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: And I’m Roy vandeWater. What Happened to Extreme Programming (XP) Jade: We were sitting around, trying to decide what to talk about, and the topic of eXtreme Programming came up. Hey Derek, what happened to XP? Derek: [laughs] I think what we were talking about it is, we were laughing, making fun of some other industrial frameworks and enterprise things. Roy: With trademarks. Derek: You can infer what you want to infer, and we were laughing, but we do get a lot of our clients that for right or wrong, call what we do the Integrum right way. I made a comment that I was doing a lot of research on some of the elements of process, and trying to dissect things, and find commonalities, and deep dive into it. That I was…I don’t want to say appalled, but amazed at how almost identical the Integrum way is to traditional XP in almost every way, shape and form. Roy: We never claim to be original. [laughs] That’s right. Derek: Right, which is hilarious, but it’s funny because we don’t sell that really do XP even though we firmly believe in XP. There is no marketability for… Roy: Right. Derek: …extreme programming. Roy: You probably don’t sell the Integrum way either. Extreme Programming Is Really Hard To Do Derek: We don’t sell the Integrum way either, right? It’s just part of what we do, but I think the conversation started to diverge into, “Well, yeah, people stopped doing XP because XP is like really fuck hard to do.” Roy: How much does XP speak about the organization around the actual development team? Jade: Not much, I mean, it demands on on‑site customer which is very, very difficult to do. It’s even more difficult, I think, than having the product owner from Scrum. I’ve been talking a lot about XP at the company that I’m working on right now. A lot of the engineers get excited about it, until they actually go to implement it. It looks really great when you read the book. It’s really easy to get excited about the values and the principles and all those things, but doing it, is very, very difficult. Agile Our Silos So We Can Keep Our Efficiencies Derek: When I look at it, I mean, I think one of the things I find interesting is, I think, XP tends to say, “Stop the silos and everything you need to be successful, pull that into your team,” which, I think, honestly is probably the most scalable way to think about the world. I think what happens is all of these enterprise frameworks that are coming out, for lack of better word, or the agile scaling frameworks. What they try to do is say, “How do we build our silos back up in an agile way”? We’ve got these independent agile teams that are doing things, but we are not allowing them to actually deliver things end‑to‑end. When we put some sort of ceiling or some roof on them where they have to interface back with the organization, which generally becomes the limiter that stops them from actually being hyper‑forming and it’s says like, “We need to have all those control valves to deal with it.” Where, I think, maybe more of the XP way and I certainly don’t want address it, so I’m projecting here. But, I think, they’re kind of saying, “Hey, if you’ve got your customer and everything is self contained. It’s almost like every team is its own start‑up.” I think if you look at what’s most scalable, that is probably the most scalable to do high performance. It might not be the most scalable for, “I want everything to be uniform. I want the most efficiency.” That’s the problem. Big companies want efficiency, so they’re like, “Well, you want to implement Scrum the same way for everybody, so that it’s easy for somebody to go from one team to another team.” They know what they are doing. There is no cost to have to switch. Everybody is doing the same thing. We’re reporting the same way. We are all using the same tool. Autonomy Leads To Chaos and Rework Jade: We’re all making sure we’re not accidentally doing rework. Derek: Right. Roy: Because I feel like that’s kind of the problem with having a start‑up idea is that you could have one start‑up over here building some minimal viable product from something over here and then have another start‑up all the way across the company doing the exact same thing and essentially wasting resources. Derek: OK, and the way I look at that is let the free market decide. If you’ve got two or three teams that are all trying to solve a similar problem, they are probably going to solve it slightly different and when they do that, the best one is going to rise to the top. I think what happens is we get so concerned about, “Well, let’s not waste money allowing three different teams to do it.” That we add so much crap that none of the three teams deliver anything because they are quagmired in, “We have to have the perfect architecture or the perfect answer to this. Or it’s got to be the end all for all three of us.” When in reality, a small part of it is really the same for all of us, but for the rest of us, it’s not. Roy: So are we talking about an organization or the head of an organization like the parent entity, or whatever, who really acts more like a venture capitalist… Derek: Sure. The Budget Already Belongs To The Group Roy: …in all of these little sub organizations that essentially get a budget? You have to figure out what they do want to do with it and it’s up to them to figure out the best way that they can add value back to the organization. Derek: All big enterprises I know already do that. They already have organizational pieces. They already have the ability that they are putting budget by group by something, right? The only difference is they are trying to squeeze efficiency between groups, or they try to say, “How can we make it so that we can communicate everything to everybody”? It’s unrealistic. [crosstalk] Optimizing for Efficiency, Stifles Innovation Roy: Is the ironic part that by trying to maximize efficiency, they generate a ton of waste? Derek: I don’t think they generate a ton of waste as much as they stifle innovation. Roy: I guess what I mean in terms of waste is the bureaucratic overhead of dealing with the organization hierarchy, so you end up with a ton of middle managers and middle managers between managers and you end up with all of that type of waste that… Derek: But to them it’s not waste because they are getting the value of being able to know what everybody is doing. Roy: I see. Conway’s Law Applies to Software Development Jade: This is where Conway’s Law starts to play in, right? The software that is developed is a direct reflection of the communication processes over the organization itself, right? If you have this very complex, very highly controlling, very convoluted communication environment, your software is going to be a direct reflection of that. I think that also plays into the XP principle of self‑similarity. That was a hard one for me to comprehend for a long time. I had to really think about how self‑similarity really works. It’s based on the same idea, right? That if you have team that is functioning in this way, it’s going to generate software that functions in this way. If the organization is functioning that way, it’s going to generate teams that work that way. Team Equals Product Derek: It’s a classic Jim and Michele McCarthy’s “Team equals Product.” I think that there is so much truism to that, but we don’t want to admit it, right? Jade: Right. Roy: Especially as a management team where the product is a development team. Derek: We want our products to be nimble and light and clean and simple and all of these words, but we build our organizations the exact opposite of the traits that we’re actually looking for. I think I read an article on Medium or one of these. There are companies trying to do “no management structure,” right? Jade: Yeah. Derek: I think there are some other examples. I think this is… Jade: The whole aristocracy. Organizational Innovation Derek: Yeah, I think there’s problems with this stuff. I don’t want to sound too idealistic or like happy‑hippie. I don’t think anybody is saying that it’s the magic pill and that everything works and that people have it done, but I think the next real innovation is going to be organizational innovation. Meaning we’ve squeezed the crap out of efficiency for technology for the most part. I think our next big wave where we’re going to get real innovation, innovation where we’re going to see like leaps and bounds and technology advancement, not efficiency is going to be when we can figure out how to optimize how we behave as human beings into organizational structure, like work structure. Jade: How does XP play into that? If we think that the ideas, the core principles and values of XP are fundamental to the way that we work, how do they play into that next revolution of organization? Revolution In The Organization Derek: I think some of it is they are just like they were revolutionary and radical ideas for software teams. I think they’re revolutionary and radical ideas for managers and organizations meaning, think about it if you said, “We need to keep all organizations simple.” A good example of this, to me, would be Netflix’s vacation policy. “Our vacation policy is you can have as much vacation as you want. We don’t really care. Check with your team. Make sure that your team says that you’re providing value and as a team, you guys figure that out. We’re not going to have a policy.” I’ve seen three and four person companies that will go to war over what their vacation policy is going to be. Which is just, to me, insane, but it’s like that institutional, but like you have to have a policy. There is no way. We’re not talking a 30,000 person company switching from like, “Well, we’ve got regulation and we’ve got history and we’ve got accrued hours and we can’t just flip the switch and go to this like really simple vacation policy of, ‘Don’t be an idiot. Do what’s right.’” We’re seeing brand new companies that form that have so much organizational baggage from the people starting those companies. That they are saying, “We can’t do this.” Roy: I wonder how much of that though is people trying to avoid personal conflict. For example, with their vacation policy and only having a four person organization. If you instill this policy and you break the policy by taking three months of vacation in the year or whatever, now I can point at a policy and it’s not me accusing you. It’s me pointing to the policy and it’s you versus the policy. Whereas, if you’re being a jerk, but we don’t have an agreement ahead of time, then all of sudden I have to bring it up with you. I have to take responsibility for how I feel. Jade: I think that plays a lot into it. When we started Integrum, a lot of people who were mentoring me were freaking out because we wouldn’t define those things like vacation policy, like some of things, because we didn’t want policy. It’s amazing when you create a policy, how everyone becomes a lawyer in the company. I’ve seen it in many different companies that I’ve been in where as soon as the policy comes up, everyone is figuring out the loopholes, the ways around it, all of those things. Where if you don’t have a policy, it does force you to deal it with on a human, person‑to‑person basis. Hiring People You Don’t Trust Derek: That’s not scalable. What starts happening is A ‑‑ we don’t trust people, so that might work really well for this little group, but I can’t imagine doing it for…It’s like, “Why are you hiring people you don’t trust”? This goes back to the core things. To me, when we talk about some of the simplicity, some of this empowerment, some of the self‑organization and self‑direction, you have to get to a point where you have such vulnerability and such courage as a leader and as a manager or an owner or CEO that you just unlock the awesome. The minute that you take good people and you start to put things around that start to show that you’re not vulnerable or that you’re not trusting, like Jade was saying, they start to build walls around that almost instantly not even knowing. Just like a self‑defense mechanism, it turns into justification. You cut out all the ability to be the best human being you can be. I think when we can get to a state on teams where we’re cutting through all the crap, and we’re just being the most raw that we can be together as people and not having to deal with all the other crap, we unlock all sorts of potential. But that’s so hard to do. Roy: Some of that too is that by trusting the people to make the decisions what ends up happening is they probably make better decisions than if you instill the rules on. Going back to your vacation idea, if you instill a two or three week vacation policy on somebody, they’re going to make sure they use up every single day. But if the rule is “don’t be an asshole,” I would not be surprise if people all of a sudden took one week instead of three or whatever. And I bet that extends way beyond vacation policies. Derek: Our number one complaint through hundred employees over time, the number one complaint with, say, vacation or lack of vacation policy is “I don’t like this because I don’t know how much time I can take. So I think you guys are being mean to me because you’re trying to get me to not take vacation by not telling me how much vacation I can take,” which to me is just, boom, mind blowing. How does saying, “Take as much as you is feel necessary and as much as the team can” gets turned around into, “This is an evil Jedi mind trick that’s getting me to not take vacation.” Jade: We’re not that smart [laughs] . The Right Amount of Flairs Roy: There’s an infamous scene from “Office Space” where the guy is like, “You need to have 17 pieces of flairs.” He’s like, “OK. So I need to get 17 pieces of flairs.” He said, “Well, you don’t need 17 pieces of flairs. You just need to have enough.” He’s like, “OK. Well, I think 3 is enough.” He said, “Well, 3 isn’t really enough. We were thinking more like 17,” or whatever. I think that’s the case in most organizations is I bet people are suspicious and think that there’s a hidden number behind the scenes, and they are just not allowed to know what that number is. Derek: What’s funny is we even had some people that asked the question. I don’t know. What do you guys see [inaudible 13:09] ? I don’t know. In most places, two or four weeks, but it depends on what your project is. I think we’re pretty open about that. I don’t think we were saying, “Well, we’re not going to tell you what the magic number is.” Jade: Or we’ll get mad if you go over the secret number. Roy: Right, exactly. We have secret meetings about the fact that you went over, and when you come back from vacation, your ass is fired. Derek: [laughs] What’s crazy is we would have some people that would take a little more vacation, and you’d have other people almost get mad at them. It’s like, “They’re following the same thing that you’re following. You just have [inaudible 13:40] hang up that you don’t want to do it.” Roy: Although them getting mad is how the system self‑corrects too. If somebody’s obviously abusing the system, then everybody else gets mad. That’s how you deal with that organizationally. The Zen Of Extreme Programming, Value Is What You Like Derek: I think that it’s just difficult for people to do. I think when I look at the XP stuff, the reason XP stuff is so hard is because it is so, so simple and so liberating. It’s like Zen. If you listen to us, Ron…I love our conversation about value and argument, and as much as it sucks to say, “Value is what you like,” at the end of the day, that’s what value is. It seems too simplistic and too easy and too raw, but I think that’s how a lot of these things tend to be. If you break them down to their bare essence and be human and be simple about it, then you get pretty tremendous results. Jade: I remember the first time I came across XP in the late ’90s, I saw it, and I said, “This will never work. This is insane.” We just couldn’t apply it. I was working at a small place that had a very tight‑knit team. Roy: I was still in elementary school. Jade: Shut up. [laughter] Jade: And still rejected it. Because it is. It’s beautifully simple, but very, very hard to live by. And on that note, thanks for listening to the Agile Weekly Podcast. We’ll catch you next week. Roy: Goodbye.

Jade: Hello, welcome to another episode of the Agile Weekly Podcast, I’m Jade Meskill. Derek: I’m Derek Neighbors. Clayton: I’m Clayton Lengel‑Zigich Roy: And I’m Roy VanDeWater. Jade: Guys, today we wanted to talk about an article that will be published in Agile Weekly tomorrow. Roy: Product tie in there. [laughter] Commitment Considered Harmful Jade: Subscribe to the Agile Weekly Newsletter at AgileWeekly.com. Written by Allan Kelly, the title is, Commitment Considered Harmful. I know we have no opinions or thoughts about this, so this might be a very boring podcast. Roy: I’m curious, why is commitment considered harmful? By who, maybe is a better question? Jade: Allen has to say that he has seen through some of his interactions with clients and other people, that…this is a quote from him. Commitment protocol for filling an iteration is actively damaging for software development teams in anything other than the very short‑run. Derek, you’re shaking your head. Derek: I don’t know. Maybe it’s too many years of therapy coming out. Jade: Too few? [laughter] The Boss Will Manipulate You Derek: If I follow the trail…when I first saw this article, I immediately thought that it was part of the no estimates crowd shtick of stuff. Jade: He specifically states that he does not follow the no‑estimates crowd. Derek: Yeah, but I certainly thought it was going down that route. What I tend to see is this pattern of, there’s something, there’s something, there’s something, and it’s all rooted in two things. Every software manager is evil and the people will manipulate the system or me. To me, going back to McCarthy’s core protocols and the perfect boss, I expect to work in a place with fucking adults. At some point, how long can we basically say, the boss might manipulate me? Well then go to a fricking job that doesn’t have a boss that manipulates you. That’s got nothing to do with commitment. The boss that’s manipulating you with commitment or estimates is going to manipulate you if you don’t have commitment or estimates either, because they’re a manipulating asshole. Roy: Yeah, that argument’s just too broad. You can replace whatever with, there’s this thing that some people have used, so you don’t do it. Attack The System, Not The People Jade: Let’s step back a second, though. We do a lot of consulting. We’ve been to a lot of companies. How many have you showed up at that are full of fully functioning adults? Derek: Not a ton, but I think my problem is attack that problem. Don’t attack the lack of commitment as being a problem. I hear commitment. I hear estimates. I hear accountability. I hear all of these things. The very first thing that was thrown out here is, “Well, you can’t have commitment, because people will game it.” Well, people will game anything. So if you have a culture that is OK with people gaming things. Roy: We talked about it in the past that‑‑what is it? I think, Jade, you quoted somebody that said, “96% of a person’s ability to self‑improve is dictated by the system.” Do you remember who that was? Jade: W. Edwards Deming. Culture of Commitment Roy: There you go. That may be the same problem in this case. What if it is a culture of a commitment that is holding these people back from becoming the adults they can? Because they are currently being rewarded for making false commitments or for gaming the system. Derek: Right. I would argue that in that point they’re not really making commitments. The word ‘commitment’ is being bastardized to control somebody to say, “You have to tell me how much you’re going to do,” and then I’m going to threaten you, or lord over you, or manipulate you. Jade: They’d beat you with a stick. Derek: Beat you with a stick, beyond that. Well, to me, that’s not a commitment. A commitment is me saying what I really can believe, and me truly believing in that and doing that. That’s not somebody else saying, “Hey, Jade. I want you to commit to mowing my lawn tomorrow. All sorts of bad things are going to happen if you don’t mow my lawn. You’re OK with that, right? Your job is depending on it. You’re OK with it?” I feel like to me, that’s not a fair thing for commitments, or for estimates, or for anything else. Bad Managers Abuse The System Jade: No. I think that what we would argue if we were working with a team, and they said, “Well, we’re doing commitments.” I think from our point of view, we would say, “OK. Why don’t you look at the work that you do?” Maybe the team, they look at one story, and they say, “This is all we can do.” The manager, I think the way that people abuse commitment, and say, “Hey, you guys have 150 hours over the next sprint, that all you are going to be working on this.” You have to have 150 hours of work to do. I think we would say, “If you want to commit to doing 20 hours of work, and that’s all you want to commit to, that’s all your going to commit to.” That’s an acceptable scenario, as far as I think we’re concerned with how commitment works. That’s now how most people… Bad managers aren’t going to abuse that, and so that comes out his commitment is bad. Does Quality Suffer Derek: What about the idea though, if you’re feeling rushed, and that making the commitment is the most important thing above all else, like keeping to your word, the idea that you allow quality to suffer because of that. That you might choose to take some shortcuts or to cut some corners, because you are trying to push it out the door. You don’t necessarily do all the good practices that you want to have, and maintain a quality suffer project. Those things will buildup over time to create a ton of technical debt that you can no longer maintain. Jade: Yeah. That’s just part of, I think, if you’re committing to doing something and you have some standard for what it needs to be done. If the standard of done means half‑assed, then, OK, fine. No, that’s not really how you want standard done. I think that is part of the bigger picture of, “What does it mean to be done?” If we’re going to rush through something, are we really done? Did we really “hit our commitment”? Probably not. Derek: I think that it’s kind of the straw man out there, right? People like to throw it out. I see so many teams that have no sense of commitment that have really crappy quality. Like to me, those things are not linked. I think what happens is when somebody is forcing you to the trough to drink water and really just slams your head in, you’re going to do stupid things. But I don’t think that’s because commitment is bad. I would say that a team that is truly committed and committed in everything they do, they say, “Hey, we’re going to have…we’re going to write tests first. We’re going to make sure that our product owner is happy with the work that we’re doing. We’re going to commit to all these things and we’re going to commit to do what we say we’re going to do.” You can’t say, “We finished everything, but it doesn’t meet the product owner’s requirements and it’s not tested and it’s not…” because at that point you don’t have a commitment either. Jade: But technically, it’s done. Derek: I know… Do What You Say You Are Going To Do Jade: The way you said, the phrase, “Do what you say you’re going to do.” I think that was a big shift that we had at Integrum of the concept. It sounds so simple, right? Do you what you say you’re going to do. I think that’s really to me is what commitment means. I’m going to say I’m going to do something and then, I’m going to do it, but that’s not easy. Derek: No. It’s not easy and I think commitment isn’t easy. Like committed to do something is difficult, right? But it doesn’t have to be this, you know, abusive tool. The Truth Killer Jade: I think to me the thing that I really love about Agile when it’s done really, really well is it becomes the truth killer. So if you can go around and say, “My team is so awesome. I’m so awesome,” and all this stuff and make all these promises and never, ever fulfill them like you’re just a lying piece of crap. Who can trust you? Whereas, if you say, “Hey, I can only do this really, really small thing,” but I think a lot of developers have problems with this because when they say, “Oh yeah, I can do this. I do this,” and somebody says, “OK, so you’re committing to that and I’m going to kind of hold you to that. Let’s talk about it at the end,” and then, you can’t do it. The developer doesn’t say, “Man, maybe I think I’m way full of myself and I should not commit to nearly as much, less time, next time. I should commit to half of that, because I didn’t even get close.” Instead they say, “Well, the problem was this and the problem was that.” Everybody else in the world was the problem and it wasn’t me. I think that’s just…if you’re honest with yourself about wanting to improve and you really want feedback, the only way you can do that is to measure yourself. So if you’re not saying, “I think I can do X,” and then, going out and doing it and measuring can you do it, how the hell can you improve? Commitment Adds Stress Derek: So we can go from the standpoint of commitment adds at least some level of stress to the… Jade: True, it does. Derek: …to the developer, right? Because now they are kind of freaking out about this promise that they made and trying to keep it. But what positive benefit does a commitment actually get? If I’m a developer making a commitment, what benefit do I get by, other than stressing out about it? Is that stressing out, is that the benefit that I get? That I get more accurate at estimating sounds, I get more accurate at committing sounds great. But getting better at committing if committing itself doesn’t give me any value, am I just getting better at something that doesn’t matter? Commitment As A Trust Builder Jade: I think you can build some trust. Or if you say you’re going to do something and you do it and you repeat that multiple times, you can build some trust that when you say you’ll do something, you’ll do it. I think, it also is a discipline thing. Having a commitment, I think, helps you be disciplined. Discipline, I think, is a very difficult thing to have in software development. A lot of teams lack that and I think that’s just another mechanism that helps reinforce that. Commitment Is A Two-Way Street Derek: I think the other thing is commitment is a two‑way street. It’s not just the developer who’s committed. The idea is that I’m saying, “I will do this if you don’t bring in anything else to me to do during this period.” Jade: Like the Scrum? Derek: Yeah. I mean, I think it’s part of the whole contract. So when people say, “Like we do Scrum, but we don’t do this and we don’t do any of this stuff.” It’s like, “Well, how can you even live up to the basic premise of Scrum, which was we’re going to agree to do X, Y, Z, you agree to leave us alone?” One of the things I’ll add is any developer out there that thinks that estimates, commitments, everything else are horse crap, come work for me and let’s talk about how we pay you. Is every week I’ll decide what we pay you? I’m not going to tell you what you get paid until after you’ve done the work and it’s entirely negotiable up to me whether I think you deserve the money or not. You may get money. You many not get money and you’re going to be happy about it. That’s what you do to every damn product owner you work with when you have no ability to say, “This is what you’re getting.” They’re spending money on you. They are giving money to you to do a job. If you don’t do what you say you can do, and you continue to extend…this is why so many companies have problems is contractors or independent third‑party companies where they get to the point where they’ve not delivered what they said they were going to deliver and everybody ends up pissed off and everybody gets sued. This is why this happens. I think it’s almost juvenile or naive to think, “Why can’t we just meander and do whatever we want and you just pay us?” Jade: This state of affairs would be totally unacceptable in just about every other industry. Derek: Sure, it would be. Why Software Developers Get Away With It Jade: What is it about software development that allows people to think that that’s OK? Derek: It’s creative. It’s an art. It’s an unknown magic. I give money to this group of people that have weird social habits. That I do not understand and I have never experienced them before. They do some magic. The type of the keyboard and magic happens. Then, they have this thing that I cannot possibly understand how it works. I could never possibly do it myself. I couldn’t learn how to do it. So, I just have to keep appeasing the magic over here. Jade: But this happens to people that do understand that world as well. Always Hoping It Will Be Different This Time Derek: That goes back to the hope thing, then, right? If people are hoping that…at the beginning of this, you could have the worst possible sprint and have a retrospective where you’re talking about all these terrible things. A lot of times when the sprint planning starts the next time, it’s like, “OK, we have a clean slate. Everything’s in the air for this time. Everyone is very hopeful.” Because people want to be hopeful, right? They want to think that this time’s going to be different. So they repeat the same mistakes. Jade: Robo Roy did you have something to say? Roy: If I hold this is in, maybe it’ll get better. It’s getting better. I think that’s one of our things is we don’t see ourselves as developers. Often times, it’s somebody delivering a service of some kind and having an output. I think failure is OK. I think it’s entirely OK, but the failure shouldn’t be that we aren’t able to deliver something. It’s whether what we deliver or not necessarily is usable or meaningful, right? We should be able to deliver something that somebody can learn from. The business should get something at the end that they can put into practice and say like, “Oh, this is right or this is wrong.” Derek: Do y’all know the [inaudible] you’re saying? Roy: Yeah. Derek: I’m just going to sell it now. The Power Of Doing What You Say You Are Going To Do Roy: I think ultimately we just…as practitioners if we could do what we say we’re going to do, that would go so much further than where we currently are today, it’s not even funny. Jade: So how do we get there? We’ve got two minutes to solve this problem. Derek: Hey, I didn’t commit to anything. I would say the best thing that I think works for teams if they want to improve commitment is basically really take a deep dive in look at what it means to do what you say you’re going to do and also, understand that you can say you’re going to do smaller things than other people want you to do. I can commit to less work than people want me to commit to and if I can do that and have success and build and learn and inspect it to death and improve, I think that is a better long‑term outcome than basically lying every time and not ever fulfilling my promises. Jade: Is that part of the major problem? Roy: Yes. Jade: Is that people can’t reconcile that fact? Jade: Yes. Derek: They don’t feel empowered to say no to those things. Either by themselves or by some other constraint. Don’t Be Stupid On Purpose Roy: I think they are stupid on purpose, too. Most teams I see are still doing two week sprints, still doing like…I mean, if you’re not able to do what you say you’re going to do, go to a smaller block of something and say like, “If I say I’m going to do this in the next two hours, can I really do it.” You’re much better off at failing at doing something in two hours, then you are failing in doing something in 10 days or 15 days. Derek: I was working with a team and I ripped down the board and said, “Show me what you can do in one hour.” They couldn’t do it. Roy: I think that’s a big problem. I don’t think it’s a matter of not allowing people to be creative or not giving them license to do something. I think in teams that are high‑performing, they are not doing a bunch of planning. They are not doing a bunch of estimating, but they don’t need to because if they say, “Hey, we can deliver you something kick‑ass in four weeks.” There’s trust that they’re going to do it in four weeks. I don’t have to think twice about it, right? Where you have to get into the legalism of things are when there is absolutely no trust. The problem is the only way to build trust is to do what you say you’re going to do. Until you can do that, you’re screwed. Jade: Tell us what you guys think about commitments. Any experiences that you’ve had with teams or yourself, failures to commit, all of these things. You can find us on Twitter @Agileweekly, and on Facebook, facebook.com/agileweekly. Talk to you next week.

Clayton Lengel-Zigich: Welcome to another episode of the Agile weekly podcast. I am Clayton Lengel-Zigich. Roy VandeWater: I’m Roy VandeWater. Failing A Sprint Clayton: Today we’re going to be talking about a very rare thing that we’ve heard about from certain people. It’s called, “What happens when you fail your sprint.” Roy: I’ve never experienced this personally. Clayton: Me either. Of course not. Roy: Right. Hypothetically, if it did happen, what do you do? What Constitutes Failing A Sprint Clayton: I guess we should define it first. Roy and I were talking about this topic earlier today and I was thinking, “I wonder if we think the same thing ‑‑ what it means if we say ‘fail a sprint’”? Is failing a Sprint the same thing as, you committed to do five stories, and you only got four done? Are we calling that a failure? Roy: Yeah. What About The Sprint Goal Clayton: OK, I think so, too. What if you committed to doing five stories and then, you also had a sprint goal and you fulfilled the sprint goal, but you didn’t do one of the stories? Is that a failure? Roy: That’s interesting. I haven’t really made sprint goals all that often, which is probably a bigger problem, but that’s an interesting point. If the value of the sprint is to achieve your sprint goal and your stories are almost an implementation to try to achieve that goal, then maybe achieving the sprint goal is all you need. Clayton: For example, I always like to use the travel website. If our sprint goal is to make it easier for people to book a rental car when they book a cruise vacation, and we fulfill our sprint goal, but we didn’t do one of the stories, does it really matter? Roy: I think that one is a little bit in our sync, because making it easier is like a slighter scale. You can make it a teeny, teeny little bit easier by doing a text change. I think the important part…I think what I really consider a failure is when you promise to deliver something and you fail to keep your promise. When essentially, you lose trust with the people that you have promised to, because you didn’t do what you said you were going to do. Clayton: Like maybe, the product owner. You say, “Hey product owner, leave me alone for the next week and I promise you that I will get this thing done.” Then, in a week, you don’t get it done. So now the product owner trusts you less. Roy: Right, exactly. Not Doing What You Say You Are Going To Do Clayton: OK. I think that makes sense. If we define failure as making a promise and then not…basically, we’re saying you aren’t doing what you said you were going to do. We talk about that, we use that phrase a lot internally. If you say that sprint failure is not doing what you said you were going to do, a lot of people I know don’t like to talk about sprint failure because they don’t like to talk about failing. Roy: Well, it’s confrontational, of a sort. Explaining Away The Failure Clayton: I see a lot of people, a lot of teams that will try to find all kinds of ways to explain why they didn’t really fail. Whether it’s, “Well we were working on these five things, but then something happened and we didn’t have to this anymore, so we didn’t really technically fail because we still did the important stuff.” Roy: Or “We worked on all of these things, but then this major interruption happened or this outside dependency caused us to fail our sprint because we were waiting to get something back from them. We thought we’d get it this week and we didn’t.” Using Failure As A Mechanism To Learn Clayton: One thing I’ve always noticed or thought, personally, is that if you don’t view failure as that big of a deal, if you view it as a learning moment, or a way that you can improve, then it doesn’t really matter if you failed because who cares, you don’t have to try to explain it away. Roy: As long as you’re honest about it, you try to fix it for the next time. Clayton: Let’s describe that then. I think there was a team that you were working with or we were talking about that had failed their sprint, or they weren’t going to get it done on time. So they cancelled their demo. Roy: They actually postponed their demo about three or four days under the idea of, “We don’t have anything to demo right now because we didn’t do the stories we said we were going to do, but we should have them done in three days so we’re going to go ahead and do the demo then. Clayton: In the entire sprint review we include the demo and the retrospective. Did they do the retrospective or did they skip that part too? Roy: No, as far as I know the iteration was essentially extended for an additional three days. Partially Done, Should We Demo It Clayton: In that case we would call that a failure because they didn’t get it done when they said they’d get it done. What advice would you give to a team that doesn’t get things done? Maybe they got 80 percent of their stories done. Let’s say that rather than being really bad and getting 80 percent of everything done, they actually got eight out of ten stories done. Would you suggest that they show something in the demo? How would they handle that in the demo? What would the team do? Roy: I would say that if you actually complete something, then show it off because it’s going to go into production, but if you haven’t finished it don’t show it because when you’re demoing, you’re demoing to not just a product owner who knows what’s going on within the team and was probably made aware way before this that not everything was going to get done, but you’re also demoing to the stakeholders, potentially even users of the system and so I feel it’s important to actually show them what they are now able to have. Clayton: So those are the things you only demo what you’ve actually shipped. Roy: Exactly. Clayton: I have always gone back and forth on showing things that aren’t done‑done or unaccepted, only for the sake of maybe really valuing extra feedback. I guess there are probably more bad behaviors that come from demoing half done things or not done things then you’d get a benefit from the feedback. Roy: I’m on the fence on that too. On one hand I think you shouldn’t demo anything that isn’t done because you are setting this expectation that features part of the product when you are starting a new moderation and it may not be prioritized anymore because something may have come up. The specific details on how to post a function may completely change. Essentially you are demonstrating something that may never happen so you are setting expectations that you don’t have the power to meet. However, gaining additional feedback totally makes sense ‑‑ that may be what drives the actual change so it’s really dangerous I feel, but if you were to be extremely explicit about the fact that this is not finished, there is no promise, you are doing it purely to receive feedback, I could see that it might be OK. Clayton: So probably don’t ever do that because most people are not going to listen to you when you say you are not going to get this. Roy: I could see tens of people attending the meeting and be, “Wow”! And then selling to all the customers and then it gets put on the back and it’s never going to get done. Then you are taking power away from the product all of a sudden cause now they have to finish it because all the customers are demanding it. Disclosing Sprint Failure Clayton: In a crucial demo part of this review, some people from the team might actually get up and showcase their features and show them on a projector screen. How do you think the team should address the sprint itself ‑‑ should they address the fact that they didn’t get it all done or should they skip over that? Roy: It is important to be as transparent as possible. If a team has failed a sprint, totally own up to it. Explain why but be really careful that you are explaining why and not making excuses. I would recommend verbalizing all reasons things specifically the team did wrong. The example I made earlier where you are depending on an outside source and they weren’t able to get you the stuff you needed on time and you thought they would. I would word that as “We made a promise for things that we did not have direct control over and the way we would mitigate that in future is by only promising things we know we can deliver.” Clayton: I was watching a video from Dan North speaking in the conference about high performing teams. One of the things I thought was really interesting was he was talking about the team he was working on ‑‑ which was really high performing. They had a component of their showcase, they were doing scrum, but the component of the demo where they talked about things they learned. I thought that was a better way where you can pretty much convey the same information but it’s not presented as, “We would have had that stuff done but excuse excuse excuse.” We didn’t get things done being very afraid of failure and we learn these things that will help us in the future. I feel like that’s a much easier way to go about it even though its sugar coating the fact that you failed. I’m not necessarily advocating that but for teams that are transitioning, that aren’t as comfortable with conflict or perceived conflict involved with saying, “We failed.” ‑‑ technically what you learn might be easier. Where Does The Retrospective Happen In Relation to Sprint Failure Roy: There might be some difficulty with how you structure your retrospective with respect to your demo. You may not have identified a good way, you may not have learned what you are going to learn by your demo time because you might your retrospective afterwards. Clayton: That’s a good point. What would you suggest is positive or healthy behavior that someone in a Scrum Master role might take to a team that failed a sprint? Roy: I would absolutely orient a retrospect around it ‑‑ start out a notion like, “Hey we failed, how can we do better about it”? I have seen many retrospectives where it’s completely shoved under the rug or brushed over. Clayton: There were some colossal failures but… [cross talk] Do Not Ignore Failure Roy: Nobody wants to talk about it, it’s really painful and it’s conflict and probably there is going to be some finger pointing and yelling and pent‑up emotions. I would expect a high performing team, as much as you say it, failure shouldn’t be that big a deal so you can learn from it. On the other hand, neither should failure be a total non‑issue, right? You shouldn’t ignore a failure and be, “Oh, whatever. We failed. We’ll fail again next week. We don’t really care about hitting our commitment anyway.” You have to find a balance and hopefully, the team cares enough to at least get somewhat passionate about making sure it doesn’t happen again. Clayton: It gives them a really concrete thing to use for inspect and adapt, I think. I’ve always felt that as a Scrum Master, if there was a sprint failure, depending on what the circumstances are, as a facilitator you’re not going to go and force them down some path. As the Scrum Master, there may be a responsibility ‑‑ you have to bring things to light, to really call out the 100 pound gorilla in the room and say, “Hey, I think we’re not talking about all the issues,” or maybe format the exercise or facilitate in a certain way, so that some of those things can come to light. Hitting Commitments Is Possible Roy: That is interesting, though, because I found that most teams don’t even believe that consistent success is possible. I know I didn’t believe that myself back when we were doing contracting work with Integrum. I always thought that Derek and Jade kept pushing us to try to hit our sprints continually. I was like, “You know, that’s a nice ideal, but that’s not actually reality.” It wasn’t until I was on a team where we consistently hit our sprint week after week for months at a time and we had one failure and it was a big deal, but then we were right back on track again. It’s truly possible, but I know that until that happened to me, I did not believe it. Clayton: One of the interesting things about that specific example was the answer to “The sprints are failing,” was not, “Work harder.” It was, “Do less until you start succeeding.” That’s one thing that a lot of teams…I’ve seen teams that will fail weeks at a time, but then, they consistently commit to big chunks of work. Rather than saying, “Hey, maybe we need to slow down to go fast, so let’s do less and less until we are successful.” Roy: Well, product owners, especially are really, really touchy about that. “Wow, these guys have $100 of capacity and they are committing to only 50 percent of that. All this wasted money and time. What do I do about that”? Then, the reality is they probably were only going to get 50 percent of the capacity done anyway. Clayton: Right. If they’re failing they might. Roy: They commit to a whole bunch, but they only hit a percentage of that. Maybe it makes sense to…Maybe what they’re doing is not committing to less, but committing to exactly what they are capable of. Consistency Can Be Valuable To A Product Owner Clayton: If I’m the product owner and I’m working with a Scrum team or on the Scrum team, I would prefer for my purposes to have something that was a little more consistent. So rather than be lied to every week ‑‑ and not maliciously lied to, but rather than have some rosy optimistic outlook of what this sprint’s, “Everything should be great this time around.” ‑‑ I’d rather have the realistic thing. If that means going slower and… Roy: But, you’re not really going slower, right? You’re just not promising to go as fast. Clayton: It appears that I’m going slower. Roy: Sure. Clayton: If that’s the case, I’d rather have reality that makes my prediction stuff much easier. Then, I think, that’s another place where inspect and adapt comes in, where you can find ways or with the Scrum Master and whatever the team can improve, so that they can go faster hopefully. But whatever their pace is, that’s all I’m going to get. I would much rather know what the reality is. Roy: I agree ‑‑ it makes it a lot easier to improve over time because if you commit to your full capacity, then you have to go from zero to 100 percent immediately, right? You either fail your sprint or you hit your sprint. But, if you can slide that capacity down to what you can actually hit, then you can slowly move that up and you have much more opportunity for incremental growth, rather than an all or nothing thing. Then you can slowly work your way up to 100 percent. Changing Commitment In The Middle Of A Sprint Clayton: One more bonus question before we go. If a Scrum team has committed to 10 stories and it’s the last day of their sprint and they realize they are not going to get the last two things done, and they say, “Oh, Mr. Product Owner, we’re not going to get these three, two things done, can we take that out of the sprint”? If they took them out, will you count that as a success or failure? Roy: I would count that as a failure because at the beginning of the iteration, they promised to get those things done. It’s a bit of a gray area, so if they realize on day one of the iteration that those two things weren’t going to get done, that would be totally different than if they realized 10 minutes before the demo. Clayton: I’ve never seen that street go two ways. I’ve only seen it where the team asks if they can have things removed, but when they finish, I don’t ever think I’ve seen a team that says, “Bring it on. Give me more stuff. We can’t wait to get more things.” Roy: I’ve seen both, but it definitely never happens at the beginning of the iteration that they say, “OK, give us more stuff.” Sometimes, towards the end, I’ve seen teams finish the iteration in half the time and then, pull in a little bit additional work… Clayton: OK. That’s good. Roy: …and demo that as well. Now, if they didn’t manage to accomplish all of the additional work before the demo, I would not consider that a failure. Clayton: To me, that says topic for another episode. All right. Thanks.

Clayton Lengel‑Zigich: Welcome to another episode of the “Agile Weekly Podcast.” I’m Clayton Lengel‑Zigich. Roy vandeWater: And I’m Roy vandeWater. Pair Programming Not Scientific Clayton: Today we’re talking about an article that we came across, it was this week. It’s called the “High Costs and Negative Value of Pair Programming” Original Taken DownHacker News Thread. It’s by Capers Jones at the Namcook Analytics blog, we’ll put that in the iTune net. Basically, it’s, like a white paper almost, about why pair programming is harmful, and it’s not really a good idea, and you shouldn’t do it, or at least, you shouldn’t do it yet, until you do lots of research about it. It struck a chord, I guess. We came across the post on Twitter, and it kind of generated some buzz on there. Then, we talked about it internally, so we were hoping to share our ideas. The first point that I thought was, that resonated with me was the author makes mention that pair programming is something that came out of the non‑scientific. It wasn’t measured very well in the Agile community. I would probably give him that, that the Agile community has lots of things that we do that are not necessarily based on hard scientific evidence, a lot of its just anecdotal experience. That’s probably a fair statement. Roy: It becomes very difficult, too, though. I think we’ve had something that we’ve run into in the past, right? Where it becomes, because of the nature of every team being different, different projects being different, the codes bases being different, like a lot of the pair programming and not just pair programming, a lot of the types of practices that teams are experiencing with are very difficult to measure in a scientific way. It’s very difficult to have a control group that’s identical except for this one variable. Clayton: The thing that was…while I agree with that general idea that the Agile community is very unscientific about how they measure things, I felt the way that they went on about, goes without measuring things in the article was kind of lame because they just made up a bunch of stuff and put it in Excel it seems like. I don’t know. My guess is you have to take a healthy grain of salt. The Nature Of Organizational, Team and Work Variety Makes Data Collection Difficult Roy: The thing that I thought was most interesting in the beginning is that the author tries to make the point that there are a lot of different scenarios about pair programming that were not considered in most cases. He goes through all these different examples of single programmers using static analysis versus expert single programmers compared to average pairs and novice pairs compared to all these ten different permutations of all these different things. Which, I guess, there are probably not many organizations that have all of these things and they are only going to have two or three at most. I thought it was odd that you go so far out of your way to make a big point of not comparing all these things, especially when there probably isn’t a whole lot of opportunity to compare them all? Static Analysis A Poor Benchmark Clayton: I thought the static analysis bit was interesting because he specifically talks about the number of defects that a single programmer using static analysis produces versus two pair of programming produce. I think the ratio is something like a single programmer using static analysis develops one defect for every 15 that the pair programmers develop? I guess maybe I don’t understand what static analysis is, because I don’t understand. Do you mind explaining real quick? Roy: The idea that static analysis is going to evaluate your code and find defects for you? I have written plenty of defects that static analysis wouldn’t have caught. There’re plenty of things that static analysis would tell you that wouldn’t be defect that you could spend a bunch of time fixing. That seems like it’s just a silly thing to even bring up. Static analysis can be important and it can hint you in the right direction and help you find different things with your code. The idea that it’s like this great tool for finding defects or even a tool for finding defects seems like a stretch. Moving on, another downside the author states for pair programming is that it won’t scale. The example that he gives is a huge software project with 500 engineers. How could you get them to pair? How could you hire another 500 more people? Which seems odd, because any software project that had 500 people working on the same thing that sounds like a nightmare, no matter what you’re doing. Can Pair Programming Scale Clayton: Right. Exactly. You are going to have so many people doing many random things and wasting a ton of time, even pair programming at that point when you have a project that big, it becomes unmanageable. Roy: If it’s 500 people across an entire organization all working on different things, then you could still pair. There’s nothing that says you couldn’t, the idea that it wouldn’t scale? That seems kind of silly. Clayton: That’s the mindset difference, right? Because he’s thinking from the perspective of “I have 500 people and I need to maintain my current productivity level, which means I have to hire 500 more.” Instead of saying, “I have 500 people and that means I have 250 pairs.” Is Pair Programming Only For Developers Roy: That’s a good point. Kind of the next thing that is the problem with pair programming is why hasn’t this been tried with other business functions or other job functions? They talk about architects and BAs and testers and all these other things which, if you talk to those who are actually doing pair programming, they have tried to do some form of pairing with people who are not just software developers. This one stuck out to me as someone that has kind of betrayed the experience the author has with pair programming and the idea that no one has tried that before. Blended Skill Sets Amplify Pair Programming Effectiveness Clayton: In fact, in my experience, the biggest gains from pair programming come when you have the most different types of experiences combining. Say, you have a graphic designer and a programmer, or something like…as different as possible. Because, if you put two people that are almost identical in front of a computer, the most you’re going to get out of it is maybe a slightly lower defect rate, because one of them is proofreading what the other one is writing. But, if you have two people that have totally different ways of approaching the problem that gives the pair a greater diversity of options to choose from, and it makes it more likely that they might pick the right one. Lines Of Code, The Bullshit Indicator Roy: The thing that struck me as the biggest bullshit indicator of the whole article was that one of the measurements that’s used in this calculation is lines of code. The measurement is how fast is an expert single programmer, based on how many lines of code they write? That’s what is used in all the economic calculations. I wouldn’t doubt that pair programming is probably more expensive, and probably slower, than single people working on things, but that’s entirely ignoring all the other benefits that you can get. If you’re just doing lines of code, if you’re working on a software project that all that matters is that you’re just pumping out lines of code, then just hire a bunch of monkeys and they can just pound on the keyboard. You don’t need pair programming at that point. It seemed like an odd comparison. I would even say that if your software project is so simple that you can just crank out lines of code, then you probably don’t get any benefit from pairing as far as collaboration, or redundancy or anything. If Collaboration Doesn’t Matter, Outsource It Clayton: You probably don’t get any benefit from collaboration of any form. You should probably just outsource, and try to get your code written as cheap as possible. Roy: Right, because if all it really takes is that you just are pumping out code, then you can just replace that person with someone else, and it doesn’t matter. But, that’s not the case, I think, in most software organizations. Clayton: I was going to say, how many projects are actually out there where you can just put anybody in front of it and pump out code? Roy: A lot of people try and do that, especially, I would say, shops that are doing outsourced software development, where they’re solving the same problem multiple times. They probably do just have a set way of doing things, where they could get pretty close to just pumping things out, and it doesn’t really matter who’s working on it. But, for most organizations that are developing either products for customers or developing products for internal customers, where there is a need for that collaboration and giving some creativity, and having that redundancy, so that you don’t have the single point of failure with the one person who knows everything… Over Valuing Individual Experts Clayton: That’s true. That’s one thing that’s not really acknowledged all that much. I believe one of the lines in that article states something about like, “If you look at the data in Table three, you can clearly see that the most efficient course of action is to hire a bunch of individual expert programmers.” If you’ve followed many of our podcasts in the past, then you’ll know that that does not really fly very well with the way we like to work, and that that sets organizations up for failure, because you end up with all of these single point of failure where if any one of them…Each one is a link in the chain, and if anyone is gone, then the organization falls apart. Roy: The single expert programmer is usually a hero and a cowboy. They are the ones that are going to stay up until 3:00 AM heroing some solution for some problem, and then they’re going to cowboy‑code their way… Clayton: They’re pumping out lots of lines of code. Roy: Yeah, exactly, and they’re going to cowboy‑code their way through everything else. If you ask any IT hiring manager, the idea that you can just go pluck expert programmers off the street…which, to the author’s credit, he does make the point that that probably only makes up about 10 percent of the hiring pool that’s available, the programming talent. I feel like that advice is…”You should only hire expert programmers” is like telling your little sister, “You should only date guys that are really nice to you, and that are financially secure, and that treat you with respect.” That’s not going to be everybody in the world. That’s probably not very good advice, right? Clayton: I don’t want my sister dating everybody in the world, though. Roy: I agree, but the idea that a hiring manager is just going to go out there and find some expert programmer and say, “Hey, we can solve all of our problems by hiring three of you, instead of having a few pairs.” That seems silly. The Cost Of Poor Decisions Has To Be Factored In Clayton: It’s short‑sighted, too, to think of things in terms of moving faster because you have a pair, because it’s a single person moving faster. If you have a single person making poor decisions, and maybe moving very quickly but creating this monstrosity that’s going to be impossible to maintain, sure, you’re moving faster for now, for the next few weeks. But then, all of a sudden, when defects come in or change requirements come in or whatever, and you start needing to adapt the system to meet the new demand, that’s all of a sudden when things start to slow down, because you didn’t slow down to begin with. Roy: Yeah. The way that the example is set up in the article, it’s very tipped in favor of the single programmer, and not in favor of a more, I would say, real‑world scenario, or at least a scenario that we see with our clients that have a dynamic application or a legacy system, or they’re trying to build a new product. They need lots of creativity, and they need that collaboration, so that they can get lots of different ideas, and so that there’s the redundancy. Those are the things they need. They don’t need people just pumping out code. Knowing What To Build Is The Biggest Problem Clayton: That’s, I think, we see in almost every organization that I’ve ever worked with. The biggest problem has always been with figuring out what to build. Not building something quickly. Building something as fast as possible has never been the issue. Roy: I would say the other thing, I think, that we see a lot is there are scenarios where saving money is a beneficial thing. I think this article comes from the standpoint, the fact that they bring it up in the very beginning, that Agile is sort of not very good with economics. Or at least, that’s the claim they’re making. Drives to the point, I think, where all they really care about is the bottom line. Which, you know, I think if you spend enough time in the community you realize that going faster and more better, faster, cheaper. That line, which is, I think, how a lot of people view Agile, maybe Scrum especially. Clayton: And Lean as well. Roy: Especially with Scrum, if we can do Scrum, then our teams will be faster. They’ll be cheaper. They’ll be better or whatever. If that’s the only thing you’re driving for then I think this article is appealing to you. If all you care about are dollars and cents. Clayton: Maybe Agile isn’t for you if you’re doing that. Roy: Right, and that’s why I would say that you probably don’t even have the culture in your organization to support pair programming if all you care about is the bottom line. Because there’s no way you could look at a pair versus a single person and determine that, “Oh, the pair is more expensive, but that’s OK.” That’s not going to be your mindset. You’re going to think of them as, “This pair is more expensive,” and you’re not going to see the benefits that you get from pair programming. So you’re just going to ignore out of hand which is who this article appeals to. Economics Of Pair Programming Vs Value Of Pair Programming Clayton: Actually, it’s a huge disparity between thinking of these things as just a set of processes and tips and tricks to try to make things more efficient or to make things better, rather than looking at it as a value system, where you are completely changing the way that the human beings within your organization interact. Roy: You’re changing the way that people will write that software. Clayton: Right. The Fallacy Of Decision Making Slowing Us Down In Pair Programming Roy: The closing point about divided work. I thought this was just another one to seem kind of ridiculous out of hand as well. I don’t think there’s anything that you could compare between pair programming, two people sitting down writing software like a software feature. I don’t think that’s comparable to military command whatsoever other than the fact that there are two people. The idea that you would say, “Divided work can be harmful because look at these examples of things that don’t work.” They’re not the same thing. It’s apples and oranges at that point. Clayton: Let’s look at it from the perspective of decision making ability, right? Where if you have two people sitting in front of a computer and they have to make a decision? They could potentially argue about it for half an hour to an hour. In the software development world, like arguing about something for half an hour to an hour is not big deal. But, I could understand in the military engagement that might be a huge problem. Roy: Right. [indecipherable 13:04] means software is malleable, right? Clayton: Right. Roy: You and I could sit down and pair program and we could come up with some solution. Then, maybe we go away for the weekend, we talk to some friend and they mention something that triggers an idea. We can come back and change that. There’s nothing. You can’t change sending your tanks into battle, and you can’t just do over. There’s no undo. Clayton: But, it is pretty common to see, especially large groups get crippled by shared indecision. It’s like everybody wants to go in a different direction. I can definitely see that extending all the way down to pairs as well, where two people with fundamentally different mindsets want to go in different directions. But, I think that ends up being a much large organizational problem in that probably speaks towards a lack of shared vision for the project. Because of everybody is on the same page where their project’s headed, then the implementation details of going one direction or another, if they’re both headed in the same way, it doesn’t become as much of an argument. Roy: I’ve seen that on teams where pairs will have very…especially, if you get two people that are very strong willed. They will have very different ideas of how the system should be architected or whatever the case may be. But, when the team doesn’t have trust and they don’t have collective code ownership with standards, that’s when you get people who say, “We should use this library.” Then, the other person says, “No, we should use that one,” when really it’s the team that should basically be figuring out, “When we have to solve this kind of problem, we’re going to do it this way.” [crosstalk] Roy: Once you get over that problem, and you say, I think a great example that we always have with the old Integrum was authentication stuff. There are 50 different ways you could do authentication and rails. We picked one and that was how we did authentication. That solved the problem of two people pairing and saying, “Well, my pet library that I think is really great is this one.” Then, the other person saying, “No, no, no. We should do this way.” Then, it was you had two different ways in this project that were inconsistent with what the team thought was the standard, if you can get over those kinds of things. That’s how you can solve some of those problems that they might seem like problems with pairing, but I don’t think they really are. Pair Programming May Highlight Organizational Dysfunction Clayton: That’s true. I think every single one of the items you listed really speaks towards larger organizational problems that have absolutely nothing to do with pairing. Like if these are the things, if these are reasons why you don’t want to do pairing, then maybe you shouldn’t be doing pairing yet because your organization is not ready and your organization needs some significant changes before you do. Roy: If you’re totally swayed by the economic argument, then you’re missing all the other benefits that you get. If that’s where you are then you’re not ready to be awesome. If I put my Derek hat on for a second, I would say, “It’s expensive and it’s difficult to be awesome and if you’re going to fall back on some excuse about how it’s too expensive with all these kind of bullshit calculators that you wrote in excel, then too bad. You don’t get a taste of the awesome.” Clayton: Fair enough. Roy: Thanks. See you next time. Clayton: Bye‑bye.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. 1. Test Driven Development Clayton: Today, we will be talking about the much talked about Seven Agile Best Practices That You Don’t Necessarily Need To Do article. If you haven’t read it, it’s on the Agile DZone. It’s called Seven Agile Best Practices That You Don’t Need To Follow by Jim Bird. We’re going to talk a few minutes on each of these. First one is test‑driven development. That’s one that somehow became synonymous with Agile teams, that Agile teams do TDD. What do you guys think? Do you have to do TDD? Derek: No. Roy: Yeah, I’m going to say that. Clayton: [laughs] Next. Let’s explore a little bit why that became so pervasive. Why does everyone thing that you have to do TDD if you’re doing Agile? Derek: Because there is a difference between Agile and good. So it’s like if you want to be good, you have to do TDD. If you just want to be Agile, like, “Hey, you don’t need to do TDD.” Roy: Also, there’s a huge feedback component to Agile, right? It’s all about quick iterations and getting feedback early. I think test driven development is the programming embodiment of that. It’s the idea of asking for feedback before you even start coding and then, gaining feedback as you code towards the failing test. Clayton: Do you think it would be fair to say that you would have to do TDD if you were doing extreme programming? Roy: Yeah. Derek: Yes. I would say you would. I don’t remember his full arguments on this, but I think it comes down to studies say TDD is not as good. If you know what you’re doing, then TDD is good, but if you don’t know. The only time that I really say that TDD should be super optional would be if your start‑up, you’ve got a limited amount of money and you have to meet the next date and slow at TDD because you don’t know how to do it. If you are competent with TDD, there is no reason not to do it. If you are going to be long‑term with a project, then there’s no reason not to do it. Roy: So part of the argument also talks about that statistically there’s an increase in complexity with TDD, oftentimes in terms of design, which I’d have to make assumptions, but I’m assuming it’s based off of probably not knowing how to do TDD properly, like abusing the crap out of mocks and spies and all of those patterns, and creating tests that are really brutally coupled to the specific implementation. Derek: It doubles the lines of code, so therefore, it’s got to be twice as complex. Roy: Right, when people, when teams get… 2. Pair Programming Clayton: Speaking of doubling, pair programming. Do you have to have two people working, do you have to do pairing if you’re on an Agile team? Roy: No. I feel like you have to be doing some form of pairing, like it may not necessarily be pair programming. But like people working by themselves, that’s not a team. Like leave Agile alone. Like I feel like a bunch of people working by themselves in isolation is not a team. So I almost feel like there has to be a pairing component in terms of like pair‑planning or pair design or pair… [crosstalk] Clayton: So the only way you can do that is by pairing? Roy: No. I suppose not. And I suppose they very specifically mean pair programming. Derek: Yeah, because I go to a whole lot of planning meetings that aren’t paired but I think that the people there are co‑creating solutions together. Roy: Sure. Derek: Again that’s one to me just like TDDing. If you want to be good, you probably should pair. If you want to be Agile, you don’t have to pair. Roy: Right. Some of the arguments are for the idea like, that some people don’t like to pair and some people will be slowed down by other people like that. If I’m really good and Clayton sucks, [sarcastic] using a realistic example, [laughing] then what we would have is like Clayton would be slowing me down all of the time, which I think is kind of the wrong way to think of that, it’s like I’d be teaching Clayton some awesome new stuff that he doesn’t know yet… [crosstalk] …and that’s more important in the long run. Clayton: They hit on or he hits on some of other common arguments about introverts versus extroverts and like smashing creativity and you won’t have time to be innovative and all that kind of thing. Roy: Like you won’t have the opportunity to go heads down and really solve complex problems but arguably, if you’re pairing properly, you’re turning all your complex problems into simple ones and you don’t end up with those types of huge complex Rube Goldberg solutions. Derek: I keep saying that you know the problem with exercising for me is that it leaves less time for eating ice cream and clearly this is a problem. 3. Emerging Design & Using Metaphors Clayton: OK the next one is emerging design and metaphor. One thing I don’t think a lot of people especially kind of the new Agile crowd I don’t think they really have embraced metaphor at all. I don’t ever hear people talking about the importance of metaphor not now at least. Derek: So I can’t speak without using metaphors, like I think you have to have metaphors to be Agile. [crosstalk] Roy: They have to be sports metaphors. Derek: Not always but usually, just because sexual ones aren’t very you know reasonable to do at work. I will remember a conversation with Chet, I believe about this, and I think they kind of said that XP dropped the metaphor at some point, and I want to say that the reason they dropped it is because it’s too fucking hard to do. Which speaks volumes for the shit that’s really good is hard to do. I think that people throw away the stuff that’s hard to do first. Clayton: Like BDD. If you look at that, and you talk about “Let’s have ubiquitous language, and let’s have a shared language.” That’s really difficult. And there are a lot of times where people can’t even think of a way to describe some part of the system, so they just throw it away. [crosstalk] They give it up. Roy: Exactly. You almost put it in the box of the metaphor: “Well this doesn’t fit our metaphor, so I guess we can’t do it.” Clayton: Right. One thing that he talks about in the article is changing the metaphor, or having to get rid of it, or being pigeonholed by it. If the metaphor is meaningful, I think you can make it work most of the time. If you need to change it, I think you can have a good reason to change it. Roy: It’s interesting to pair this up with emergent design because I don’t necessarily put those two in the same box in my head. Emergent design, the idea being “I’m not going to design this entire thing up front. I’m going to be able to build on top of it as it goes on.” Clayton: Then that’s some of the fallacy that in Agile you never talk about design. This is, in practice, not true. I think if you go to high‑performing Agile teams, they’re talking a lot about design. They just don’t do the huge design up front stuff. But, they don’t not talk about it. Roy: And, it stays flexible the entire time, so nobody’s totally stuck on a particular interpretation… Derek: [sarcastically] How are you going to grow your architecture e‑peen if you have emergent design? Now, come on. Clayton: There you go. [crosstalk] Derek: I want to back on this one a little bit. Look at some of the most prolific onboarding applications of computer history. If you look at Twitter, if you look at Facebook, if you look at some of these companies that have gone from zero users to several hundred million users in a very short period of time, all of their architecture was created using emergent design from a standpoint of they didn’t know what they didn’t know. I believe there’s an article on this. We’ll try to see if we can get it in the show notes. Twitter had done a ton of performance testing. They had done a ton of load. They had done a ton of stuff where they could deal with literally hundreds of thousands of follows per second happening on the system. What do you know? Ashton Kutcher goes on “David Letterman” and says, “I want to be the first person to a million followers. Everybody go follow me right now.” Total edge case in, “Yes, we support a hundred thousand users following another user, but we don’t support a hundred thousand people following the same user in a one second time frame.” How do you deal with those things that come up? You can’t cover every edge case, and I think continuous deployment has moved us to a point where what you’re really doing is saying, “We discover by the feedback the system gets us.” And, we’re able to adapt and deploy so continuously and so quickly, that it doesn’t feel like we have architecture problems. I think this is something that the old‑school, old guard just can’t deal with. It’s like, “No, but we have to get it right the first time!” Roy: I kind of feel like if you don’t have some form of emergent design you are, by definition, not doing Agile. Derek: You’re screwed! Roy: Right? Because, other than the human relationship and that component of it, I feel like the ability to pivot and change your mind as you gain new information is the fundamental core. 4. Daily Stand-ups Clayton: What about daily stand‑ups? Roy, you just mentioned the human component. Getting together and talking to other people on the team on a daily basis. Is that something you have to do? Derek: Is that what they said? I don’t know the wording. To me, if they said “daily stand‑ups,” no, I don’t think daily stand‑ups are mandatory. Do I think the people on the team need to talk to each other at least one time throughout the day? Yes. I think that is necessary. Clayton: To really nit‑pick, I think what they’re really getting at is, “Does everyone have to stand up?” Roy: We didn’t. We did an entire episode on whether or not you should stand up during a stand‑up. We came to determine that yes, you should. Derek: I think it goes back to “Do you want to be good, or do you want to be Agile?” I think you could be totally Agile without doing any kind of formal stand‑up. I think if you want to be good, it’s just like using a white board versus using a tool. Can you do things without using white board? Sure. But, you get some benefits from the other one that you don’t. Roy: I’m guessing that part of this is driven through experiencing bad stand‑ups that are a waste of your time. Because just like any other meeting, you can screw this one up, and make it a total waste of everyone’s time. Where it’s just like a status report, and I go, “Yesterday, I did X, today I’m going to do Y, no blockers.” Nobody is listening to each other. You’re totally defeating the purpose. Derek: I see another one too with a lot of teams that are co‑located and within the zone proximity. “We sit next to each other all day long and we pair, so why do we need a stand up? We’ve got a physical board. We sit next to each other. We talk to each other every day. Everybody already knows what everybody is doing. Why the hell do we need to do a stand up every day?” Clayton: I think what’s funny is that most the time those people don’t actually know what is happening. Derek: No, they don’t. I see that too. 5. Collective Code Ownership Clayton: Speaking of everybody knowing everything, what about collective code ownership? Is the idea that everyone can work on any part of the system and everybody knows the system to some degree? Is that a reasonable thing? Or should you say, “It’s OK that Derek doesn’t know how to do this right.” Derek: Some people are too dumb to work on parts of the system. Roy: Right, they shouldn’t be allowed to work on parts of the system. Derek: People won’t say that, but that’s what they’re saying when they say that. “Not everybody is as knowledgeable, not everybody is a god like me.” Roy: Actually this article does say something specifically along those lines and not everybody should be allowed to modify parts of the system. Clayton: I think what they’re getting at is it’s not realistic that that is the case. It isn’t realistic that everybody on the team can work on any part of the system. To me that sounds like, why is your system so complex? Derek: What it sounds to me is why do you hire stupid fucking people? If you have people that you hired to code and you don’t let them go to certain parts of the code because they’re not competent to go to the code, why are they employed by you? Clayton: That’s a good point. Roy: Or if you don’t let them go into the code because the person that owns that code is extremely territorial over it, then why do you have that territorial person employed, and why are you letting them boss you around? Derek: I don’t know if you could be Agile without having collective code ownership. The first time you have to say, “Sorry, Clayton is on vacation, I can’t really deal with this problem.” By default, you are not able to respond. 6. Writing All Requirements As User Stories Clayton: That’s true. You couldn’t respond to that change right? We’ve heard that user stories are a representation of a conversation. Why wouldn’t you write every requirement as a user story? Is it un‑Agile to have a requirement on the system that isn’t a user story? Derek: This one I think they’re pretty in line with. I think that the multiple formulas that exist out there are really good. I think they help people write good, small parts of the system. I think somebody could go write one or two sentences on a board and still get stuff done just fine, if you have the conversation. I think the actual card and the conversation are far more important than the stories themselves. Roy: One of the values of a user story is that it can’t give you enough information to substitute for a conversation. I can’t write a user story that tells you everything you need to know, so you have to come talk to me. Clayton: They talk about using a use case, or a test case, or a wire frame, or something which they are great examples of things you can add on to a user story as you have that conversation, but I don’t think it’s an and/or. If you were to say that you didn’t write everything in user stories, I could see somebody getting a little crazy with writing too many use cases, and then you go off the deep end in that regard. Roy: Right, and then before you know it you have a full spec outline ahead of time so that we don’t have to spend this entire time arguing with the developers and negotiating someone’s criteria. Derek: You get off the rails pretty quick, right? If you don’t keep it nice and short then we start assume, “Oh Roy, you’ve got 80 pages of Cucumber specs for me.” So I don’t need to actually ask anything about the system. Roy: It’s all here. Derek: Clearly you’ve thought of everything, right? 7. Relying On a Product Owner Clayton: The last one talks about relying a product owner. The single ringable neck and having one person that is supposed to be the gateway to the customer. If most Agile shops are doing some form of Agile are probably doing Scrum and they probably have a product owner. How did all the Agile people miss the boat on this one? Roy: I kind of think it would be OK if there was more than one product owner. It doesn’t necessarily have to be a product owner as long as there is just one backlog. You still get into the problem of if you have this one backlog and you have two different people that are both your boss. They’re arguing over what a specific story is supposed to be like. I can still see a ton of problems there. You have to have somebody that makes the final call. Somebody at the top of your organization has the authority to say this and not that. Clayton: I think there’s a distinction between being the voice, the single point of contact with a customer and the person that makes decisions. Should the only person that ever talks to customers be one person and the product owner? Probably not, and you should probably find lots of different ways to have that interaction and get that feedback. If you had more people talking to the customer and more people making decisions, I don’t think that’s what you would want. Derek: This one is really odd for me in the sense of I’m starting to find that actually in some ways I believe that having a product owner is non Agile. Part of it is, I think that if a team, when I look at small startups and I see them do things with no product owner. They really are doing things by committee. They really are doing things by unanimous decision. I think it’s because they have got strong vision, and they’re aligned. To me the need of having a product owner who is the one all that says, “I’m going to make the decisions so we can move forward.” I think that’s almost a crutch that says that you’re not providing enough vision that the team is actually aligned behind the product, because if they were, you could get to a unanimous decision fairly quickly. You could be biased towards that action. Roy: That’s a really interesting point. I hadn’t thought about it like that. The reason why we always think that you need a product owner is because you have dissenting viewpoints on which way to go. That’s because tradition decision making is made by majority vote, in which case you have a bunch of people that aren’t happy. If you’re always unanimous, then you have a team that is acting as one anyway so it’s like it’s one single [inaudible 00:16:15] . Derek: You probably have a much better product. To be clear, I think product ownership is very necessary is most organizations because they’re having to deal with them as a dysfunction to how they currently work. I think you could absolutely be on a highly Agile, adaptive, high performing team, and deliver great product, and not have a product owner. Clayton: I think we’re out of time. Thanks guys!

Roy vandeWater: Hello, and welcome to another episode of the Agile Weekly Podcast. I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Clayton Lengel‑Zigich: I am Clayton Lengel‑Zigich. Standard Patterns Of Growth Roy: Today we are talking about establishing a growth path within an Agile organization. The general idea that you have a bunch of employees within the organization that all want to improve themselves, or maybe don’t want to improve themselves. How do you show them what they can do to get better, and incentivize them to want to do those things? Clayton: Do you mean like get a raise? Roy: Sure, I think that’s the classic management 1.0 way of incentivizing people to get better. Clayton: “I want to climb the ladder, so I can make more money.” Roy: You start out as junior developer, you go to senior developer, then you become manager, then you eventually become a [indecipherable 00:52] level officer. Each one of those titles is associated with a salary band. I think that’s… Clayton: Standard corporate stuff? Roy: Very conventional. Then you have less people at the top, so it’s a standard pyramid structure. What else can you do? Money As A Motivator Clayton: I guess we should talk about money as a motivator. I think there’s some literature out there, and some studies that show for knowledge work, money is not a great motivator. There are probably some people who still associate money as a status thing, or titles as a status thing, so they want that thing. Roy: That’s still the way that most businesses do it today, so I would definitely say the majority of people think that way. Clayton: Would an Agile organization be somewhere that people are so engaged in the work that giving them a bump in their pay is not “Make it or break it” territory? Roy: There are definitely studies that show that once you get beyond a certain salary range, I think I heard you talking about it, Clayton. I think you said 80K or so. Clayton: I think that’s what is in Drive. Roy: I’m sure that number may be different, it’s probably different for every person. But that beyond a certain salary range, people are much more motivated by the work they do, and the people they are surrounded with, and the environment in which they work, than they are by the actual salary. If you look on the list of things that they look at, as far as making a decision to switch to a new job, it’s very low on the list. They need to make enough to survive, but other than living comfortably, they don’t really need all that much money. Most people aren’t choosing a new job to get rich. The people that do that become entrepreneurs. The Free Market Dictates Something Different Derek: I think some of the things you potentially limit is if you have good people somewhere else that you are trying to attract, the problem is if you say 60K or 70K, or whatever that number is, the number you care about, then as long as you provide meaningful awesome work, that’s great. What if there’s this really great person but they’re making 130,000, and their mortgage and their car payments and everything total up to that? In order to attract that really good person now, that person has to sell their home, sell their house. I think that if everybody was level set starting at zero, I absolutely think that that works. But how do you be competitive, and luring good talent, when other companies aren’t following that same suit? What happens? How do you deal with that? Roy: I can understand what you’re saying there, but I think there’s a difference between trying to lure people over with your culture and then dropping the salary down, and matching their existing salary but then luring them over with the culture. What I’m saying what wouldn’t work is having a crappy culture but having an awesome salary, that’s better then what their making now. Making Great Culture The Baseline Derek: Yes, I agree with that. But I think one of the things that you start to do is, do managers start to have a conversation where they really talk about, “Hey let’s level set, and it’s really not about money, and let’s make the culture really awesome.” You make the culture really awesome and you start to set this baseline. What happens when there’s an incredible employee that everybody wants on the team. Everything’s great, but now you’re going to pay that person twice what the current people are there because they can’t do it? There starts to become some issues. I absolutely agree that throwing money at the problem to make existing employees more happy is not a path to being good. If you’re paying someone 80K, and you’re giving them crappy work and they’re not doing what you want, and they’re not learning, and they’re not growing, giving them 90K is not going to make them happy, is not going to make them grow. It might bump them for a few months or a year, but then they’re going to be right back to where they were at. But I think it’s sticky if you just start to say, “Oh we don’t need to pay anybody more than the base that Dan says, and then life is good from there.” I don’t think that’s a very realistic approach either. A Better Path Of Career Advancement Clayton: Getting back to your original question about growth, or career growth. I think you had talked about how do people advance, and we were talking about the corporate ladder. What I’m wondering is, what could a manger or management team do to outline some things, like a better path? What could they do to set expectations so that people knew, “Hey, in order to level up, these are the things I’d have to do”? Roy: I feel like those expectations and those things to level up need to come from the team, or need to be based in the reality of that organization. Just saying “I need you to work twice as much,” if there is no demand for that, that may not be realistic. I feel like it needs to be very applicable to an individual team. Certain teams may value a certain type of behavior more than others. Holding Yourself Accountable To Your Team Derek: Let’s say that, as an organization, that you decide that technical excellence is very important. Would it be fair for someone to say, “Hey, if you want to level up, and be viewed as the next level in the organization,” that you would always demand technical excellence? Here are some different ways that you could show that that’s happening. Is that the kind of expectation or metric you could use? Roy: I kind of agree with that, but like I said, I feel like if people feel they are holding themselves accountable to the team…I am a part of a team of so many people. As a team, we run into this problem, and as part of solving that problem, I need to get better technical excellence. Let’s say we are a team that’s having huge problems with technical debt. Because I am passionate about the team, and I demand that my team does great work, I am going to have to become passionate about technical debt in order to make my team great. But if it’s not a problem, if technical debt’s not a problem, for whatever reason, then maybe I don’t need to be awesome at technical excellence. That’s kind of where I am coming from. It’s applicable to the individual team, and the problems that they are facing. Encouraging People To Learn Derek: I think there’s a couple of problems, potentially, with that. One is you are saying that “I can impose on you that you have to grow, you don’t get a choice about that, but then it is your choice on what you can grow on.” I’d say, “If it’s so important that I get to make all the choices, why do you get to make the choice whether I grow or not? What if I think I am really great, and I don’t care, and I don’t think that I need to grow to deliver this product? STFU.” The only reason I bring it back to that is I think that what we’re really talking about is, “How do you encourage people to learn?” My answer to that largely is, “I don’t think you can.” What I mean is, I think that you got growth‑minded people and you’ve got fixed‑mindset people. I think that the first thing that continuous learning organizations have to do is starting to say “We’re not going to waste our time with people who don’t want to learn.” Converting People From Fixed Mindset to Growth Mindset Roy: But you can convert people from fixed mindset into a growth mindset. I think that the best way to do that would be through the team, and have a team really be pushing for that type of behavior. As a manager, I wouldn’t be encouraging people to learn. As a manager, I would be demanding greatness from a team, and the team would figure out a way to help Clayton learn whatever. Derek: But wouldn’t it be fair for the team and say, “I don’t want to fart around with trying to make Clayton learn. I want to do this other really magnificent thing”? Roy: Yeah, after they have tried to make Clayton learn. Derek: But why? If you are going to totally give them the power to do what they want as a team, why can’t they just say “Because we don’t want Clayton on our team?” Self Direction vs Self Organization Roy: It’s too easy to cast away people that could potentially be great, just because nobody gives him a chance. It’s really easy to make the easy call of, “Oh, we just don’t want this person, because it’s really difficult dealing with their problems.” Derek: I guess where I’m getting is, I think that what you’re saying is that there is a difference between self‑direction and self‑organization. I think it’s totally OK for an organization to say, “We think, for our organization to be successful, people need to have these type of skills, or need to have these type of abilities, and that we’re going to chart your success how you’re getting to those.” Earlier you were saying, “I don’t think you should chart what I should be growing towards, you should let me totally define that.” Roy: I don’t think that’s what I intended to say. Maybe that’s what I communicated, but I think I failed to communicate, if that’s the case. Lack Of Organizational Mindset Derek: I think if you’re going to say you’re stuck with certain people, potentially, on your team, and you are stuck with that there is an expectation to learn, I think it’s OK to say “This is the expectation of what we expect you to learn, and that we can chart, do you have growth towards that?” I think in a perfect world you’d say “Hey, you work with the people that you want to work with. If people are dragging you down, don’t work with them. You define how you want to grow, and what the best skill set is.” I just don’t think most organizations are mature, and have teams that are mature enough, to fully operate in that capacity. Roy: That’s true. Most organizations aren’t even working in a capacity where any of the individuals of the team have the emotional maturity, or interactive tools, to deal with giving people feedback. If I had a problem with somebody on the team I wouldn’t even know how to address that. Maybe the best thing I would know how to do is go to my manager and complain, and that’s it. Or maybe complain about it behind their back at the water cooler. But I don’t know how to actually deal with a problem. Derek: I think we even did this at Integrum at one time, maybe if we can find it, we’ll post it. We listed out like, “Hey, to be a good Agile coach, what are all the skill sets that you need? What are the things you need to grow in?” and then like, “Hey, can we self‑assess ourselves to say, ‘Hey, if we’re looking at this, where am I deficient, where could I grow the most, and can I be deliberate?’ Can I do deliberate practice on how could I be better at coaching somebody?” Roy: Even in that, I remember when we did that exercise, we ran into some specific technical issues, implementation details that didn’t work out for us. Derek: I guess that’s part of [indecipherable 10:55] . I think this is really difficult stuff to do. Simple Rules Clayton: Derek, you’d mentioned the concept of simple rules. I think it was from…What’s that podcast? Derek: “Partnerships and possibilities.” Clayton: You mentioned simple rules, the idea of having very simple things. I like the idea of saying, “To be a certain level of senior software developer,” maybe, “You value openness,” or something. I think there’s a lot of different Agile frameworks and different things out there that would list, say five, six values that are pretty easy to adopt. Something like openness seems very simple, and there’s probably a lot of different ways that most people do not practice being open or transparent. I think that’s a very easy indicator, where you could say, “What behaviors have you changed, or what behaviors have you adopted, that show that you value openness?” Those are the kind of things that you would want to drive towards. As far as growing on the team or in the organization, if you had a list of those kind of things, it seems like it would be fairly easy for individuals to pick those things, and decide which ones they think. Maybe they would need some help with the self‑assessment part, or becoming self‑aware about how good or bad they are at those things. Roy: It’s funny you should mention that as a specific example, because actually I had a discussion earlier today about openness. The problem that the team was having was, they have individuals on the team that are braided by the rest of the team whenever they make a mistake, and that those types of mistakes are never forgotten or let go, it’s constantly being brought up. In this case, estimating for example, they estimated higher than everybody else. It’s like, “Oh, look at this person who doesn’t have any experience and estimated higher than everybody else.” Now, they’re afraid to make any estimates at all unless they look at the team to see what the team has done first. Making fun of that didn’t allow for the openness, but I don’t think the team is even in this point where they realize that their behavior caused this non‑opened culture. They probably think, “We totally criticized him, and that was nice and open, and we know how he feels about it.” They didn’t realize that they shut down the very thing that they claimed to probably have tried to create. How Much Effort To Waste Before Giving Up Clayton: Derek, in your example where the team would decide, “Hey, I don’t want to help this person try and learn anymore, I don’t want to make them learn anymore.” In a situation like that, how much effort would they have to put in before they said, “This person just doesn’t want to learn, so I’m not going to waste my time.” Derek: I think that’s the organization’s call. I think it’s either you give people the power to say who’s on and off their team, or you give people and say, “Hey, here’s your team, and you guys need to learn how to work together as a team.” I don’t think there is a right or wrong to that. I think there’s pitfalls to both sides, and if you’ve got somewhat immature people on teams, it gets really petty that you are just swapping people from team to team. You’ve got somebody who doesn’t have skills, who doesn’t want to learn, so they go from one team to the next team, to the next team. Maybe they are a reasonable potential talent, but nobody’s mentoring them, or giving the time. I think there is some danger in there unless you’ve got some mature organizational pieces, but I think it could go either way. Roy: I think we’re about out of time, so thank you for joining us. If you have any opinions, please join us on the Facebook page, at facebook.com/agileweekly. We’d love to hear what you think about this. Thanks, bye bye.

Clayton Lengel‑Zigich: Welcome to another episode of the “Agile Weekly Podcast”, I’m Clayton Lengel‑Zigich. Jade Meskill: I’m Jade Meskill. Roy vandeWater: I’m Roy vandeWater. Clayton: Joining us today is David Foster. Say, “Hi, David.” David Foster: Hi. Jade: No, say, “Hi David.” Roy: Hi, David. Clayton: All right, good job. [laughter] What It Means To Be A Senior Developer From A Manager’s Point Of View Clayton: As usual, it’s guest choice for the topic. We wanted to talk a little bit about what it means to be a senior developer, and maybe even more specifically from a manager’s point of view. How do you define those things, and what’s the whole process? David, this is something that you’ve been working with for a little bit now. Can you explain where you are, and what struggles you’ve had so far? David: There’s three development managers in our organization, and we’ve been working on this for the last several months. We recently transitioned from an organization that was definitely more hierarchically driven. We wanted to be able to move into more of a management stance where we’re actually empowering the teams, and letting the teams make decisions on their own. Which of course calls into question, what is our role as managers? We look at it as if the teams’ products are the software that they’re actually building and delivering for the product owners, then our product is actually the teams themselves. What would be our responsibility in helping the teams to be better teams? We decided that one of the things that we could do was try and set a vision for what we saw as being the kind of characteristics that a senior developer should have on a team. A “Senior” being defined as somebody that would help with the growth of the team, help with the creation of the team, and making sure that the team is running well, as a team. They would be a lead, in that respect. Titles Are Stupid Clayton: I think some people would say, “Titles are stupid,” and, “Why do you need a senior developer role?” What do you say to that? David: I would probably agree with that, from the perspective of having an organization that is completely run by titles, where you’re just pigeonholing people into some position and role, based on what you’ve hired them for. We definitely want to have teams where the teams can organize themselves, according to whatever the context is that they find themselves. What is the problem that they are trying to solve? In order to distill that into what we’re looking for, the criteria we came up with were really more along the lines of the kinds of things that we would expect to see from an Agile team member. Not so much somebody who’s just a senior developer, as defined by typical enterprise cultures these days, where it’s defined by the kinds of things that they do from a skill perspective, and the kinds of things that they do from the coding perspective. These are really more of the kinds of skills that we would see in an Agile team. Loyalty And Length Of Service Roy: What about loyalty? I feel like the title of “Senior” is oftentimes a reward for loyalty. Like, “I’ve been with this company five years. Shouldn’t I get some recognition for that?” David: Yeah, that’s basically what we find ourselves with in the company structure, because the company definitely has that, from an HR perspective. They definitely have that, where the actual salary is banded to a specific kind of a title. There’s a senior‑level band, and that has a salary range that’s associated with it. If you want to actually progress according to the company’s HR department, then you have to be able to fit within these bands. That’s kind of a constraint that we had as a management team. We want to be able to have a fairly flat hierarchy, where we’re not really telling the teams what to do. We’re not really acting in the traditional role of a manager, the teams can decide for themselves. But we still have to be able to help them along with a career path within this organization that is still hierarchical. Impact Of Not Having Hierarchy Clayton: Jade, I was going to ask you. We’ve never really had a big hierarchical situation, or really big on titles at all. Do you think that ever had a negative impact with Integrum? Jade: It’s something that we’d discussed a lot when we were first starting the company. We tried really hard to map people into all these different levels. It just got so confusing and so hard that we decided to throw it out the window and say, “Who needs this crap? We’re going to do this totally differently.” As far as did it cause any problems with the organization? I think it caused problems with individuals who are looking for that recognition. Either they wanted it on their resume or for their ego, or whatever it is, they wanted to be called a “Senior Developer.” As from the actual organization standpoint, I don’t think it caused us any problems. You guys were there. What do you think? Roy: I remember interacting with a few people while I was still in the intern, and that I was at first somewhat treated a little bit as an intern, and then there was somebody else who considered themselves a “Junior Developer.” I don’t think anybody in the organization would have said, “Oh, this title is ‘Junior Developer.’” I remember that being kind of interesting, because I remember acting not like an intern, and it very quickly stopped. I was no longer treated like an intern. I still had the lack of knowledge. I had the amount of knowledge as an intern, I just acted a little bit more confidently. I think that was interesting to see, that he was still stuck in the “Junior Developer” role, and couldn’t get himself out of that, to step out. I don’t know, Jade. I think you know who I’m talking about. Did he actually have… Jade: Is this the person that became our senior intern? Roy: Yes, that’s right. Jade: [laughs] Falling Into The Prison Of Your Assigned Title Roy: Was that a self‑assigned title? Jade: Yeah, very much so. I think he mentally assumed the role of intern, instead of imagining himself as coequal with the rest of his team. Roy: Because I see that as one of the big problems with titles, is you put yourself in the box. David, we’ve had this interaction with a few different people, where somebody says “This is my title. I shouldn’t be doing this other stuff. Even though I am passionate about it, and I think it should be done, that’s not me, that’s not my title. I shouldn’t be doing that.” David: Yes, we were definitely running into that. We know that by actually going this route, which is a complete change from what existed before, that there’s going to definitely be a major friction created by this. We expect that we’re going to have people that are going to just be completely uncomfortable by this, because when we actually show these criteria that we would expect from one of these developers, they’re not oriented along the ways that they’re used to. “I just want a check list.” It’s not going to be like that. It’s really going to be “These are the kinds of things we’re looking for out of a senior‑level developer, and we expect you to figure out, and set your own goals, for how you’re actually going to achieve these things that you may be lacking.” That is definitely different. We don’t really know what that means, in terms of how many people are going to be uncomfortable with that. But just like you said, Roy, we’ve had some people that have already butted up against that. “We’re empowering you to make decisions, we’re empowering you to find solutions for yourself,” and there are people that are really uncomfortable with stepping out of their box, their prescribed box that they’ve been given. It’s definitely going to create some friction. Having A Roadmap To Progression Helps With Self-Awareness David: I’ve worked in jobs that have a traditional hierarchical organization, and one thing that was nice about having all those hierarchies was that you knew what was expected to go to the next thing. Sometimes it was very cut and dried, and I think that’s one thing that’s difficult if you have a very flat structure. It’s hard to know what you need to do to improve. Most people I don’t think have the self‑awareness to realize where they’re deficient, or where they maybe could be more valuable, if they were to do certain things. I think that’s something, at least the stuff that you’ve been talking about so far, that I’ve liked about the way you guys are trying to define what it means to be a senior developer. It’s that those things are very tangible things that I think you could grow towards. If you looked at one of the requirements and said “I don’t really understand what it means to do X, Y, Z,” I think you and the rest of the management team could say, “Here are some more fine‑grained details about what it means to do those things.” I think that could be very helpful for people who want to actually grow in their career. Roy: I think it’s important, though, that there aren’t step‑by‑step instructions. Because if you have step‑by‑step instructions, anybody could follow it. At first that sounds like a good thing, but part of what you’re looking for, as somebody who is in a lead position, or whatever, is a mindset and a self‑awareness that you can’t get. If you tell somebody, “Just do the grind. Follow these steps. Kill 300 boars in the forest and you’ll be level 12, then we’ll give you your salary increase.” That shows that somebody’s willing to throw themselves against a wall for however long, but that doesn’t necessarily show that they have self‑awareness, and leadership ability, and an understanding of what’s going on. That insight to be able to figure out how to personally improve themselves towards these values is very important. Personal Improvement In Relation To Compensation Jade: How is personal improvement tied to compensation? David: Difficultly. At a very high level, what we’re looking at is…We don’t really have any junior developers, we really have senior‑level developers and then we have mid‑level and then we have what are called “Principals,” which are above a senior‑level developer. Roy: When you’re talking about these titles, you’re talking about people who have these titles, or people who actually fit these roles? David: I would say that people that are in those titles, that are in those job bands. I would not say that these are people that are actually necessarily in those roles, as we’re trying to define them now. A mid‑level would be somebody who’s…In general it’s somebody who’s a really good member of the team. They’re definitely a contributing member of the team, they definitely work well with the team, and they’re learning how to be a more productive member of a team environment. The senior would be somebody who’s actually able to help the team grow. They’re helping to nurture the team, they’re helping to grow the team, working with the product management, or the product owner, to really help make the team be more productive. Then they’re able to, perhaps even go and create a new team, start a new team. We take an individual that is actually operating at a senior level and actually say “OK, we’re going to build a new team around you, because you definitely understand those principles.” A principal would be somebody who would be helping to foster the creation of maybe multiple teams. That’s kind of how we’re looking at that. Compensation would be tied probably more towards those levels of activities. Multiple Skillsets Necessary To Build Strong Teams Jade: So what happens if you come across someone who’s really great at getting the team to be cohesive, to be effective, but they’re not strong technically? David: That is a team problem, and we would expect a team to try and figure that out. How they figure that out we’re not really sure, because we haven’t had a team empowered yet enough to actually address that. We definitely have that problem with some of the teams, but the teams have to be able to ferret out what that means to them. Do they want to just shelter somebody and keep them going along, or do they want to actually confront the issue and actually make some changes? Jade: What if it’s not important that they’re strong technically, the team’s good enough to take care of that? They’re really great at getting people to work together and assemble and do all the things that you need to do? Roy: That sounds valuable me. It sounds to me like if the team feels that this person is contributing a ton of value, maybe they don’t have that much technical experience, maybe they should be made aware and know that that’s an area of improvement. Trying Things Differently Is Hard On The Organization David: I think the personal performance, and performance reviews and all that stuff, there are people that are maybe exploring, self‑organizing teams, or doing things differently, or having a flatter organizational structure. It’s the same thing with facilities. You’re trying to do all this new stuff, and then you go to HR and they are operating in a much different capacity. For as much as I think the Agile community tries to shoehorn Agile stuff into HR, maybe it just doesn’t fit. This example you’re giving, Jade, think that is a totally reasonable thing. Why wouldn’t you be able to set the compensation or to have the person on the team? I think the answer is because they don’t fit into “Software developer level one, tier three” category, so you don’t know how much to pay them. You are trying to use this antiquated system to figure all this stuff out, and maybe you should just not worry about that, but that’s hard to do. You can’t just tell facilities, “I’m going to kick down the cube walls,” because someone’s going to freak out. That’s not how they operate. Jade: I think it’s a big challenge. Especially as we look at compensation, individual compensation has direct repercussions on your behavior on a team. It gets very complicated very quickly, as you start to muddle those things together. Roy: It gets really weird too, because sometimes you think you are rewarding a good behavior. You’re rewarding a good outcome, that can lead to some really bad behaviors. Salary Disclosure Is Taboo David: The most radical example of fixing that problem would be where the team has some salary budget, and you basically just tell the team “Here’s you’re budget, and you divide it amongst yourselves.” Jade: Yeah, there’s people that do that. David: Which is a very scary thing. Even for smaller organizations, that usually doesn’t fly. I think when it comes to payroll and compensation, those things are so stuck in the old way of doing things. Roy: Very taboo. David: Yeah exactly, it’s taboo. Can you imagine if you took the average kind of corporate Scrum team, even if they were a pretty good self‑organizing team, and you said, “Here’s everyone’s salary, and feel free to move everyone up and down the slider, according to where the team thinks they are.” I can’t even imagine doing that. Jade: We’re pretty progressive and pretty crazy, and we have not even touched that issue. Roy: Every time we talked about bringing it up, we keep switching over to something else. It’s crazy too, because from a logical perspective it doesn’t even make sense. The idea, and I don’t know if it’s an American culture thing or a world culture thing, but you are never supposed to talk about how much you make, and you are never supposed to bring that up with other people. You’re not supposed to know how much other people make, and if you do find out, you keep it to…Why is that such a cultural thing? Jade: That sounds like another topic. [laughs] Roy: Fair enough. Humans Act Irrationally On Some Of These Topics Clayton: It underscores the fact that some of this stuff gets int territory where we don’t act super‑rationally about things, which makes it even harder. I think we are about out of time. David, did you have any parting thoughts, or anything you’d like to leave behind? If there’s another person in your position who’s considering doing something, did you have any advice for that person? David: The simplest advice I could give is just figure out a way to get yourself out of the mix with the teams. It’s a really hard thing, as a manager, to want to go in and mess with things and to toy with things. The sooner you can get yourself out of that, the better off the teams will be, and being able to perform. Clayton: Great, thanks. Roy: Thanks. David: Thank you.

Clayton Lengel-Zigich: Welcome to another episode of the Agile weekly podcast I am Clayton Lengel-Zigich. Roy vandeWater: And I am Roy vandeWater. What Does It Mean To Revisit A Decision Clayton: Today we are going to be talking about the churn of revisiting decisions. I guess by that, what do we really mean, Roy? We mean a team makes a decision about maybe how to implement something or some approach of solving some problem. Then maybe even after the fact it gets, I guess, revisited or gets talked about again and kind of the impacts…Does that sound about right? Roy: Yeah. Clayton: An example that we actually both saw this week was a story got demoed to the product owner kind of informally and it got accepted. After the story got accepted, and actually on the board physically moved over to done, with the green pin, and the whole nine yards, someone on the team kind of started objecting about “well we really should have done it this way, and I wasn’t involved, and something, something, something.” What was that impact of that on the team, do you think? Roy: It felt really odd, because the team had made the decision to move forward in a particular way, and I think we kind of have agreed, probably not explicitly, but kind of agreed as a team, implicitly, that if you’re not there, then you’re going to kind of abide by the teams decisions. It sounded like this person wasn’t present when some decision was made, and when they got back, the story had gotten accepted and they’re like “well we could have it this other way,” and the team’s like “OK, yeah it could have gotten done this other way, but it’s done now, so why would we spend more time on it.” We delivered a value we set out to deliver and if it becomes a problem, we can revisit that decision. When There Is New Information Clayton: I see people revisit those kinds of choices when they make a decision based on the information they have at a certain time, and then they get more information later, and then they want to re‑hash it again. I think maybe what you’re getting at is: hey, we finished it, it’s done, we delivered some value, let’s just move on. Do you think there’s still room for learning new information, and fixing it, or making it better? Roy: There’s absolutely room for learning new information. Learning new information is always better, because it allows you to make better decisions moving forward. That’s the whole reason why we have retrospectives. I definitely think that, like in this type of situation where if it becomes a problem, we’ll totally revisit it and we might choose to solve it in a totally different way, since we now have newer information. Just because you have newer information, you have to be careful about whether or not the cost is worth the value that you’re going to get out of it. In this case, some features delivered that provide some value x. That feature could be rebuilt in a way that either reduces technical debt or whatever, but if rebuilding it, still only allows it to deliver value x, you have two choices. One that has zero cost, which his leave it like it is. One that has a significant cost. It’s going to take some amount of time in order to build it, but delivers the same value. If you look at it from that perspective, it makes sense to go with one that’s got zero cost. The Cost Of Re-Work Clayton: Do you think that an argument could be made that “It really doesn’t have zero cost because now we know something new. Now that we know this new thing that changes how we would’ve done it and we would do it so much better this time”? Is that the motivation you think that a lot of times decisions get revisited? Roy: I can understand why that would be a motivation for a why a decision gets revisited. But I would say like, “Great! You learned a whole bunch of new stuff. That’s going to be awesome. The feature’s that we’re building moving forward. Let’s build those because we don’t have a shortage of work to do.” Nobody has that problem. People who have that problem don’t have jobs anymore. Clayton: [laughs] Do you think that some of this conversation comes back to the simplest possible solution where you’re trying to do just the simplest thing you can do, which is often times very difficult to do the simplest, to deliver whatever that value is? Because that sometimes when you’re making those choices about what the simplest thing to do is, you maybe make trade‑offs or maybe you don’t get a lot of consensus? The Trade Off’s Of Technical Debt Roy: I think Derek’s actually been…I don’t know if he said it on the podcast before but I know that he’s definitely said to me in conversations before as saying like, ” A team that is not creating any technical debt while they’re moving forward is probably not a high‑performing team. A high‑performing team would be moving quickly and making the trade‑off of sometimes accruing some technical debt that they know they’ll have to pay off later in exchange for increased performance.” Clayton: That would be more calculated debt, not the big bottle of mess that… Roy: Right, exactly. It’s the type of debt that an investor goes into. Not the type of debt that a… Clayton: You get from running up your credit card buying stuff. Roy: Right. Exactly. Right. Decider Protocol To Make Decisions Clayton: One of things that’s in the protocols that we like a lot. We like to use decider to make decisions as a team. If you have new information later, you basically support the best idea that exists at the time. You have to have the faith in your team that they’re going to support the best idea. You can always come back and make a new proposal to change things but you would never revisit something. You would always be doing it in the spirit of moving forward. Roy: Well, the commitments, you are to support the best idea at the time, right? Regardless of where it came from or what it is, but while that’s the case, you will also always continue to seek to improve that idea or find a better one. Clayton: If you find a better idea, great, but your situation changes as well. You are no longer in the same green field state at the end of the course of the decision, right? Like in our example, you’re no longer at that same state where you haven’t built this feature yet. You now have something. That changes the scope of your decision. You can’t think of it in the exact same mindset as before you started it. Roy: Do you think if you’re using the decider because of the format for the decider protocol and the way that it is basically so structured to deliver that consensus, you never really are revisiting things because you are always making a new proposal to improve? Is that kind of what you’re getting at, I guess? Clayton: Yes, it is, but I have definitely found myself, in certain cases, with the decider feeling myself a little bit conflicted, because I felt like I had a better idea that completely against the previous Decider and as part of accepting, thumbs‑upping or glad‑handing a decider, you promise not to sabotage the decision. Sometimes, I feel like I’m sabotaging the decision when in reality I’m actually proposing a better one. Like I’m not really sabotaging it because everybody else on the team has the opportunity to thumbs‑down it, right? I’m just presenting the time with an alternative choice. Avoiding Decisions Until Certain People Are Present Roy: I think, everyone can probably think of somebody that they work with on their team that has a tendency to maybe revisit things or revisit decisions, especially ones that they were not part of. Do you think that’s something that a team should really be concerned about? If there are people on the team that are always bringing kind of the old, decided stuff, should they go out of their way to avoid making decisions until that person is there? Clayton: No. I think if you’re, see I’ve been thinking about this because I’ve been experiencing something very similar, and I think what is important is that if you are not present at the time the decision is made and you come back and you have some additional information, you have the responsibility to disclose what you know. Then, it is up to the team to choose whether or not to revisit that decision. I would say it would be good for like you to make a decision, me not to know about it, come back, find out and then, say like, “Oh Clayton, by the way, were you aware of this?” Give you some information. What would not be acceptable, though, is me pushing the agenda and the opinion I have. I wouldn’t be like, “Clayton, you are doing it wrong. We need to do it this other way. Let’s undo your decision and do it my way instead.” That’s a totally different message than, “Here’s some new information, what would you like to do with it?” The Emotional Needs In Decision Making Roy: I guess, I feel like the reason that people, there is turnaround like revisiting decisions, or at least the intent, most of the time is the people who will want to revisit things aren’t doing it just for the sake of conversation or they’re genuinely curious about why the decision was made. A lot of times, I think, they think that there are some drastic, like the train’s going to go off the tracks if I don’t step in and tell them this new information. A lot of times, I think, that’s why it’s so difficult to have those conversations because it’s not from necessarily like a rational, “Let’s move things forward.” It’s from a, “Everything’s going to fall apart, unless you listen to me and we talk about all the reasons why you made that decision all over again.” Critical Missing Information Clayton: Yeah, it’s a difficult situation to be in. I can understand that emotional need and sometimes I think I may even be a legitimate thing, right? Like you might actually have mission critical information where you know the train is going to get derailed, but it’s really tricky on a personal level to make that determination. Roy: Do you think in a situation where there was something that was kind of extreme like that, would it be appropriate for a team member to come back and say, “Hey, I know you guys decided that without me and even we decided that we were going to do this way, but I know this new information, X, Y, Z, I think we need to re‑decide. We need to revisit it”? Clayton: I don’t know if it’s like a revisiting decider or it’s like a, “Hey, here’s some new information. I propose we revisit this decision. One, two, three and then, you can just throw it aside on whether or not to.” Roy: Even if they weren’t, the team wasn’t trying to use the core protocols. you were just making a proposal. But, for us teams that aren’t using the core protocols, it seems maybe it’s a fine line between when it’s appropriate to revisit it and when it isn’t. Clayton: I think if you have mission critical information and you bring it up and the rest of the team hears it and they don’t say, “Oh, you’re absolutely right. We did not consider that. Let’s revisit this decision,” then it’s not important enough to revisit the decision. However important you think it might be, right? I think you’re going to have to lean on the knowledge of the team. Where if the entire team hears this piece of information and decides it’s not important, it’s not important. Length Of Feedback Loops On Decisions Roy: I think another aspect of this whole thing is the feedback loops like how long or short they are. In a situation where maybe there’s like a more senior developer on the team that has more experience using some technology. The team gets a story about doing something with that technology and nobody really knows how it works, and maybe they don’t implement it correctly or they make some bad choices about that. I think the tendency of this more senior person is to come back and say, “Hey, you guys did it wrong. You really should have done it this way.” But if you had a shorter feedback cycle, maybe if you’re doing it at a one‑week iteration, would it be OK if you said, “Hey, you know what, I wasn’t here. The decision was made to do it this way. It would be too much work to go back and totally change it. It’s already almost done. Let’s finish it up and then, we can maybe next week or the next iteration, we could revisit it”? Clayton: I don’t even think that’s necessary. I think that’s more like, “Hey, I just want you guys to know like this is how I would have done it. I totally understand why you guys did it, but in the future when it’s this type of thing, I have some vast experience. Try to include me in the decision. I’ll do what I can to be available for that.” Roy: You’re saying that you’d…trying to include yourself in the future decisions about that thing, but not really worry about, “Hey, what’s done is done.” You’re not going to worry about it. Clayton: It’s kind of like a signaling thing. I am offering myself as a repositor of information on the subject, right? Like whether or not I actually know anything about it. Then, giving those people the choice to use it. How To Stop Revisiting Decisions Roy: As far as like minimizing that type of turn or I guess on decisions that are being revisited, is that just a matter of stopping that behavior? Should the team just not accept the fact or they shouldn’t accept anyone revisiting things? Or does it make sense to have more of a formal structure for making decisions? Everyone has a framework for coming back to the team with information. Clayton: I think, as far as making decisions, decider is a great way to go, so there’s your structure framework right there. It provides, like you mentioned, avenues for revisiting the decisions because you through out a new proposal. If you want a framework, it’s there. I think the deep root of the problem is if you have people that are continually not there. That, to me, signifies a huge problem. If you have a team that’s working together on a commitment, they should be continually working together on a commitment, right? They should all be present and engaged most of the time. I understand that there are some exceptions. I think that most teams that think they are ‑‑ the ‑‑ exception, really are just making excuses and probably should be together more often. Presence Prevents Revisiting Decisions Roy: Component would be just like the presence of everybody on the team… Clayton: Right. Roy: …with each other. Clayton: If everybody is there, then you don’t have to worry about revisiting a decision. You might still gain new information, right? That still needs to be brought up, but new information is based off a decision that the entire team made, right? It’s a little bit different. Then, it’s not a, “Hey, I wasn’t included and I want a part of this, too.” It’s a, “I was included. We made the best decision as a team. I was part of that. I take as much responsibility as you guys for this decision, but we just found out something that forces us to revisit it.” Roy: Do you think that a team that is working on like a Scrum format or that have the dedicated planning meeting in the beginning of the sprint, do you think that they could avoid some of this stuff if they spent more time trying to decide exactly how the implementation would work during the planning period versus being a little more vague at that time and then letting people figure it out as they go? Clayton: I think that’s totally up to the team and it has to do with trust levels on the team. I think that a team that’s initially forming needs to be very specific about how they actually implement different things. But that specificity is going to start building the trust and start building the idea of, “This is the way our team does things.” The team gathers around this culture. “This is the way we solve problems.” Then, over time as the trust builds, you can start back off on the specificness because now everybody knows the way the team does things. Like if I’m working with somebody I’ve worked with for two years, I can something vague, “Like we need to make a log‑in page,” right? But if I’m working, whatever the job is…but if I’m working with somebody that is I’ve just met for the first time yesterday, we’re going to have to get a lot more specific. Roy: Coming to a conclusion, maybe revisiting things isn’t always bad. You should always disclose new information you have to team. Using a decider is a good way to make decisions so that you have a framework for making changes to those decisions, I guess. Clayton: Right. Roy: Maybe spending the appropriate amount of planning, based on how much the team has standards, I guess, for the work that they’re doing. Sounded all right? Clayton: Yep. I think that’s it. Thanks for it. Roy: Thank you.

Jade Meskill: Hello, and welcome to another episode of The Agile Weekly Podcast, I’m Jade Meskill. Derek Neighbors: I’m Derek Neighbors. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Roy VanDeWater: And I’m Roy VanDeWater. Finding Yourself In A Not Ideal Situation Jade: Guys, we wanted to talk about what happens when you find yourself in the less than ideal situation. Roy: That’s never happened to me. Jade: You’re always in the ideal situation? Roy: Yeah. Facilities Preventing Team From Sitting Together Jade: That’s good for you. For the rest of you, who aren’t as awesome as Roy, let’s start with a hypothetical situation, in that you’re working with a team where the facilities prevents them from actually sitting and working together. Just the way it’s set up, the way people are distributed, everything. They just can’t physically be together. They’re in the same building, but they can’t physically sit together. Derek: Is that when it’s time to work from the library or at a local coffee shop? It seems to me you can take a non‑ideal situation and make it into an ideal one. I feel a self‑organizing team shouldn’t let facilities get in their way. If a team is producing results and making it difficult for facilities, I don’t think any management out there is going to be, “No, no. We really got to break up this team. Even though they’re performing, facilities is more important.” Clayton: I think that’s the interesting thing about facilities. You have the entire org structure that the team is under. Then there is always somebody else that’s entirely separate that is almost never in that building that is in charge of the facilities people. The idea that there’s this bigger group working together to solve some goal of, “Our teams need a place to work together. They need to be able to sit together.” You’d be able to go talk to the facilities people and say, “How can we make this work?” That never happens. The teams complain about not being able to sit together. The facilities people say, “Hey, man, I’m just doing my job. I got to keep track of all these desks and cubes.” It always seems to get in the way. Hacking Your Way To Proximity Derek: I think there’s a couple of things. One, is you can hack your way through. I think that’s what you’re talking about, Roy. We can’t figure it out, let’s go steal a conference room. Let’s go somewhere else. We’re not going to let somebody stop what we’re doing. I think that’s pretty practical most of the time. Except for when you have to be on the network. You can’t go to the library because you don’t have VPN access, or something to the network. Jade: Or you’re doing something highly confidential. Derek: Or you don’t have conference rooms, or you don’t have laptops, or other things. Some of it goes to, can you do baby steps to get there? “Hey, Can we pair? Can we both squish in one cube?” We can’t all be in the same spot, but instead of me being totally siloed, can I be near two other people or, can we move to some part of the area where at least more of us are close…? Roy: Proximity. Maybe work for the corporate cafeteria or something? Derek: Right. So, I think there are some things that you can do that are kind of “Hey, can we baby step to get there to explore the benefits, or, start to show the benefits which then might help accelerate facilities’ issues or other pieces that are there.” But, I think it’s tough. I think Clayton put it well, “Facilities don’t give a shit about your team”. Jade: Let’s imagine it’s not the person, right? It’s the environment not conducive to working together. So, what are some other situations that you guys have found yourself in where you’ve had to work around something that’s preventing your team from being as performer as they could be? Testing In Legacy Code Clayton: I think one thing I’ve seen is you get teams that have big, kind of old legacy nasty projects, and they want to maybe try and improve their technical practices. And so, I think right now if you were to go out and start, kind of Googling around for maybe TDD or BDD things, a lot of the things you run into are either technology stacks that are newer, or they’re using what seem like contrived examples. And so, I think a lot of people get turned off where if I say, I heard about this BDD thing, and I go Google for it and I stumble upon Cucumber, which is in Ruby, and, I get upset that it’s not in Java or, whatever my language is. And, yeah, you can go find those things have been ported, or exist in your language. But, it doesn’t feel the same because it kind of takes the new and shiny off of it. And so, I think in those cases, having to take the stuff that’s new and exciting but, kind of having to map it back to your like, the daily grind, I think turns a lot of people off. It’s difficult to do. No Local Development Environment Derek: I think one of the ones I see a ton is a local development environment doesn’t exist. A team development environment exists and a test environment doesn’t exist that actually mimics production in any way, shape or form. It’s so impossible to get to that because we don’t have access to our local machines to install things, or, our machines are so crappy and old, we can’t install them. Or, we don’t have licenses to the software to install it. Or, the list goes on and on and on about why teams can’t do that. They lose so much time. Hey, we’re working together, and, we’re doing something, and, we have to wait 15 minutes for something to compile on the test server so that somebody from test can look at it instead of just coming in coding, and, letting them run on their local machine. Various things like that tend to be these prisons that are non‑optimal. It’s not our fault, we have to talk to ops and deal with that or somebody has to order hardware or something completely out of our control. Jade: So what are some simple tricks that you’ve used to at least help alleviate some of those problems. Derek: Usually one of the things that can alleviate it is usually you can get the local stuff done. So it’s like, if you can at least get the point where everybody’s got the full stack running locally in the same way that cuts a lot of the problems out. At least you never have to wait for a server to be able to look at or do something. I think the other things that we see all the time are go get rogue hardware. Find any empty cube that’s still got a machine in it that is slated for somebody who is not currently working there, pull it over to your thing and ask for forgiveness. Later when you turn it into your CI box or into your dev bill box, the chances are nine out of ten times nobody even notices it’s gone, and when they do it’s like wow. OK, maybe yell that for 20 minutes… Clayton: That’s why facilities hates everybody. Derek: Right Product Or Marketing Won’t Let Us Deploy More Frequently Roy: Another one that I’ve seen a few times is when the development teams wanted to play really often because they see deployment as a painful something, and by deploying often they’re hoping that they’ll force themselves to making it better. But that marketing or sales or product owners, whoever, are not comfortable with deploying that frequently, either out of fear of the deployment process isn’t rock solid or because they can’t market in that way where they release regularly or it doesn’t fit their business model. One of the tricks I’ve seen to solving that is when they set up an internal fake customer box where they deploy to every commit to practice the deployment that replicates production as close as possible. So that when they actually do deploy to production it’s something that they have done every day for the last however many days instead of something they haven’t done since last year. Believing It Is Possible, The Art Of Pretending Clayton: I think a big part of it is just believing that it’s possible. Having a local environment I think you can hear so many excuses, like the self prison stuff. I think a lot of it is that people are wanting to ask permission first for a lot of things. But a lot of times you tell them about a story like GitHub or something where they hire a new person, get a laptop and 30 minutes later they’re committing to production. I think to them that seems impossible. Obviously it is possible for some people and it’s all just computers and stuff and you know that you can automate it and you know you can make it work, and you probably aren’t a special snowflake. So you can kind of get over that hump of thinking that it’s impossible to do those things, I think that goes a long way. Derek: It’s true, it’s like that typical, “Yeah, we like to do that in the perfect world but we have this limitation. OK well maybe the limitation is a problem which you can solve, and you can be in this perfect world with the rest of us.” Poorly Defined Roles Clayton: I think another big example of the non‑ideal state is I would guess a lot of people would go get their CSM and they’re in their training and they talk about the different roles, and here’s what the team does, and here’s what the product does, and they go back to their office and the product owner really doesn’t spend all of their time with the team. They used to be a product manager so they have all these other tendencies. Half the team came from some other team and sometimes the other manager comes over and asks them to do work on this other project. There’s all these things that don’t fit into the roles at all. I feel like that’s got to be a huge problem for a lot of… Jade: That would never happen. [sarcastically] Clayton: Right. [laughs] Derek: Right, and they come back and try to adapt everything to fit into their existing business, their existing corporate structure, right? So, a kid like, “OK, I understand that scrum is supposed to have a product owner that is present all the time but we can’t have that. So we’re going to adapt it to meet our company’s needs, and that will make it better.” Clayton: I think in a lot of those cases you just have to, to some degree, just buck up and say, “Hey, in order to have a successful scrum team we need to have a product owner that has authority and has presence and can be with the team.” That’s just how it has to be. So we’re not really going to find some way to weasel around that. As far as the kind of hacks and stuff go I don’t know that there’s a whole lot you can do other than basically just being real honest about what you have to do to be successful in that role. A Coaches Approach Jade: As our role as coaches, Clayton you talked a bit about just believing that it’s possible. Let’s step back from the specifics and let’s talk about our philosophy. How would we approach this? You show up and you walk into an environment that is so complicated, so convoluted that there are no simple, obvious ways to start to make these type of improvements to work a little more towards the ideal. How would we start to approach and unpack that problem? Clayton: For me I think that comes down to looking back to looking at some values and principles. You’re not going to be able to go in and necessarily find a list of 15 things that they’re “doing wrong,” and if you fix those things, then they’d be better. But if you stick to the values and principles and you start observing some of their interactions in the existing processes. You say, “Hey, I think one is kind of misaligned with the values that we’re trying to go for.” At least, get into that baby step of just exploring that possibility. That’s probably a good first step. You can start finding real small things to break things down. You have to take those trivial problems and break them down into smaller chunks. Roy: I think, something that’s important, though, is getting the team that you’re working with to actually believe that something like this is possible. I think, you alluded to that earlier, Jade, where there are bunch of people working these types of environments, these oppressive environments, their entire life. They think that something like 10 minute build or an easy deploy or testing before you develop quota or anything of those things are just impossible. That really is unachievable fantasy land of perfection, rather than a real practical thing that you can actually do. I’m not quite sure how you could convince them that that reality can be true. Derek: I think, for me, the way that I’ve been framing this lately, is it’s permission versus policy. Most of these organizations are really strong policy oriented and don’t trust their people. For me, the first thing, is whoever is asking me to be the coach, do they really believe in what they’re doing? If the answer is yes, I ask them for permission to give me latitude to really push the bounds of things. I think, that’s the only you can show teams that the culture is changing, that the system is changing and that they aren’t allowed to have permission. Because, more often than not, they’ve been slapped down so many times, they are not going to believe it by default. Then, it’s a matter of taking every opportunity to deal with those civil disobedience issues, where it’s, “You know what? There’s a server that’s been sitting on that for the last five days. Nobody has touched it. Nobody can tell me what it’s for. I’m picking it up. I’m making it the CI box. I will do that and I will take all the heat for that as a coach. I’m willing to go tell the executive sponsor that I’m doing it.” If they say, “No, can’t do that.” I say, “OK, great. We’re done with this coaching engagement. You are not serious about the change.” I’m giving you an out that you can blame me. You don’t even have to say you know about this. I find that executive sponsors are serious and say, “OK,” stuff tends to start to happen and unfold. They need that catalyst or the change agent to stand up for teams and stand up for change. I think, you have to know how hard to push, right? I’m not suggesting you go in, you just start tearing everything apart. Jade: I formatted this machine. I hope that was all right. Derek: Yeah, I think… Jade: That was our production change. Picking Your Battles Derek: …you have to pick the battles and see where you get the most lead for the team. The team starts to push harder and then, pretty soon, you really do have a civil disobedience going where it’s get harder and harder for shitty managers to push back against empowered teams. That’s part of the goal is to get people to say, “Hey, we do have the power to make good decisions. If we don’t, hey, we’ll be let go. If we’re making decisions…” Clayton: I think I’ve seen teams where they knew based on the Scrum rules that they were supposed to be able to dictate to some degree how the stand‑up meeting went, but they would laugh about it every time. They hated the stand‑up meeting because there was a controlling manager that made them do it a certain way. To them, it was impossible. There was no possibility of any change, whatsoever, because that one little example. If they couldn’t change this in that meeting, they couldn’t do anything, so what’s the point? That was their big barrier to even believing. You could convince them that there are teams that have a 10 minute build and do CI and all this other stuff but, “Not in our world. It just doesn’t exist.” Jade: I think, that’s it for this week’s episode. Thanks for listening. Check us out on Facebook, facebook.com/agileweekly. We’ll talk to you soon. Good‑bye. Clayton: Thank you.