missing content The Integrum team traveled to Irvine, California to attend the Agile Open Southern California on September 15th and 16th of 2011. During the event we had the chance to be able to interview some of the attendees and talk to them about the Open Space that they had just facilitated. Open Space Technology conferences are great events where the attendees get to create and completely control the content of the “conference”. Enjoy this video as we talk to Marsha Garczewski about her Open Space on “Getting Started with SCRUM“. For more information on this event or their sister event Agile Open Northern California check out the site at www.agileopencalifornia.com. The post Special Episode : Marsha Garczewski – Getting Started with SCRUM appeared first on Integrum.

missing content The Integrum team traveled to Irvine, California to attend the Agile Open Southern California on September 15th and 16th of 2011. During the event we had the chance to be able to interview some of the attendees and talk to them about the Open Space that they had just facilitated. Open Space Technology conferences are great events where the attendees get to create and completely control the content of the “conference”. Enjoy this video as we talk to Woody Zuill about his Open Space session titled “Intro to Agile“. For more information on this event or their sister event Agile Open Northern California check out the site at www.agileopencalifornia.com. The post Special Episode : Woody Zuill – Intro to Agile appeared first on Integrum.

missing content The Integrum team traveled to Irvine, California to attend the Agile Open Southern California on September 15th and 16th of 2011. During the event we had the chance to be able to interview some of the attendees and talk to them about the Open Space that they had just facilitated. Open Space Technology conferences are great events where the attendees get to create and completely control the content of the “conference”. Enjoy this video as we talk to Darrin Ladd about his Open Space on How Can I Help My Teams Continue to Improve?. For more information on this event or their sister event Agile Open Northern California check out the site at www.agileopencalifornia.com. The post Special Episode : Darrin Ladd – How Can I Help My Teams Continue to Improve? appeared first on Integrum.

missing content The Integrum crew decided to head to Agile Open California South this year as a way to spend some time together. We took the opportunity to capture some pictures and video to share with others. Sometimes it’s important to get out the office and meet new people. We hope to see you around. The post Special Episode : Integrum Invades Irvine appeared first on Integrum.

Jade Meskill: Hello and welcome to another episode of “The Scrumcast”. I’m Jade Meskill. Roy vandeWater: I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Drew LeSueur: I’m Drew LeSueur. Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich. Starting With Retrospectives Jade: This week I had somebody ask me…they had just formed a new team, they’re building a new product, and they heard about the Scrum thing, and they really want to implement it. Their question to me was, “Where do we start?” Let’s talk a little bit about starting Scrum from ground zero. I’ve heard of Scrum. I think it’s cool, I think it’s the way to go, but I don’t know anything about it. What do I do? Drew: I think it make sense to start with retrospectives. I think we’ve talked in the past that with Agile… Jade: What’s a retrospective? Drew: We start with weekly meetings, in which we review the last week, and think of how we can do things better. Jade: Why every week? Drew: Why not every week? [laughter] Jade: Who runs this meeting? Drew: Whoever is in charge of the new team. Jade: Who is in charge of the new team? Drew: I don’t know. I assume there’s somebody in charge. [indecipherable 1:14] asked here the question. Jade: Who’s the team? Define The Roles Clayton: I think one of the first things you can do is identify the roles. Who’s a product owner, who’s… Jade: What’s a product owner? [crosstalk] Drew: This is the E‑Course. Clayton: I’m talking from ground zero. I’ve heard of Scrum. Where do I begin? Drew: That’s a problem. You have a lot of roles that need to be identified… Clayton: Where do I find Information about this? Drew: You are not going to be able to afford to go to a Scrum training class, if you’re a start‑up trying to figure this out for the first time. Clayton: OK. So? The Scrum Primer Derek: There’s the Scrum Primer. It’s a two‑page document, very simple basic, what is Scrum, what are the roles, the ceremonies, the artifacts. That’s where I would start. Clayton: Awesome. Derek: Have everybody read that. Clayton: That’s what I told them to do. You’d start with the Primer and just learn the basic elements of what makes up a Scrum team, and what are the ceremonies involved. Clayton: I guess when I think about it I question, “Do we really want to be advocating Scrum to people, just because they’ve heard that Scrum is this cool new thing? How do we know that Scrum is or isn’t viable for their organization”? I can think of at least one organization we’ve dealt with at one point, and we asked, “What’s your goal of doing Scrum and Agile”? The answer was, “I don’t know. That’s the project, we have to implement Scrum”. Roy: It was to implement the Agile. What Is Necessary To Improve Clayton: Right. I guess what I mean by that is, are there things that you could take to an organization or suggest an organization that could get them to start thinking about some of the principles behind Scrum, before they necessarily jumped in and said, “We’re ditching whatever we’re currently doing and going full board into Scrum, doing absolutely everything Scrum‑based.” When we say just go look at the primer, somebody looks at that and thinks, “In order to do Scrum I have to do everything on here,” which is true. But the question is, do you have to do Scrum in order to improve your team? Could you do just a retrospective and improve your team? Could you do just a stand‑up and improve your team? Could you do just a planning meeting and improve your team? At some point you would have to do more, but I’ve seen a lot of teams that they don’t even talk to each other. Just talking to each other would be an improvement to their team. Roy: I think those are really good points, but let’s just imagine that you don’t have hours and hours to coach and counsel them on what it is that they need to do. They’ve expressed an interest in going this particular direction, and it’s easy to say, from your perspective that, “Yes, maybe you don’t need all these pieces,” but they are not going to know that. Unless they have someone that’s experienced working with them and helping them along, they’re not going to have that context to understand that, “Hey, we just really need to start by doing stand‑ups.” You’re not going to have that insight into what their team makeup is, and they’re not going to be able to share that with you, in passing. Follow As Prescribed To Start Clayton: My recommendation would be, “If you have decided to go Scrum, as your Agile framework, then you follow it strictly. Don’t take just pieces out of it, because, if you don’t have the experience to know which pieces, why they exist, and what impact they have, then you probably have not the experience to make that decision. I think human nature will tend to avoid the difficult things, and there are some parts of Scrum, some of the ceremonies, that specifically expose those difficult things. It almost seems it’s those ceremonies that produce the problems, when really they’re uncovering the problems. If you don’t have the experience to see that, “Oh, it’s actually an underlying problem, we need to solve this,” your natural reaction may be to shy away from doing that particular, “OK, we won’t deal with having just one product owner, because that just doesn’t work for us. We’re going to avoid that because that’s…” when really that’s a huge problem for your team and maybe you should be addressing the problem, not what exposed it. Without Experience Following The Guidelines Is Difficult Derek: Yeah, I agree, but that’s different between saying, if you’re going to do the ceremony, follow the strict guidelines of the ceremony versus saying, do the ceremony or don’t do the ceremony. I guess where I’ll play devil’s advocate is, I’ve seen teams do virtually every step of the Scrum and not do Scrumbut, and still completely fuck it up, meaning just because you have a planning meeting and you say, what we did yesterday, what we’re doing tomorrow, and any impediments, you can still totally screw that up. I was in a planning meeting today and it was, we said what we did, said what we’re going to do, and then we said, here’s the impediment, and passed the token to the next person, and nobody talked about actually removing the impediment. Jade: That’s the Scrum master’s job. Derek: Yeah. Jade: [laughs] Derek: I’ll also go against a little bit of what you said, Roy. I think that different teams are at different levels, so when you say, do everything for Scrum if you’re going to do Scrum, don’t pick and choose which ones that you want…I don’t know if that’s what you said… Roy: Sure, I think I’m more saying that, if you’re in [indecipherable 6:33] , if you’re in the position where you don’t know anything about Scrum, and nobody on your team knows anything about Scrum, but you know you want to do it, I would say you’re in no position to pick and choose what works best for you. I’d say that’s a very dangerous choice to be making. Drew: I would agree with that. Derek: I’d also say that, maybe you want to experiment with one feature, and you can gain value…it’s true, like you said, at the beginning. Start with retrospectives. You can gain value over just one aspect or one ceremony or one artifact of Scrum as you transition into it. Roy: That’s true. Derek: It depends on what level the team’s at, and maybe how committed they are. Roy: I could definitely see that, doing one thing, adding one thing at a time and measuring what effect it has. I think that would get you a really good understanding of what that particular thing actually does. It’s Not About Experts, It’s About Learning Clayton: I think to me, we put way too much emphasis on experts. I think that the whole premise of Agile or Scrum, if you look at it from an inspect and adapt method, is that there is no prescribed, real formula. It’s really all about saying, what are we doing? Is it working? How could we make it better? Certainly, experience helps accelerate that, and to me, that’s the difference. If you’re not willing to invest in training, if you’re not willing to invest in doing a ton of reading, if you’re not willing to invest in hiring a company to come in and do coaching or hiring in somebody experienced to put them on your team, you’re going to have to go through some learning phase. It doesn’t matter if you read every Agile book out there. At the end of the day, when you go to apply it to your team, you’re going to run into things and you’re going to make wrong choices. I see experts every day make wrong choices, and that’s OK. The thing is, how can you iterate over those choices as quickly as humanly possible to speed up an improvement. I think when you’ve got more of an expert eye towards things, you can make that change happen quicker, just because you’ve seen the patterns before. But I think that we need to stop trying to circumvent learning in organizations. Drew: I feel like some of the stuff that you’re saying there, in terms of what the principles are and everything, are some kind of based on nuance or your experience. I think if you’re the average person that says, “OK, I’ve heard about Scrum, and I want to implement Scrum at my company,” they’re going to go on the Internet and they’re going to watch some videos and read some things and they’re going to say, “I have to do these 15 things, this list, and I have to follow this order. I think that’s what they’re going to do. They’re not going to immediately jump to, “OK, I just need to inspect and adapt.” I don’t think anyone out there that’s selling Scrum…I think most of the stuff out there for Scrum is really promoting Scrum for a commercial reason. “Here’s how you do Scrum, and I know it’s very confusing, so come and talk to me.” Because of that, no one’s saying, “Hey, you can get started with Scrum by doing this simple thing. Just inspect and adapt and just do a couple things and see what works and learn from that.” No one’s really talking about the nuance of it. It seems almost impossible, if you are not really part of that culture or part of that community, to understand that that was the case, and understand there’s a different way of doing it. Jade: Going off what you’re saying there, could you…and the situation that I’m faced with…could you come in and do Scrum in 10 minutes? What would that look like? You have 10 minutes to explain Scrum to a team that wants to implement it. Go. Scrum in 10 Minutes Drew: It seems like, if you had 10 minutes, you’re going to focus on more of the principle stuff, and then it’s not going to look like Scrum necessarily. I wonder, if you were to do that, then would you begin some kind of mixed messages? Then, where do you go from there? Because, if you go seek out the next step, or, “OK, we’ve been doing this for a few weeks now. What do we do now? Now I’m going to look for Scrum stuff, and it’s not the same thing I have learned already.” Scrum Is Not a Panacea Clayton: Yeah. I think some of it is we highlight Scrum as this panacea or this magic pill that, if you just do it, all your problems go away. I think that, if someone were to come directly to me, what I would probably tell them is, “Hey, here are some resources, here’s the primer, you might want to read my koans, user stories applied, [indecipherable 10:59] menu planning. You might want to read a couple of different books that help you accelerate your learning. But, ultimately, it’s really, really simple, but it’s really, really hard. Don’t get discouraged. Just make sure that, every week, you’re improving. As long as you’re on the journey towards improving, don’t worry about whether your implementation of Scrum is perfect.” I think maybe that’s the chicken’s way out, but I think that the problem that we do is we do this [indecipherable 11:30] . I think the community has this thing that, once you know Scrum, then you have to do exactly Scrum. You’re not allowed to do in Scrumbut, and, if you have any problems and you’re failing, it’s because you’re not doing the exact prescribed elements of Scrum. If you would just do those, you would stop failing. I think that’s bullshit. Human beings are involved, and, even if you follow the process to a T, you are going to have failure sometimes. I think every human being is different, so every team is composed of multiple humans. You’re going to have a unique problem on every single team that no Scrum guide can solve for you. Roy: That’s definitely true, but I think the beginner’s approach, often, is the think that every problem you run into is your own unique problem, and it’s very difficult to get away from that. Without experience, it’s impossible, really, to see that this isn’t a unique problem. This is actually the problem that the ceremony or whatever was directly designed to address, and it’s exposing the problem. That’s my concern. I think it’s important that you inspect and adapt. It’s also important that you start out with some kind of framework. If we’re going to go with Scrum, just going over a set of principles, like Agile in general, then it seems to me that you’re interested in having a starting‑off point. You inspect and adapt, but you start off with something that you can inspect and adapt, so you don’t have the blank page problem, where you sit in front of that and you don’t know what to try first. At least, Scrum gives you something there, but it’s difficult to make a [indecipherable 13:03] to say, “This is working for us” or “This isn’t.” Drew: Yeah. I would imagine that it’s pretty easy to say…the person that came and talked to Jade says they want to do Scrum. Jade points them in the right direction. They start doing Scrum, and they get to a point where there are some psychological issue with people on the team, and that’s a totally separate thing that is not necessarily discussed in the primer. I think, unless they are willing to go above and beyond, maybe they’ll go do some more reading and say, “This is a deeper issue.” Then that’s how you get into doing Scrumbut, where it’s like, “We had this problem on our team which I didn’t read anything in the book that says anything about this, so we’ll change it a little bit.” We’re still doing Scrum, and then you get to the point where it’s like you’re not doing Scrum at all. You’re doing this weird bastardization of it. Jade: So it doesn’t matter? Drew: What? Jade: If, let’s just say, I end up going down that road. I learned the very basic principles of Scrum, and now I’m changing it to fit our situation, but maybe it’s not the “right way.” Does it matter? Drew: I guess it doesn’t matter in the sense that you would be doing maybe just as bad, and you’d be doing it in some other way. Don’t Get Discouraged, Focus on Improving Derek: I think it doesn’t matter, the one thing being that you cannot accept stagnation. You cannot be willing to accept that you refuse to improve. Because I think I’ve seen that before, where people come up with their own derivative of Scrum, and they say, “This is our Scrum,” or, “This is our process,” or “our method” and then they start making changes, they start looking at anything that has changed around them, and they just stick with the exact same thing. Clayton: I think that is the problem. What we tell people right now is, “Go read this primer, and, if you implement Scrum, all your problems are solved.” So what they’ll do is they’ll go implement Scrum, and they’ll find little things here. Maybe I can have one product owner, so I have to, or maybe Scrum doesn’t really address velocity, hours, or something else, so we roll our own based on some anecdotal evidence. Then, when somebody comes in and says, “We’re frustrated. We’re still not delivering on time. We stopped using Scrum, because Scrum doesn’t work for us.” Then you talk to them, and you say, “What you’re doing is not really Scrum, and you’ve got these other problems,” but what happens is people stop inspecting and adapting. What they’ll do is they’ll say, “I implemented Scrum. It didn’t work for me, whatever part. I made this change, and that didn’t work either. Therefore, I’m going to just stop trying and go back to just whatever we were doing before that didn’t work either, because this Agile stuff just doesn’t work.” I think the crime that we’re committing is we’re not telling people that making the first deviation is actually OK. But, when that deviation doesn’t work, you should be asking why didn’t that deviation work and trying something else. Maybe you’ll get two, three, or four deviations before you finally go “Ah! Light bulb moment! Now I understand the strict version is this. Maybe I need to back and try that based on what I’ve learned.” I think we teach people that it’s not OK to make changes to Scrum, which isn’t novice. I think it is dangerous to do that. I really do. I’d recommend to try to implement a fairly strict version of Scrum before you make any changes. But, if you start to make changes, don’t give up if those changes don’t work. Keep making changes until you find what works for you. Derek: Right. I think, even if you implement the ideal version of Scrum, and if feels like it’s working good, still keep making changes, because it could be better. Jade: Still inspect and adapt. Maybe not necessarily make changes. Derek: That’s true. No. Actually, I want to take that back. That’s not true. I would say, even if you are happy with your results, still make changes, because, what if it could be better, and you are just on the other side of the hill and there’s an oasis on the other side. I would say, even if you feel everything is going great, still make changes and still take risks. Jade: Any last parting thoughts for new teams looking to implement Scrum or explore Scrum for the first time? Roy: Yeah. I like what Derek said about you’ve got to understand the underlying principles. I also like what you said, Jade, about if you had 10 minutes to describe it, what would you say? I think we can combine the both. Nobody is going to learn everything in one go around. The principle of inspect and adapt is huge, but, if had 10 minutes to describe it to a team, I would talk about the basic principles: weekly iterations, a deliverable product after each iteration, teach them the Scrum primer, and then have them continue to learn and grow, and don’t reject it if it doesn’t work the first time around or if it exposes issues the first time around. That’s what Scrum’s all about. Clayton: I think the thing that kind of uncovered this conversation for me is I don’t think it’s realistic to say “How do I implement Scrum?” Then I’m going to tell you what to do, and then you’re going to go on Scrum. I’m going to tell you what to do now, and then we’re going to have to keep you talking about it. It’s going to have to be an ongoing relationship, and ongoing thing. As you go through the motions of implementing Scrum, and you get the growing pains and everything. You’re going to need someone to talk to, and discuss what’s happening. I think the only way you can say “How can I implement Scrum?”, is to have an ongoing conversation. Drew: I think one thing I would add too, is to try to get the entire team to be open and honest about their feelings regarding their teammates. Especially regarding how they are feeling about the current process. I think it’s going to be impossible to successfully implement a, or maybe at the very least extremely difficult to implement a successful version of Scrum. Unless you get buy‑in from the team. If you have an entire team of people that are against you, I think that that’s fighting an uphill battle, and at the very least you should know about it going into that. I do think that you should promote the honesty. Just because they don’t agree with you it doesn’t make them wrong. It’s better to know how they feel than it is for them to hide it for fear of pissing you off. Jade: Thank you for listening to the Scrumcast. We’ll catch you next time.

