Roy vandeWater: Hello, welcome to Agile Weekly Podcast. I’m Roy vandeWater. Alan Dayley: I’m Alan Dayley. Derek Neighbors: I’m Derek Neighbors. Jade Meskill: I’m Jade Meskill. Why Is Agile Faster Roy: Today we’re going to be talking about “Why is Agile Faster”? Alan brought this to our attention. Do you want to give a quick intro? Alan: This is something you see all the time online and that I encounter with clients and so on. People say, “We want to do Agile because we want to be faster, because faster is better and Agile will be so much faster.” I recently did a blog post about this and thought it would be fun to bring up here to talk about the perception of Agile being faster ‑‑ is it really faster or not? Why would it seem to be if it is or isn’t ‑‑ all those kinds of issues. I proposed in my blog post that Agile isn’t necessarily faster. Just because you’re doing Agile or you’ve done it for three sprints or iterations, that doesn’t mean people are coding faster or the testers are testing faster. Delivering Value Sooner Roy: Does it mean you’re delivering value faster? Alan: Well, I’d rather you use the term sooner than faster in that case. Biased Towards Action Jade: I think a lot of it is biased towards action. If you look at the core of what the Agile principles and values get you doing as a team, you’re looking at moving towards some goal sooner. Alan: That can be one of the factors right there. Uncovering Better Ways Derek: I guess, for me, when I look at the Agile manifesto and corresponding artifacts, I don’t know if I’ve ever seen anything talk about faster, sooner. I’ve seen “better.” “Better” could include faster or sooner. I don’t want to call them illusions, because I think ultimately, over time Agile teams do tend to perform better. I’m not discounting that that’s the case, but I think some of it is the illusion of speed ‑‑ how quick you get feedback. I like metaphors, so maybe I can explain with a metaphor. If you are in a car and you are going 70 miles an hour and you look out the front window, it very often does not feel like you’re going 70 miles an hour. If you’re in the same car going 70 miles an hour and you hang your head out the window and you look at the little striped lines and you see how fast they’re going by, it feels a lot faster than when you’re looking out the window. You’re going the same speed. The difference is you’ve got some indicator that is giving you perception that you have movement. I think one of the things that Agile methodologies tend to do is make things visible. They make movement visible where you didn’t see movement before. Even if you’re in a long iteration, if you’ve got burn‑down charts, if you’ve got card walls and other things that are showing movement it feels like “Man, we’re really getting a lot done,” or “We’re really going fast” because we’re seeing lots of movement. Where before it’s “Hey let’s go do this stuff and we’ll come back in X number of weeks when the project manager comes by and says “Are we on track for this”? And nobody on the team is really seeing any movement except maybe the person doing the individual silo‑ed work. Focus On Improvement Alan: One of the interesting things that I point out many times in these discussions is the retrospective and the focus on improvement. Most teams traditionally are not spending any time trying to improve. The reality is that you are going to end up spending less time coding because you are going to spend time trying to improve. The payoff is in the long term ‑‑ some iterations down, some months down ‑‑ the team will actually have more efficient processes and better ways of communicating, et cetera, because they have taken the time in the early iterations to build some of that. I think that really does help improve actual higher production, or more output. Roy: So they will eventually be faster? That’s what I’m buying if I’m converting my company over to Agile? Derek: I don’t think you will necessarily be faster. You’ve made an investment in being able to respond better and you’re hopefully focusing on doing the right things. If we’re doing the wrong things really fast, we haven’t actually made any progress. Alan: Yeah, that’s kind of the input side which we can address here in a little bit. Iterating To No Where Derek: Iterating to nowhere. I think it was Carlos Segura or some fairly famous designer I thought put it really well. You see a lot of design firms that get paid millions of dollars to make a logo and other designers say “Well that’s crap, how dare you get paid a million dollars to make the Nike swoosh logo? Come on, that’s just drawing a little flip of the wrist. That’s so easy.” I think Carlos put it as “It’s not that I drew a little “fwoop”, it’s that I knew what “fwoop” to draw that was worth a million dollars.” I think that Agile teams start to become the same thing because they are collaborating with the customer, because they are iterating with things, because they are putting working software, they are getting feedback. They learn what the right things to be doing are. It’s not that they are able to do more things. It’s they’re able to do the things that have bigger impact. Again it gives that illusion of, “Man, this team is really fast.” No, maybe they’re just really good at saying no to stuff that doesn’t matter to anybody. Working On The Right Thing Alan: That, again, drives to the input side of things. One of the powerful things about many of the Agile frameworks is the collaboration with the customer and having somebody that’s picking the right thing to work on and the right target to shoot for. Of course, in many organizations, that is still a very neglected part, and most organizations are focused on output ‑‑ make sure the programmers are shipping and sending stuff. But eventually, you have to address that other end that says, “Are we working on the right thing”? How do you help the product owner and the infrastructure around that whole management of portfolio and feature ideas, to pick the right ones that’ll have the most impact? Jade: I’ve met a lot of organizations who have an amazing tolerance for wasting everybody’s time. It just blows me away every time. Derek: There are some organizations that I’ve been in, they introduced me when I started there by saying, “Oh yes, this project is really cool. It only took three months of discovery.” I said, “OK, so what did that produce”? They said, “Well, here’s this document.” I said, “Well, where’s the backlog”? “Well, we don’t have one yet. That’s going to take another month.” Roy: Well, wait until you see the product. It’s going to be [sarcastically] so cool and awesome…in five years. If I’m trying to justify it to a superior, I’m trying to sell somebody on it, what I’m hearing is I can’t really go, “We’ve got to use Agile because it will make us faster and it will make us more efficient.” I’m hearing… Derek: [jokingly] Use Kanban for that! Roy: We need to use Agile so that our teams will tell us “No,” when we want stupid things. It totally makes sense, but I feel like that’s going to be difficult to sell. Developer Engagement Derek: If I were to try to sell an executive who was on the fence on Agile, I would start with a couple of things. “How engaged are your employees in your teams towards the work that they’re doing”? If their answer is, [unenthusiastically] “Yeah, I got a bunch of eight to five people. They don’t really care.” You’re probably going to do a better job solving that problem if you really start to become Agile, than you are going to solve the “going faster” problem. You can come in and you can do Agile wrong and implement Agile. As part of that, you might get teams to go way faster, but they might completely disengage and I like to call it “iterating to nowhere”. “Your velocity is just climbing like a beast, but you’re not shipping any software.” Or, “You’re shipping software, but nobody likes it. Everybody thinks it’s horrible. It’s not selling better. You’re not…” The big thing is I can tell what an executive is looking for by how they want to measure Agile. If they want to measure Agile like, “I’m doing Agile this year and I want 100 percent of my teams to be using Rally and have increased velocity. That’s how I’ll know I’m successful.” It’s like, “You don’t really care about agility, right”? If it’s, “My problem is we’re only shipping our software every six months and I want to be able to give features to customers every week and get feedback. I want to be able to have really high net promoter scores and have my customers love our product.” To me, it’s, “What are you trying to do by being Agile”? I think the thing that we’ve done in this community that has been a travesty is we have sold Agile as more quality, faster, and…better. The problem is we did that because everybody wants that. That is good to the bottom line… Roy: It’s easy to sell. Derek: …in some ways. It’s easy to sell and we can produce that fairly quick with XP and Scrum and Kanban and these things. We can see those things pretty quick. The problem is that going faster without meaning, without purpose and without collaborating with the customer doesn’t mean crap. Attracting Talent Roy: That’s perhaps another good benefit, too ‑‑ the using it to entice people. If you believe in the principles that are in the Agile manifesto and you want to attract people, then that might be like trying to create a culture that attracts more of it, so you can get the people that you want on‑board. Speed of Delivery Derek: This would be a great litmus test for me. Those of you that are sitting in the audience, if you think you’re Agile and it takes you more than two minutes to deploy your software, and more than two minutes to undeploy your software, you are not Agile. It’s all about responding to change. I don’t know how many teams I talk to that say, “Oh, yeah, we’re doing ComBomb. We’re doing Scrum. We’re doing whatever and we are totally Agile.” They have a [slowly and dramatically] 64 hour deployment process. Jade: You mean deployment sprint. Derek: Right. I mean, how on earth can you respond to change… Jade: Deployment epic. Derek: …when it takes you 64 man hours to get something? Can you imagine going to Walmart to buy a block of cheese and them going, “We’ll check you out in 64 hours, if you can just stand in line and wait there, we’ll gladly ring you up in 64 hours.” Jade: They’ve got to grow that cheese. Alan: Well 64 hours… Jade: Cheese tree. Alan: …in some environments is very, very fast, by the way! Jade: Not Agile ones. Increasing Speed of Collaboration and Communication Alan: Not Agile ones, no. The other part of this that we touched on earlier that I think we could address is the talk about collaboration and communication, right? Over time, an Agile team, I think, does lose a significant amount of the overhead that it takes to collaborate and communicate and that can help make them work faster. If you’re spending less time in meetings, reading documents, arguing about what it really means we’re really fully collaborating. That’s another place that it looks and can feel much faster. Overall, the real benefit there though isn’t speed. The real benefit there, again, is focusing on delivering the right thing. That’s where that’s valuable and has nothing to do with being faster. Roy: That makes it difficult from a measuring standpoint because the feeling that I get from it is, “It’s going to be really hard to measure, but if it’s done right, you’ll know,” type of thing. “You won’t have to measure anymore at that point to see if you are Agile.” That’s difficult to sell at first, but it kind of… How Do We Know We Are Getting Better Derek: I think it goes back to people instantly wanting to say, “Well, OK, how do we know we’re getting better?” You’re selling me this. Roy: I think that is a good quality in general. Derek: Most people say, “You should do Agile because it allows you to do more, better, faster.” Then people say, “OK, how do I measure that I’m doing more, doing it better, and doing it faster?” We get into the increased velocity point, reduced defects. You get to all kinds of weird things. To me unless you’re in the business of selling agility to people, why on earth would you use any of those metrics to tell if you’re successful? If I’m making hot dogs and I want to become an Agile hot dog vendor, do I really care that I’m making more hot dogs if I don’t have more people buying the hot dogs? Do I really care that the hot dogs are better quality if nobody is buying more hot dogs? Do I really care that the hot dogs are 20 percent bigger if nobody is buying the hot dogs? I should care, “Am I selling more hot dogs? Are my customers happier with the experience of the hot dog”? Those should be the measurements that I use for success. Alan: You don’t want to measure saying, “Well, it only takes me 30 seconds to cook a hot dog, instead of a minute and a half.” Therefore, I must be better. Derek: I might want to measure that if I’ve got so many… Jade: If you’re trying to sell… Derek: …customers queuing up that they’re leaving me because I can’t serve them hot dogs fast enough, right? But, I mean, it should be around those things, right? If part of we’re not responding to change or we’re not adding the features at a rate to be competitive with whoever our nearest competitor, like, “OK, those are great,” but usually that’s not the case. People are saying, “Well, I don’t know how to measure a software development team, so these outputs tend to be what I should measure them on.” They don’t look at the system, they look at the team. Who Works On What Roy: The role to figure out who works on what, what is being worked on and what provides a lot of value has traditionally been more of a management decision than an individual developer decision. Derek: That’s a huge shift in Agile and why if what you’re looking for is more, better, faster for your team, you’re not really ready for Agile, because Agile requires that you look at the whole stack. The team, the product owner and the management team, all the way to the CEO have to really be having discussions about “How are we getting better at what we’re doing”? If we’re the hot dog vendor, how do we sell a better product to more people, make more money doing it? That conversation involves everybody from how we market the hot dog to the customer experience… Alan: To where do we buy them from… Derek: The whole thing. You can’t do that if you’re just talking more, better, faster. Jade: The challenge is that’s so convoluted in most companies to understand that whole picture, that it’s hard to even have the discussion. Alan: There are multiple layers on both ends, from collecting the requirements, there are 14 layers… [crosstalk] Derek: You get to the point where when you’re at a big company, you might have a sales team that is 2,000 miles away doing something totally different from the marketing team, doing something different from the development team. It’s not that they don’t collaborate, it’s like they don’t even know each other exist. That’s how removed they are. Roy: Thank you for joining us today. Alan, thank you for joining us. Alan: Thanks for having me. Roy: Please join the discussion at facebook.com/agileweekly and give us your thoughts as well. Good‑bye. Alan: Bye.