Drew LeSueur: Welcome to another episode of “ScrumCast.” I’m Drew LeSueur. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Stand-Ups In Agile Drew: Today we are going to talk about stand‑ups, why we do them, why people sometimes don’t want to do them, and why they’re important. Roy, we were talking earlier, and we talked about a team who didn’t want to do a stand‑up. Why do you think that is? What are some of the reasons teams don’t want to do stand‑up? Resistance To Stand-Ups Wasting Our Time Roy: The most common reason that I’ve heard for not doing a stand‑up is, “We feel like it would be wasting our time. We want to spend these 15 minutes doing development work. We don’t have time for this bullshit stand‑up, where we’re just going to stand there, and talk about nothing that matters. We could be coding.” They Will Be Longer Than 15 Minutes / Take Too Much Time Derek: I definitely think that some of it is people don’t believe that they’re really going to be 15 minute meetings. They’ve never been to a meeting that’s probably taken less than an hour before. The thought of doing five meetings, each an hour, you’re looking at five hours worth of meetings per week. If you’re only there for 40 hours, that’s a pretty huge commitment. Sometimes it’s fear of is this really only going to be 15 minutes? And if it’s only 15 minutes, can it provide any value at all? Drew: That’s a good one. Another one might be, we’re all in the same room, if you know they are in the same room, and if we need to talk to each other we’ll just say it. That might be another reason why they don’t think they…they can just talk to each other, they don’t need anything extra and special or ceremonial to discuss. Roy: That’s referred to as the water cooler effect. You know we’ll see each other at the water cooler later so why have a personal conversation now? Its The Missing Communication Channel Derek: I’m on an engagement now. It’s kind of interesting, one of the teams did not really want to do a stand‑up. We kind of had a scrum of scrums type of stand‑up. Each one of the managers had started to on their own bring the concept of the stand‑up back to their individual teams before we even brought it up as something they might consider doing, except for one group. The one group was told, “Hey, everyone else is doing this, this is working really well, you should try it.” They were a little reticent to do that for a number of reasons. It was interesting. They ended up having their first stand‑up, and everybody on their team went around and gave. They’re checked in and did their stand‑up portion. At the end the manager said, “I’m amazed that none of you guys said anything at all about this massive thing. We’ve got this huge thing coming up [laughs] in like five days, and none of you guys said anything at all about it.” They’re like, “Oh, yeah. That’s right.” Here is something that the team thinks is clearly on the front of the manager’s mind that, “This is a big deal, and we’ve got to get it done. I’m not thinking about much else.” Yet everybody else on the team was like, “Oh, yeah. I totally forgot. That is happening in three days.” Like, duh. That’s just proof positive that one of the hardest things about communication is understanding that you don’t really know what the other person is thinking. Here’s a manager who thought that everybody on his team had this on the front of their mind, and in reality it wasn’t even on their mind at all. Just by having something that simple is awareness that, “Holy crap. Nobody on my team is thinking about this. I better get them to start thinking about it.” Be Brief, To The Point Roy: I do think though that while stand‑ups are great for that type of interaction and getting everybody on the same page, I’ve been part of a lot of stand‑ups that feel like they drag on forever and that probably exceed the 15 minute time block and more. People are taking up such a long period of time to express whatever their concerns are for the day that I just completely am not able to pay attention. I’m trying with every bone in my body to pay attention, but I just can’t do it. Derek: Yeah, and even if they don’t exceed the 15 minutes, they can still drag on too long. Roy, you’re good at doing this. If a side conversation starts happening during stand‑up, you’ll say, “OK, why don’t we take this offline?” That way the two parties or the two developers involved can have a deeper conversation if needed, but it doesn’t have to affect everybody else and the rest of the stand‑up. Respect The Time Box Roy: Yeah, I definitely think that there are a couple of key things. Either a Scrum master or somebody on the team needs to be really good about respecting time boxes. That is the most powerful element of a stand‑up, keeping it time‑boxed because it really teaches the team about respect and about respect of a time box in a very safe manner. A couple of things that I’ll do is absolutely, if somebody’s getting a little wordy, take it offline. Or feel free to say, “What are you getting at?” We’ve had on our own teams some people that get a little diarrhea in the mouth when it comes to turning it into more of a status update and wishy‑washy. It’s OK to say, “Well, is there anything blocking you?” If the answer’s no, go, “OK, great. You’ve lost everybody.” The other thing that I’ll do if I start to see things going is to tell people, “It’s OK, we’re going to start the stand‑up at the same time whether everybody’s here or not. We’re pretty much starting it, and when the 15 minutes is up, if you’ve got something that you need to be doing and you feel like your time is being wasted, feel free to go ahead and basically check out.” Obviously, here, we like to use core protocols. Feel free to check out and show people that your time is being disrespected. When you start to do that and you start to be honest with each other, it starts to be like, OK, maybe I need to not be so verbose during this. Keep The Structure Derek: In line with the core protocols a bit, when you’re doing stand‑up to have a very rigid structure for what everybody’s supposed to say. Like, whether it is three quick phrases or one to two quick phrases that say whether you’re happy, mad or sad about something. Or if you use the standard stand‑up thing, which is like, “This is what I did yesterday, this is what I’m doing today, and these are where my blockages are,” That’s very important, too. If you get into the stand‑up where everybody is kind of free form speaking, that’s when you get into where people are kind of like, first off, people feel like they have to say something, so everybody says something. Then they also just drag on and on because they’re trying to remember if they’re forgetting anything important. With the format, you’re like, OK, that can itinerize very quickly. These are the things that are going to be blocking me. Let me get those out, because those are realistically, in my opinion, the most important, because those are the other things that the team can help me on, then also the things that I worked on yesterday and today and then should be done with it and move on. Stand-Ups Arent Status Meetings Roy: Yeah, I definitely think a lot of people try to make them status meetings. In a status meeting, if you’re not talking a lot, it means you must not have done much yesterday. I find that certain personalities really try to be verbose because they’re trying to make it sound like they’ve done a ton of work, when in reality, what they’re talking about, nobody really cares about. Another thing that we’ve played around with a little bit here, too, is, once you start to get a high performing team, what did you do yesterday and what are you doing today really are not that important. It’s really about what impediments are standing in my way. Where do I need help. One of the ones we’ve tried to start to bring in, not so successfully, but it’s going down the road. That’s, what do I feel exposed on? Where am I scared? Where am I feeling inadequate at? In a high performing team, those types of questions become much more important, because they’re really talking about, how do I get better? How do I remove the roadblocks? How do I not feel afraid? Speak Only To Add Value Derek: Also, the attitude of stand‑up where everybody has to speak, with core protocols is great, because you go around the circle very quickly. But if you’re doing just a quick what I did yesterday and all of that and you’re really just concerned about impediments, it’s not necessary for everybody to speak. I’ve seen a ton of times where people are working in pairs, so two individuals did pretty much the exact same thing in a given day. When they’re listing off what they did yesterday, they both repeat almost verbatim what the other person said. That’s not necessary. We could have cut the entire stand‑up in half if everybody’s paired up. Roy: Yeah, that’s one of the reasons I don’t really like the whole status kind of piece so much. Especially on the slightly larger teams, you might be working in code based pieces that are different enough, that if you’re really trying to give any kind of level of detail about what you did, the other people are checking out because it’s irrelevant. Derek: Like when Coney starts to list down acronyms for startup projects. Roy: Yeah, if you’ve got your ADO, right, exactly. It becomes really easy to kind of check out. Whereas, if you keep it at a much higher level, it gives people insight to say, like, “Oh, I’ve worked with PDF before, generating PDFs before. If you need help, let me know. I know a lot about that.” Or Rest our API or Soap or whatever. If you keep it at that high level, it’s meaningful. The minute you start to drop into, like, implementation, it’s probably better to be offline if you really need to talk about that stuff. Learn To Allow Yourself To Be Exposed Derek: I liked one thing you said about saying how you feel exposed. That’s a great way of bringing out some lurking problems and bringing them to the forefront, because there are a lot of things, as we develop, as we do things where, hey, I feel a little bit exposed. In the future, I can foresee an issue here. Even if it might not be an immediate impediment or an immediate roadblock, you can still feel exposed on some lurking issue. That’s a great place to bring it out, in stand‑up. Lateness Roy: Yeah, some of the other things with stand‑ups, too, even once you’re doing them, it’s hard to do them well. It’s hard to get everybody to show up at the same time and not be late. I remember here at Integrum we probably had three years worth of fighting to figure out what the right stand‑up time was. To figure out, do you punish people that are late? Do you not punish people that are late? Derek: Do you lock them out of the room? Roy: How do you do that? [crosstalk] Roy: Not until in the last three or four months have we really gotten to the point where stand‑ups flow really well. There are not people pissed off that somebody is not there because people are only not there if they’ve got a good reason to not be there, that they’re efficient and effective. It’s a lot like pair programming. It’s something that’s really, really easy to start doing. “Hey, we’re pairing. We’ve got two people sitting in front in the same pairing station. Hey, we’re doing stand‑ups. Everybody meets for 15 minutes.” Doing them well and effectively and getting the most out of them is very, very difficult. Standing Up During Stand-Up Derek: This is one, I’ve seen quite a bit with people that are first starting out doing stand‑ups. “Stand‑ups, do you really need to stand‑up for it?” I always tell them, “If you want the meeting to be 15 minutes or less, I highly suggest it.” Drew: There is saying, “Even if you do your stand‑up, sitting down.” I’ve always stood up for it. I’ve never found a need to sit down for it. Derek: The best part is when you ask them, “Well, why don’t you want to stand‑up.” The response you get, “Because it’s uncomfortable.” That’s the entire point of the stand‑up, everybody in that meeting wants it to be over with as quickly as possible. If you’re at a meeting in a board room with comfy leather seats and donuts, everybody’s going to take that time away from work and just relax and be happy that they’re away from the daily grind for a little bit. Whereas, if everybody is standing up, it’s uncomfortable, but it’s a necessary uncomfortableness that everybody tries to get it over with. Talking Token Roy: It’s hilarious that you bring that up. In a recent engagement, this happened just the other day, is I instituted a talking token or a token to pass around for stand‑ups at an organization. All of the groups that are doing stand‑ups are using stand‑up tokens. We usually use a marker or something, whatever is close by. They pass it around and one of the teams that was not doing stand‑ups and was kind of allergic to them, when they did their first stand‑up, their manager started off by telling them that, “Hey, the stand‑up thing, I know it seems really stupid and it feels dumb, and passing this token around is really childish, but I thought the same thing when I was in my first stand‑up. Give it a chance because it has really improved communication amongst the team I’m doing it with. It would really help our team do it.” It was funny to hear somebody who was visibly uncomfortable during stand‑ups, but when he tells his team, really articulates that this feels really childish, this feels really stupid, but give it a chance because there is something kind of magic to it. That is some of the key to a lot of the Agile, not ceremonies, but some of the ceremonies as well as a lot of the activities or the thoughts or the principles are they take us back to that more childish state where you’re almost uncomfortable doing them, so you get duped into paying offense “Tom Sawyer” style. All of sudden, you’re like, “Hey, what a minute. I just got tricked into giving away vital information that I didn’t really want to give away.” There is some magic to that. It’s OK to feel uncomfortable. If you’re just starting out, it is absolutely, positively, normal for stand‑ups to feel uncomfortable… Roy: Oh, I know. Derek: …when you start doing them. Roy: For my, at least, first two or three of mine, I had this crazy way to put hands where I’m standing up. Then, the waiting for everybody else to speak, it felt really awkward, but it’s something that you get used to. Drew: That’s it for today. See you next time.