Derek Neighbors: Hello and welcome to another episode of the Agile Weekly Podcast. I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Jade Meskill: I’m Jade Meskill. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Derek: Today, fresh from Twitter, we have Mike Vizdos. Mike Vizdos: Hello. Derek: A custom that we want to do with our special guests is we’re going to allow them to pick the topic of their choice. You get to hear what we’re passionate about all the time. We want to hear what some of our listeners are passionate about. Mike, what’s got your interest today? Mike: Let’s see. We won’t talk about estimation and planning or certification. Let’s see what are some other hot topics that we don’t want to talk about. Jade: Can I get certified in estimation? Mike: Certified estimation planning. Although, Mike Cohn might have a copyright on that one, too, right? [laughter] Derek: Anything’s possible. Mike: He’s planning poker, I think. I’ve got to send him a two cent royalty just for saying that on here. OK, you’ve got to check. Derek: There you go. Lean Startup Didn’t Work For Me Mike: I don’t know. What are you guys doing with the Lean Startup role? Anything there or what’s going on with that for you? Clayton: We were just talking about Lean Startup the other day at lunch. I had shared a blog post that I had read about some people that had tried to create a start‑up. I can’t remember what space it was in. But they tried to create a start‑up and they tried to use Lean Startup. Jade: It was in the non‑profit space. Clayton: OK. It sounds like they were 37signals devotees, so they read a bunch of 37signals blog posts and their books and everything. They tried it and it didn’t work. It was the fault of Lean Startup. Then, if you read the blog, it didn’t look they were very “Lean Startuppie.” I’m curious, how many other people are in that same boat where they read the book, they try it and it fails and they blame Lean Startup? The Early Adopters Jade: I used a Lean Canvas, why didn’t this work? Derek: I think you’re going to have a lot of Agile adoption, horror stories. The early people that are doing Lean Startup actually have experience and spent decades figuring out how to be successful in bringing product to market fast. So they started a document in it. They wrote books about it. They are doing conferences about it. Now, as you start to get into a little past the early adopters on the curve, you’re going to have people that read a book, but have no experience doing anything. Then, go out and basically say, “Look, I followed all the rules, but it didn’t work. I’m not making a million dollars, what is wrong with this”? In the same way that people go out and read a user’s storybook and they will still go out and write bad users story or go to a Scrum certification and still do all sorts of horrific things to their teams. Jade: But, we did it iteratively. [laughs] Derek: There you go. [laughter] We Failed Fast Clayton: That’s right. We failed fast. Roy: I think that’s exactly the problem though especially with this Lean Startup one is a fear of failing. The entire idea, at least for me, the big motivation of Lean Startup is to try to fail as early as possible, so you can eliminate a possibility and I think that’s really difficult for people when they get passionate about something is to all of a sudden find evidence that it’s not worth your effort. You would claim the term I think “Fat Startup” at some point. Jade: That’s the name of their book that you can buy. Roy: That seems like if you try and develop the entire product and wait until the end to release it to find out that it doesn’t actually meet any customer demands. Decomposition As A Product Owner Derek: Yeah. What I’m seeing a lot in the places where we’re doing a lot of this stuff at, people are really, really bad in breaking functionality down into small bits and I’m not talking developers I’m talking product owners. They don’t know how to ask any of the right questions. They say, “I want to do Lean Startup,” awesome, great “What experiment are you going to run”? “What do you mean”? What needle are you trying to move, especially when they have got an existing product were this thing is existed from a year to 10 years and they have never ever done anything other than a customer service satisfaction survey before. It’s like, “Our biggest problem is that we’re trying to reduce churn.” OK. Awesome. ”Do you know what’s causing the churn”? “No.” Do you know what could possibly be causing it”? “No.” “Is there anything you could potentially measure to try to change, that might affect it”? “Oh, maybe.” “OK great so how are you going to measure that”? “I don’t know.” I mean it’s so difficult for people to figure out how to ask questions, how to do experiments, how to make the hypothesis…the other thing that I’m seeing is that development teams are not high‑performing enough to actually do Lean Startup work. Meaning, even if you have a product owner come in and say, “Hey I want this.” It’s like “Oh you want that piece of data, that’s going to be 3 weeks to build that metric so that you can start collecting that data and then that feature you want us to test that’s going to be another 10 weeks to develop.” I think enterprises want to adopt this stuff, but they are just not ready. Jade: …but that is lean! It took us a year to do it last time! [laughs] Three Guys In A Shop Mike: One of the things I’ve been seeing out there as I go…especially in the larger companies that I’m going ‑‑ the enterprises ‑‑ is I put off this warning that there’s three guys in a shop that I’m calling it, that are just going to get out there and kick your ass. I got this great idea again to just go ahead and start another site, and this one is definitely Lean Startup style. It’s totally testing the initial hypothesis of “is this even worth it”? If you go to 3guysinashop.com right now, it’s basically very, very Lean Startup style. Let’s get it started and see what happens. What I want to do with this is start showing the failures, and that failures are good in the Lean Startup world. My hypothesis is there are a lot more failures out there using Lean Startup than there are successes, and I want to use this as showcasing people trying and showing what it’s like to fail and succeed. Don’t know where it’s going to go with that. One of the projects I’m starting out with that, to show is totally non‑software development related. There’s a company called Leanpub that I’m doing some publishing in it, being pretty well‑used in the agile world too. I know Brian Marick and a couple of other people have got some stuff out there. I started a children’s book of a kids’ book that I used to, stories that I used to tell my kids. It’s called “The Pirates’ Cavern.” It’s going Lean Startup style to actually show a product being delivered. It’s totally outside of the software delivery world, but I’m going to chronicle what happens along the way with that. LeanPub Book Process Roy: For example with that book how are you collecting feedback on that? Could you describe one of the experiments you ran while working on that book? Mike: I literally have just gotten it up there over the weekend and my first request is to have them, the readers read it to their kids. Read it with their kids and see what their kids’ response is. The feedback that I’m been receiving so far has been ranging from “meh” to “holy cow this is awesome”! Now I’ve got to figure out what the “holy cow this is awesome” and what the “meh” is about. That’s what I’m testing right now. Derek: How are you going about testing that? Mike: Right now it’s just feedback via email. Leanpub allows you to collect email addresses of people that download your book. It’s amazing too. I’ve got a sliding scale up there of pricing. I’m giving it away for free. It’s like zero to five bucks. People are actually paying more than five dollars for this book. It doesn’t seem like a huge deal but it’s also good for testing pricing models too along the way. Roy: Is that your measurement for…there’s an improvement because the average price has gone up? Is that kind of the idea? Mike: No. Right now I’m actually just seeing, “Take it for free really,” I mean I’m surprised that people are paying for it. One of the next tests I’m going to ask about is, “Why? What made you pay even more than what the suggested price was”? Because Leanpub allows you to basically pay whatever you want. How Do We Make Money Derek: One of the other things I’m seeing a ton is that…I teach an entrepreneurship course as well at the university. The other thing that is really missing in these big companies are, they are so far‑removed from actual profit and loss of their products that…meaning they have revenue stream coming in from…They don’t know whether it pays their salary. There’s no like, “Man, if we don’t do something quick to get more users or get more money that we are going to be out of the job.” That just doesn’t exist in the enterprise world for the most part. The two key things that most real lean start‑ups start to look at is, “How much does it cost just to acquire a new customer or to keep a customer and what is the lifetime value of that customer”? If the lifetime value is smaller than what it cost to acquire them we should kill the product or figure out new feature sets to increase the price or to get more customers or do something. When I start to ask those kinds of questions, these bare simple, like, “How are you acquiring your customers”? “I don’t know.” “How much does it cost”? “I don’t know. Marketing does that.” “You’ve got customer A that uses your system in x, and you’ve got customer B that uses it in y. Which one is more expensive for you to maintain or do they cost the same to maintain”? “What do you mean”? “I mean does one of them require more of your time and attention than the other one”? “Oh yeah, customer A, they call in to support all of the time.” “Do you charge more than you charge customer”? “No.” That makes no sense to me. Vanity Metrics Clayton: That’s interesting that you brought that up, in Lean Startup they make a big deal about vanity metrics, and there’s all these startups that go around promoting these metrics that are not especially meaningful. Even in the enterprise they don’t even have the vanity metrics. Roy: Can you give an example of a vanity metric? Clayton: Like if you say revenue or something. Jade: Or number of users. Clayton: Yeah, number of users. Derek: Like, “We had 100 new sign ups.” It’s like, “OK.” Jade: “We lost a hundred million dollars on a million users.” Derek: “We have the three biggest NBA stars using our product. We pay them each a million dollars a year to use it.” Clayton: Yeah, I mean if you have amazing revenue, but if you make $100 of revenue for every customer and it costs you $99 to get that customer, you can have a big number but it is not super‑impressive. Playing Telephone Game With The Customer Roy: Something you had mentioned, the marketing people are in charge of talking to the users. That seems to be a really common threat too, that the people that are in charge of doing the work and the people doing the work and all of the improvement stuff are really, really far‑removed from the actual users of the system, and most of the time from the customers of the system as well. Where you have to play this entire game of telephone where somebody over here…like there is a whole body of people here who don’t like something and it goes up through the channels or it goes up to the marketing people. The marketing people bring it around to the CEO and it makes its way back down and trickles back down into eventually the product owner and the developers. Derek: I think we separate the people doing the work from the outcomes of the work. If the product owner can’t tell you how much it costs to acquire a customer, and they can’t tell you how much revenue they make off a particular customer, and they can’t tell you who’s a good customer versus a bad customer financially, how on earth do you expect the developer or the UI person or whoever on the team to be able to tell you that? What starts to happen is even at the marketing level, they don’t really know those answers. All they are looking at is their revenue stream. Are our revenues going up? If we do this kind of marketing…or this is all the vanity metrics. We’ve got 10,000 customers in our system currently. Our quarter four goal is that we have 15,000 customers. If we market and we spend $1,000 per customer to acquire a customer and our product only has $10 ever that we get out of this customer, but if it makes our number go to 15,000 we are totally happy with that as the marketing department because we met our quarterly goal. We got more customers. So many teams and so many products are not looking holistically at their product. They are looking at one…we want to stop churn, we want to increase revenue, we want to increase numbers of users, we want to get into market X. That’s only one part of the formula. Big Company As A Lot Of Little Companies Clayton: If you talk to a lot of product people, they have a ton of ideas, and then they can’t pick which one or they can’t execute on them. Do you think it would be better served rather than have these big economies of scale where you have these big departments that are all supposed to be doing one main goal? Would you be better off plugging one person from marketing, one person from sales, one person from this, one person from that, and creating little Lean Startup teams that could work on one idea at a time and just burn through those things? Mike: Sounds familiar. Roy: A bunch of little “three guys in a shop.” Jade: What’s that called, cross‑functional teams? Derek: I think what’s happening is we are seeing it on the development side, so let’s take a QA person, let’s take a designer, let’s take a whatever and create them as a team. But if you look at the startups that are scaling well, they are the ones who say we are creating products, and our products end up being encapsulated by we have one of everybody on the team, and we don’t have necessarily the global marketing department. We don’t have the global whatever, each product sort of stands on its own at some level. Any final parting thoughts, Mike, before we let you go back to writing your book? Mike: Yeah, everybody laughs about it, but they also laughed about that little cartoon site that I run too [laughs] . No, just go ahead and follow along. This is public accountability on my part too for 3guysinashop, let’s see where it goes. Get out to leanpub.com/piratescavern and get me some feedback on that. I appreciate you guys taking the time to have me on here tonight. Roy: Thanks Mike. Mike: Cool, thank you. Derek: For those following along, we’ve got a prior episode where we actually had the founder of Leanpub on, and we had another episode with “Lean Startup in the enterprise”, with David J Bland as well. Go back and brush up on those and we’ll see you next time.