Jade Meskill: Hello and welcome to another episode of ScrumCast. I’m Jade Meskill. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Drew LeSueur: I’m Drew LeSueur. Development Team Jade: Today we want to talk about the new addition of the Scrum guide that came out from Scrum.org. There’s been a lot of controversial changes that have been made. Some tweaking to the language, a few different things and we’re just going to go down the Scrum update bullet point by bullet point. Share some of our feelings and opinions. To kick it off, let’s talk about the first change that they talked about here. The team of people performing the work of creating an increment, is the development team regardless of the work performed by individual team members, they are known as developers. What do you think about this? Roy: I like it. I can tell by the way you are looking at me that you don’t like it Jade. [laughter] Jade: I’m just moderating here. [laughs] Roy: I like the essential idea of it because I’ve seen with multiple scrum teams that when they go in they run across the concept…we even came across with this at Integrum last week where we said, “What if only one guy is able to perform this specific task”? We have all these people who are able to work but there’s one thing like, “That’s Jade’s job. Jade’s the only one who can handle that.” I think that’s a big problem. I think that is what they’re trying to address here, is that everybody should be cross‑functional, everybody should be able to perform any of the work inside of this sprint. Clayton: I think some of the hangup comes from as a developer, like software engineer, you think of the word developer meaning someone who writes software. I think if you take a step outside of that you could say the word developer really means someone who’s developing something that gets to potential shippable software. I guess I’m OK with this one. I don’t think there’s too much wrong with it. Derek: I think that one of the problems you have is on a lot of teams you might have Q&A, and database administrator, an architect. Everybody identifies themselves differently, and so in other language if it’s said the programmers there would be people who say, “I’m not included in the team because I’m a Q&A person, I’m not a programmer.” By switching it to developer I think they’re using a little bit softer language. I think you could even argue that it allows for scrum outside of software. So from a project management framework perspective, a developer could be anybody creating something. If I’m developing something, whether it be a courseware, or a piece of art, or whatever, I’m a developer. I think that they are softening the language for the some ability to go outside of the network. Drew: Yeah, I agree as well, I think the core idea of this change is to unite the team, and let’s give them the same name. No Commitments , Just a Forecast Jade: All right, let’s move on. The next bullet point ‑‑ Development teams do not commit to completing the work planned during the sprint planning meeting. The development team creates a forecast of work it believes will done, but that forecast will change as more becomes known throughout the sprint. Roy: That sounds like the exact opposite of a locked‑in sprint. The idea’s always been ‑‑ we lock in the time, the development team gets to establish the scope. If, now we get half‑way through the week and I don’t think I’m going to be able to make it. In traditional Scrum, that would be a huge deal and you would have to have an early sprint termination, and you’d have to replan or restart your sprint, and that should be a painful process because that should happen very rarely. Derek: To me, this is the pussification of Scrum. Jade: That’s the exact word I used before we started. Derek: Straight up ‑‑ it went from, this is a contract whereby you commit to the work ‑‑ you get to decide how much work you commit to, you commit to it, and the other side of the contract is that you do not have to accept change that comes in as part of that contract. In fact, at one time, my understanding is that the right way to abnormally terminate a sprint because of change, was to physically throw yourself on the floor and scream bloody murder like a young toddler until you got your way that the change went away or that management was sufficiently known that bad things were happening between the contract ‑‑ between the team, the development team and the product owner. And now we’re using language that says, “Well, you know, the team just kind of says that they would like to get this stuff done, but if the world changes, and stuff happens and we’re not really making a commitment.” Roy: I think, too, the guy that coined that way of doing an abnormal sprint termination is Ken Schwaber, one of the guys who signed the… Derek: That’s correct. I think what they are trying to do is remove absolutism or pragmatism, and I think by softening the language they’re going to do the exact opposite of that. So they went from something where it’s very hard ‑‑ you terminate the sprint in this way, and you’re a total asshole about it ‑‑ even if it’s the right thing to do. To now, “We don’t want to ever say you ever really make a commitment because that’s sometimes not the right thing to do,” and I think that really it’s a middle ground where you should be making a commitment. The commitment should be something that you really honor. But, if there is valid reason to change, to terminate, or to do that, or there is some ability to negotiate, I think you should be able to do that. I think, by going to the wishy‑washy language, they really don’t help anybody. You’re going to have teams who say, “I don’t have to commit to anything. What are you talking about”? If I can only do a 5, even though I told you I could do a 50, that’s Scrum. Clayton: Yeah. I think that the second part of this, where it talks about how more we’ll become known during the sprint, I think that’s just another way of saying “negotiation.” I think we do that now already, where, if something comes up, you can negotiate that. Maybe it’s a big deal, maybe it’s not. I think the change from commitment to forecasting, what’s been interesting for me is, if following all this on Twitter, there’s been a lot of people that have said things like, “I think ‘commitment’ is a great word, because I want the development team to feel the weight of the world on their shoulders, like they feel like, ‘Hey, this is a really big deal.’” Then, other people are saying, “Gees, the weight of the world, and I want to make the development team feel like they have to do it.” Those are all very negative words. I agree with you that’s a pussification. Derek: Scrum pussies. Clayton: Right. It’s like, “Let’s be very gentle and let’s be very cautious of not making people feel bad,” that kind of thing. I agree that there’s a lot to said be for the feelings, the emotions, and the words that we use, but, at the same time, I don’t think that the “commitment” stuff is negative, necessarily. I don’t think that has to be a negative thing. I think that can be viewed as a positive thing. Roy: I think that too. As far as the negative emotions of saying, “You have to get this done,” “Well, yeah, I committed to it. I said that I would get this done,” and whether you see that as negative or not, it shouldn’t be a negative thing. If I said I can get this done, then there shouldn’t be anything negative about me getting it done. That should be a positive thing. Derek: I’m pretty trying to go back to my wife and say that I’m not really happy that we’re married and I made a commitment. I would like to forecast that we will be together for the next six to seven years… [laughter] Derek: …and we can renegotiate another six to seven years… Jade: …as more information becomes available. Derek: …if we get more information. [laughter] Clayton: I will say that, since I read the actual longer‑winded update about “order” versus “prioritize,” which we’re going to get to in a second, I will say I will withhold judgment on this one until we get the full explanation, but my gut feeling is that it’s what we’ve been talking about. Roy: My other thing is one of the things that Derek mentioned when he was talking about the pussification of Scrum, where the idea of the commitment is that I say I’m going to get this done and commit to absolutely getting this done and locking the sprint. That’s my part of the deal. The other part of the deal is that I won’t get interrupted with any requests. That’s not really a sacrifice, but, if I don’t make that promise that I’m going to get something done, and if I don’t give something from myself, then why should the other people, why should stakeholders or product owners respect the fact that I have a locked‑in sprint? If I can change my mind halfway through, why can’t they? Drew: Also, I think, with the word “commitment,” right, Clayton, you talked about how people might feel bad if they don’t get it done, or it’s the downer term. But still, I think, obviously, there are going to be times where you don’t reach your commitment, through whatever reason. But the fact that it is a commitment and they set it as a commitment, and then you didn’t hit it, that brings up a conversation: What causes you to not hit your commitment? And that brings up, maybe, an underlying issue: If you just say it’s a forecast, and, “Oh, we didn’t hit it. Oh, it’s OK, because it was a forecast, anyway,” then, maybe, the underlying issue of the real problem, “Why you didn’t hit your forecast or commitment”? It’s not going to be brought up. Roy: Right. We’re almost getting into the wishy‑washy territory of having the commitment be the same thing as estimates, where you’re like, “OK. Well, we didn’t do this in twice the amount of time as the other tasks, so our estimates are wrong. Well, who cares about estimates”? In this case, they’re forecasts, but a forecast should be commitments, and they should be accurate. If they are wrong, we should do something about it. Derek: Yeah. I think it is they’re trying to soften the language to change the emotional tone. On that level, I don’t have a huge problem with it, but I also think that it does fundamentally change the contract or the original intent. This really changes it more to, “Ah, we’re estimating what we can get done this week,” opposed to, “We’re going to get this done.” To me, one of the biggest things that I see people interested in adopting Scrum for is they want predictability in work, so that they can understand, as a sales team or as a CEO, how can I determine what the future of this company looks like based on the work that can be committed to. If it really becomes a super loosey‑goosey, forecasty type of thing, the predictability goes way, way down, because nobody trusts a forecast, especially when it’s really seen as a forecast. Maybe over time, if you hit your forecast considerably and do that, then maybe it is something that people feel can be predictable. But I don’t know. I’m a little torn over this. I think they’re going a little bit too wishy‑washy for my liking. No More Burndown Charts Jade: Let’s keep moving down. Scrum does not mandate a burndown chart to monitor progress. Scrum requires only that remaining work for a sprint is summed and known on a daily basis. Trending toward completing the work of the sprint is maintained throughout the sprint. Roy: OK. If you don’t want a burndown chart, you want to represent it using something else, whatever. That doesn’t bother me. I think it’s a good idea to have a burndown chart, but I don’t think that particular format needs to be the case. I like that it says how much work is left. It needs to be known every single day. That makes sense. Clayton: I think they clarified this in some of the other documents where they wrote about the documentation. They say that they’ve tried to remove some of the tips and best practices, and they’re going to put those out as a separate document, so I think this is thinking that out. Jade: So they’re just going to move to best practices. Clayton: Right. Derek: I think this is a case where they so specifically said everything that happens in a burndown chart that it almost makes it say, “Really, you have to do a burndown chart unless you can come up with a better way to achieve all the exact same objectives of a burndown chart,” which, to me, is a good way, I don’t think they’ve softened what they’re asking for. They’re just being more open to different ways to do it that they may not know today. Release Planning Isn’t Necessary Jade: Let’s keep moving quickly through here. Release planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself. Clayton: I think it falls in the same category. No Need To Decompose Work Jade: The sprint backlog is the product backlog items selected for the sprint, plus a plan for delivering them. There is no longer a required concept of spring backlog items, although that technique can make a great plan. A self‑organizing development team always has a plan. Derek: I think one of the clarifications here is that sprint backlog items is generally what I think a lot of teams call tasking. When you dig your stories from the backlog into the sprint backlog, the sprint backlog items are not the stories that you’ve selected from the backlog, moved into the sprint backlog, they’re actually the tasks for those stories, is my understanding of their original concept of a sprint backlog item. In this case, I think they’re saying, “It’s not necessary that you task out all of the details of the stories to do the work, but a good team has a plan for how they’re going to do the work.” I take that very similar to the burndown effect, where they’re saying, “You still have to have this element if you’re doing a good job, but we’re not going to say the tasking is necessarily the way that you do that.” Product Back Log Ordered, Not Prioritized Jade: All right. Finally, the product backlog is ordered instead of prioritized, providing flexibility to the product owner to optimize value in his or her unique circumstances. Clayton: When I read this one, I had the same reaction as the forecasting commitment. At first glance, it’s just semantics, where it’s like, if you were really taking to the letter of the law, and you were saying, “I have to prioritize these, and, to me, priority means the most important ones at the top and the least ones at the bottom, and there’s no other way I can do it,” I guess, if you really took it that way, and you’re really being pedantic about it, then yes, that’s what you would think. But I feel like you would be able to exercise some flexibility and say, “There’s some other ways.” This is more important, and I think they get into that with the blog post that they posted today about order, not prioritize, where they actually go into the details about this. I think they do a good job explaining why it really is just…they’re opening up the different ways that you could prioritize. Priority is not maybe the best way to do it, and there are lots of different ways to order a good backlog. You don’t necessarily have to order by ROI all the time. There’s some things that would be more valuable than others at different times, and there are a lot of different relationships that certain backlog items have. You have to look at them all together. I think the document they’ve put out since then has really explained what they mean by this, so I think it makes more sense. If this helps people to understand the intent or the meaning behind what it means to order or prioritize a backlog, I think it’s a good thing. Roy: I agree. I’ve seen situations in the past where a product owner would go through, they’ll take 20 backlog items to go through, and 5 of them are priority one, 3 of them are priority two, and so on. Then they don’t think of it in terms of which one gets done first. They’re like, “This one is really important. This one is more important than all of these other ones, but these are all about equally important,” and, when we get into sprint planning, that makes things very difficult, because, then, when we start the week, they don’t know which ones to pull in. If you spend the time thinking about ahead of time, and the article that you mentioned talks about doing a bubble sort, where you take each story, you compare it to the one above and the one below, and say, “Is this one more important than this one”? Or, “Should this one be done first, or should the other one be done first”? If you go through and order the entire backlog that way, I think you’ll get a lot more value out of that than just assigning a priority number to each one. Derek: Pussification of Scrum again. [laughter] Derek: I think the problem is you’ve had 15 years or 10 years of, basically, poor definition of the word “priority” to product owners, probably from Scrum Masters or the development team, so everybody thinks of priority is low/medium/high, important/not important, critical…those are the words we think of when we think of priority. I don’t think that’s the definition of priority. I think priority can be one, two, three, four, five, six, seven, and, when somebody says, “One through five were all the same to me,” I can call bullshit. Do you want to be in fifth place or do you want to be in first place? Those are not the same things. You need to learn what is really number one, what is really number two, what is really number three, what is really number four… Roy: I think that’s the order addresses. That’s less ambiguous than prioritize, because prioritize can mean different things to different people, but order is always the order that they are on the backlog. Derek: I agree, but I also think it pulls out and also makes things a little bit less of a language do. Order doesn’t have nearly the urgency to being ordered. If you say, “Can you order those”? Yeah, you can order them, but is there an urgency to having them ordered? Where a priority gives to me the thing that is on the top of the order is more important than the thing on the bottom of the order. If I order something, I can reverse‑order something, and the most important thing then be on the bottom or top. When I call something a priority, I expect the thing on the top to be the most important. I think where they’ve gotten this muddy language is they’re like, “It’s by business value, or by this, and there are different ways you can prioritize, so we need to…” No. That’s not the fucking problem. I think that you can definitely prioritize by different things, and you can do that on a case‑by‑case basis. You can come in and you can prioritize one week based on business value, and, another week, you can base on customer demand, whatever. You’ve got the ability at the end of each increment to move this however you want. The problem is that they don’t want to talk about the real problem with the language, and that is that telling product owners that they may have to make hard decisions. You have to know, “Is this story more important than this story”? I think that most teams get away with letting product owners go, “Well, this block of things are all the same to me.” I don’t think calling it ordered is going to make that problem go away at all. I think it’s just going to compound it. Roy: I think there’s a problem too even with they’re using the word “important.” I think Drew and I have had discussions on this in the past. Let’s say you have two items. One is pretty important, and I’ve got another one that’s about half as important, but it takes a fifth of the time to complete. When I’m talking about “important,” I mean it’s going to earn me a dollar value. The other one is going to earn me half the dollar value, but it’s also going to take one fifth of development time. Derek: That’s why the product owner gets the big bucks. He has to make that decision to say which one is the one that needs to be done first: the one that takes longer but makes me more money, or the one that I can get done quicker and doesn’t make me as much money? Roy: Or which ones I have are higher priority. I think “priority,” in this case, is a loaded word. That’s why I like the idea of doing it from order, like, “This one is first over the other one.” Derek: How is calling it “priority” over “order” any different? Roy: Because, even in the way that you described ‑‑ you said, “This one is more important than the other one” ‑‑ it’s not more important. It’s half as important. But it gets me money faster. Derek: How is it not more important? If I want it done first, it’s more important. Roy: I don’t think that’s necessarily the case. Jade: Priority doesn’t mean importance either. Drew: Right. People attach maybe money value with importance. “This makes me twice as money. It’s going to be more important. It’s going to be more priority.” But that’s not necessarily the case. Clayton: Yeah. The problem I have is I think a lot of the reasons they give for why they switch order is they talk about how there’s so much complexity about, to quote this article, knowledge of evolving market windows, market conditions, engineering dependencies, knowledge of business. There are all these things that go into it. I feel like, if you’re the kind of person that really understands those things, where you could make use of this concept, the actual paradigm difference in ordering and priority, if you actually understand all those things, I don’t think you get hung up on the word “priority.” I don’t think you say, “I have all this knowledge, I’m a very intelligent person, and I understand all the nuances, but the word says, ‘priority,’ so I have to do it by priority.” I don’t see that happening, so it seems almost meaningless at that point. Roy: But with the beginners, just people first coming into it, I think they do get hung up on the word “priority,” and I think that “ordering” would set them on the right path quicker than using the word “priority.” Clayton: But I think the point they’re making is that you can order a lot of different ways. I think you can prioritize a lot of different ways. In the product owner training that I attended, there were lots of different ways to prioritize. It wasn’t that you just prioritize by one… Roy: It wasn’t just alphabetical. Clayton: It wasn’t just you prioritize by ROI. There are lots of different ways to prioritize. I think, if you understand that and you realize it’s not just by what’s most important or just ROI, then it’s meaningless at that point. Roy: But I think it’s harder to get people to actually understand that and internalize that. Clayton: Yeah. Had they called this “order” originally, and then now they’re changing to “priority,” I guess we would be just having this exact same conversation. Derek: Here’s my problem with it: it’s the definition of why they’re making the change. If they said, “We’re going from ‘priority’ to ‘order’ because we feel “priority” is a loaded word that confuses new product owners,” I would be totally supportive. That’s not what they’re saying. They’re saying, “We changed from ‘priority’ to ‘order’ because you can’t prioritize things by different things.” That’s [bleep] . I’m sorry. I’m sorry, flubber. You’re a [bleep]. Now, if you want to say that you changed it because the language is confusing, I absolutely buy that. “Priority” is absolutely a loaded word. But that’s not what they’re saying. I disagree with their reason for the change. [laughter] Discussion And Change Is Good Jade: All right. Hold on that wonderful note. Let’s wrap this thing up. Let’s take the next 30 seconds or so and just talk about what are your feelings overall with this change, what are you most afraid of. 10 seconds each, tell me what’s you’ve got. Clayton: All right. I think it’ll generate a lot of discussion on social networks, podcasts, and things like that, and, in six months, it’ll be totally forgotten. Roy: I think that generating the discussion is a good thing to bring visibility to the Scrum and agile. The only element on this that I’m really concerned about is the term “forecast” instead of “commitment.” The rest, I’m either impartial or I actually prefer. Derek: I love the fact that they’re actually making change for a framework that’s all about, and “Inspect and Adapt” has not changed much for 10 years, so I cannot give you credit for having the balls to make change. [laughter] Derek: The thing that concerns me the most is the comment that says that we have worked “closely with the community,” and they name two people that they’ve worked within the community. I’m sorry, this community is now tens or hundreds of thousands of people. The way you approached change is probably not the best. Drew: Yeah. The only thing that I’m really fearful of is the “commitment” versus “forecast” change. I think that “commitment” is a good, solid word, and I would like to hear people use that. Jade: All right. Thanks a lot with that. We will wrap up this ScrumCast. Thanks for listening.

Roy vandeWater: Hello, and welcome to another ScrumCast. I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Drew LeSueur: I’m Drew LeSueur. Chris Coneybeer: I’m Chris Coneybeer. Jade Meskill: I’m Jade Meskill. The Trust Paradox Roy: A few weeks ago, Derek posted an article by John Hagel on the Trust Paradox. Derek, do you want to explain why you presented that to all of us? Derek: Absolutely. When we deal with teams and we talk about teams quite a bit. If you look at Patrick Lencioni’s “Five Dysfunctions of a Team,” trust is one of the pillars or the key elements to building a team. We see all the time people talking, “Yeah, yeah we need trust,” and even “Oh! Yeah, yeah our team’s got real high level of trust.” Then you see all sorts of behaviors that are entirely counter intuitive to how people who trust each other will really behave. I think the article really did a good job of talking about that everybody acknowledges that trust is important for team building. The way that most teams go about trying to build trust with each other, is the exact opposite way in which you would build trust. He kind of comes up with the term, it’s kind of paradox, that the things that people are doing that they think are building trust within their team mates, are actually destroying trust in a much more rapid pace. I thought it was relevant to say, “I think that the biggest part of software development with Scrum, is building team and how teams interact.” Trust is probably one of the biggest values that we have to deal with in being successful or what we do. Values That Build Trust Roy: What are the values that people feel builds trust, and how do they conflict with what actually builds trust? The Illusion Of Perfection Chris: In reading the article I thought one of the things that was pretty interesting is we talk about teams nowadays, and the fact that too many times people think they have to be perfect. People think that you can’t have flaws. You can’t have issues, and when you are trying to put on this perfect face all the time, and you’re trying to act like all your skills are perfect. You don’t want to show you have deficiencies with the team. That is one of the points that is counterproductive to trust, because you’re hiding something. If you want to trust somebody you can’t just have trust and parts of relationship. You have to have trust in the relationship as a whole, and that’s for the positives and negatives. Look at any relationships that you have, be it a marriage, be it a team, somebody you pick up on the street, whatever. If you want to build trust with them, you have to do on at all levels of that relationship. Derek: I think one of the best stories I heard about this, we were talking at one of the scrum gatherings about peer programming. Mike Cohn mentioned that he was one of the first people to start with one of the pair programming, and the story of how we got there was kind of funny. That was, “I had been working with one of the big five consulting firms,” or I can’t remember the exact place he was working. He took an assignment that was all code and C, and he said I really have never had really coded in C before, “But I had kind of done some C in school. I figured I could probably fake my way through it, and learn over it. I really wanted to do that particular work.” He said, “I flew out there, and got in there, and was really nervous that I was going to be ousted that they would realize I didn’t know C.” “The next day another guy that was joining the team from the company came and flew in. We started talking about the work and push came to shove and I felt vulnerable for a minute. I went ahead and I told them, ‘I just want to be totally honest with you, I really don’t know C, but I’m a bright guy and I really think I can get up to speed. I kind of fluffed a little bit my experience on this but I’m sure you guide me, and you’ll never know the difference.’ The other guy said ‘Oh, shit I did the same fucking thing, we’re screwed.’” They said, “How about this, every time were working on code we’re working on the exact same piece of code, so that if we completely fuck this up they have to fire us both. They won’t know who to fire, because we’re both doing the same thing.” He said, “I’m sure we invented pair programming because of that.” I think that you know why it’s a funny story. I think it’s a perfect evidence of how when you actually build trust, and are vulnerable, which I think is one of the key components of trust, to be able to say, “Hey, I just want to let you know I’m not really confident in this, but I’m willing to make up deficiencies, and work my best to get the best out of this,” and somebody else is able to make the same thing. They came up with a solution that ultimately was better for everybody. Meaning the project was entirely successful they both really got up to speed with C, best of all outcomes. Whereas if both of them were to hold up and try to lay blame, “Oh, well, he doesn’t know what he’s doing,” or whatever, the project would have failed. It just would have been disaster across the board. I think too often teams there’s no availability to express vulnerability that actually allows for good solutions to happen, and good bonding to happen. Going Against Conventional Wisdom Jade: By saying that, you’re going against tons of management advice, and personal growth advice. You’re supposed to never let them see you sweat, and always project confidence, and be the big alpha dog. What you’re telling me now is I’ve got to be this wussy guy, who lets everybody know and cries whenever something goes wrong, right? Derek: I pretty much carry a binky and a blanket wherever I go. Jade: Oh, OK. Roy: I thought I’d seen you with that. I was wondering what that was for. Drew: One of the things I thought that was interesting in the article where they talk about the kind of thing you were talking about, Jade, was built on how corporations treated branding for so long. It was, you only show your strength and you hide your weaknesses and act like they don’t exist. That’s how people treated their personal brands. You look at any resume, most people look at resumes, and if they look at their own resume they think, “Oh, this is all great stuff,” and they read someone else’s resume and they’re like, “Man, this guy is so full of BS.” I think what Derek’s getting at is the idea that we need to be able to expose our strengths, and by exposing our strengths and acknowledging where we have deficiencies, like what Chris was saying, that’s the new way to be confident, and project confidence and do the right thing, and make progress. Jade: What you’re saying is when somebody asks me what my greatest weakness is in an interview I shouldn’t say that I work too hard. Drew: Yeah, I interview at companies where people ask stupid interview questions. Roy: I feel like, intellectually, there are at least a few people out there who know that but don’t act on it because it’s very difficult. It seems to go against human nature. Why do you think that is? Chris: I think part of it is, one, it’s against human nature, but also, take a look at the training we had. Take a look at the way that we’ve been raised in a lot of corporations. We’re on an engagement right now where I’m seeing patterns that I used to work and live in. I worked and lived in this non‑trust culture, and now I have a level of trust with my team and my family here to be able to say that… Jade: There’s the crying again. How Are We Teaching People Chris: …to be able to say that. I can stand in front of you guys now and say, “I suck at this,” and somebody will be willing to help stand me up. I can ask stupid questions and people are willing to help me, because we realize that we’re building on one another, but also, you don’t turn around and go, what a dumbass for that. Where before, in the corporate world, you were treated like that. I think that goes back to, how are we teaching people? What is excelling? What is making you different than somebody else? Sometimes that’s all about finding your secret project, and working on it, and hiding it from everybody instead of making sure that you’re doing something as a team and learning together. We’re seeing where we have silos right now and some of the information on our current engagement, and there are trust issues at the very bottom of that. I think that if these people were able to trust and open up a little bit more instead of worrying about somebody else looking at them and going, “You suck at this,” they have so much knowledge that they could bring together, they could move together. They could move forward so much faster. Fear Driven Culture Derek: Yeah, I think a lot of this, too, is fear‑driven, fear‑driven and peer‑culture driven. What I mean that is, I believe it’s Ken Robinson talks a little bit about this. If you take a five‑year‑old into a crowd of people, and you tell them to dance or to perform, they’ll do so, no problem. If everybody in the room starts cracking up, they’ll probably get even more crazy with whatever they’re doing, because they’re getting a reaction. If you take a 35‑year‑old person, and put them in a room of strangers and say dance, they’re like, “No way.” Even if they did, if somebody criticized it, they would stop immediately and totally shut down, because of response. I think we have the same self‑preservation mode, this mechanism that says, I don’t want to be vulnerable, because if I’m vulnerable to my peers, and my peers react in a negative way, I have no other way to deal with it, and so my way to deal with it is to shelter it or camouflage the weakness, so that I’m not attacked in that area. I think from Robinson’s perspective, a lot of that’s the heart of where creativity is. When you’re in a mode where you’re able to say, I’m going to try things that people might laugh at me for, is when you have the highest propensity to do the most magnificent things. When you’re operating in a mode that, “I don’t want to do anything that anybody could possibly laugh at or criticize at,” you’re actually shutting down. You’re limiting yourself severely. I think that teams and organizations fall into that trap, where they’re so concerned about looking bad to each other, or being laughed at that they, basically, strike out all ability to do any kind of innovation, or do any kind of really gel at that next level. I think it completely impacts the way they’re able to interact and be vulnerable with one another. Clayton: I agree with that. When that is the status quo when you’re working with a team like that or organization like that, it’s a perfectly rational thing to have that behavior. If my performance review, my pay raises, how I’m viewed on this team, and my advancement in this corporation are determined by my strengths and weaknesses compared to people at the same level. It’s perfectly reasonable to say, “OK, I’m going to hide all my weaknesses. I’m going to have my secret project, and try and make everyone else look bad.” That’s a very rational thing to do. Roy: If you’re in that type of situation where you have a culture of people that are throwing each other under the bus, and trying to make themselves look better. Drew, if you were working in an environment where everybody was throwing each other under the bus, what would be the best way to approach that, and try to rectify that type of culture? Building A Culture Of Openness Drew: Showing an example of openness would probably be the best way to do it. Be the one where if you make a mistake, “Hey, it was my fault. I did this. Can you help me figure this out?” and pull in another teammate or something. Jade: Then you’re fired, and no problem. Drew: Maybe I’m wrong on that, but I think people will see that. If everybody’s throwing each other under the bus at a corporation, people are going to notice. Higher ups are going to know that, “OK, they’re always just blaming each other.” They’ll probably take a dose of transparency with happiness, and they’ll probably embrace that, and enjoy that. It’ll be refreshing to them. That’s probably how I’d do it. Chris: Hope the guy throwing you under the bus is your manager. Make Everyone Around You Better Jade: One of the mistakes a lot of people make is they believe that their success is hinging on their ability to perform some skill to the best of its ability, not realizing that what’s more important, especially to management, is your ability to make everyone around you better. If you can rise to the top as leading that type of a change, people respect you much more for that than your ability to be the best .net developer out there, when it comes to this particular niche technology, “I’m so awesome, and I can code anything.” In a team situation, it’s really more about what you’re contributing to the team. If you can make everyone on your team at that same level, then that’s way more impressive, way more valuable. That’s going to build a lot of trust by investing back into the people around you. Moving Towards Trust Derek: There’s two segments to it. The first segment is, if I’m a CEO or a manager that’s trying to get a team to have trust, you’re spot on, Drew, that there’s really two ways to do that. One is, to model it. Be open and transparent, and really model that to the team, and look at how you’re incentivizing the team. Whether that be through their performance appraisal, whether that be through how you articulate and express that you’re happy with them. Make sure that you’re reinforcing behaviors of vulnerability, transparency, and authenticity, and not performance. You’re putting more reward towards people modeling a value system of trust than you are whether they’re succeeding or not. As a team member who wants to create a more trust‑filled team where you aren’t getting management support, I would say the same thing. It’s really about modeling. I would also say, one of the things that Hagel talked about in his article that is totally relevant is, for 30 or 40 years, brands got away with being absolutely inauthentic in masking what they were horrible at, and highlighting what they were great at. Everybody believed that. We’ve come to a point now that, once you spill 100 million gallons of oil into the ocean, it doesn’t matter what you do to try to PR that up, people know that that PR is bullshit. Anybody who’s been the workforce for any amount of time, any amount of time being twelve months or more, knows that there’s so much bullshit in teams that they know when people are glossing, when people are highlighting the right things, and pushing the bad stuff under the table. It’s such a breath of fresh air when a team member comes in, and is authentic, helpful, and vulnerable that it becomes really hard to ignore that. You earn the respect of management and of your peers so much quicker, because you stand out so much more than everybody else around you. It’s almost contagious. That’s the hopeful message in this because, right now, most teams are fundamentally broken. It only takes one person within a team to start modeling this for it to become contagious, and start to infect the team and organizations involved with the team. Roy: That’s it for today’s ScrumCast. Thanks for joining us.