Jade Meskill: Hello, and welcome to the Agile Weekly Podcast. I’m Jade Meskill. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Big News Build Up Jade: Roy, you wanted to talk about something, but I’ll send you an invite for it. Then maybe we can talk about it. Roy: Let’s try it this way. Audience members, we have big news about Agile Weekly, but we’re not going to tell you until two weeks from now. It could be either good or bad. Derek: The surprise in the box, people love surprises, right? Jade: Quick disclaimer, we have no news. You don’t have to wait two weeks to find out. The Withholding Pattern Derek: I think that I’ve seen a couple of patterns happen here. It’s the person that really gets off on the big surprise like, “I know something, and I’m going to tell you something. It’s exciting for me…” Jade: …To withhold the… Derek: “…To withhold the information, because I’m going to give this big surprise.” Roy: I’ve caught myself dong that a few times. Derek: The problem is they don’t understand that the person on the other end does not know if it means they’re getting a shotgun to the forehead, or they’re getting a $30,000 raise, and they always are going to default to shotgun in the face. Roy: That’s Safer. The Flaunter Pattern and The Hide The Crazy Pattern Derek: That nice two week pause of anticipation is like waiting for your cancer test results, and they don’t get that. That’s one pattern I see. The other pattern I see is the, “I just want to tell you that I know important stuff that you don’t know, and it’s really like I just want to flaunt that,” which is another bad pattern. The other one is the, “We don’t know what the hell we’re doing, but we know we’re doing something. When we just unload and say, ‘Hey we did this crazy thing that nobody agrees with, and we didn’t consult anybody about,’ you would criticize the hell out of us that you didn’t even think about that, you just pulled it out of your ass.” Instead, we tell you, “This big thing is coming that we don’t know what it is, and we’re going to pull it out of our ass, but it’s not going to look like we did, because we told you two weeks beforehand that we we’re going to do something.” The Leak The Bad News Pattern Roy: There’s a fourth option, too, which is we got really, really bad news, and we don’t know how to break it to you, so we’re going to give you two weeks to start some rumors, and see how people react so we can adjust our message accordingly. Derek: I think a lot of the bad news stuff really comes down to people don’t know how to position their message. Like it’s the whole crucial conversation, fierce conversation type of thing, where instead of just being direct and saying, “Here’s what’s going on, here’s what I know, here’s what I don’t know. These are the potential things I see, these are the potential things I don’t think are going to happen.” Instead it’s like, “Well, until I have all the information I don’t want to go tell somebody, because if they ask me a question and my answer is, ‘I don’t know,’ that’s going to be worse.” The problem is if they know something’s happening, and you’re not giving them any information at all they will assume the absolute worst case scenario. I’m just telling you, if you’re a manager out there, you need to tell people something, and you don’t have all the information, you are better off giving them the information that you have available, and saying, “I don’t know” to the things you don’t know, then you are trying to hold off for all of the information to be relevant. Stop Playing The Wait Game Jade: Or don’t tell them that you’re going to tell them. Derek: Correct. Jade: Wait till you’re ready to, actually, tell them, and then just tell them. Roy: Seems simple. Jade: Must be impossible. Roy: In a perfect world. Purposefully Doing The Wrong Thing Jade: [laughs] In a perfect world. Speaking of perfect world, what happens if you’re working in a team, and they know that they’re doing the wrong thing? There’s some force that’s causing them to do the wrong thing intentionally, but yet they don’t seem to do anything about it? Derek: They don’t do anything about it? Jade: Maybe they feel powerless to refuse to do the thing they know is wrong. Organizational Smell Derek: I think to me it shows the lack of health within the organization as a whole. I think if you’re kind of co‑creating things with a product owner, with management, with your organization. If you see something that looks like is really damaging, or a complete waste of time you should be able to have that open dialogue. There should be trust on both sides to say, “How do we reconcile it?” Maybe, I think, it’s a waste of time, you don’t. Maybe you can help me see that picture. Maybe I can help you see my picture. But there’s some kind of dialogue or compromise, or something that happens there. I think when the teams get to the point where they’re like, “Yeah, this is a classic case of you go to no planning meetings, you go through all planning, and everyone is totally complicit.” Nobody says anything bad about what’s happening, and then the minute they all leave as they’re walking down the stairs or down the hallway they’re like, “This is the dumbest thing ever, this is a…” that is a huge sign that there’s something wrong. The problem is, what it does is it starts to build up to the point where the teams just don’t care about the product. If you’re constantly being told to do things that you don’t believe are the right things to do for the product, pretty soon you don’t care about the product. Then it makes it impossible to do even the right things for the product. How To Reconcile Teams That Aren’t Engaged Jade: How do you start to reconcile that? Let’s say you’re working with a team that’s been put in this position where they know that what they’re being asked to do is not the right thing for the product. They’re very resistant to doing whatever is being asked of them, but yet they don’t know how to address that, or how to reconcile it with the organization. Derek: I think one of the ways that I would start to approach it is if I understood why the team felt that way, it would probably depend on what the reasoning was, and coach to that. More often than not it’s usually like, “We just think this is dumb.” Roy: Right, they think it’s a waste of time. Derek: There’s no value in it, it’s a waste of time. What I would generally do is say, like, hey, you might be powerless to do anything, but you can do the exact same thing that you should expect people to do from you, and that’s hold you accountable to your action, or ask you to be responsible for your actions. What I would do is I would ask the product owner, “Why are we doing this? Can we measure that this is moving our product forward? Are we going to gain new customers if we do this? Are we going to prevent losing customers if we do this? Are we going to be able to up‑sell existing customers that we have? How is this benefiting our product?” If they’re not able to tell that story with data, then I think you can push back a little be on them and say, “Man, you know, we would feel more passionate about this if we really knew that this was going to solve the problem.” I think that if you do that enough times, what can start to happen is the product owner has to start seeing themselves for what they are, which is hey, I’m just shooting from the hip, just saying, “Do X, do Y, do Z.” I’m losing credibility with the team, in the same way that if the team just says like, “Oh, we’ll get stuff done, we’re going to get it done, and don’t ask us to look at anything. Don’t ask us to be accountable for our work or be responsible for when things ship,” the product loses respect or loses trust for the team. If I never do what I say I’m going to do, and never produce results as a team, the product owner gives up, in the same way the team gives up if the product owner never produces results. Roy: But, Derek, what do you do then if you go back to the product owner and say, like, “We don’t really feel comfortable,” and the product owner says “Tough shit, do it anyway?” Leaving Is An Option Derek: I think you’re in a slightly precarious position. I’ll be honest, if I’m a developer in that situation I’m starting to dust off my resume. If I can’t be passionate and care about the product that I’m developing, and I can’t see where it’s going, I’m wasting my time. I would be as transparent and open as possible to my manager, to my team, and to the product owner about that, saying, “I’m having a hard time understanding. You are telling me drive faster, drive faster, drive faster, and you refuse to tell me where this car is going. It’s hard for me to want to stay in for the ride. I really want to, but every day I feel like jumping out of the car even though it’s moving, so can you help me get there?” If the person can’t respond to that, you’re working for a product owner that can’t deliver. If that’s the case, you’re working to nowhere. I think that the best answer that could potentially come out from that ‑‑ or not the best, but the most honest answer ‑‑ is for the product owner to be able to say, “Look, I’m struggling. I don’t know, you know, I don’t know either. I’ve got some other pressure that’s forcing me to do this and I don’t want to do it either.” At least at that point it’s, like, OK, now let’s go ask the person up the food chain what’s going on. Because a lot of times I think what happens is stuff gets passed down through layers. A CEO, a CTO, somebody, sales, says, like, “This is a huge problem and you have to take care of this right now,” and they’re talking about it in a complete vacuum of information. It just goes right through the food chain all the way down to a product owner who is like, “Hey, I don’t care. My boss’s‑boss’s boss told me that this has to be done.” It’s like, “Does that person even know anything about the product?” It’s like, “No.” Sometimes if you roll that back up the food chain, and save the large picture, and you say, “We’ve got this huge thing, this giant vision that we’re driving to over here, and we’ve been asked to make a right turn that’s going to make it so we can never get back there. Do you understand that?” The person will be like, “Oh! Well, no, don’t take the right turn, no. We definitely need to go to where we’re going.” But that conversation doesn’t happen. I think if people don’t try to put on the brakes, and I’m not trying to say be… Jade: …obstinate. Derek: …combative or like, “Hey, I’m not willing to work,” but if it really is just wasting everybody’s time, and it’s a consistent thing. It’s one thing if it’s a one off, and you’re just like, “Hey, you know, whatever, we’ll do it, it’s part of our sprint, or a whole sprint.” But, if stuff like this is coming up every single sprint, this is a symptom of a huge problem. Roy: It’s like the difference, too, if one person feels this way versus a bunch of people feeling that way. If one person disagrees all the time, then maybe that one person has a problem. But if the entire team, each time has gone like, “This is the wrong direction, this adds no value,” or whatever, and they constantly express that, that’s when we start paying attention. Why Aren’t Teams Dealing With This Issue More Often Jade: Why do you think more teams don’t deal with this? Roy: Because it’s a lot easier to keep your head down. In my experience, when I speak up, I feel like the rest of the team goes ahead and shoots me down preemptively so they won’t be held responsible for my actions. [laughter] Derek: Enemy might come in, shoot your own soldier, something like that. Yeah, I think that it’s difficult. Some people, they’ve got a mortgage to pay, they’ve got a family to support. They’re afraid of making waves, makes them not promotable, or, fireable even. I think sometimes they don’t know. It’s in my gut, I feel like we’re just wasting our time. I’m just a little developer on a little team, part of a bigger micro [inaudible 11:32] , and I have no idea if the product owner really says this is the most important thing. Even though it feels completely not important, maybe there’s some magical information happening out with our customers that I don’t know about, and this is really is the most important thing. Even though it doesn’t feel like it, even if I don’t understand it, even if they can’t articulate it. I think we become subservient to like, the boss said it was important, so, it has to be important. How can you question the boss? Jade: In which case, if it really is important, a simple question of, “Why are we doing this?” should have a quick answer. But, usually it’s not the case because the problem is much more systemic than that.

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. How Do You Handle Executives In Agile Clayton: Today, we have a few things we want to talk about. First thing we’re going to talk about is executives in Agile. How do you handle executives in Agile? Is that even a question, a valid question? It presumes that there’s something to handle, right? Derek: Yeah. To me, when Agile first started, there was no Agile to talk about, so executives were completely not aware of it. If you look at almost everything that exist, that is Agile or has to do with Agile, it largely focused around teams and really, the team level. From my perspective, I don’t even think you need “executive buy‑in” to do Agile. You could do Agile just within yourself. You could get that to stand to your team. To get it outside of your team, you probably need some level of support every rung you go up, but I think you’re probably in a losing proposition if you have to “convince” your executive that they should be Agile. They are not going to have the mindset that it’s going to take to do it. I think it’s a different story if the executives are saying, “We want to be more Agile, and we don’t know how to get there. Can you help us?” Then, I think, there’s a role that you could play in helping guide them through that process. Clayton: I could see that in a small organizational structure where if you have maybe like an executive only a few levels above the team, where teams start performing up to the limit of what they are currently allowed to do or the limit of their self‑organized ability. Roy: [laughs] That’s trademark. If they’re up against a limited app, I can totally see the team approaching the executive and being like, “Listen, we really want to get better and right now, you’re behaving in way X that is holding us back. What can we do about that?” Selling Agile, Two Variants Derek: I think that’s different than trying to sell Agile. I think the problem that people have is that they try to sell executives on Agile opposed to saying like, “Here are the things that aren’t working. We’re not trying to prescribe an answer.” I think that’s a much better sales technique than like when you do this Agile thing. I think we can see it in a difference in our client’s that come to us. There tends to be two funnels. There tends to be the funnel that says, “I want to be agile, and I want my whole company to be agile, and all I care about is agility.” What the hell does that mean? You manufacture widgets, so why do you care if your company is “doing Agile.” Then there are the people that come to us and say, “We’re not the best company we can be and we know it’s because we have these problems and this baggage that is holding us back, and we think some of these Agile principles, values, and frameworks could help us get past those problems. I think it’s very rare that we hit the second one, where they’ve been sold Agile. Roy: I think the first one is much more common. It’s usually that some executive has read a book, talked to a CO or an executive at another company over a game of golf or something like that. Or they have recently been acquired from a company that did “Agile.” They don’t really know what it means themselves, but they have been sold this tale of success that it means more, better, faster, stronger. Should We Do The Big Re-Write Clayton: Speaking of tales of success, what do you guys think of the big rewrite? Derek: Never, ever do it ever. Roy: I don’t think I’ve ever seen a tale of big rewrite success. Derek: I’ve been part of big rewrites. Clayton: It’s very alluring, right? It seems like it would be a very good idea. You’ve got this big clue with a bunch of technical data that’s causing all kinds of problems, so just get rid of it. Apply Technical Excellence Or Build A Competing Product Instead Derek: The thing that I’ll say is that in twenty years of doing this stuff with a ton of different companies I’ve never seen a new rewrite replace the old thing. What you end up doing is having to maintain two things indefinitely. The second thing becomes the ugly thing. Then you end up with the new rewrite which is the third thing. You can never really phase these things out. I think the two approaches that you can take to deal with the big rewrite, meaning there’s definitely technical debt that exists in products, and there’s definitely problems that need to be dealt with. There are two ways that I have seen people successfully deal with them. One is that you take the product, and start to apply technical excellence to it. You start to say, “Every time we touch the code we’re going to make it even better when we’re inside of there.” The other way is you say, “We’re going to basically create a competing product that’s going to try and kick this products ass. If that product can take the market share from our existing product, then it’s gone.” That’s really hard to do if you’re talking about a payroll system or something bigger. Clayton: That’s bigger than the big rewrite. That’s an entirely separate thing you’re talking about now. Roy: I like that, I believe I read somewhere an article from “Thoughtworks” (really Joel on Software) that says like, “Never do the big rewrite,” or something like that that got posted a few weeks ago. They said something similar where they said like, “Write a competing product, and let it be market driven, and don’t try to replace your existing product. Rather build this product to fill all those holes that your current product doesn’t fill. Let the market drive the features of your new product. Then, eventually, it may or may not replace your old product.” Derek: Yeah, I think that’s one of the big problems with the rewrite, is it never feature complete to what the other product was. Roy: Right. The features of the other product usually 60 percent or there’s some large percentage of those features that I never use anyway. Why are you wasting a bunch of time rewriting those features? Replacing Your Family Analogy Clayton: I heard it described by Llewellyn Falco, actually. I thought it was a good way to describe it. Imagine if you had your family, and you suddenly replaced your husband or wife, your spouse, basically. You replace them, and you want your kids to act like nothing is different. Roy: It sounds like the American way. Imposing WIP Limits Clayton: Like, “Hey kids, we’ve got a new wife and everything should be just fine.” That’s kind of the big rewrite. Everyone thinks it’s going to be that way. You’re going to get this newer, better thing that solves all the problems, and no one is going to notice, but everyone does notice. I want to talk about working on one thing or imposing a WIP limit. There’s a lot of scrum teams that have that problem where they work on five things all at once, and they never get anything done. Derek, you and I were talking today about thinking of things, I think it was an article you’d read about like doing an hour class board, where there was this visual limitation of WIP, basically, where you could only work on one thing. You were talking about maybe splitting that up and making those smaller things so that you can only work on a few stories. Maybe you could explain that a bit more. Derek: I think one of the things we see in teams all the time, or I see in teams all the time and seems to be, is that you’ll be multiple days into a sprint and there are no points burned down. We’ve got five people on the team, we’ve got 10 stories. Person A is working on one story, person B is working on another story, person C. You’ve basically got all five people split across all five stories. They get towards five, six days into a sprint or whatever, and none of the stories are done yet. They’re all 80 percent complete, 90 percent complete, opposed to actually getting completion. I think one of the things that is interesting is I try to encourage teams. Try to get points knocked out as soon as possible, really trying to finish functionality, trying to have swarming type of behavior as much as humanly possible. Usually there’s also the pushback and excuses and reasons. I think if you’re going to be prescriptive on a team, you could probably do something where you enforce some kind of WIP limit at a story level instead of a task level. You could say like, “We’re a team of five people, and there could be no more than three stories being worked on at any given time.” When you, physically, pull those three stories down you can’t go get another story until one of those stories is complete. Roy: That makes sense. I’ve worked on a team where we try to do some forming and at first there was a ton of resistance, because we’d have two to three pairs working on the same story. I felt like we’d be stepping on each other’s toes a whole lot. Then, with some extreme cases where we had extremely linear tasks where one had to be done before the other or [inaudible 08:42] serial. We’ve noticed that instead of stepping on each other’s toes a whole bunch, it causes us to talk a whole bunch because we now have to. The entire team is in constant communication which helps the entire team stay focused, and everybody is aware of everything that’s going on. Derek: I like to say that teams that really back against swarming, especially extreme swarming. Usually, it means their design sucks, or their code is extremely monolithic. If everything is all in one giant method, yeah, I believe it is very hard for us to all work in the same code. Where if we’ve got a much more modular way of thinking, it becomes a lot easier to say like, “Hey I’ll go add the verification stuff while you’re adding this stuff, and while you guys are doing the front end stuff.” Now we can very easily split up, if all that’s lumped into one file, one method that’s much more difficult. Then even on the serial thing, you’re exactly right. The problem is they just don’t want to talk. If you’re forced to, basically, say like, “Hey we’re going to build a rail road track coming from each direction, and we’re going to meet in the middle.” You need to be calibrating that every step of the way, or you’re going to end up grossly off. The Price Of Ignoring Information Radiators Clayton: In a situation where the team might get five stories almost done. It seems like every time that happens everyone seems surprised at the end. I’ve seen a team recently who I feel like has been ignoring their information radiators. I noticed that because they had a build monitor that, after a power outage, came back on and was just stuck on the screen saver. It’s been maybe two weeks now and no one has noticed, I don’t think. I was wondering what is about that where it was a visual thing that played noise, and all that stuff, but it seems like it didn’t take them very long to forget about it. I’ve seen the same thing happen with boards and anything that you would put up on a board. Why do you think that is? Why do you think people have a short memory for that stuff? Roy: I think in such instances, there’s sometimes a lack of demand from the information radiator. For example, a CI server is really important if you’re releasing really often because you need to make sure your code is stable at any time. If you’re not releasing for another nine months, who cares if your code is stable for the next month? There are all sorts of reason you should care, but… Clayton: That’s the mindset maybe they get in to? Roy: Right. Information Radiators Enable Accountability Derek: It’s fucking hard to be accountable. I think information radiators help us hold ourselves accountable, because they air our dirty laundry for us. I think when nobody else talks about it, why would I talk about it? If my room is messy and I know I’m not allowed to go out and play until I clean my room, I’m probably not going to want my mother to come into my room, if I know I want to go out to play. I’m going to do everything possible to try to get out to play before she looks at my room. I think teams start to have the same behavior around information radiators in a sense of like, “Hey, if one of them shut off or stopped updating, and nobody has said anything, I’m not going to jump up and say something, because that’s just going to mean more pain for me at some point.” Clayton: I’ve heard people talk about how, like a burn down chart for instance if it looks like maybe after the first few days of the iteration that burn down chart is going, basically, horizontal, I’ve heard people describe that as being useless. But I feel like that tells a very important story, so I could see that maybe there are some times where the team might see that stuff and say, “Well, we forgot to update it, and it doesn’t really show us anything. It’s not burning down, so it’s a waste of time.” It seems like the waste of time stuff is the first trigger for, “Let’s not look at it.” I feel like that’s always a cover for, “Am I doing it right?” Roy: When the information radiator is giving information that people feel like a waste of time, or shows something wrong, like it would normally be small, like in your case with a burn down chart that’s level half‑way through the sprint. Or, for example, a combine board that keeps getting stuck with WIP limit three and that seems to be like a bottle neck when things go wrong. I usually see people try to start ignoring those things, or instead to start making rules around their information radiator to cover up that problem. What I really rarely see is people actually address the problem that the information radiator is trying to indicate. It’s Hard To Be Good, Not Everybody Plays In The NBA Clayton: I guess, what you’re saying, Derek, is it’s hard to be good, right? Derek: It was really funny the other day. One of the teams I’m working with has a retrospective goal to increase some of the test coverage. They are all very committed to it, and they really want that to happen, but they’ve really been going all out trying to do some work that’s really challenging for them to do. They had put up an information radiator to show their code coverage on a couple of pieces of the code, and it’s been flat. I had updated it for them the first couple of days just to show them how it went, and I haven’t for the last two days. One of the guys really cares about quality, really cares about what they are doing, come up to me and I said, “Hey, nobody updated the challenge goal. Are you up‑to‑dating it?” He says, “It hasn’t changed at all. We probably shouldn’t even have that chart.” I said, “Didn’t you commit as a team to make improvements to this.” He’s like, “Yeah, but how are we going to do that?” I said, “Well, are you talking about it in stand‑up?” He’s like, “No.” I’m like, “Why do you have the visibilities?” He’s like, “Man, if we do that, how are we…? That means everybody is going to have to do more testing when they’re doing features.” I’m like, “But, isn’t that what you wanted?” He’s like, “Yeah, but, that’s hard.” I’m like, “Hey, man, not everybody plays in the NBA.” He says, “You’re right.” I think that is the essence of it. It’s really easy to say, “I want more testing. I want to be a good developer. I want blah, blah, blah.” Then, when the rubber hits the road, it’s like, “Well, that’s hard.” Encouraging Accountability Clayton: Do you think that’s the case where maybe someone like the Scrum Master can kind of play “Captain Obvious” in that situation? When the team makes a goal to do something? Let’s say they go as far as making an information radiator. Then, they don’t do anything with it and it’s very obvious that they are avoiding it. Is that the role of the Scrum Master to say, or somebody, the coach or whatever to say, “Hey, you remember about this thing?” Kind of have that conversation. Derek: I really struggle with, “Can you hold people accountable or not?” Part of me says, “No, you can’t, because everything is going to be after the fact.” But, I think you can encourage accountability and especially if you do it via culture. I think one of the things you could do, like if I’m a soccer coach, and I see somebody not training hard. I have a conversation, “Hey, Roy, you’re really not training hard. If you want to start this weekend, you are going to need to step up your training.” If that doesn’t happen, then I don’t start Roy, and he doesn’t play. Yeah, it’s after the fact, meaning I wasn’t able to hold him accountable during the actual practice, but I’ve set something in motion that says like, “Hey, I know coach is watching, and if next week I don’t perform during practice, there is a consequence to it, or there is an action.” I think you do need somebody out there saying, “Hey, you’re goal, you’re retro‑goal was X, and here’s a chart and it’s not moving. What’s going on?” Can I force you to increase the coverage? No. But, what I can do is say, “I’m instilling in you that somebody is watching this, and we’re having a conversation about it.” Clayton: With that, we have run out of time. Thank you guys. Derek: Thank you.