Clayton Lengel‑Zigich: Welcome to another episode of the Scrumcast. I’m Clayton Lengel‑Zigich. Derek Neighbors: I’m Derek Neighbors. Roy VandeWater: I’m Roy VandeWater. Jade Meskill: I’m Jade Meskill. Translating Principles Into The Real World Clayton: Last week we as a team went and did paintball. Wooh. It was a lot of fun, and one of the things we noticed that a lot of the principles that we use day to day really translated pretty well into paintball. We were all surprised by that, as we talked about it more and more, at the end of the day. Roy: How nerdy is that! [laughs] Clayton: Yeah, I know. [laughs] Clayton: As we talked about it more after lunch, after we did paintball, we were pretty surprised. One thing that’s kind of funny, to give a mental picture to everybody, is that the opponents for paintball were a bunch of 13 year olds. Roy: At best. [laughs] Clayton: Yeah, at best, so think about that. [laughter] Derek: With pro gear. Clayton: That’s true. Jade: They did play everyday. Inspecting & Adapting Clayton: One of the principles that I think we kind of discovered that we did…As we went through the different rounds, the format was basically, we played three games with two matches each or something like that. We did a pretty good job of inspecting and adapting. Who wants to jump in and comment on that one? Roy: I thought one of the things that’s pretty cool is that it felt natural. We didn’t even realize that we were trying to adopt, inspect, and adapt principles until way after we went home, after the paintball event, right? Like it just came natural that “All right, we did this, that didn’t work. Let’s try something else.” We were constantly reflecting and spending the time between matches, coming up with what we were going to do better to follow the match. Derek: I think the thing that stuck out to me the most is we didn’t really talk at all about the other team. When we had success or failure, every time we were looking for improvement, it wasn’t anything about “They’re doing this. We need to do that.” It was all, “These are the things we need to do and to improve.” I thought that, that was kind of interesting. Our focus wasn’t like, “Oh, they’re killing us at this. So, we need to respond to that.” It was like, “These are the little, itty‑bitty incremental things that we need to do to improve how we’re doing things.” Jade: Which was interesting because when we first started, this is the first time that almost all of us had ever played paintball. We did end up playing against a bunch of 13‑year‑olds, but they really did have pro gear. They came in every day like this is what they did, but our focus really wasn’t on them at all. We were a little worried we’d get our butts kicked the first time in, but we just didn’t sweat it, man. I thought that was really cool when you pointed that out afterwards, Derek. We just never even mentioned them. It was all focused on ourselves. Play To Beat Yourself Clayton: One of the thoughts that I wrote down was that, ultimately, the first game we probably tried to beat the other team and then after that it was just how can we beat ourselves from the last round. I thought that kind of encaptures that thing. One of the other things that we’ve started to do after we did the paintball, it was easier to describe in a kind of a paintball you’re talking about being shot at and those things, but was the concept of exposing your vulnerabilities. There was times where you’d say, “When I go over here, there’s a guy that can shoot me from that little window or whatever.” We talked about that a lot, and we found ways as a team to solve that problem. How does that really relate to the software side of things? Exposing Your Vulnerablities Derek: I think a lot of times we go into standup and we really only talk about, “What did you do yesterday, what did you do today, and what are your impediments?” While all of those things are really relevant, I think the things that are usually the largest risk to a team are the things that the team is actually afraid of or exposing themselves to. I don’t think we really talk about risk during a lot of our different ceremonies inside of Scrum, and I think that that’s something that we need to, as teams, as we become more trustworthy with one another and become more vulnerable with each other that we start to say, “These are the things I’m worried about,” or “Hey, by doing this, we’re leaving ourselves open to that.” During paintball, one of the things I saw was we were doing something like duck and cover type of maneuvers where, “Hey, you’re going to send somebody out and I’ll cover you.” The first time we did that, we were fairly successful except at one point when we advanced almost all the way to their base, our guys got nailed. When we came back, the adjustment was, “The problem is when you’re covering me, you’re covering me from the wrong angle and therefore, you’re leaving me exposed. When I get to a certain point, your angle was no longer effective cover for me and so I’m exposed, could you adjust and give me a slightly better angle so that I have more cover.” I think we don’t do that enough as teams to say, “Hey, if I take this risk, I’m going to be exposed and if you could just shift over and do this thing for me, it would really cover and help me manage the risk that I’m taking to take that risk.” I don’t think we do that. I think that’s why a lot of teams don’t take risk. The second part during the last game we had I thought we were super aggressive and it had everything to do with trust meaning that, by the sixth game, I knew that if [inaudible 00:05:24] said, “Go ahead and advance, I’ve got your back,” I could pretty much just stand up and run right to the target and stick a gun in their face, and not have to worry about getting hit because I knew he had my back. When as teams you start to provide adequate cover to each other to take risk, the amount of risk you can take is monumentally huge compared to the cover‑your‑ass perspective of, “I’m not going to take any risk because I can only take care of myself.” Roy: I think what’s important there too is that when you have somebody covering like that, the risk becomes less of a risk. Derek: Correct, that’s correct. Roy: There’s is less chance of this going wrong because I know there’s somebody that’s got my back. Derek: Absolutely. Power Of Incremental Improvement Clayton: So one of the other things I think we did a good job of from game to game we kind of improved on small things, so it’d be kind of do some incremental improvement. We all had our own ideas of what those things were, but I was curious what you guys thought. What are some things you thought we did better incrementally over time? Roy: So I think one of the things that we started doing was splitting off into [inaudible 00:06:27] of teams. So we’d start off at six and split off into three, and then eventually we decided actually do pairing where we would have each person buddy with another person and kind of work from that perspective because that gave us more flexibility and it was really difficult to keep track of three people [inaudible 00:06:41] . Like we actually split up into smaller chunks, but we realized every man for himself was not practical, or feasible. Derek: Yeah, I think the other thing that was interesting is I thought we did a fair amount of self organization and self direction within. So after the I think it was the first game or the second game, and we kind of decided to split up into pairs, we kind of did direction where we said, “OK this pair you guys get the right flank, this pair you get the left flank, this pair’s going to hold and cover the base or do whatever.” But that was as far as the direction went, and then it was really up to each pair to say, “This is how we plan on attacking to the right, or attacking to the left, or holding position.” The rest of the team didn’t even have to know what was going on from that perspective. It then kind of goes back to the trust issue for me, right. If I say, “OK, Clayton and Jade, you guys have the right side, Roy and I are going to take the left side,” we’re not worried about are you really going to take the right side. Right, you’ll let us know, you’ll scream at us if you lose your position, you’ll let us know that. Until then we just trust that you are doing that, we don’t have to worry about it. Individuals Blame The Game Clayton: Kind a good parallel was the team, maybe this was just because they were 13, but the other team I noticed that they were pretty much everyone for themselves, and when something would go wrong it was always like, “Oh man, why didn’t you see that guy, or why…”? It was always someone else’s fault. But with our team we did a pretty good job of when someone got out it was a…OK now that we’re starting this game over, or the next game, like, “Hey, why did you get out, what’s going on, and what can we do to improve next time?” I thought that was a pretty direct parallel. I think most teams you got a bunch of individuals that are all going their own direction, and it’s kind of a blame game when something goes wrong. Constant Communication Derek: Yeah, I think one of the things I noticed too was I think you heard us talk the entire game. Like definitely between the pairs there was definitely a ton of talking, and I don’t think I heard the other team do very much verbal talking at all. Jade: No, I never heard them, because I think they thought that that was a strategy to keep them safe. Right, was to keep quiet and keep your head down. I think we definitely bucked that and just kept in communication the entire time. So Clayton, you said that we’ve started to use this idea that we came up with of exposure. Maybe you can explain to the listener how we are incorporating that into our stand‑up, and how it flows in the stand‑up, and what are some of the results that we’ve seen from that already. Exposure In A Stand-Up As A Means Of Preventative Care Clayton: Yeah, so we’ve started doing something towards the end of this tenure. If you feel like there’s something that’s happened recently, or if you feel like you’re going to get into a situation, or you’re going to be exposed, where you are going to be facing some extra risk or something like that thereon, communicate that with the team. Earlier this week we’ve had a situation where someone said, “Hey, I was making good progress and things were going well but my pair they’re sick, and they’re going to be out now. I am going to be exposed because I’ve got some meetings, and I was going to rely on them today, but now that they are out what am I going to do?” Those are things that normally people would kind of ignore that, and it might come up the next day, but that’s something that we were able to discuss before it even became a real problem. That’s pretty much the flow has been, if you’ve got something that you feel exposed on, even if it’s not anything directly related to the work that you’re doing that day, but more of a concept of, “Hey, we’re going down this road with this solving a certain problem. It seems like it’s going to be OK, but I’m a little worried.” Even that kind of stuff has been helpful to get out and exposed to the team. Jade: Do you think that’s helping us to preemptively recognize things that could possibly be impediments, but, instead of ever materializing as impediments, we’re catching them sooner because we’re getting ourselves in that mental mode of thinking defensively? Clayton: Yeah, I think it’s a good way to put it. I think we’ve treated it like preventative care, almost. Normally, it would have been acceptable or OK or part of the process to say, “Yesterday, I had this impediment that slowed me down,” but now we’re getting ahead of that. We haven’t solved every single problem so far. There have been times when we have said, “Hey, I’m exposed,” and the team says, “OK. There’s not much we can do,” or whatever the situation is. But it’s at least been out there and been on people’s minds, and we have been able to prevent those things before they become real impediments. Vulnerability is OKAY Derek: To me, the biggest benefit is it really puts people in a state where vulnerability is OK, where it’s OK to say, “I’m worried about this technical challenge,” or, “I’m worried that my pair is not going to be fully available and that it’s going to be hard for me to focus or to achieve the volume of work,” or, “I’m worried that XYZ is going home, and that’s going to impact my ability to participate ABC or be distracted.” For teams, it’s very difficult to be vulnerable. So, by putting within a ceremony an ability that allows people to, in a safe way, express what they’re feeling exposed to can potentially, if not abused, help build trust by encouraging people to be vulnerable in a safe manner. Clayton: Yeah. I think vulnerability is the key there. When people say “trust,” a lot of times, if you’re not really familiar with what that means on a team, I think a lot of people think that just means, “I trust Roy to do his job.” But vulnerability is really the key aspect of the trust, when people talk about it in relation to a team. Jade: It’s been interesting to watch, because, a while back, we implemented from core protocols the check‑in and then talk about some of our feelings and emotions to try to get to some of that vulnerability. We still glossed over a lot of things, because we weren’t thinking in that defensive mindset. It’s, “OK, here’s maybe some raw emotion. I’m mad because blah, blah, blah,” or, “I’m sad because of this,” but it’s really helped us have a frame of reference to think about how am I exposed today and what’s going to happen today that’s going to leave me in a potentially vulnerable state, and sharing that with the team. I don’t know, what you guys think about that. Short Feedback Cycles Clayton: One thing I always thought was interesting was we do week‑long sprints, so there’ll be times, towards the end of the week or retrospective, someone will bring up some problem that they had, and then maybe they were trying to be vulnerable. They were talking about something that was a problem. But then, come next sprint, over the weekend, it was like they forgot about it, and the behavior never really changed. What was interesting with the paintball was that it was so quick. Basically, there were maybe five minutes between the matches. Sometimes, we took a longer break ever now and then for 10 minutes. But it was so fresh on everyone’s mind that, “Here are the problems. Let’s talk about them,” and then, at the beginning of the next one, everybody knew what we needed to do. We knew all the issues that we had, the vulnerabilities. So it was easy to come back and immediately go into that. That’s been part of the problem with some of the core protocol stuff that we’ve been doing. I think that we’ve been glossing over that, but it’s easy, especially now that we all have paintball on the mind when we’re talking about the exposure stuff, so it’s easy to think in those contexts of, “OK, I’m going to talk about what I’m vulnerable or how I’m exposed. And I’m not going to gloss over anything, because I know that I’m going to get some impact from the team, or something is going to happen right now. It’s not going to just wait. I hope someone says something later.” Building Trust And Learning To Be Vulnerable Jade: As we wrap up here, what would you recommend other teams do who are maybe struggling with building up some of this trust or talking about the vulnerabilities and exposures that they have? What would you recommend for them to do? Roy: The core protocol portion of the stand-up, and having people start talking about their feelings, is a good place to start. Because the facts are great, and all, but as Jade likes to say, perception is reality. If people are feeling a certain way and perceiving their own realities in a specific way, then it’s good for the rest of the team to know that, so they can understand where that person is coming from. Derek: I’ll provide a counterpoint to that, and I’ll say I absolutely agree that perceptions can be reality, but I’ll also follow with feelings aren’t facts. I would say that when I’ve seen teams do the best when it comes to vulnerability is when they have a shared vision. Because of that, basically, it allows all the baggage and all the bullshit to be dropped. When everybody is going a different direction, there’s all sorts of grandstanding and lobbying, and there’s always this undertone of, “I’m trying to convince you to do my direction, and Clayto was trying to [inaudible 00:15:44] somebody else to do their direction.” There’s all this silly political bullshit underneath the surface, where I think then vulnerability is locked out. When it comes cut and dry is, “Is this pushing forward to our vision? Yes or no?” It becomes a lot of easier to say the hard things and have the harder conversations, because they’re not loaded with all the baggage of the feelings, so to speak. You can say, “This is how I feel,” get it off the chest, and then have the real conversation instead of play that political back and forth, like, “I’m trying to jockey to determine what direction to take things.” I would say the best thing a team can do is get on the same page with where they’re going and then start to talk about their feelings once they’ve got that set. I think the rest works itself out over time. Clayton: Yeah, that’s what I was going to say. No. I’m just kidding. [laughter] Clayton: I think that talking about vulnerability and being vulnerable with the team mates is pretty difficult. I think the team should start with trying to find ways to get more into healthy conflict and not having the perceived “everything is OK” feeling. Basically, a lot of stuff that’s in… [phone rings] Clayton: A lot of the stuff that’s in the… [laughter] Clayton: I’m sorry. I’ve got to take a call. [laughter] Clayton: To find dysfunctions on a team, and the chapter that talked about, there’s a list of things that teams who don’t have trust, these are the bad habits that they have, and here are ways you could figure out. If your team does have trust, they should exhibit these traits. I think driving into some of those is a good step in that direction. [background music] Jade: Thanks for listening to ScrumCast. Hopefully, you’ll catch us next time, as we continue to expose ourselves.