Roy vandeWater: Hi and welcome to another episode of the Agile Weekly Podcast . I’m Roy vandeWater. Jade Meskill: Jade Meskill. Clayton Lengel‑Zigich: Clayton Lengel‑Zigich. Everybody’s Talking About Value Derek Neighbors: I’m Derek Neighbors and today we’re talking about value. Roy: Clayton you brought this up earlier. What kind of context were you talking about value? Clayton: I brought it up because Derek and I were talking about it. Derek and Jade and I were talking about it. Jade: Derek, Jade, and half of twitter, and Clayton were talking about it. Clayton: I think the core of it is everyone talks about value. It’s like this litmus test. If you go to a Scrum user group and somebody’s talking about something, the way that you can make it seem you know what you are talking about is if you say something like “I just focus on delivering value to the customer.” Everyone is like “I heard that once in an article, and I read that in a book so this guy knows what he’s talking about.” Then you scratch a little bit and then if you peel back the onion what do you get? Jade: More value. Derek: It’s because the quality conversation ran out of gas. [laughter] Derek: It used to be quality, and then, once people realized that, “Crap, that ship don’t sail anymore,” they… [crosstalk] Derek: …to value. [crosstalk] Derek: Quality’s hard. What Does Deliver Value Actually Mean Derek: I’m actually thinking a lot of this Lean Startup. All the Lean Startup stuff came out, and it was really pushed in from our product perspective value. I think when you’re talking technical excellence, the word that everybody uses is quality. When you start to talk about product ownership, product management, or the proxy side of things, it’s all about value. My question was simple, I thought. Apparently questions piss people off. And that is, what is value? I don’t know. I hear it said so much that it’s like that void word that has no real meaning. Clayton: What if you go with the easy answer, which I think may be…the easy thing to measure is money. Value is when I make more money. if I had a feature that makes more money. Roy: That’s probably a good starting point. Derek: The Lean folks probably come from that lineage that really says, value is that which makes you money, that which saves you money, or those things that help you discover how to make or save money. I think that that’s not a bad definition. What if you’re working in an industry where money is not the end goal? How do you deal with things like customer satisfaction or delight, or some of the other elements that are important? May be you could push those back to; if your customers are happy they refer people enough. If they refer people, that makes you money. You’re really talking about making more money. I think the problem is…I don’t think people are having those conversations. They just say, “Yeah well, I met my value stream and I’m going to provide a whole lot of value and the user stories have to have a value clause.” When you say, “OK, what is it that you guys value?” “Value. I’m just talking value. Come on man, value.” Roy: I guess it’s kind of specific to your vision, right? Because, if your vision is, for example, to make a huge impact in the world, money may be totally irrelevant. Value Is What You Like Derek: I think Ron Jefferies, I think kind of put it is…it’s what makes you happy. I think that that’s a fairly reasonable answer from a Zen kind of state, right? Roy: Who is you in this context? Derek: Value is what makes people happy, right? If you’re making your customers happy they’re going to give you money or they’re going to do whatever you’re trying to drive them to do. If you’re happy doing what you want, you get the personal satisfaction that what you’re doing is meaningful and has a purpose and everything else. I think that’s over simplified. can you imagine if people ran around going “Your user stories have to make you happy. Do what makes you happy. Whatever makes you happy.” Right? I think that the problem is, not that people use the word value, but rather that I don’t think people are talking about what it means. Not a single person that I talked to could respond back with a specific of what value means. Except, I will give Alan Shalloway credit. He gave the lean answer for what value means. Most people couldn’t answer the question. How are we going around professing “Do things that deliver value” when we don’t even know what that means? Roy: I think happiness is a good place to start. You talked about, obviously can’t go around and always say, “Do what makes you happy.” In the long run, not having a job might not make you happy. If you keep that in the long sight… Jade: Well, it’s not about making you happy. It’s about making your customer happy. Whoever it is that’s a recipient of what you’re doing. What We Like Or What The Customer Likes Roy: I don’t know if I agree with that. Why do we work? Right? I think the end result of why people work in general is to make themselves happy… Jade: If we start to optimize for our own happiness, we’re not going to build the things that delight our customers. [ crosstalk ] Roy: Only if we shallowly make ourselves happy, right? Clayton: No, but if you’re talking about developing a feature, or if you have a list of features and you’re trying to say like, “I want to do the one that’s most valuable,” and that’s the way people talk, right? “Let’s do the feature that delivers the most value the customer” I don’t think it has anything to do with your meaning… Roy: Yeah, that’s a good point. It’s too high level to prioritize one thing versus another. Conflict Of Delight Derek: I think the thing is I think you could say it’s your own happiness as well. The problem is, and this is where I went back with Ron on was, that I think that is potentially non‑sustainable. If what makes me happy is doing 3D video games and I work for a social media company and therefore, I don’t do any work except for 3D video games. I’m probably either not going to be not employed very long with said company or the company is going to have operative problems to the point where I’m not happy for other reasons. Roy: Right, that’s what I’m saying. It’s short‑sighted thinking in terms of trying to do what makes you happy, right? I totally agree with you but I guess what I’m saying is in the end result you’re still trying to make yourself happy you’re just taking the long view and saying I can’t do what makes me happiest right now because in the long‑term I won’t be. You Have To Know Your Own Values Derek: I don’t even know if it’s that. I think this goes back to if you’re talking the Zen conversation, right? One of the things that you’re saying is if I really want to do 3D video game programming, why am I working for a social media company that’s not allowing me to do 3D video game programming? If you follow that line if it doesn’t line up to my value system, why am I doing the work? Why am I not going and finding another job that makes me happy and makes my customer, however… The problem is it takes a level of actualization to have that be true for everyone. That’s what I was really asking is “OK, I’m OK with that definition but not everybody is mentally there to make that so what does the path to get there look like?” Clayton: We were talking about a shared vision, maybe putting it from a company’s perspective. If the organization has a shared vision then we were thinking it might be easier for them to assign value to things based on what achieves that shared vision or what gets them closer to that. I think is more in line with the customer delight stuff and probably further away from necessarily dollars. We realize in some cases that maybe your shared vision is very money‑oriented so that would be a reasonable way to value things. No One Inspired By Money Alone Roy: Most people tend not to get, especially in larger companies and even the smaller ones, I find that people don’t seem to get that motivated based on visions around money to a point, right? Nobody gets inspired by “We are going to increase sales by 25 percent”. Clayton: That would be a crappy shared vision. If we’re talking about the Red Cross; the Red Cross has efforts where measuring money would make sense as far as donations are concerned. That’s why I think you could totally have some stuff to say, “Hey if we implement these features, we could increase donations.” Roy: That’s how your vision, no, no… [crosstalk] Clayton: No, that would be a money thing but they could also have stuff that could be surrounding. We need to be better at helping other people. That’s like their core right? I don’t know what their mission or vision statement is, but at their core they help people. There are things they could do to help people that have nothing to do necessarily with money. That’s separate from the donation stuff. Derek: Most companies don’t have vision. They don’t have vision as a company and they certainly don’t have vision at a product level. If Apple’s vision for the iPhone was to make two billion dollars on their phone sales in two years, they probably would have not had any engineers at Apple really interested in working on their product. Instead, by saying, “We are going to transform how people think about mobile computing and we’re going to transform how people interact with computers in a substantial way,” I think they get a hell of a lot more buy‑in and by getting that buy‑in, they probably have a product that sells a lot better. That is so rare in companies. We are in companies all the time where the product vision is either “More customers this quarter”, “Less churn this quarter”, something similar. I’m not saying that those numbers are bad things to have and that you shouldn’t measure those things and that you shouldn’t have targets for those things, but that is where the vision begins and ends. There is no vision of “We want to radically change whatever marketplace we’re in.” “We want to be the talk of the town” or whatever it is. There is nothing substantial. How, when you get a story in, how do you measure that toward 25 percent increase in customers? That gives…really difficult to aspire to that. Maybe It Doesn’t Matter, It’s Just What You Like Clayton: Let’s say all you heard about was increasing customers and you heard a bunch of stories that you thought could achieve that goal and you could measure; that was your value…you were saying, this is more valuable because I think I can get more customers, that’s all I care about. Are we just saying that value is relative in that regard. That might work for a while and it’s OK if you call value whatever gets me more of X. It may be for some people that are really self‑actualized its happiness and for the people that all they can think about is getting more customers It’s just more customers. Whatever that means to that end I don’t care. That’s what I am calling about you. Roy: Those people are in the same organization? Clayton: No, I’m saying, is that fair to just say that value…I think that goes back to value is whatever the hell you want it to be. Roy: Sure. Whatever makes you feel good! Clayton: I don’t really think that forwards the conversation. Roy: I guess step one is that you need to as a company find out what you value and I think most people aren’t doing that. Most People Aren’t Even Talking About It Derek: I don’t even think they are talking about it. In the sense of …even if we said like it’s to get more customers. We’re implementing all sorts of crap features that have nothing to do with getting us more customers. It’s someone screaming real loud at Customer X or Boss Y or UX person Z is saying I want this and they’re not tying it back to, well this gets us more customers. Clayton: I think it’s to the detriment of…as long as we are going to talk about value…and the Agile Community, I don’t know that it can be really be this totally abstract concept that’s…make it whatever you want…there is no concrete term, or it doesn’t matter what you call it. Just value. We’re just back to the point of being able to just talk about value and make yourself sound important or smart. I don’t think that’s helpful at all. Derek: It’s because you don’t care about quality. [laughter] What Will Be Hot Next Clayton: If we wait long enough until the value thing gets boring and then can move on to… Derek: Something else will come up next. I think that this is the ebb and flows in this community, whether it be that people are trying to sell their expertise or whether it’s the…they don’t want to look stupid or whatever. I think people don’t like to say, “we don’t have a good answer.” I think that’s a scary thing to say is, we’re shooting this word out all over the place like we are experts in value. When it comes down to it, we really can’t pin our fingers…or put our thumbs on what value really means. Be eloquent about how to say that to someone. Maybe there are some people out there that are doing that, right? Clayton: They are probably not an Agile Community though. I mean that’s how everything in the other community works. The people that think they have the answer for something and it turns out that they are just scratching the surface of some other huge body of knowledge that has existed forever. Then there is some expert over there who knows what he is talking about. Roy: In the meantime you have a handy tool for building credibility. Just mention your increasing value and you’re good. Clayton: I think it’s funny if you look at the value of ValueStream. If you look at the hashtag [crosstalk] …and you watch that there is so much stuff that goes on there where it’s totally spammy stuff. You can tell people are picking certain key words and they’re using… they’re talking about things in a certain way. Especially people who are talking about things like value. They are picking some certain topic and they’re acting like it’s all already figured out, which I feel is at odds with the way we talk having an agile mindset. You aren’t necessarily going to settle on this is the definitive answer for doing this every single time. That’s the way people talk about it. Derek: I’ve got the solution! Nothing could be better. Clayton: Right, I mean that doesn’t make sense. Derek: We like to talk about learning loops, not actually use them. Clayton: I guess that’s convenient. Roy: All right, well thank you for joining us. Please come and talk to us on Facebook. We got some feedback the other day, which is great, except that it was about something that was going wrong, which sucks. It was also because we got to interact with one of our listeners. We’d love for you guys to come and interact with us on Facebook, even when things are going well. So check that out at Facebook.com/agileweekly. Thank you.

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. Jade Meskill: I’m Jade Meskill. [laughter] What Metrics Can I Use To Measure How Agile I Am Clayton: We almost forgot you are here. I want to do Agile, and I want my teams to be awesome, and go faster and be better, and do more better. What metrics can I use to measure how good I am at Agile? Jade: K‑Locks. Roy: Velocity. Derek: Velocity. Roy: I already used that one. Derek: For me, this is so difficult because in other question I always ask, “What is your company doing?” What are the goals of your company? If you’re doing the Agile, you’re succeeding at things you weren’t succeeding at before in your company, whether that’s making your customers happier, whether that’s achieving some new functionality, or gaining more users or doing something, moving in the market. But, to me, unless you are a software consultancy that is getting paid to be more agile, why on earth would use any metrics of agility to measure whether you are successful? Being more agile has no purpose if you’re just more agile‑like. If I’m a thousand percent more agile, but I don’t know what the hell to build with that new agility, what’s the point of being more agile? Jade: We are talking about problems for developers here. I’ve got to get these developers in shape. Those are problems that I need to worry about. Everything’s cool there. We’re good. Don’t worry about that stuff. The developers are what’s holding us back. How Do I Know If My Teams Are Agile Derek: One of the things I’ve started to do a little more, at least at the team level is ask that the direct manager for the teams to say, “How would you know that these teams are better? What are some things that you would know?” I, basically, right off the bat say, “If your answer is more, better, faster, I’m not interested in helping you.” What we generally started to see are things like, “We want the team to be interacting, more co‑creation to happen. We want it to be easier to on‑board new team members. We want the quality of the code or the technical debt to start to recede. We want more automation. We want to be able to deploy more often.” There’s still shallow, technical things, but they’re not velocity, or story points, or that we’re doing process X or process Y. There’s something more tangible, like, “Hey, it used to take us three days to deploy the software, now it takes us a day. We’re getting better at being able to do the deployment of the software.” To me, that’s something, and that’s better than velocity. But to me, great, if you can deploy every 30 seconds, but you don’t have anything worth deploying, what’s the point? Clayton: I had a manager tell me recently that they wanted to do agile, because they wanted people to stop leaving. Derek: I’ve seen that in a couple of the value sessions, or goal sessions that I’ve done with managers, where some of it is they identify, they want a culture that is more friendly. I’ve got one team that overtime, lot of overtime, and big pushes for major events are a problem. One of the things they really wanted was more of a sustainable pace. The reason why is because they said, “We want to stop burning people out because we’re losing good people to it.” I think those are good and noble things from a technical and team perspective. If you’ve got this great sustainable pace, but you’re crappy in the marketplace, you’re not going to be sustainable as a company. The Only Thing That Matters Is Customer Delight Jade: That’s why Steven Denning says, “The only thing that matters is customer’s delight.” Clayton: If I’m kind of some average manager guy, and maybe I read “Lean Startup,” the takeaway for me is you need data and experiments, the scientific kind of thing. Then I talk to kind of the run of the mill agilist, and they say, “Metrics are kind of wishy‑washy, you don’t really need those.” Do you think that’s some of it? Where people think that they need to measure something, and science is so important. I just need and data crunch numbers and have a yes or no binary answer? Jade: Look at the success of Frederick Taylor and scientific management. It’s build wonderful companies where people want to work…not. Derek: I think what happens in organizations, they want “organizational agility.” Organizational agility means everybody is “agile.” If I’m the person that’s, basically, championing that, I have to be able to tell the CEO, “Hey we’re agile now!” He’s going to go, “How do you know that?” “Because all the teams are agile!” “How do you they’re all agile?” Because of… Jade: We’re all doing Scrum! How To Measure Organization Agility Derek: …they’ve all doubled their velocity. I think there’s a lot of that going on. People are trying to measure that binary bit, are we agile or not? Opposed to organizational agility being about, “We’re more competitive in the marketplace and we’re making our customer happy. We’ve got better employees, and we are learning more,” and all of these kind of principles and values behind that door, like nobody wants to top us on. I am all‑for the majoring stuff. It’s just be careful what you major, because we are going to give what you major, and people are going to focus on what you major. If you focus on velocity you might get some really great stories “done.” But the quality can suck ass, the automation could be horrible, and your customers could be miserable. You have to be a little bit more holistic in what it is that you are really trying to achieve, and so when I always try to do is say, “Why do you want to be agile”? More, better, faster is not a thing. If you want more, better, faster, give me a whip, and let me fire anybody who does not code up to standard right‑now‑today. I’ll beat the crap out of these people, and you’ll get the best code you’ve ever seen for twelve months, from a speed perspective. The problem is that’s not what people really want. Clayton: You might be in the checklist for agile, but you are delivering something crappier or whatever. Even from speed, I think a lot of people, ourselves included, would say that releasing frequently, and giving feedback is a good thing, so isn’t that more, better, faster? If I release every four week, or something, or at the end of every sprint? Jade: I think it comes down to what your intentions are behind doing that right? If you are doing that to make more money, or hit these quarterly deadlines that are being set for you, then that’s not the right thing. If you are doing it because you find that giving your customers more frequent access to new updates to your software provides better feedback that allows you to build a better product. Now you are actually doing more, better, faster, but you are doing it for the right reasons. Derek: I would say the big push off is, if I just want people to release faster, for the sake of releasing faster, that’s shallow crap, and nobody should do it. If people are releasing faster so that they can get feedback more quickly, and they can learn, and they believe they are getting feedback from a real experience instead of a stimulated experience, is a more valuable learning loop, and that that learning loop can be closed faster and faster allowing them to become more and more nimble. Then, I don’t think that it’s about going faster, that’s about learning faster. I think that’s totally different. If we say we want faster production, then we are going down the wrong train. If we say we want to learn faster, we want to be more quickly attuned to what our customer needs, that speaks more towards agility. You might not have to even release software to do that. You could do paper prototypes and customer surveys, and you can go out and talk to customers and something else. But you might say the problem with that is, “That’s not a real experience and I want to give somebody the real thing.” In order to do that, if I can’t produce quicker, it gives me tighter loops. I think if you are going faster just so you can say, “We are a fast team,” you are doing it wrong. If you are saying, “We want to go faster so that we can validate our hypothesis much more quickly, and respond quicker to customer demand to make them happier,” I think you start to win. Why Is Releasing So Difficult Clayton: What is it that makes releasing so hard? Why is it that so many companies seem to have really hard time releasing software frequently? Derek: Lack of automation. I think that is the number one thing. They do it so infrequently. They do not know how to do it. The other thing is technical, that they are scared to release something, because if something goes wrong, it is really difficult to undo that thing. Roy: Organizationally, too, a lot of times sales tunes are set up to deal with much larger releases. They do an annual release or whatever, after spending all this time, wrapping up and selling the big new feature, because customers purchase features. If you are really thinking of service, it’s really obvious to do version increase, just because instead of as your customers they keep subscribing to your service. But if you sell a product, and especially when you want to charge a lot of money for the project, like a lot of companies do, like Adobe, or any other companies. You purchase Photoshop, and it’s really expensive, so there it has to have a lot of features in there. The inverse business model to release a product like that, does it have to reselling a cheap product really frequently, in order to make some of that money back and that they probably end up making less. You know what I mean? A Lack Of Automation Points To Lack of Technical Practices Clayton: Derek, you’ve mentioned automation, and the pressures of the sales people wanting to sell the big features that you’re able to upgrade kind of thing. Why hasn’t there a focus on the technical practices that a lot of agile people are talking about? When you get back to technical practices, developers have lost their way, and they don’t value that stuff anymore. Derek: For the automation side? Clayton: Sure, yeah. Derek: I think for the automation side, the problem is that people tend to get told they have to go really, really fast, and the pressure is on to ship features, so they don’t ever take the time to slow down to go fast. If I got to do something a hundred times, and it would take me an hour to automate it or it would take me 10 minutes to do it, which one is better? If somebody’s holding a bat to my head and say, “I need this right now.” I’m going to take the 10‑minute option almost every single time, because I don’t want to get hit in the head with a bat if I take an hour to do it even if it means it’s free every time after this. I think people are trained to not automate because it takes time to automate. I think a lot of the people in the industry right now are coming from environments, where they’re not very Unix based. They’re not used to toolsets and tool chains that allow for really good quality automation of passing thing from one thing to another, controlling things via command line, and a number of things. I think some of it is technology has gotten better. It’s, basically, hidden some of what’s underneath the hood to a lot of the current developers that are out there. They don’t even know it’s a possibility to do some automation. Infrequent Releasing A Sign Of Bad Product Management Clayton: How much of not releasing frequently is just bad product management? Like they don’t have anything to release, or they’re afraid to release something, because it’s not good enough, or there’s no innovation. Would you think a company might release more frequently, or they would push that issue if there was a ton of innovation going on, and they have all these awesome ideas, and all these awesome stuff that they could execute on? Jade: I think a lot of it is overcoming the legacy of packaged software. The Internet has radically transformed our ability to release often. That didn’t use to be a thing that existed. You go back 15 years, you couldn’t do that. Derek: It takes a couple of weeks to produce an ISO. Jade: Yeah, at least, and it costs a lot of money. The upgrade costs were very painful. A lot of people who find themselves in product management situations, they’re still tied to that legacy of thinking that way. Some of the Web startups, they embrace that right away, because it’s totally possible. They have come to the realization that that world exists, and they can do whatever they want. They can release whenever they want, and their customers won’t even really know. But that’s a relatively new thing that has happened. Organizational Debt And Project Hell Derek: One of the things I’ve seen a ton of happen, and I think this is to me the equivalent of organization, if there’s technical debt, I would call some of these organizational debt. Especially in enterprises one of the things that happens is everything becomes a project. Then all projects become interdependent. Then we can never release because we’re always waiting. The example I used with somebody today from a metaphor perspective is imagine if you get off the airplane, you go down to catch the shuttle to go get your rental car. The guy pulls up, and you get in, and he sits there for four hours. You go, “Aren’t you going to take me to the car?” He’s like, “Well, look there’s other people coming off the plane. Until everybody gets off of every plane that comes in tonight, we’re not leaving.” You would be pissed off. What happens today is you get on that. Two seconds later the door shut, and he takes off. If somebody is running behind the thing and you say, “Hey, there’s somebody waiting,” his response is going to be, “That’s OK. There’s another shuttle in two minutes.” What happens in the enterprise world because they’re not having these frequent releases and because everything is interdependent, nobody can leave to go get their car until every plane has landed, and everybody is on the shuttle. I think that… Jade: Forever [laughs] . Derek: Forever. It just gets to the point where a six‑week contingent becomes a 10‑week contingent becomes a 12‑week contingent because now everybody is scared shitless to release it, because they don’t even remember what’s in it anymore. Then people starts to say, “We have to release now. We can’t wait anymore. There’s some big ad coming out. We have to do it.” Then people start tearing out half‑done features. Then they’re really nervous, because now they don’t know what they’ve added, and what they’ve removed. I think this is one of the things that automation and that doing it regularly. If you can get to the point where you say, “Just go ahead and put it into production, the next shuttle is coming in two minutes,” it really changes how you think. But I think it also requires that people stops thinking in terms of projects from a product management perspective, and think much more in terms of features. “This feature is done, lock and loaded. Go,” and not, “There’s this 60 features, and they all have to be released at the same time.” Jade: It’s being tied to the legacy of selling versions. Long Release Cycles, Who Moved My Cheese Clayton: You made a point about this a couple of weeks ago, Derek, that you might be wanting to shift more away from that big versions or the release once a year thing. There are some people that might say, “Hey, give me every single update. I want to be bleeding edge,” and there are some existing customers that might say, “You know what, I’m fine with the one big year update.” For the most part, that would be pretty seamless for them. They’re going to get essentially all the little updates all at once, and to them, it’s going to seem like the same old big release. But the other people, they can just get the new stuff every month or whatever it is. I thought that was an interesting point, and a good way to think about transitioning from people who are in that, “I have to make a DVD, and mail it to people” mindset to more of the software’s a service but not jumping full shift into that. I think we’re out of time. Thanks guys. Derek: Thank you.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Derek Neighbors: I’m Derek Neighbors. Roy van de Water: I’m Roy van de Water. Jade Meskill: I’m Jade Meskill. Clayton: I’d like to start out by asking everyone if you could please go to iTunes and rate this podcast if you get it from iTunes. We would appreciate that. We like the feedback. We did see one comment. Someone mentioned that we sound inexperienced. We’re going to take a look at the equipment and see if we can get that fixed. [laughter] Derek: What do you mean “sound”? Clayton: I assume it’s something wrong with the border. [laughter] Working Agreements In The Real World Clayton: We’re going to start talking about “working agreements.” Here’s right off the bat. Roy, you work on a team where you have a working agreement with the team that says, “No production code will be siloed, so you’re going to pair all the time.” But, the rub is that you have an odd number of people. How does that work? Jade: …and then odd group of people. [laughs] Roy: Yeah, we have an odd group of people. Clayton: It’s the second area of problem. [laughs] Roy: For us, that currently works by, “If you can’t silo, and we always pair, that means that if we have an odd number of people, we have three people in front of a computer.” We talked about that last time, “stooging”? [laughter] Derek: Is that three keyboards? Three mice? Jade: This isn’t XP, my friend. Roy: It’s two keyboards and two mice, you can’t really sit all across, because then you’re at too extreme of an angle to the screen, you can’t see anything. Jade: Let’s talk about what happens when you’re in this “stooging” set up, just to set the stage real quick. Mandated Pairing With Odd Numbers Roy: What happens when I’m in it? Or ideally what happens? Ideally, in this case, usually what happens is, there are two people that are pairing and one person that just sits behind and peers over both of their shoulders. Jade: Has your team discussed this working agreement and the consequences of it? Roy: Yeah, we discussed it this morning. Jade: OK, how’d that go? Roy: I got shot down with an absolute “no,” when I proposed abolishing it. Clayton: Was the reason it got shot down was because they feel very strongly about not having silos? Roy: Yes, the reason I got shot down which is a legitimate reason and a legitimate problem, was they don’t want silos and the reason they don’t want silos is because, if someone is working alone, they can make decisions that the team is not privy to. They’re really concerned about somebody making some decision by themselves and then the rest of the team has to deal with the consequences. There may be other ways for us to solve that particular problem but that is the group fear that we claim to have. Clayton: What are some ideas that you had for fixing it? How could you still have that working agreement where you don’t let people silo on production code, but not do this thing where you have to peer over people’s shoulders? Roy: Did you say still have people silo or don’t have them silo? Clayton: Not having people silo on production codes is a totally valuable, reasonable thing to have. Roy: Sure. I agree and I don’t. There’s other ways to mitigate it. For example, what if we switched off pairs really, really frequently? Then you wouldn’t get the opportunity to silo for long enough to do any real damage. If you were to do a no‑siloing thing, I don’t know. At this point, the way that I feel when we’re stooging is when I’m the odd man out that’s sitting in the back like, “I am just wasting time.” I could be doing anything like answering email, or doing self‑improvement, or something like that. I feel like that would be a better use of my time. Working Agreement Causes As Many Problems As It Solves Jade: To not get distracted with trying to solve that particular problem. On a team, what happens when you end up with a working agreement like this where the team feels very strongly about trying to protect one thing, but they’re actually causing other problems with the working agreement that the team has agreed on? What do you do? Derek: I don’t really think you can force teams to do things. Sometimes, you could but it’s probably not prudent more often than not. Sometimes, you have to let people be a little bit stupid until they recognize that maybe their stupidity’s holding them back. It sounds like, in this instance, there’s inklings that people are understanding that what’s happening is problematic, but at this point, they have a value system that says, “We value this so much that, right now, we’re not willing to divest the value of that for something else.” Roy: It might be legitimate. I have not been with this team very long, but I’ve heard that in the past, they had some major issues with siloed work that caused major harm to the team and put several of our commitments either in danger or actually destroy their ability to commit to stuff. I can understand and relate to that. Ways To Prevent Future Problems With Working Agreements Clayton: Is there something about the way that a team might make working agreements where they would have the foresight to avoid some of this stuff or…in my way of asking this, how frequently should the team revisit their working agreements? Jade: The trick is, a lot of times we want to write them down and carve them into the tablets in the Ten Commandments of the team when, really, they’re a fluid living thing. The intent is that they’re there to help reinforce behaviors that we wish we had. Once we’ve addressed that, we should get rid of that working agreement. Once it has become habit, let’s move on. They should be very fluid living things. It’s hard to live with that reality. They can be changing all the time. How Often Should You Revisit Existing Working Agreements Roy: Does it make sense to have a team working agreement to revisit all of your other working agreements on a regular basis to review them? Should instead, have a working agreement until something comes up that causes us to question it? That’s the time to bring up whether or not we should continue to have it? Using Values and Principles Instead Derek: I’m starting to lean more and more in life towards working agreements are evil hell. In the sense of they look like what we call “policy,” elsewhere. We’d be much better suited as teams if we rooted ourselves in values and principles. We could say, “Behavior X is violating value Y.” Opposed to, “Here’s some hard and rigid rule we have to revisit.” As we continue to add to them, it doesn’t fit on an index card. Then it doesn’t fit on an “8.5 * 11” sheet of paper. Then it doesn’t fit on a poster board. Next thing, you have got the 795‑page working agreements book that people are trying to, “Subsection B.593 of the working agreement states…” In this case, if the team said, “We value working together more than value working independently.” They could say, each one of those things “Is it valuable enough for us to do this first”? They could weigh values against each other. Roy: I totally agree. We used to have that problem with Integrum back when we were doing contract development work. We used to come up a smart goal every week. Five weeks in, you totally forget what your smart goal was five weeks ago. Until you break it and it is convenient for somebody else to point it out. After a while it builds up so much stuff, it’s hard to remember all of it. A base system of values is not hard to remember. You just use logic to figure out the rest. Derek: Smart goals are a little bit different. It’s important that you set marks for success to say, “If we do X, can we change our behavior Y and measure a change”? If we have a hypothesis, and then we do something to work against that hypothesis, can we get the thing we are trying to measure to move? That’s a little bit different than a working agreement. For retrospective goals, they are only as good as that sprint. Unless, the next sprint, they decide to do this again. They are temporal. Working agreements are a little different. When people put them down, they think of them a lot more like policy. They exist until somebody says we terminate them. Fixed vs Growth Mindset Jade: It really comes down to a fixed mind set versus a learning mind set. If we treat the working agreements as rules ‑‑ which is not their intent ‑‑ but it tends to happen that they become the rules of the team. We’re really missing the point. We’re probably doing Agile, and not being agile. That’s what we really need to be weary of as a team. Even values and principles ‑‑ if they are being used in such a way that they are a weapon against your fellow team members, you’re missing the point. Clayton: One thing that’s interesting. If you took a team that wasn’t especially mature from a team perspective. Let’s say they knew about XP. They knew that courage existed. Courage means a lot of things to a lot of people. Even if they read into what they mean in that context, they might agree to it. If the team is immature, they might need something that is more of a specific working agreement. As the team matured and grew with that working agreement, they probably would come full circle to, “Hey, we are now at courage again. It means something different to us.” I wonder if, as the team matures, they can shed some of the weight of those things being rules and can get to the principles. They were always at the principles and values, the entire time. They just didn’t realize it. Roy: That makes sense. I like that. Team Rules Instead Clayton: I don’t know if that’s the case or not. It seems like that’s the way things go. Roy, you had mentioned the idea of having a working agreement to revisit the working agreements. Jade, you had mentioned that they are a living document. I don’t even know that a lot teams take working agreements seriously. They treat them more like rules, like what Derek’s getting at. How much effort should you put into those things? How much meaning should they have on the team? You mentioned team rules, which sounds bad. Doesn’t the team need something like that? Roy: As little as possible so that there is as little resistance to change, if you want to change them down the line. Jade: I have a question real quick. This team that you’re working with, have you guys discussed your principles and values? Are those things that you’ve identified, or did you just jump right into working agreements? Roy: I want to say yes, but I’m not entirely sure if we ever have. I don’t know, sorry. Clayton: That’s another thing I’ve seen too. Roy: I wouldn’t be able to tell you what our values are, principles. Sorry. Clayton: Where people will have a Scrum team and they’ll say, “Oh it’s a Scrum team, so they use the Scrum values,” and then what are the SCRIM values? “I don’t know.” They never even agreed to these things. I feel like that happens all the time. Roy: Even at our place, we have the core commitments posted on the wall, but nobody’s committed to them. Commitments Vs Agreements Derek: To me, as I lean further away from working agreements, things like the core really appeal to me. Where you’ve got core commitments, which are like working agreements, that are a lot more value‑based than they are rule‑based. Then you’ve got constraints to work within, to say this is how we can solve problems based on these values. So that every unique situation that comes up, we don’t have to say, “How do we interpret the rule”? We’ve got mechanisms to communicate with each other to navigate how we want to deal with that rule. Jade: These are the Core Protocols by Jim and Michele McCarthy. Roy: Trying to avoid getting sued for your GPLv3 stuff? [laughter] Clayton: Are we, maybe saying, “You shouldn’t use working agreements”? Derek: I don’t know if I would go as far as to say, “They’re evil. Stay away from them. They’re horrible.” Like all things, they’re a tool and tools can be easily abused. People tend to…when they get into working agreements they tend to get legalistic really quick. What happens is either that people don’t take them seriously at all, so they have no value, or people abuse them by using them as a stick to hit people with it, that they disagree with, when they want to disagree with them. Jade: If they’re done in the right spirit to really support your principles and values by establishing some habits that you really wished you had. They can be effective. Legalistic Nature Of People Roy: You mentioned about the legalistic thing, I’ve noticed that a lot in all sorts of teams, and groups, and people that I’ve interacted with, there just seems to be this human nature to always go towards the legalistic. Why do you think that is? Derek: I don’t know if it’s human nature. It’s because we don’t do well with ambiguity. We all bring personal baggage. There are so many things. When we lack construct, when we lack guidelines, we really crave that. Our natural tendency tends be to crave over doing that. Where when you look at things like the core, they just give you good operating principles to guide on, so that you can deal with issues as they come. To me, that’s like where we’re evolving from an Agile perspective too. You had traditional project management PMP that was very, very, very, highly prescriptive, highly rule‑based. Any little thing that comes in as a change order, now has a full change request thing, because it’s just not designed to deal with any new introduction into the system. Now, we’re getting more and more nimble things. Where we say, there’s less and less structure and there’s more and more values and principles. As things come in, you try to basically do the right thing. That’s a much different. I like to call that “it’s permission versus policy.” When you start to move more towards that, you have to have much more robust ways of dealing with that. If you’ve got no structure at all. It’s almost like the inverse. When you look at Agile, people think, there’s no structure. It’s actually highly, highly structured just in a very simplistic way. The rules are much more simplistic. They’re much more difficult to understand or nuance. It gets into the whole whether you call it [inaudible 14:00] , or whatever. People that have been doing it for a long time can’t understand why people that are new to it, struggle so much. It should be so simple. There’s just these few little things, but it takes years and years of experience to understand when and how to apply those things. There’s so much context to them. Clayton: All right. I think we’re out of time. Thank you, guys. Jade: Thank you.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile weekly podcast. I’m Clayton Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. 100th Episode Celebration Clayton: Today, we’ve got some topics for you that come straight from the trenches. I’d also like to point out that it’s the 100th episode. Although, if you were to add them all up, we probably missed a few, so this is probably, really, 96 or something. Roy: That’s true, counting as one of our strong suits, and our special episodes, and then there’s all the other episodes that we recorded but lost. No Silo’ing Working Agreement Clayton: I would encourage you to go back and listen to all of them, and check, and see if we’re right or not. The first we’re going to talk about is kind of an interesting thing where you’ve got a team, and from what I understand, they make a working agreement that no one can work as a silo. They have to be working with someone, everything. There’s a problem when there’s the odd number of people. How have you guys been solving that? Roy: Our solutions for the last few months has been to do something that we call trying. Clayton: I’ve also heard stooging for three people, because it’s the three stooges. Disengaged Pairs (Stooging) Roy: I was thinking of the third person as a stooge. I don’t really have a high opinion of it, based off of the experience I’ve had with it, because I’ve actually joined in on some of them. I’ve actually been one of the three on the tri. The common pattern of what I see is, there will be two people working and one person watching, because we do the two keyboard pairing. When you have two people working, and one person watching, the one person watching is not really usually contributing. In some cases they contribute a little bit, because they happen to be the person who has the knowledge but if the primary knowledge holder is the one that’s driving, forget it. The person that’s in the back is going to stay there, and is going to be nodding off before too long. Clayton: I’ve heard a lot of people that try and defend this sort of thing. They make it sound like it’s really easy for everyone to be engaged, and they can learn a lot just by watching, but I don’t think I’ve ever seen that in practice. Roy: All I can say is for me, personally, I can’t stay in [inaudible 01:55] . I am not physically capable of it. I tried today. Today I was doing some tri‑pairing, earlier today, and I was peering over the other two shoulders, going like, “Hey guys.” Clayton: You felt like you were in the back seat? Roy: Right. I felt like a voyeur, watching two other people code. Clayton: The thing I always think about when I hear this sort of thing or people suggest this is they haven’t really done pairing. I think if you’ve really done pairing, and you know what it’s like to have that back and forth, you know that it’s impossible to have a third person there. Mob Programming As An Alternative Roy: I’ve heard of people taking it to extremes, and doing mob programming. I couldn’t imagine having five people. I can’t even do it with three. Clayton: The thing that’s different about mob programming, at least, is that there’s one person driving and everyone else is participating. Roy: That’s true, everybody else is just shouting along. That’s true. You’re not the odd man out at that point. You’re the odd man in. Clayton: Right. I think it makes a difference, at least from the pictures I’ve seen, from mob programming, there’s usually one person in the front, and the other people are behind. Roy: Maybe, we should switch up our mob programming, or, trying strategy, and, instead of two people behind, one person up front, on the keyboard. Clayton: I think space is a limitation. Not everyone has the perfect set up for pairing, let alone a set up where you can see over someone. It’s like you have stadium seating. Trying To Spread Knowlege Via Culture Of Learning Roy: That’s true. When I’m in the back way off to the side, I can’t read a thing, even if you turn the font size up. Clayton: One thing I’ve heard, you’ve mentioned, and I’ve heard other people say this, and I’ve kind of hinted at it, it’s a good way to learn. But that’s not necessarily the team trying to have a culture of learning. Roy: No. Originally, it was. Originally, the problem was we had silos on particular stories, and we had a problem with cherry picking as well, that nobody would call that on because the team was still in the forming stage. You’d have a story about a particular technology, and somebody would say, “Well, I’m familiar with that. I’m going to go ahead and take that and work by myself.” Then nobody else would have the knowledge to transfer. This was to combat that, and I think it was really effective. Originally, I think, it was probably a necessary step for us at first. Closing Skills Gaps Clayton: Do you think it has helped people that have a skills gap, and close that skills gap? Or, do you still see the same people that started out with a gap, are they still in that same phase? Roy: That’s a good point. It depends. Some people still have a bit of a skills gap. I think pairing is a really great tool for teaching, and for learning. But only if everybody is actually in it for that. You know what I mean? It can also be a really great tool for, “I just want to coast along. I’m just going to pair with a bunch of people who do all the work, and then I never have to do anything.” Clayton: Especially, if you’re not driving. If you’re the guy in the back, you can pretty much get by, by just seeming like you’re pairing. Roy: Especially when you’re driving, it’s actually probably easier to get away with that. You can just blindly stenographer everything somebody else says. You don’t have to understand everything that goes on. Clayton: That’s a good point. That’s one of those things where I think if you’ve got someone who’s driving that maybe does have that skills gap, as the navigator, you have to find some creative ways to guide them towards the right direction, but not necessarily tell them what to type, right? Roy: That’s true. It’s difficult and it’s frustrating, because I’ve paired before with people like that where they sit there and look, and like, ” [inaudible 05:13] . Tell me exactly what to type.” Clayton: Or, they kind of act frustrated. But I always wonder, do they just have a fear of getting it wrong? They’re just afraid to fail, and so they wouldn’t start? Roy: I’ve been part of a team before, where two people are pairing. One person was a junior developer, and the other person was a senior developer from back when they had titles. I saw the junior developer do something, type something out, make an attempt at it. I don’t even remember the specifications of it. It was pretty basic, he took a stab at it, and took a paradigm from one language which works in that language, but doesn’t work in this one or something. The other person was like, “Oh, you’re so stupid. I can’t believe you just did that.” Made everybody from the team gather around and look at it and be like, “Look what he just did.” It’s like that person never took any risks anymore after that, like, “I’m not typing anything unless I know for sure it’s correct.” Acting Stupid To Diffuse Anxiety Clayton: You were talking earlier about the concept of acting stupid so you don’t write dumb. I thought that was interesting. Explain that. Roy: Yeah, the idea behind that is instead of trying and looking dumb, and everybody makes fun of me for being dumb. I’m instead going to be dumb on purpose that way nobody can really make fun of me, because I’m the first person to do it. You know what I mean? Clayton: They can’t make a joke about it? Roy: Right. It’s how you would work with a bully at school. You would be like, “Well, I’m going to make fun of myself first, and then that way the bully can’t make fun of me for it.” That is really effective, and maybe the core problem isn’t the person being bullied, maybe the problem is the bully. Clayton: I think on that team, if the team chastises someone for getting it wrong, that doesn’t necessarily sound like they have a learning culture. Roy: Right, but we used to have this culture at Integrum. Remember when we would have fun with that. You, Jade and I all the time, if we catch each other doing something stupid, we’d be like, “Hey, look what you did,” and make a big deal about it, because it was funny, but we’d be OK with it. Teasing When Making Mistakes Clayton: I guess there was something different about that. Because I think we internalized that. We acknowledged the failure maybe, and so we thought it was OK, and it was kind of a learning experience. Roy: Yeah, we still do that. Clayton: That’s true, yeah. What’s different about our team than an average agile team? Roy: Maybe it’s because we feel like we are on equal footing, and we’re doing it in a sense of camaraderie and to communicate. Maintaining The Pecking Order Clayton: I don’t think we have that fear of failing. We aren’t afraid of it. Roy: Also, what I see on some of the teams, or teams before is that it is a way of putting somebody in their place, and maintaining the status quo of ranks. If I’m the senior developer, I’ve got to make fun of the junior developer when they screw up, or else they’re going to be senior developer. If we’re all senior developers how can I be better than everybody else? Clayton: I think that makes sense. I wonder how pervasive that is. I’m sure there’s a lot of people that self identify with the senior developers, and they would want to hold on to that as much as possible. I could see that. A lot of the reasons I think I’ve seen that senior people will either take control and drive all the time and they leave the junior people behind is that they want to get stuff done. I know that your team has been experimenting a lot with pushing the boundaries between having fun and getting things done. Is that a hard line to walk or…? Having Fun And Productivity Roy: It’s really difficult, especially when it seems like when we are having the most fun, and feel like the least productive it often times turns out we were pretty productive. Other times we are not productive at all. A good example is that we had a planning ceremony about a week ago, where normally it takes us about an hour and a half to task out a sprint. In this case we were laughing the entire time, and we were throwing index cards around. I got a picture I think I showed it to you. The entire place was trashed. There were index cards everywhere. Which we all picked up, don’t worry, right before the end. We felt like it was the least productive thing ever, and an hour later we are done with our sprint planning. We were like we can’t have more planning sessions like this, because it is just chaos and un‑maintainable. But then we thought when we stepped back to look at it, but wait we just planned out a sprint’s worth of work in one hour when it normally takes us an hour AND a half, and it was a blast. Clayton: I think sometimes when you are having fun, time flies. You don’t really notice. It doesn’t really drag. Was anyone on the team kind of frustrated with that, maybe were some people not having fun so they thought it was unproductive? Roy: I don’t know, I know personally in the back of my mind I was like, “Man, this is fun, but God I’m going to get in trouble later when it turns out we don’t have anything done. We don’t have any sprint work. We are going to get reamed.” Clayton: Is that your conscience telling you, “Maybe I’m having too much fun?” Or, ” [inaudible 10:16] got to reel it in a bit?” Roy: Yeah. Reflecting On The Level Of Fun Clayton: I think that’s a good point you made about stepping back and reflecting on it. I’m sure in every team there’s varying levels of how much fun they want to have. Roy: That’s true. Clayton: Most agile teams, to some degree, value fun, but I think a lot of them don’t value it enough. Roy: A lot of people are scared of them. Clayton: Scared to have fun, you mean? Roy: Scared to have fun or scared to be seen having fun, because then their managers think they’re not doing work. Clayton: I guess the traditional thing is if you’re having fun at work, then you’re not working. Roy: Right, exactly. Clayton: Which is pretty sad? Roy: I’ve worked with people where we try to have fun. They said, “Hey, we came here to work. We’re here to work. I come here, show up, and do my work and go home. I can have fun at home, but this is not the time and place for it.” How miserable is that? You spend a third of your life here, and you’re not allowed to have fun? Clayton: I think a lot of agile teams embrace the idea of having fun. But maybe they don’t spend enough time reflecting on how much fun their having, or maybe where that boundary is? The boundary between having fun and being productive is kind of a moving target. I think if you have a lot of fun and getting a lot of stuff done, then, usually, people don’t seem to notice, right? Roy: Right. Definitely, there have been times when we have a lot of fun and nothing gets done. Clayton: That’s true. How does your team compromise? How do they mitigate that? Perception Of Work Vs Fun Roy: On a side note real quick. It’s funny how that perception happens, because you remember today, you walked over to our team. Because you all of a sudden heard us be silent, and said, “Hey, it sounds like you guys are finally starting to get some work done,” because we’ve been screwing around. The irony part was, the reason we were all silent was because we all turned back to look at our email and stopped working, for that little bit. Exactly when we were not working, was when you thought we were working the hardest. Clayton: That is interesting. I guess the perception from the outside could be pretty misleading if you don’t know how the team is operating. When you guys are having fun, how much does that play into creating that kind of learning culture? Do you guys try to have fun as a means of learning? Roy: I don’t know if it’s a means of learning. Learning should definitely be fun. If you make work fun, then you make people passionate outside of work. If your work is dreary, then why would you spend your free time getting better at it? It’s like, “I hate programming. The last thing I’m going to do at night when I’m sitting at home is program. I’m going to watch TV or read a book,” or whatever it is you do. If your work is fun, then all of a sudden you’re like, “Man, this is great!” Programming is awesome if you have fun at it, and work with good people. It can be a really fun experience. With Start‑Up Weekend we got together the group just for fun. We programmed for fun. Nobody paid us. We made a product we knew we were going to throw away at the end. Clayton: That’s true. Roy: It’s a blast to work that way. If that type of thing is true, and you enjoy what you do, then all of a sudden it’s going to become worth it to you to spend your free time learning it, too. Like, “This was fun at work. I’m going to do this as a hobby. I’m going to get better at it,” which in turn makes your work more fun. It all of a sudden starts feeding back on itself. Clayton: Fun is definitely underestimated. I think it’s talked a lot about in the agile community, and it’s really gamification and all that kind of stuff. I think as a team value it probably goes under represented. Although I feel like at a human level, everybody wants to have fun. Even the people that say they don’t want to have fun at work, they want to have fun. Roy: I think most of the time when fun is brought up during a retrospective or something of that nature, it is almost always in my experience, in the context of we are having too much of it, and we need to cut back. Clayton: That’s true. Roy: What’s interesting is that the talk isn’t we aren’t productive enough and we need to be more productive or we need to hit our sprint. It’s we are having too much fun. That’s our biggest bottleneck. Clearly, if fun was less, the work would be more. Clayton: Maybe that’s a knee jerk reaction to some kind of old way of thinking about things? That everyone’s baked in their mind set about how works supposed to be? That’s why they want to dial back the fun? Roy: Yeah, that makes sense. Clayton: Interesting. I think we are about out of time.