Chris Coneybeer: Hello again. Welcome to another addition of ScrumCast. I’m Chris Coneybeer. Roy vandeWater: I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Drew LeSueur: I’m Drew LeSueur. Why People Crave Documentation Artifacts Chris: Today, trying to go through topics and something we thought about was large corporations and the need for artifacts during sprints and during projects using agile methods. I’ve worked in several large corporations where have been beaten under with pages and pages of requirements, tracking, and all kinds of other documents or artifacts needed for managing a project. I want to get the group’s feedback on what your feelings are and also with some of the people here that have been working offsite at other teams. Have you come across these issues? How have you tried to deal with that in adopting agile and scrum techniques? Roy: I think part of it with the documents ‑‑ what is the real value that they are trying to get out of these documents? What are they trying to accomplish by having these documents as part of their process? Chris: I think traditionally what I’ve seen with a documents is that they have been put in place to try to enforce processes, when other ways weren’t working for making sure that these processes were happening ‑‑ such as release management, and making sure the security have happened, code checks have happened, just sign off. People weren’t doing their jobs. People weren’t being held accountable, and they weren’t doing what they said they were going to do. Documentation and processes were put in place to try to clean that up. Documents For Accountability Roy: Would you say that most of these documents or most of these artifacts are documentation of accountability? Chris: I think accountability, but also user requirements. I’ve seen some rather large user requirement documents that if you had interactions, if you had conversations with a business owner and the stakeholders, you could do a lot better job in understanding instead of just throwing a document over the wall, and then waiting for something to come back over. Documentation Highlights Silo’ed Organizations Derek: It’s right, because I used to think of the desire to over document. I think we can all agree Agile is not about documentation. But I used to think it was all about cover your ass ‑‑ meaning that the reason that most of the managers I saw that were demanding documentation as a team member, I always felt that they were doing it because they didn’t trust the team. They wanted some artifact to prove that if their boss yelled at them, they could say, “Well, look. We documented all this. The documentation has been for a long time, and nobody commented on it. How would we know?” But the other night, I was re‑reading Lisa Adkins’ “Coaching Agile Teams” book. She said something in it that made me just now think about documentation. She said when she was a typical project manager before adopting Agile, one of the things that she said is she didn’t ever have to deal with conflict. The reason she’d never had to deal with conflict is because the way that the processes were built. Everybody was siloed. You were only on a project for a certain amount of time. If I am the manager of a testing team, I’m only on the testing project for a certain amount of time. There are all sorts of conflict in whatever brewing up it doesn’t really matter, because in four weeks we’re not on this project any more. All the conflicts we had with other people were gone. I think this was one of the key reasons big companies really want documentation, is they are so siloed. They play pass the baton so much, that they’re definitely afraid of it. It’s almost like having turnover every four to six weeks inside of a company. If you could think about your entire team leaving and another team picking up where you left off, that’s really scary. The best way to combat that is why I want all sorts of documentation. When I’m the new guy coming in, I’ve got my cheat sheet to go back to if I get confused. To me, is this part of the problem with big organizations? Is it they’re not fluid enough. They’re not cross‑functional enough. It incurs the desire to have documentation to cover up for that. Roy: I think that’s a really great point. Obviously, there’s less of a need for as extensive documentation when you’re working in a more open environment, where the team communicates verbally, primarily. I also really think the comment, or the phrase, or the idea that the main artifacts should be the code and the tests, is really powerful. What actually is happening? The documentation can say whatever. It can become outdated. But the code and the tests that pass are, actually, real concrete documentation, and commit histories as well. I think in an environment where you’re more open, where you’re not siloed, where there’s more of verbal communication, and where you have good code and good tests then there’s a lot less need for extensive documentation that is probably not read very much, anyway. Documentation Shouldn’t Replace Communication Chris: The one thing I throw out there is that in regard to this documentation conversation. I don’t want people to get confused and say that we’re trying to say throw out all documentation, because there’s still going to be some documentation that’s needed. You’re going to have compliancy issues. You are going to have maybe general architectural diagrams for a high system level understanding. What I have seen, though, is that since I have been at Integrum I have learned communication. Communication is everything and team ownership of code is everything. That makes a big difference and what I have seen in corporations is that they are replacing communication with documentation. That is where, Derek, maybe the reason some of this turnover is happening is because there is no communication. Who is happy on a team when you are not communicating with anybody? They don’t realize it and maybe that is why people will get upset at what they are doing. How do we try to replace communication? Replace that documentation that is being used as communication that we are used to in the projects that we manage? Roy: Part of what Derek initially stated where you had previously believed that it is a lot about trust. I think a lot of that still is true, a lot of is about trust, and that if you have a team that is consistently underperforming and whether it be because they have only been on the project for two or three weeks, because everyone is on the project only two or three weeks at a time. If people stay on a project for longer and start performing and start doing well, I think that their managers will find less of a need to require documentation of them. Because they know that this team is going to do what they say they are going to do, regardless of whether or not they fill out the whatever report. Also as far are teams switching out really frequently, what is the primary reason for that? Treating People Like Resources Instead of Humans Derek: I think it is because everybody is specialized. If I am the enterprise architect, I am only needed really at the beginning of the project full‑time, and then after that you just consult me if you feel that there is a change in architecture. If I am the QA team, and you really consider a story done when it is coded, not when it has gone through full Q and A, I am looking at the project in a much different time than everybody else. I need all sorts of artifacts to come along with me, because you are on another project. As a developer you are working on another project potentially by the time I am doing a large portion of the QA, or the enterprise architect is now on another project by the time it gets to it. I think that there is something to be said for communication pathways. I think large companies have larger teams, which means it is harder to communicate face‑to‑face or person‑to‑person. It is easier to say we need to write that down so that anybody on the team can have access to that even when we are on the same project. But when I think you add in the silos and not being cross‑functional, to me, it really comes down to people are treated like resources instead of like people. Managers treat everybody like a completely interchangeable widget that they are just pushing and plugging, so it is really easy to say, “I really like the work that Roy is doing and I need Roy this week, so I am going to pull him, pull that widget out and plug him into this other product.” Now all your knowledge is gone, and because now you are on another team, it is no longer culturally acceptable for everybody on your old team to communicate with you to ask you information. If you didn’t leave a litany of artifacts and you hadn’t been communicating with that team, all of your knowledge is now gone. The way managers try to protect themselves from that, I believe, is they want people to document absolutely everything so that they are guarded. If their resources get taken away, they’ve got a backup plan or a transitional plan to bring on new resources. Chris: That goes so much back to silos. Drew: Yes, I agree as well. Even if there is a situation, like you were saying, how somebody is just kind of plug and play like a widget out from one team to another, I still think that the need for extensive documentation is still not needed if the coders, if the programmers write good tests, write good code. Sure, maybe give a shorter overview of written documentation that is not part of the code or test as needed just for kind of a big picture. But if they are doing things the right way, then yes, still extensive documentation, extensive artifact, extra artifacts are needed. Stop Emphasizing Specialized Roles Roy: Do you feel that it is necessary for large corporations to have all of these specialized roles? Like people who are… Derek: No. Roy: Especially because I understand that if we take it to a tool shed metaphor. If you have one employee who is good for everything, something that is used for everything like a hammer that you can use for whatever tool. It is great to have on hand, because you can use it wherever you go, but having a specialty tool is way more effective in those key circumstances. Does that metaphor carry over into the business world or is that a broken idea? Derek: I don’t think it does entirely because the two things that I think that it leaves out is, one, it leaves out what you get from somebody who is well rounded meaning that when you’re really talking knowledge work, it’s not cutting dry of, “Here’s the band saw I need. Cut the band saw, and now I’m taking it over and using sandpaper, and sandpapering it.” The work that teams do is dynamic enough that you really need to understand the whole concept of woodworking. It’s not just a matter of being able to understand like, “I’m the best drill press guy in the world.” You’re probably not making a whole lot of great furniture if you only know how to operate the drill press. If you get to be a little more rounded, you may not be as good as the guy who only works the drill press all day, but you’re now also be able to create things that somebody else that is unifunctional is not capable of doing. I think that that’s probably the biggest piece that, to me, pulls on to the second side and that is that you’re not nimble if you have a bunch of specialist, because you’re limited by your resource allocation. If I say I’ve got one of these guys, five of these guys, six of these guys, or eight of these guys, and all of a sudden a competitor pops up, and I need to handle something. I need to extend the software. I need to create a new project or do something, and I don’t have an enterprise architect ready right now. Now I have to wait to when is the next time an enterprise architect’s ready. “OK, six months.” “OK, we can’t start that project for six months.” Whereas if you got well‑rounded people, it’s a lot easier to be able to pivot and to shift because even though they might not be the best in a particular thing, they’re able to get up and running with that. If you’re in an environment where there’s communication and self‑organization, what I see is people make the right choices. If I really suck at JavaScript, and I’m going in a project that’s heavy JavaScript, I could tag out and say, “You know what, Drew, you really need to be on this project. I’m not the right person for this. We need to shift places.” If we’re allowed to do that, the right things happen. Or, “Hey, I need you to pair with me on this, because I want to get better at JavaScript, but I don’t want to slow this project down, or I don’t have the expertise to do it.” I think if you let people make good decisions, they’ll un‑silo themselves. Chris: You got any other comments on that? Drew: I think that’s a great point, the pairing. It merges into cross‑functional teams discussion a little bit. But yeah, pairings pave for that. Improving Communication Chris: I think it really comes down to a lot of, like you said, Derek, getting the teams to communicate, being able to get people to work together, and also, not just communications on the teams but communication throughout the business. Let’s get rid of 500 page requirements documents and start the communication channels with the people that are involved with the software. Roy: I’ve met quite a few developers that are not a big fan of doing communication. There’s a lot of people going into the computer science industry that I remember from college that couldn’t wait to graduate, get their own cubicle, and never have to deal with another human being again. How do you feel that people like that that are hiding behind documentations and using documentations as a wall around them, so they don’t interact with people? How do you think that affects the company? Chris: For myself, I think it impacts the company poorly because how are you going to really understand what you’re writing software for if you just surround yourself with documentation? How many times does it help when you, actually, have a one on one talk with a user, and you see the frustration, you see their eyes light up when they think about something, or you actually watch them work? There’s something to be said about that, because at the end of the day, we’re writing software for human interaction, so we need to have human interaction to understand how that works with the software. A piece of paper doesn’t tell me that. All a piece of paper does is signify what made it through the process that probably higher ops or whoever’s in charge of the project [inaudible 13:55] out and say, “No, this is as important as this is,” but they aren’t the people using the software at the end of the day. There’s something to be said about having that communication. I think no matter what we’re always going to have people on the field that are going to stand behind the documentation, and we need to learn how to get them on the team, and how to use them as effective resource. Like Derek said, make sure that they’re not just a hammer. Make sure that they’re well rounded, and we can use them in many different circumstances. But make sure that also you have components on the team that are able to have open honest communication about what are the problems that you’re trying to solve. Communicating User Requirements Drew: Coneybeer, I really like your answer to Roy’s question, people who wall themselves away with documentation. There’s also that documentation of user requirements where that can be minified or reduced with just communication. Here we’re not talking about just communication between the team but communication with the end user. I really like that, because the communication in the team and out of the team reduces the need for endless writing. Roy: I think a lot of times it unlocks a lot of innovation too where I, as a product owner, may build the requirements documents and say, “I want a piece of software that performs all of these functions and has all of these features.” In a non‑communication sense where it’s purely documentation, I received that requirements document, and I start building the software based off of that. At the end of the day, I give them some software, and they say, “This doesn’t give me the value that I’m looking for.” The developer can say, “But look, I can check mark all of the requirements and [inaudible 15:23] those.” But if they had taken a moment from the beginning, taken the time, and got together, and talk about what the user really wanted or what the product owner really wanted in that case, they may have come up with a way better solution that’s maybe easier for the developer to implement, that maybe gets the value to the end user better. That would have been a better overall solution. Instead, they choose a limited form of communication to try to tell the other person what they want when they really know what they want. Chris: Because how many times have you had that conversation were you do get a chance to talk to somebody, and all of a sudden, you both go on the same page and go, “Wow, we could do this, and it’s going to be hell of a lot cheaper, hell of a lot easier. It’s going to be a better solution”? But too many times when people write up documentation, they put these limitations on their knowledge ‑‑ what they know how to do or what they’ve seen ‑‑ that hampers and changes the way that they’re writing out that documentation. Then, you’re already starting with some limitations in place based upon what that person knows. When you have that communication, you’re able to figure out better solutions just like you said. How many times do we have that where it’s just like, “Oh, we could do this so much easier”? Guy In a Room Derek: To me, I think the question was something to that effect of, “What happens to the person that just wants to hold themselves up?” To me, this is one of the biggest detriments we’ve seen in this industry in the last 20 years. When I look back at the ’50s and the ’60s, some of the most prominent software developers were women. You didn’t have a cube. You had a computer room that was bigger than most offices that you had to operate in. There was a much more communal aspect to computing in the early days of computing. I think that it showed in the type of innovation, and the type of work that was being produced at that time, and the quality of the work being produced. I think as we’ve turned into the, “Put the programmer in the dark cave, and feed him food underneath the door, and he’ll spit back code” has really hurt our industry and innovation that we see. I think what we’re starting to see right now is, as teams start to adopt agile methodologies, they become much more diverse. They attract a much wider range of individual. You start to see their solutions has become much more creative, and you start to see the people who want to work on those teams interact in a much different way. I think you might see a day where there’s not very many jobs available for the coder that just wants to go in, and basically bang out code, and be left alone because I don’t think that’s where innovation lies. I don’t think it lies in one person’s head, and I think history proves that to us all across the board, medicine, architecture, you name it. It’s not one person in a dark room being inspired by what’s in their own head. It’s by being inspired through conversation and interaction with the environment. I think that’s the type of development we are moving to. It’s a more humane style of development. Until then, see you next time.