Jade: Hello, and welcome to another episode of the “Agile Weekly Podcast.” I’m Jade Meskill. Roy vandeWater: I’m Roy vandeWater. Derek: I’m Derek Neighbors. Clayton: I’m Clayton Lengel‑Zigich. How Technical Does a Scrum Master Need To Be Jade: Today, guys, we wanted to talk about how technical does your Scrum Master need to be? Roy: Define technical. Jade: Let’s say that your average software team…At what level of technical detail do you think it’s good for the Scrum Master to be aware of and maybe what’s too much? If you had someone that used to be a developer on the team and then they got promoted to Scrum Master, theoretically, they are going to have about the same level of technical knowledge. Roy: They should know how to turn on the computer and know how to use Rally. [laughter] Roy: [inaudible 0:00:53] one that’s said Derek optional. Derek: The second one is optional. OK, so you are talking software, hardware technical, not Scrum technical. Jade: I’ll give you an example. Let’s say that I’m a Scrum Master on a team and the team is planning and they’re going through some implementation. They’re talking about it and I get the impression that they’re going off the deep end and they’re just going in circles but I don’t know enough about technical stuff to be able to tell if that’s true or not so I just keep my mouth shut. Roy: I think I’ve heard Derek say this before, where if you can’t, as a non‑technical Scrum Master, if you can’t understand what’s going on, during like a planning meeting for example, or even worse in a story workshop then it’s probably to implementation level for that type of ceremony. It’s something that should be talked about during pairing. Derek: I guess for me, the way I would look at it is, that the Scrum Master should understand the work that needs to be done. They should not care how that work is done. If you’re talking about a self‑organizing team, I think the Scrum Master needs to understand what the product [inaudible 0:01:56] owner wants so that they can help facilitate the team to get there. I don’t think they have to know anything about how the team is actually going so in some ways that actually cripples a scrum master because they get way too lost in the technical details instead of just looking at the signals, right? If I’m an EMT, I don’t need to know how to do heart surgery, but I should be able to read any EKG reading right? I think the same thing…A Scrum Master should be able to take technical readings of what the data is telling them and burn‑downs and other things and stand‑ups and ceremonies and be able to say, “I’m worried”, but they shouldn’t care about the actual technical details. The Scrum Master During Planning Roy: In this particular case, you are talking about some kind of ceremony. I can’t remember if you said planning or… Jade: I said planning yeah. Roy: A planning session where they’re getting into details as a scrum master can’t understand, and I guess my attitude is, as a non‑technical scrum master if you can’t understand it, then it’s probably too technical to be discussed during planning, and it’s not a matter of the scrum master not having enough technical knowledge. Jade: You’re right. I’m getting the impression that if I as the scrum master, rather than focusing on learning more about the technical stuff so that I could understand the problem better, which would be the EMT learning more about heart surgery, I should really focus on my facilitation skills and being able to pick up on those cues and triggers, better read the EKG. Derek: I would say, “Why do you care how technical somebody is in a planning meeting? If people need to get very technical in a planning meeting, why should that be a problem?”. Usually the reason it’s a problem is because they’re taking forever planning because they’re getting into way too much detail. If I know that, “Hey, we’ve got X amount of work to plan” or we’re going through planning, and people are taking forever to get something done, I could say, “It feels like we’re getting into a lot of detail. We’re taking an awful lot of time discussing implementation, maybe we need to step it up a little.” I don’t need to know anything about what that implementation is. I just have to facilitate, “Hey, the energy in the room is completely dropping. There’s something wrong. Can we change it?” Roy: That’s true and you’re right, because I’ve seen people that have absolutely no technical background still be able to tell like , “Hey guys, Isn’t this a little too in the details?” Derek: I think having a technical background can help, but I think more often than not it tends to hurt more than help, because you try to use that technical knowledge to help your team. Roy: It’s hard to be impartial when you have knowledge. How Does Workspace Design Impact Teams Jade: Yeah, you’re your own worst enemy at that point. Let’s talk about work space design, work space layout. How does the work space that you’re in affect the team itself and the work that you’re doing? Roy: I personally feel like there’s two very important pieces to a good team environment from work space perspective, which is the ability to communicate freely between the team members directly, being able to see each other, and then also having the freedom to communicate loudly without bothering the people around you, if that makes sense. I can see Clayton and talk to him directly if he’s on my team, but me talking to Clayton will not bother Derek who is on another team or working by himself. That to me, is a good work space. Jade: I did an exercise with…I guess probably about forty people or so, and I had them draw their ideal work space. They all pretty much were the same, where they had a team area which describes kind of what Roy’s getting to where people could pretty much look at each other, and talk to each other very freely. There was always a space for some kind of quiet thing, like you could get away from the team if you wanted to. There was some fun aspect where that would be like, you do work over here but then over here is where you have fun. There were some other things sprinkled in but those were the main themes. I think almost all of them were framed in the concept of a bull pen, which I think was more just. That’s what the people who did the exercise were familiar with. They hadn’t experienced something like a gang plank which had a very open floor plan that was very sprawling. That’s kind of their mind set. They were in that box. I like the idea of having the free and open communication with the team members and having an open space that you can feel safe talking in. Derek: I think, I don’t know, probably circa 2006, 2007, Mike Cohn made a really great blog post called “The Ideal At Work Space”. It had nine or ten qualities and I believe our Integrum made a counter video to that. They added two or three additional ones as well as showed some visual parts of the work space. I think all of those things are still absolutely relevant today. I think you guys hit on two of them. One which was every person on the team should be able to see the other person on the team, which I think, whether it’s a bull pen, whether it’s a wide open space, that you should be within visual contact of everyone on else on your team. Another one was that there’s a place to have quiet meetings or what not. I think there’s something about visual pieces that the work is visualized somewhere within the space. There’s a number of things. Those are all great points. The thing that is really difficult when I see a lot of teams struggle or organizations struggle is they say, “OK we’re willing to make the commitment to go to some more kind of open style. “But they have this whole inventory of this really crappy cubical furniture and so there’s this sunk cost of how do we get rid of this and disbelief that you could go to really light weight six foot tables that are upper end Ikea type of tables and put them on wheels. That is so foreign to facilities like whoa…”but then how do you deal with power and how to you deal with Ethernet?” It cascades this panic within the organization of un‑possible. Jade: Probably just like their software. Cultural Debt Derek: Yes. This is something we talked about with [inaudible 0:07:52] in Portland at Agile Open Northwest, right? There’s cultural debt in the same way that there’s technical debt. When you build up these giant facilities department who has three hundred change orders who have to fill out to get an Ethernet moved in a day where 90% of people connect through wireless anyways. It’s like when you can’t move your physical location from one cube to another, that’s an act of God. Imagine if you say, “We’re just going to get rid of all the cubes.” That is full on pandemonium like whoa. How will we track our assets if there’s not cubes that they belong to? Currently we use a Cube ID to track everything that happens. Roy: For effective management. How do I know if Clayton is even working if he could be sitting and working from anywhere. I got to be able to stop by his cube at several points [inaudible 0:08:42] the day and make sure he actually shows up. Yahoo Banishes Remote Work Jade: Let’s go down a tangent here on this one. Marissa Mayer just announced at Yahoo there is no longer a remote work policy. Roy: What? [laughter] Jade: I know, can you believe it? As of June, Yahoo employees either need to move to be physically near their headquarters or they no longer have work from home privileges. What do you guys think about that? Derek: I think if we go buy those principles of what is a quality as a work space, one of things is you should be able to see all the people on your team. Jade: I have Skype and I have Google Hangouts. Derek: Now that said, I think you can do close facsimiles of or proxy’s thereof those things. Roy: [inaudible 0;09:26] keep with people who use the real thing? All Present, All Remote or Hybrid Derek: The problem is that is it really difficult? If everybody is virtual, I think you stand a better chance than if only a few people are virtual. If you have the choice between interacting with the real thing and a virtual thing, you will probably choose the real thing more often than not and so those people become ostracized as the virtual people. If you’ve ever been on a phone call with a conference call calling in, and there’s eight people in the room and two people on the phone, it’s amazing how people will end the meeting without even saying goodbye to the people on the phone because they’re not even part of it. Roy: We even observed this with Integrum when you were working from out of state, Jade. Jade: Yeah. It was very hard to be part of the team. I’ve seen a lot of reactions to this announcement. The biggest thing I think of, when I see what people are writing is, this really comes down to the type of work that you’re doing. If you’re doing very individualized work, it really doesn’t matter where you work from. It doesn’t matter, because your work, is your work, is your work, and you can do it wherever, whenever you want. What I see, is people who value having team based, shared commitments, who are probably doing something that is more on the innovative, creative side than repetitive tasks, individually focused. They really struggle with being distributed. It’s much more difficult for them to do. Remote Optimizing For Experts Derek: I saw a counter to that, in an article and I don’t know if I’ll be able to find it again. They said, “If you’re doing really raw, simple manufacturing type of tasks, then yeah, everybody should be together. If you’re doing really complex work, you should be spread out, all over the place, because it requires really specialized people and you can’t find the best, specialized people on the same location. If you are going to do a really complex thing, you’re going to have to get the best expert in the world, and they might be in Russia and the best expert in the world, on this other thing, is in Brazil, and the other person, is in San Francisco. It’s impossible to build teams that solve complex problems that are co‑collocated, because you can’t get the best people. Roy: I don’t think I agree with that. Clayton: Well, that’s always the argument. You see this a lot from programmers, who talk about, “Oh, this company… Derek: …Ten times… Valuing Being A Team Over Being Individuals Clayton: …wants to hire this awesome…Yeah, exactly. “Ten times programmer.” People who think they are. “Oh, this company wants to hire these people that have this awesome resume but, they only want people to work in Nebraska.” Well, that’s bullshit because, I’m so awesome, but I want to live, wherever I want to live. Personally, I don’t want to work on a team, with a whole bunch of awesome people that are all over the place. Give me the average people that can be a team. I’d rather work in a team environment. Roy: If people think they’re so awesome, that they should be allowed to work from home, are probably not [inaudible 0:12:06] culture. Jade: It again goes back to if I am doing something that is highly specialized, individualized, then yeah, that’s probably a true statement. I probably can’t find those people around my local area. Derek: Well I think… Roy: How many people are really doing something that’s that specialized? Derek: I saw somewhere… Jade: I think a lot people think they are. [chuckles] Working When You Are Most Efficient Derek: I saw somewhere that somebody had summarized, well what I think my viewpoint on that in, that is, if you want to be the most efficient, probably work anywhere you want, anytime you want, however you want, is the best place to go. If I work best from two o’clock in the morning, to six o’clock in the morning, if you want me to be the most efficient, you need to let me work at that time. If I worked the best with headphones, in the dark, in a basement, you should let me work that way, if you want me to be the most efficient. Roy: I don’t think I agree with it. Derek: I won’t necessarily be the most creative, and I won’t necessarily have the best solution, so the counter argument to that is, if you want people to be the most collaborative, the most creative, and solve the hardest problems, they actually have to be co‑collocated. You are suffering a little bit of efficiency gain, at the individual level, to have a better systems gain. Clayton: Possibly a lot of efficiency. Roy: In terms of efficiency though, that’s a lie too. People lie to themselves when they talk about how efficient they are when they work from home. If I were to not be honest with myself, I’d say, I could work from home, over the weekend. Did you [inaudible 0:13:29] you turn me down? [crosstalk] [laughter] Jade: Tell us how bad you are working from home. [laughter] Roy: I could see myself, I’d work the entire weekend, and I could work the entire time through, but in reality, if I was really honest, I’d probably end up working, maybe, two or three hours out of that, if that, and I’d probably be distracted a few hours. Reality doesn’t quite correlate with what it’s going to be like. Jade: I think there’s a lot of studies that showed that people are more productive at home but then I always wonder, if you have a BS job, where you are pushing paper around all day, and you just do it from home. You are probably more productive because you don’t get interrupted by your stupid middle manager, who is a total waste of space too. This whole thing is a foundation of lies. You are doing creative team based work. I just don’t buy it. Efficient At What Derek: Well, I say this all the time. I am way more effective when I work from home. In doing the stuff that only I need to do. I can bust through my email box, get my to‑do list done, get all sorts of [inaudible 0:14:24] and I am way more effective at home doing that. Even if I only work two hours, opposed to six hours. The problem is, I am not effective at all because I’m not able to leverage the thing that I do best, which is, get people to work together to solve real problems. Can I be more effective? Sure, in answering email. Can I be more efficient in answering email? Absolutely. Is that the most effective use of my time is answering email? Probably not. Jade: I think the trouble is, you get distracted. Doing those things at work, with a whole bunch of other people, that you don’t even have time to focus on the creative stuff. We’re not valuing those things in the work that we’re doing. Alright, well thanks for listening to the Agile weekly Podcast. We’ll catch you next time.

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. Generating Team Culture Clayton: Today we wanted to start talking about cultural norms or generating the culture of the team. Roy, that’s something you’ve been experiencing lately, so tell us about it. Roy: I have been working with a team for the last few weeks. We really have started to generate more and more stress…a switch‑over to one‑day iterations. That has started bringing things that were always there to a head. Now we have to start to deal with them because it’s no longer able…in the past, we get to say, “Hey, we’ll get to it on Friday when it’s an issue.” Now that we’re having this issue every single day, it’s becoming something we have to deal with…it’s pretty cool. Clayton: What’s it been like with the different personalities on the team? Do you feel like the team is catering to certain people ‑‑ maybe they have more seniority? How’s that shaking out? Roy: I don’t necessarily think that matters ‑‑ seniority ‑‑ in our case we have some personalities that are cruder and more vulgar, and, in some cases more childish. Myself included. [laughter] We have some people that are a little bit more straight‑laced, and that are bothered by some of our antics. In this particular issue, there are other issues that come up. It feels like we’re a team of a bunch of alpha‑people, so we argue a lot. Clayton: So, lots of alpha‑males or people that want to be alpha‑males that are trying to find their place in the pecking order? Roy: Mm‑hmm. Dealing With Variety Of Personalities Clayton: Derek, you’ve been dealing with a team that’s adopting Scrum, or trying to get a little bit more serious about it, that has some of those personalities. What’s that been like? Derek: I think that one of the things that is difficult is often times people will say they’re in a team…in reality the team definition is simply a group of people that all have a reporting structure that is shared, or a group of people that all sit in the same area of the office. There is no real team happening. When work gets done it’s independently divvied out and there’s no collaboration happening. I think that for this particular team there is an alpha personality. An example…this person does all the estimating for the team, all the counter‑views, this person is the only person that is allowed to deploy the software to the target production environment for the team. As the team is starting to take a little bit more ownership for work, they want to improve. Part of their improvement is they want to talk about “Can we start to swarm on work instead of each one of us take a story for our self for the entire sprint. Can maybe three of us work on the same story and how do we break that up”? The person that is normally in control of everything, this is a rage‑infilled behavior for them. This is just not acceptable on every single level that they don’t even know how to respond. So much so that they basically throw out all the work of the team and basically say “I’m going to tell you who’s going to do what work.” What’s interesting to me is this is not a manager, this is just a developer on the team. This is somebody who says what they’re allowed to do and what other people are allowed to do. It is a dynamic that I think some people are seeing some empowerment, and are able to fight against now, and getting some support from management and external co‑teams to say “No it’s OK for you to do this,” and the person is seeing their world be torn apart and is not happy about it at all. Roy: I think everyone listening has either worked on a team with someone like that or maybe has been that person themselves or has experience with that. We highlighted that it is a negative behavior, but what can you really do if you have someone like that on your team so that they can be more collaborative and they can be more part of the team and they are not the code police? Dealing With Alpha Behaviors Derek: Some of it is figuring out why they are the code police. It might be that for a long time that they were the only ones responsible or ever held accountable when something went wrong. So “If I’m the only one getting slapped when something goes wrong, I’m probably going to make sure that I am going to control everything possible to make something not go wrong.” Or maybe, “I inherited really crappy architecture when I started this job and it took me two years to clean up the mess from whoever was before me and I’ll be damned if I am going to let a bunch of junior idiots come in and tear my code masterpiece to hell.” It’s finding out what makes them tick and trying to show them how they have safety in a team and that they can actually do some of those things better without expending that amount of effort. I suspect most of them don’t want to work 70 hours and have to micro‑manage every line of code. They’re doing that because there’s some other thing involved that’s making them do that. If you can say “Hey, you can get all of the things you currently want, but without having to command and control your teammates,” that’s a win‑win for everybody. I think it’s investigating what that is and trying to show them techniques or ways to basically move around that. Clayton: Roy, when you’ve ‑‑ in the other team you’re on ‑‑ been experiencing this generation of culture and the culture stuff, have you noticed any of the people that are more senior members on that team having a hard time making decisions or participating in a certain way? They’re used to acting in a certain way and having veto power, but now that they are on this collaborative team where everyone’s input is supposed to be more equal, have you noticed anything like that that’s been difficult? Roy: Not really because on our team, everybody has the exact same veto power which is absolute veto power. We used the Core Protocol’s Decider, so all decisions must be unanimous. There’s been a lot more argument than there probably would have been. In the past, seniors members could have said, “It will be this way. No argument.” They can’t really do that anymore. Overall that’s a good thing and I think even the senior people would agree that this discussion is driving better ideas and is driving us to…now, a junior member comes up with a crazy idea, and we incorporate that and come up with something that’s way better than any individual could have come up with by themselves. Dealing With Conflict Clayton: Derek, the example you mentioned where the guy came back in and redid everything and seems like he blew up a little bit, I think for a team or maybe an organization that’s trying to make a cultural shift, those are the cues where someone that is afraid of conflict or has more traditional mindsets is going to put the brakes on and want to hold off. That’s probably the wrong thing to do, right? Derek: Yeah. I think it was interesting because this team happens to be doing scrum, they believe they’re doing scrum. I would say they’re not really doing scrum, but they do have a scrum master. Clayton: So they’re doing scrum, right? Derek: Yeah, I believe that the scrum master knew this behavior was not kosher, was counterproductive, but they had nothing in their toolkit to say, “I’m going to prevent you from going off and doing this crazy thing and redoing the planning meeting all by yourself in the vacuum and delivering a PMP level schedule back for when things are going to be done and who’s going to do them and everything else.” They knew that was totally wrong, but they didn’t know how to deal with the person. The best that they could do is say, “OK. Well, if you’re going to do that then I’m going to hold you ‑‑ hell or high water ‑‑ to that schedule, and if you’re one minute off from that schedule, this is going to be how I’m going to say, ‘That’s why we don’t do it that way,’” which is not necessarily a good response. It was nice that they didn’t just dig their feet in and say, “We’re not going to try to improve because somebody on the team has got a problem with it.” At the same time, one of the things that’s difficult about change is if you do not have people around that know how to deal with change and with personalities, you just say, “Hey, yeah we still want to change, but I don’t know how do we tell him no.” Is A Good Or A Bad Change Roy: How can you tell a change is good change or bad change? Derek: The upper management team, when they heard this was happening, I think their initial thing was, “Do we need to fire the person?” I was like, “Whoa, whoa, whoa.” That sets all sorts of bad precedents ‑‑ you go against what somebody wants, and that means you get fired. That’s not the culture you want either. At the team level, it’s, “Nobody has ever told this guy no before, so how do we do that?” Clayton: Do you think that if you were a scrum team that was doing more traditional scrum, and you’re having your retrospectives…I would assume that that’s the kind of thing that would come out in the retrospective about that behavior. What do you think led to this going on for so long? Retrospectives Need To Have Safety To Be Effective Roy: Not knowing much about the situation other than what we’ve briefly talked about in this podcast, my guess would be that the retrospectives don’t feel like a very safe environment to bring this type of stuff up. Either retrospectives aren’t frequent or not happening, or when the retrospectives are happening, nobody feels like they are in a safe environment where they can bring up anything like this without getting totally shot down. Derek: I suspect that more than anything the retrospectives are probably a little bit shallow. I’ve only seen half of the retrospectives that this team has done, so I can’t really speak to it. But it definitely seemed like a fairly shallow, [sounding bored and disinterested] “Hey, does anybody have anything we want to improve? OK. Do you have anything you want to change? OK.” Not a whole lot of techniques used to provide safety to people…I don’t think there was necessarily any kind of hostile environment during that, but I don’t think that there were the typical tools that a good facilitator would use to try to deal with some of these problems. One of the other things is it’s just the way that they work. People don’t think, “Hey, maybe we would change this” or “Hey, this could be different.” It Is Hard To Go Against The Status Quo Roy: Instead of abiding and perceiving that there’s a problem. Derek: A great example is during their planning meeting, this particular individual was not there. They were tasking some stuff out, and it came down to “We can’t task this out because so‑and‑so is not here.” It was great because their manager said, “What do we do?” I said, “Why can only one person do this?” Ultimately, their manager really pushed them and said, “So you’re not capable, Clayton, of doing a database change?” Clayton said, “No, I am.” He said, “Then why can’t you task it out?” “Well, because Roy says that we’re not allowed to do that. Only he’s allowed to do that.” Roy: This is true by the way. [laughs] Derek: The manager says, “Well, I don’t care. If you’re capable of doing that, I trust you to do it. Task it out.” The look on that developer’s face is, [shocked] “Oh, wow! I’m allowed to do that.” They wouldn’t even think to question it. I think we forget how programmed people get where it’s, “Well, that’s not my job. That’s someone else’s job.” When it comes to retrospective, I’m not thinking, “How can I get Roy’s job so that I can do database work.” Clayton: Let’s just say that’s the culture. The men go out and hunt, and it’s, “Could a woman go along and hunt too?” Probably, but that’s not what they do. That’s not how the culture works, so that’s crazy to even promote…suggest that idea. Roy: We see this all the time with QA people. “Man, that QA person touches code like ‘Ooh!’” They might fully know how to do some automation. They might already be doing some code like bud. Derek: It’s funny when you talk to some people that are in that QA or tester space. There’s a lot of them that on their own or at some other job have some experience with the code. Whenever they talk about it, you can tell how bad the culture is by how much they diminish their own skills. “Well, I’m a QA person. Yeah, I’ve done some Java stuff. I’m really bad. I really don’t know what I’m doing.” That speaks to the culture that they’ve got going on, wherever that is. Roy even hinted at people not feeling safe in the retrospective ‑‑ a place where you can feel safe and share your feelings and talk about things. Roy: Right. Derek: Are you talking more about people on the team? I might say something in retrospective and some of my team would be upset? Or is it something management would hear about and use it against me? Roy: I assume that in Derek’s case it would be more of a team‑related thing where I would be the alpha person, and you’d bring something up. Then I would shoot you down and be, [angrily] “Well, that’s because I know more than you, and I have more experience. Can you just shut up and don’t bring that up again”? The other option you’ve mentioned, I’ve seen happen as well, where something’s been brought up in a retrospective, and a manager finds out about it and one by one interrogates every member on the team to try to figure out who said it, so they can do who knows what. Clayton: They feel or I guess there was something that they didn’t know. Roy: If you don’t feel safe inside a retrospective, you’re not going to get anything accomplished. That’s the type of area where everybody should bring up the things that are really bothering them, so you can move forward as quickly as possible. If the team doesn’t feel safe, it’s not going to get brought up, and then you’re not going to make the changes that you need to. What Is A Team Clayton: Derek, you’ve mentioned these people having “teams” where it’s just a collection of individuals that are loosely grouped together. I think anyone in that situation is going to feel very vulnerable to express some problem they have. Roy: They don’t even know each other. I talked to a team last week where there were some members of the team that didn’t even know other members of their own team’s names. Clayton: The “team” right? Roy: I have seen that quite a bit actually [laughs] . Model The Culture You Want To See Derek: It’s really difficult. As a coach, one of the things I really try to do is mimic the things that I’m saying that other people should do. I’m real big on that managers should be highly transparent and open. So one of the things that I do is I tend to keep coaching journals. In my coaching journals, I’m really wide open ‑‑ I criticize things probably overly a lot of times. I really struggle ‑‑ do I give access to those journals to the management teams that I’m working with? My biggest reason not to, often is I don’t believe they can express the maturity to be able to handle what’s in those in healthy ways. I think it would be vitally important for them to see what’s happening within their teams and in these ceremonies if they were taking that information and saying, “Hey, can I do some things infrastructure‑wise or organizationally to help deal with that?” But what they tend to do is look at the personal things and say either, “I’m going to go fix the personal thing” or “Ooh, that really pissed me off. How dare somebody say that about my organization?” and be punitive about it which is just non‑helpful. Retrospectives to me are the same way ‑‑ do you give that data to people outside of the team? Part of the answer is, “Absolutely! Somebody should be able to, outside of the team, see that data.” But the problem is we’re human beings, and we act stupid all the time, and if you do that, you lose a lot of the safety involved. I think some managers demand, “I want to see what’s coming out of the retrospective because I want to make sure,” in the guise of, “I want to be able to help the team,” in reality, “I want to see what the team’s talking about, so I can go flip my lid.” A Storming Team Roy: Ultimately it should be up to the team themselves because a team that is first storming is going to be extremely protective of their opinions and want to keep that to themselves. As they mature, they will start to grow trust amongst each other. When they say something, even if the rest of the team disagrees with it, they know that the rest of the team will have their back. That’s when they start being more OK with having that type of stuff be open. If a manager goes out and goes, “What the heck were you doing saying that about me?” the rest of the team is going to back him up and be, “Hey, this is a retrospective. They have the right to say that opinion. Back off of our team member.” Derek: Yeah, I definitely think it should be up to the team. In the current engagement I’m on, I’m lucky enough to be doing some pair coaching, so it’s nice I’m able to open that up to my pair coach and be able to get some of that organizational feedback, and have the safety that that person is in the same boat. They’re putting their notes up as well, so we’re able to help each other out, which is really nice. Clayton: Great. Well, I think we’re about out of time. So thanks guys.