The podcast discusses strategies for Scrum teams dealing with underperformance close to fixed deadlines, exploring the options of adapting Scrum practices, switching to Kanban, or finding alternative solutions. It emphasizes transparent communication with the product owner and the dangers of wishful thinking in Agile methodologies. Additionally, it touches on the consequences of disregarding Scrum practices, managing impending deadlines, and the importance of taking extreme risks in high-stakes situations.

Derek Neighbors: Hello! Welcome to another episode of the scrum‑cast, I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Llewellyn Falco: I’m Llewellyn Falco. Learning From Teaching Kids To Program Derek: So Llewellyn, you’ve got a site called Teaching Kids to Program and I know you guys are doing a ton of work with different teaching styles to get kids adapted and wrapped up into programming, obviously programming is a moderately complex task. So for a young mind I’m sure that you have got to take a couple of different approaches. I’m just wondering if you guys have learned anything that you could maybe take into the coaching or to the agile world or to the adult world about learning styles that you have seen and how you might apply those to teams that we are working with today? Roy: Absolutely. In fact, I find that both. We take a lot from Agile into when we teach. I teach both kids and adults, and in both cases I’m taking techniques from Agile there. Then I find that in the same way as every time you do a retrospective, that you realize, hey, there’s something else you can do, it transfers back and it creates a neat cycle. But the first thing that we’ve seen is just this importance of feedback. In the same way as it’s really important to get your code [laughs] in front of a customer, it’s important to make sure that you are getting constant feedback. Not just as to what the kid is doing, but the kid is getting constant feedback or the student is getting constant feedback. Feedback Influences Learning Derek: Absolutely. I noticed that in one of the models that I’ve seen it really talks about how you give feedback can be monumental to fostering additional learning. So one of the theories currently out there is, if you ask somebody to do something and you give them feedback, and the feedback is like, “No, that’s wrong” or “Yes, that’s right,” that you actually discourage them from wanting to learn. Where if you reward them for the effort placed in, regardless of whether the answer was right or wrong, you say, “That’s a really great job. You did a really good job of trying to solve that problem, but it’s wrong. This is how you solve it,” that you actually encourage continual learning. I know you are really interested in some of the mindset kind of concepts, and I think the author of that book talks a little bit about that as well. Are you seeing patterns about how you give feedback or how feedback is applied dictates how much a participant will dive in or not, dive in in the future? Roy: It sounds a little bit the everybody‑gets‑a‑trophy. Derek: I don’t think it’s really everybody‑gets‑a‑trophy. It’s not saying it’s not OK to tell somebody that they’re wrong or that they’re right. It’s that when you say that all that matters is the answer, that’s where the problem is. If you say the process of getting to the answer, I’m going to reward you for the effort of trying whether you tried or failed, that encourages people to go ahead and expend the effort the next time. If you have a right answer and I say, “Yup, that’s absolutely right” and I don’t reward you for the effort you put in to get the answer, you’ll actually still be discouraged from wanting to put the effort in in the future to get the answer. Feedback Vs Praise Llewellyn: There are actually two things that are at play here that a lot of times get lumped together. One is feedback, and the other is praise. I think sometimes we consider them to be the same thing. Even if you did horrible, there’s a difference between saying, “Hey, you really suck at this, and you’re never going to be any good at it. You’re just bad” versus “You did bad at this, and you need to work harder at it. You’ll be better, but you have to try harder.” One part is the feedback. “Did you do good or bad?” The everyone‑gets‑a‑trophy idea that says everyone is good regardless of what they did, and that’s not useful. In fact, that actually is removing a layer of feedback that’s important to the kids but the idea of then also how you praise. Separating just the answer and the praise is a very important thing because it really is, and time and time again, the amount you work, the amount you practice. These things are really what determines where you end up. Roy: I think it’s important to keep the two separated as well because in the past we’ve talked about the crap‑filled Oreo, right? Where it’s like the copout on how to give bad feedback is you give them a compliment like, “Hey, you’re doing a really good job.” Then you throw in something about the performance or something bad and be like, “But I notice you’ve been struggling in interacting with others.” Then you follow it up with another compliment like, “But you’re doing a really good job, so keep it up.” Then the person walks away from the interaction not knowing whether they were rebuked or complimented or really where they stand. Llewellyn: Yeah. Willing To Give It A Try Derek: One thing that I know is really in working with kids I think more often than not for most kids, not all kids, they still have a pretty strong belief that they can learn new things or tackle new things. They seem to not quite give up as much. I know that in working with adults, a lot of times if you encounter an adult that doesn’t know how to program, they say, “Well, I’m just not good with electronics. I could never do that.” Whereas a kid, you put it in front of them. So are you able to take anything you’re learning with working with the kids and that can‑do attitude of…So are you able to take anything you’re learning with working with the kids in that can‑do attitude of, “I’m willing to give it a try. Even if I’ve never really played with a computer before, I’ll try this programming thing” and take that back to teams who maybe say, “Well, we’ve tried that” or “We can’t do that” or “It’s not possible to do that”? How do you get them to start to change maybe their mindset a little bit to be a little bit more like a child in being able to try new things? Kids Embrace Change Llewellyn: That’s actually really important. It’s weird to think about, but as a kid your life is so topsy‑turvy. Everything is changing. Your interests are changing. The people you’re around are changing. Each year you have a new grade, and your grades get bigger. You’re in smaller classes when you’re in kindergarten, but when you’re in high school the school is just massive. In your world, you’re constantly in this state of flux. But what’s surprising is when you get to like 35 or so, all of a sudden you can do the same thing day in and day out and the same people. Your world becomes very much more controlled and smaller. You’re just not in the same kind of, “Hey, let’s go try something.” To take just a very extreme example of that, think about in college when you head out to college in your dorm, you literally share a room with just some random stranger. That seems like an OK thing to do. But now the idea that, “Hey, I’m just going to randomly…” having a roommate, that’s a push. But a roommate usually means two rooms in the same house as opposed to the same room. We have gotten ourselves into a much more controlled place, and that really cuts down on the experimentation. Kids are naturally in a better spot for that. What that means is you can just quicker do the thing that you need to do, which is crucial, which is get them doing something because for any kind of learning to occur, first you need some sort of experience. Derek: I was going to say I think that’s something that definitely you can take back to teams. I think teams will debate things to death a lot of times when they don’t know. Even if it’s implementing a feature that maybe they’re not sure of the best technical way, they’ll want to beat that to death. “Let’s talk about it.” Whereas if sometimes you’re going to say, “Let’s jump in and do it,” put out a spike, put out a tracer bullet, do something to just actually get into the doing side of things, how quickly they can come back to that childlike state. Whereas if you let them stay in that corporate state, it’s really easy to come up with a million reasons why “We can’t do that” or “We can’t try that” or “This isn’t viable” or “I don’t feel comfortable with that.” Where if you just push them off the ledge, they go, “Hey, that was fun. I want to do the ride again.” Llewellyn: One of my favorite quotes from Agile is “Don’t spend 15 minutes talking about something you can do in 10.” Derek: Right. Roy: Derek and I both volunteered with the First Lego League last year… Llewellyn: Ah, fantastic. First Lego League Learnings Roy: …helping out. I guess if you don’t know what First Lego League is, it’s a program where you have teams of…I think it’s 8 to 14‑year‑olds. Is that right? Derek: Yeah, 9 to 14. Roy: 9 to 14, who work together as a team to build a robot to perform a set of tasks that’s standardized across all the teams. Then they show up in a competition and compete against each other, and then they also have to build a research project around that. Llewellyn: This whole thing was actually implemented by the guy who did the Segway, and it’s a fantastic competition. If you have kids, I highly recommend it. Roy: One of the things that we noticed when we were working with the kids is we’d try to implement Scrum with them and at the very least start it out with having retrospectives with them every single time. We only met once a week, so we would have a retrospective every single day that they got together, so once a week. One of the things we noticed is, first off, they were a lot more open with their feelings and exactly what was bothering them than most of the adult teams that we’ve worked with. Llewellyn: [laughs] Roy: The other thing is that we ran into the exact same problems with kids as we ran into with adults. Llewellyn: Yeah, to a large extent people are people. Grown Ups and Kids, It’s All People Problems Derek: It’s amazing seeing the engineering camp challenges be almost identical between grown [laughs] teams and teams of 9 to 14‑year‑olds because at the end of the day most team problems are people problems. People don’t change a whole lot in their core behaviors from the time they’re nine to the time they’re 99 in most cases without a concentrated effort to try to improve. That definitely was a learning experience for us. We thought we needed a video series on, “This is you on Scrum when you were nine.” Llewellyn: [laughs] You also pointed out a really interesting part that I’ve seen emerge as part of a pattern of teaching, where you get them doing something and then you have that retrospective. Sometimes the retrospective is just so that they can see the patterns, that you need to do something two or three times before there is a pattern to detect. You need to get them engaged, and then you need to retrospect over it to see the pattern. Then, of course, as a teacher I think the job is to guide them to see patterns they haven’t noticed or explain patterns that they haven’t noticed once they’ve had a chance to have done it before. Derek: Absolutely. Probably the best example of that was this last year when we decided to put all of the challenges up on the board that they could potentially complete. We asked them to go estimate them from a 1 to a 10 how difficult they thought that those were and to do them as a team. So basically do planning poker. We didn’t explain what planning poker was. We didn’t explain anything about it other than just from a 1 to 10, how hard do you think it was? In about three minutes you had seven kids basically doing planning poker and pretty much being within one step of agreement of each other on almost every single challenge. I don’t think we’ve ever seen an adult team do that. I think as adults, what the problem is, we have no ability to believe in something anymore, so we have to question every little thing like, “Why are we using points instead of hours?” “I don’t feel comfortable about this.” Whereas a kid, they’ve never estimated anything really before. So to them it’s like saying, “How many pennies do you think are there in a jar?” They’ve got no problem throwing out some random number. If they’re wrong, they’re wrong. If they’re right, they’re right. Whereas in the corporate world, well, if I tell you that’s a three and then you’re going to calculate my velocity, then you’re going to give me a raise based on whether my velocity’s too high or too low, I’ve got all this baggage that makes me want to not actually give you an estimate. Llewellyn: And not engage. Derek: Right. Engagment Is Everything Llewellyn: This is the thing. You’ve got to engage first, and that’s why the first few iterations, of anytime I get a team together and we start iterating, are not indicative of how that team will perform. It’s after three or four sprints that some sort of stabilization occurs and jellied. Derek: Yeah, absolutely. So what are some other things you’re seeing out there that have your interest right now? Kids Pairing To Foster Collaboration Llewellyn: So talked about feedback, but I’ve found that if I get students to collaborate or pair, I think pairing is a very intense form of collaboration. It’s definitely not the only form, but it’s one that serves us very well, that they get a much better feedback cycle going. The environment for learning, there’s less control that’s inherent when two people work together. The control is already shaken. They’re more willing to just try stuff, and they are constantly giving feedback. One person’s seeing something, but the other person doesn’t see it. You just get this much better environment for learning, and I’m actually surprised. When you walk into a classroom, it’s a very quiet place normally, and I think that actually really hurts learning quite a lot. I see it in companies, too, where people don’t want to talk to each other. They just want to go into their own cubicle and work. While that might be good if you already know how to do something, I think it’s really bad for learning. Schools Seeing Open Workspaces As Enablers of Collaboration Derek: It’s funny that you say that. I think a lot of that’s modeled from the top. We’ve been doing a ton of work recently with school districts, principals within school districts, and superintendents of schools. We’ve got one school that we’re really partnering with on a regular basis, and we’re doing a lot of coaching and training of their staff on ways to be more agile in the classroom and be more twenty‑first‑century minded. After just a number of sessions, leading a number of sessions with their staff with their principal with them, their principal released. I’ll put it in the show notes. He wrote a diatribe that he said that after coming in our workspace and being here for a fair amount of time, that he thinks it’s almost criminal that he has an office at the school. He says, “When I go in there and I sit and I’m doing my email and I’m being productive, the thing that I’m really doing is I’m shutting out all my students and all of my staff from being able to have access to me and for me to really be effective.” So he’s actually looking to get rid of his office and start to work out of classrooms of the students so that he’s more available to his staff and to his students on a regular basis so that he’s there. I think that the important part from my aspect is talk about the power of leadership saying, “I think it’s important to be collaborative. I think it’s important that I’m making myself available and I’m doing that.” He even stated, “I’ve had open‑door policies ever since I’ve been an administrator both literally and physically. But people don’t come in and interrupt me because the fact that I’m in my office makes them think I’m not accessible.” Roy: Then he talks about, too, how he feels like he’s chained to his office and conjectures to imagine what students must feel being forced to sit in the same desk, shut up, and just pay attention the entire day but not be able to contribute to their own education. Joy In Learning Llewellyn: Which is horrible because again, once you start engaging and you start looking at it, that’s joyful. Learning in general is a joyful activity. Just to go into this idea of feedback and collaboration. Another concept that we’re seeing a lot, which is layering, which is you don’t learn everything at once. You build. You layer learning on learning. That’s how you gain skill. One of the places that I think is doing this better than any other area in the world right now is video games. If you look at a lot of video games, there are a lot less instructions. The tutorial is becoming the game, and you’re getting amazing feedback in these nice little layerings. Through that and interaction you’re learning pieces of the game. There are some really nice examples out there right now. Portal springs to mind, a really good one. Also, there’s a game called Limbo. Both of them are teaching you something with a very interesting model of instruction. Derek: Absolutely. So we’re at our time. Any final words or parting thoughts before we head off? Llewellyn: The first is go and teach your kids to program because it’s really on you to do it. There are a lot of neat resources out there. I know you guys run great stuff out there. Chandler, if you’re online, we have more structured courseware at TeachingKidsProgramming.org. Even if you do no courseware, just sit down with your kids and program with them, it’ll open whole new doors and worlds for them. Derek: Absolutely. Thanks for joining us, Llewellyn, and we’ll see you in a later episode. Llewellyn: Thanks. Derek: OK.

Jade Meskill: Hello and welcome to another episode of The Scrum Cast. I’m Jade Meskill. Roy vandeWater: I’m Roy vandeWater. Perry Reinert: I’m Perry Reinert. Alan Dayley: I’m Alan Dayley. Corporate Cultures Jade: Today, we wanted to talk a little bit about corporate cultures. To get it started off, do you guys think that there is a particular type of corporate culture that is more naturally inclined to be Agile? Roy: Yeah, absolutely, there is. Any kind of culture that really embraces change is one that’s definitely more Agile, more likely to be good at Agile. There are different cultures where, I’ve been in companies where there definitely is more of an inertia that is against change. I’m also in companies where it’s, “Let’s make changes. Let’s make changes,” and it’s through the company. It’s at all levels, and all different departments. “Make the change and see what happens. Make the change and see what happens.” That’s a good thing. Radical Candor Alan: I think cultures that don’t have a stigma against talking back to your superiors, that’s not quite the way I want to put it, but the idea of the people in charge are open to input. Not just open, but constantly asking for input from the people that are beneath them. I would even say that the flatter culture is the more everybody feels comfortable to add to the entire organization that that would help Agile adoption, and the organization would be Agile a lot, I think. Perry: There are certain managers who, in my experience, naturally, or they’ve learned to allow, usually it’s individuals because they haven’t thought about it on a team level yet, but they allow people to self‑manage, or self‑organize as it were, in the Agile sense. Cultures and managers, or departments that have people in charge that have already allowed the people that work around them, and with them to make choices and take risks. Those are the types of cultures that will accept Agile. Or just look at it and go, “Hey, somebody codified what we already do.” Ability To Fail / Response To Failure Roy: Kind of to build on top of that, I think failure, and being able to fail, that’s a big thing. I’ve been in companies where the president or CEO stands up and says “Hey, I screwed this up. I made a mistake, we did the wrong thing. We learned from it, and let’s move on.” I think that attitude coming from the top really makes a big difference. Everybody sees that it’s OK to fail then. Jade: I’m really glad you brought that up, because it’s not just a willingness to change, right? It’s, how do you respond when things don’t go according to plan? Roy: Yeah. Perry: Yeah. Jade: What do you think leads organizations down that path? What has happened in that organization that has put them in a place where maybe they’re tolerant of risk, accepting of failure, and they’re willing to embrace change? What has happened in that organizations development that has put them in that position? [microphone bump] The Right People To Start Roy: Perry is pointing at me, but I don’t have an answer to that question. I have encountered companies that are that way. I have encountered companies that are the opposite, if you would call it an opposite. They’re a different flavor that doesn’t allow failure, or is not a safe place to fail. I haven’t seen a company change or been in a company when it’s changing that drastically, to know exactly, or be able to point out an instance, when that changed. The only one I can think of is when there was complete change of management in a department one time. The managers that came in were considered a little more radical. But it wasn’t instantaneous. It took six or eight months before some kind of new thought around failure, and being allowed to try new things, happened. Alan: I think a large part of it comes down to having the right people, especially to initially get a kick‑off. If you have already got an Agile organization, and somebody comes in that doesn’t necessarily fit in with the culture, it’s not as a big of a deal to indoctrinate them. If you’re in an organization that has the wrong culture now, and you’re trying to transform the culture, I almost feel like you have to have the right people. In fact, the transformations that I’ve seen, nearly all of them, there has been significant turnover as the wrong people left the organization, so that the organization could transform the way they wanted to. Roy: Yes, I’ve seen that also. Stagnant and Compliant Cultures Perry: Yeah, I really believe, again, from the kind of leaders, on down and how they handle things, and that’s kind of what starts it. I think, having leaders that are either seen the success of making rapid changes and rapid corrections, failing fast and making those rapid corrections, or also seen the failures from not making changes. Being sort of stagnant and you can end up failing that way also and that can be a big impact on the leadership. Alan: Do you mind if I take this, Jade, in a little bit different direction because the subtle thing I’ve noticed recently about culture… Jade: Yeah, go for it. Alan: There was a company I was visiting with last week that their culture compared to many companies is good and the bosses are nice guys. The managers do well and they help their employees and they smile, and all that. The culture at this particular company is that of the managers telling people what to do. They tell in a nice way and a kind way, but as they sit the employee down, and they say, “Here’s what’s going to happen and here’s what we’re going to do. Do you have any objections?” I noticed that creates a kind of culture of compliance. Nobody is unhappy and they won’t say they’re unhappy, but the employees are not taking risks because they expect to be told what to do. When they’re told what to do, it’s presented in such a way that the decision has already been made. I think this is a subtle culture that is hard to describe to people the negativities of it. I wonder if anybody else has seen that sort of thing and how do you point that out to people? Perry: Yeah, I’ve seen that on all sorts of different levels. You’re right, when you’re telling people what to do, what that really does is that, just tells them that they don’t have to think about it. They don’t have to think about the problem or what to do. You end up losing a lot that way because, there are a lot of smart creative people out there that think of things, and think of the ways to do things that are different than just you. If you’re not taking advantage of that and providing that freedom for those people to think that opportunity for those people to think, by just telling them what to do, you’re missing out. Guilt Trip Management Alan: I’ve also seen in kind of a similar way, where the management says that they’re open to criticism or open to new ideas but then, the people that work for the organization are almost guilt‑tripped into choosing what management wants anyway. The choices are presented and you get an illusion of choices, but then there’s an obvious right answer and if you pick anything other than one of those three options, it doesn’t feel that you have more than three options and there’s only one right answer and those three options. I’ve seen that happen in the past. I don’t know if that still works. If the developers still get a choice or if they consciously or subconsciously see right through that and if that really hurts them, I don’t know. Jade: What are risks to the teams in a culture like that? Alan: The Company that I’ve been thinking about is normally always doing Scrum and what they end up with is this ritual that doesn’t really have too much meaning. They do the retrospective and they talk about the little things that can be changed, but not big things because they’re waiting for the boss to tell them, what the big things are and they plan things that are safe. They know exactly what the boss has told them through the product owner and maybe just the boss directly, what they should be working on and how they should create it. They just plan it as if they’re going to do it the way they’re told and they don’t interject any contrarian ideas in the planning, etc. It becomes very flat. Perry: I think, what problem we get with that is that you’ve a bunch of mindless drones that are working. You lose a ton of creativity and innovation because really you have one in that situation where everybody listens to the boss and then the boss comes up with all the ideas. You have one creative person within the entire organization and there is no way, no matter how creative that person is, that he is ever going to be able to be even close to the sum of how creative an entire organization could be, if everybody was allowed to add their own experiences and add their own unique viewpoints and ideas to whatever the product is. Roy: Eventually, they’ll self‑select. Your team will become the ones that are willing to follow and the ones that want to lead, want to try something new and stuff. They will find other places to go. The Joy Of Being Surprised Alan: Yeah, I agree with all that especially the lack of innovation. I think you get less ownership, too, from the people that are working on that, whatever it is, less ownership. You kind of teach yourself out of the joy of being surprised when somebody overachieves and comes up with something great that you hadn’t thought of. Roy: “The joy of being surprised,” I like that. Alan: Yeah. Getting Over Mediocre Jade: Let’s imagine that you’ve been brought in by somebody in this organization, who has realized that this is going on, but not the top leadership, how would you approach this with them? Because they’re nice guys, they’re doing a good job, they’re treating their people well, what are you going to do? Roy: Not the top leadership, but sort of the mid‑level leadership? Jade: A second level manager has noticed that this is going on. Alan: That sounds like that’s really tough, especially, when the entire organization thinks it’s a good thing and everybody thinks they’re as happy as they could be. That makes it really difficult to convince anybody that there is anything wrong especially like introducing change and having to see their CEO or whoever is at the top to try to convince him to start listening to the input is going to be hard on him, and why would he do that because he is happy as it is? There’s a lot of benefit for the business as a whole and for all of the employees, but I think it’s going to be very difficult to justify that to somebody who has never seen the effect of that type of culture in person. I would try to maybe see if you can integrate that CEO, or whoever the bottleneck, is into a culture that houses open quality and show off the benefits and show what’s possible when you allow that type of stuff to happen. Perry: I would seek out experiential ways to show the benefits. I am trying to think of specific ones, but there are certain different Agile games, innovation games, etc., that even the playing field and create a situation where people who usually don’t talk or usually don’t introduce creative ideas are allowed that space to do so. Including, perhaps, doing some things that are just with the team members and not with management to try and create some safe environments to let some of the creativity blossom. I’d have to go where I can look at some of those ideas, but I know they exist. I always remember the first retrospective I did with a team where we did the dot voting at the end where the most outspoken member of the team waited to the very end to do his votes. He went up to the board and he said, “I don’t have enough votes to make it go to the way I want.” That was a radical change to the team because suddenly the rest of the members realized they had a voice, and they had a way to start speaking up and they could say things, and this dominating player didn’t have the ability to dominate in that situation. Roy: I agree with all that, just more education, lots of reading material about this, self‑organizing teams, letting the team make decisions and seeing it done, going and visiting other teams, and watching how they work is absolutely a good thing. Root Cause Of Stagnant Culture Jade: What do you think is the root cause of a behavior like that? Roy: I think, the root causes could be just coming from an organization that worked that way where you were expected to be that guy. You don’t have a team and you’re the guy who has to solve everything and so you solve that. As the people grow and the team grows, you still solve things and just tell them how to do it. The traditional project management model is certainly much closer to that approach than the Agile approach. Perry: In smaller companies, this is kind of a natural thing where you have a three to five person company that has grown a lot within a year and, say, they have doubled the number of people. As those new people come on, they look to the people that were there, as they answer people and that can stick. I am not sure how it creates in a large company, how you would have a department or a team or a group of teams that has these sorts of ideas. It could be the managerial breeding that you guys had at Scrum Cast recently about how we tend to hire people who think the same way we do. If you think that you should tell people what to do, you’re going to hire people that think they should listen to what you say to do, and you can grow a whole company that way probably. Rescuing Feels Good Alan: It feels good to be that person who is the one who rescues everybody. He’s almost got that martyr syndrome where it feels good to be the guy that saves the entire team every time. As soon as somebody else starts stealing your thunder, like as the boss, I could see how it would be really tempting to throw him out like “No, that’s mine. I get to save this organization. You get to be saved. That is your privilege.” Jade: Does that mean there’s only one superman on this team? Perry: That’s right. Jade: All right, guys. Well, thanks a lot for joining us, and we will catch you next time. Perry: All right. Alan: Great, thanks.

Clayton Lengel‑Zigich: Welcome to another episode of the ScrumCast. I’m Clayton Lengel‑Zigich. Jade Meskill: I’m Jade Meskill. Roy vandeWater: I’m still Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. **Jade:** So like Still Water… [laughter] Jade: …is like because you’re European…What you? Roy: We’ll mix up the verbs and other things. Digital vs Physical Boards Clayton: Quite, you’re so European, you don’t even know, to get the things up. Today we’re going to be talking about Digital Boards and Physical Boards. Let’s say that I’ve got a digital tool and has my Scrum board in it. And I’ve a physical collocated team, is that going to be problem or can never just look at a computer screen. You’re Brain Works Differently Derek: Certainly, everybody could. The question is what are the benefits of a Physical Board versus Digital Board. Andy Hunt’s “Pragmatic Thinking and Learning” is a great book that talks about some of the brain science behind physically writing things down versus typing them into a computer, or versus seeing them on a computer. It cements something different in your memory. I like to equate this to when I see great schoolchildren or even college students, being asked to memorize vocabulary words or terminology. Usually the teacher requests that they write them down, write them in a sentence, write the definition down. Then they memorize from there. They don’t just give them a printed sheet and say, “Go read the printed sheet and memorize it.” It’s because something in our brain is wired differently when we actually do the act of writing things out. When you’re forced to write out the story or write out the sprint items or the tasks, I think that something wired different in your brain happens. The second thing is, nobody goes to their computer to look at all that stuff. When there’s big visible charts all over the walls, it’s much easier for somebody not involved directly in the project, or somebody on the outside, to ask questions. They’re not going to go look at the chart in some digital tool eight things deep, find something out, and then send an email, or not very often. Usually it’s too late. If they’re getting to the point where they know something is that wrong and they’re looking at the tool, it’s probably too late to help. Difficult To Hide A Physical Board Jade: If you are physically collocated team, it’s much more difficult to hide from a physical board that has a presence in the room that you’re in, where it’s very easy to minimize a window and just essentially ignore everything that’s going on inside of the software system. Roy: We’ve even seen examples where we would send emails of our burndown chart for example to everybody within the company or post a picture of it in the chat program we use, and still nobody really commented on it or noticed it even though it was being hand‑delivered to you saying look at me, it still didn’t really have the same effect as to something you occupy every day. Jade: I saw a really interesting study that really talked about the brain and how when you move from room to room, that the doorway actually creates some physical barrier inside of your mind and that when you walk into a new room, it basically forgets everything about the old room. ref: Forget Why You Walked In The Room? I started thinking, “Does that apply to windows in our applications”? Like when you minimized that window, does your mind like basically shift gears into, “Well, now I’m doing something new and I’m in a new room. I can disregard all the other stuff.” Face To Face Conversations Clayton: What are some of the other benefits that you would get if you were a physical team having a physical board? Does that help promote collaboration or communication? What are some things you would get from that? Jade: I think it’s a lot like having a face‑to‑face to conversation. There’re a lot of things that are communicated without words, and by placing it up in a physical dimension, you can tell so much more out of glance than looking at your screen which can only convey so much information and so much detail, just due to its limited size. You can get away with a whole lot more. You can have a lot of more informal statistics or data that becomes very difficult for a computer to calculate. If I want to write something up on the board, I can just do it. I don’t need a special place to put it or if I want to post something new that we’ve never tried before, I don’t need a code to let me do that. I can do it with a piece of paper. Derek: Some of it goes towards…if you’re really trying to be agile, you want to be locked into some best practice? That starts to… Jade: Or at least a practice. [laughs] Open Possibilities Instead Of Fighting Tools Derek: Yes, that starts to cramp. A good example on build now on what Jade said is, “The nice thing about blank index card is it’s a blank index card,” so anything your mind can imagine to do with and index card, from shredding it up to adding new elements to doing anything, is possible. Whether you want to use pushpins with different colors to meant different thing, if you want to use different colors with a type of marker, the sky is the limit. So if you want to try something, a great example I’ve seen our teams do in the past on occasion is, “Hey, we really want to enforce time boxing. We want to see how we’re performing against tasks, because a lot of people are questioning that. It’s as easy as drawing, if we think this is going to be a hour long task drawing one square for each one of the tasks, and then filling it in as it’s getting completed.” That would be really difficult to do in a tool that didn’t have that functionality already built into it. The nice thing is, you can experiment with that. If that works really well, great. Maybe you keep doing it. If it doesn’t work well, or you get the data that you need to make the decision, I think in a lot of the cases I’ve seen a team think, “Oh, well the problem is our tasking is really, really horrible. It’s taking us way longer than we think to do the task.” When they do something like that, they realize it’s not that the tasks that we are putting out there are taking too long it’s that we’re doing really crappy planning. We are not putting out half of the tasks that actually need to be done to complete the work. We put task A is going to be half an hour, and task B is going to be half an hour. We find that it really only took half an hour to do each one of those tasks. But we totally glossed over the fact that there were tasks C, D, E, F, G, H that we just totally didn’t even talk about in planning. In reality, we need to fix our planning, not fix the estimates of our tasking. It allows you to play with things in a lot more easy format without having to fight against the…you never hear, “Well the index cards don’t do that.” Jade: [laughs] Roy: Right. Tedious To Update Physical Board Clayton: To play devil’s advocate a bit, I’ll ask, “Doesn’t it take a really long to update your physical board”? Everybody: Right. Everybody… Clayton: Yes, it does. Is that what you are saying? Jade: Doesn’t it take a really long time to update your digital board? Four Reasons People Replace Physical with Digital 1. Too Much Overhead 2. Saving The Trees Roy: Every Agile team at some point, it seems like, gets into the, “OK. We need to start replacing the physical tools with digital tools.” I feel like they always have four big reasons for doing that. The first as I say, it’s way too much overhead to update a real board; which I think is kind of bullshit, because it doesn’t take any less work in my opinion, than filling out a digital tool. And it gets you a lot of value. Another reason why they oftentimes want to go with digital as opposed to a physical board is because they say they want to save paper, which I think is just bullshit altogether. [laughter] Derek: You’re European, so it makes sense. 3. We Are Distributed Roy: The third reason is because they are a distributed team, which I think is the only reason that I can come up with that has any validity at all. The fourth reason ‑‑ I forget at the moment, but I’ll jump in a second with it. 4. Save Historical Data Clayton: Oh, I have another one. I would use a physical board, but I need to keep track of everything we’ve done, because what if I need to look at it again later? If I have a digital tool, it will save it all for me. Roy: Yeah. So, you’re never going to need that data. Clayton: Yeah, but I really, really do. Roy: No, but you really won’t. Jade: When you need it, you can write it down on the index. Derek: I think a lot of this goes back to… [crosstalk] Jade: You can save all the cards. Trying For Accountability Derek: …a lot of teams still have project manager mentality. The idea is, “I need to track tasks and I need to track who is doing the tasks. I need to track the actual hours against the tasks. I need to track all this data because at some point I need to hold somebody accountable.” The truth is, if your team is doing that, you’ve got way bigger problems than for using a physical board, or using a digital board. That’s because you don’t trust your team, and you don’t believe the team’s going to do the best decisions. The teams that want that information so that they can actually improve don’t have a problem collecting that data. I know that we’ve thrown together spreadsheets on several teams where it’s like, “Let’s collect the data for two weeks and find out what’s really going on.” Then make an adjustment and collect another two weeks. But very rarely you need to collect that data long term. I think that it’s one of the classic be careful what you measure. If you’re concerned about measuring the number of hours of tasks, and who is doing what, well that’s what you’re going to get. You’re going to get people that try to game the system, so that they don’t look like dumb asses for the number of tasks. If you’re actually trying to deliver software of value, make that be what matters. [crosstalk] Jade: Measure lines of code. Derek: Make that be what gets measured. [laughter] Derek: Function points are my personal favorite. Some of that goes back to…that’s more of a management thing usually, than a team thing. Or if it’s a team thing, it’s because somebody is definitely afraid that they’re kicking ass, and that they’re not getting credit for kicking ass, which I also think is an entirely big smell. That you’re not a team player if you’re only worried for getting credit for the work that you’re doing, and you’re not actually worried about delivering the best product and making it the best. Jade: That or you know that Clayton’s doing a terrible job and you just want to expose it. That’s how you’re trying to come up with that. Roy: Leaving your paper trail so you can fire him. Who Decides Physical or Digital Clayton: Let’s say I’m a development manager, and my team comes to me. I have this Scrum team or whatever. They come to me and they say, “We’re using this digital tool now, but we’ve all talked about it. We listen to the really awesome podcasts. And we decided that we want to have a physical board.” Roy: Is there a podcast out there that talks about this? [laughter] Jade: Yeah, we’ll send you the URL later. Clayton: Is that something the team can decide? Should I let the team do that? Or should I just jump out the window and give up? Those are the two choices. Jade: If I was a development manager… [laughter] Roy: What’s the title again? Derek: If it’s got the word “manager” or “management” in it, you should just jump out of the window now. And yes, I’m kidding to all those people that are managers. Jade: Should we let the team do it? I think if you truly believe in self‑organization, then, yeah, you should let the team do it because that’s their work. I think you have a reasonable expectation to get the information that you need to do your job to report to the people above you and stakeholders and all that stuff, so that information should be delivered to you however you need it. But when it comes to the team performing their own work and managing their own work, that is the team’s realm of responsibility, and they should be fully able to do it however they would like whether that’s a digital or a physical tool. I don’t think it’s management’s role to dictate that solution. Clayton: What are some instances…You hinted at Roy, but what are some instances where maybe we would want to use some digital tool? Maybe we want a physical board, but we think we need a digital one. Roy: The one that I brought up was a distributed team. That one I would say, “Why distributed”? But if you really have to be distributed, then you have to have some way of keeping track of everything, and I haven’t found a better way than a digital tool, but as soon as I do, I’m jumping off the… Jade: [laughs] Teleportation. Derek: I think anytime you got a lot of cash to burn and you want a bunch of licensing fees is a good time to… Jade: Yeah, if you really like that tool vendor [laughs] . [laughter] Jade: I think a distributed team is definitely a situation where a physical board does not work. We’ve tried it many times being distributed ourselves to try to manage a physical board, and at some point, it completely falls apart. Roy: It was a physical implementation of a digital tool because it would be, one person would maintain a physical board and take a picture of it and send it to everybody else. Jade: Which was just insanity. It was… [crosstalk] Roy: …writing an intelligible digital tool that you couldn’t update immediately. Jade: Yeah, it wasn’t providing value. What About Reporting Up Derek: Another valid reason for it ‑‑ and I would say that this should be a short‑term reason only ‑‑ is if you are in probably a larger company whereby you are a pilot or one of the few teams in an agile organization and you still have reporting structures that are requiring some of the data that you might need digitally. Now in those instances, I would really recommend to go ahead and let people use a physical board and then actually key the information that you need for whatever roll up reporting you need for your manager. But I would say that in that case, it would be worth double keying that information to allow the team the benefits of a physical board. But I could see somebody saying, “It’s just not worth a waste of doing it in paper and keying it in.” I’d say, “I don’t think you understand the benefits well enough,” but if you really believe that, I think that that is another reason. If you have to report some of the upstream until you can convince them otherwise, that might be a reason why you would see that. Roy: Another reason too in that exact same situation ‑‑ why you would want to double key the information? ‑‑ is nothing starts conversation as well as a board. I can’t tell you how many times I’ve been sitting around here at Gangplank and then somebody comes up and asked me, “What’s the deal with all these cards”? Even people that normally wouldn’t ask questions of anybody else. Jade: We’ve seen that in client’s sides too. The CEO or some executive VP walks by and says, “Oh, what’s going on? What do these charts mean”? And you can start to have a real conversation. Card Man Brings The Serendipity Out Derek: Absolutely. One of my favorite stories along this line is, we implemented cards, and I was sitting more where the executives were not necessarily where the team was, so the team had decided to put the board in that hallway, which I thought was bad for the team, but I thought it was good because it got a lot of management highlight. I had one of the members that wasn’t on our team ‑‑ she’s not part of the development at all ‑‑ walk by, and she’d called me “card man.” We joked and laughed. She said, “Even though I’m teasing you, I’m serious. I really liked it.” She showed me cards that were for…The output of the software directly affected her department. It was the tool they used. She said, “Right here, it says this, but it’s missing one. Do you know when they’re going to do that”? I said, “Well, they chose to not do that this sprint.” She said, “Well, why not”? She actually got really upset like, “That’s the most important thing, and it’s not even on there.” She was able to go back to that development manager and say, “Hey, how come your team didn’t do this”? They gotten to a lengthy discussion, and it brought out all sorts of things about the inefficiency of the particular tool. She would have never done that if they were using a spreadsheet or some tool because she wouldn’t have ever known that it even existed. That it’s those serendipitous moments that we don’t even really talked about very much that sometimes provide the most amount of value by having things out in the open and able for feedback from anybody. But Im On a Distributed Team Jade: What do you do if you’re a distributed team? Roy: Cry [laughs] . Clayton: Also jump out of the window is an option. Jade: Jump out the window. Yeah, OK. So I’ve cried. I’ve jumped out the window. And they brought me back from the dead for this project [laughs] . What do you do to try to get the advantages of a physical board and a distributed world? Roy: One thing that I’ve tried in the past is to use an online spreadsheet tool, like Google Spreadsheets, because it gives you a lot of flexibility while still maintaining somewhat a structure. Although, I found that that works great for two weeks, and then it starts to get really disorganized as we try to make the same types of adaptation that look perfectly organized on the index card, but it starts to look very messy on a spreadsheet. Derek: For me the problem is that you’ve got a much bigger problem than your board once you get distributed. I think that not being within proximity of other people is a much larger problem when you’re distributed than whether it’s physical or digital boards. I’d say the first thing I would do is try to do everything humanly possible to simulate being collocated even though you’re distributed, whether that be Skype, whether it be pair programming, whether it be some kind of online instant messenger app, anything that promotes a lot of communication that is asynchronous and can simulate real being in a physical presence to someone. I would really stress that that’s probably the most important. Once you have that, I think then you can start to add ways to say, “Hey, maybe every so often, we’re going to post the current burn down, or we’re going to do something, or maybe we’d add another stand up or something.” I think there’s ways you can start to say, “How do we incorporate what we’re putting in a digital tool into the conversation”? But most distributed teams just don’t even have the conversation, which is, I think, absolutely critical to have. Making A Board Better Clayton: To wrap up, can we go around and get one thing that you think will make the most of your physical board, something that will make it better than it could be on its own? Meaningful Colors Jade: Colors. Big Visible Charts Derek: For me, the biggest one is big, visible charts. Jade: I should say “meaningful colors,” not just random rainbow. Visual Details and Overviews Roy: What I’ve seen help a lot was Derek’s example, where you show your time box by indicating the black boxes for you’re still using your time box. For every 15 minute increment, you draw a square. As you exceed your time box, you start drawing red ones. It becomes very easy to see. At an overview, you can see an entire board. You can see where sections are red and where sections are green. It becomes very easy to see which stories cause the most problems throughout that week, and which ones went a lot faster than expected. Collapsing Board In Real Time Clayton: For me, I would say updating the board in real time and collapsing things. You collapse all your tasks that you’ve completed down so that over time, as you’re passing by, in your subconscious you can look at the board. It looks different. It starts looking smaller, and it looks like things are going away. Derek: I think that’s a really powerful one. Jade: That’s good. Clayton: Thanks guys.

MISSING CONTENT Clayton Lengel-Zigich, Derek Neighbors, Drew LeSueur and Roy van de Water discuss story sizes, naming your sprints and partial credit:  20, 40, 100 story point sizes  Less accurate as they get bigger  Naming your sprints  Rally point for deliverables  Historical data  Sprint goals  Partial credit for points  Does story size matter  Symptom of a deeper problem  Too focused on velocity  Paycheck advances  The defect board as a debt collector The post Episode #44 – Story Sizes, Named Sprints and Partial Credit appeared first on Integrum.

**Roy: vandeWater:** Hello and welcome to another ScrumCast. I’m Roy: vandeWater. Alan Dayley: I’m Alan Dayley. Derek Neighbors: I’m Derek Neighbors. Perry Reinert: And I’m Perry Reinert. Jade Meskill: And I’m Jade Meskill. Roy:: I would like to welcome you to a special edition of the ScrumCast. About 12 months ago, we all got together and came up with several predictions on what we felt were going to happen throughout the year, with regards to Scrum and Agile. We’d like to take a moment, real quick, to reflect on our predictions of last year and see how well that went, and then also make some new predictions for the upcoming year. Alan, you made several predictions last year? What you felt really happened and didn’t happen? Losing Labels, Community Conflict Alan: I thought the most promising thing was to start losing the labels around the different frameworks, and I saw a movement happening in that regard. I think that was a pretty safe prediction. It’s happening. My secondary one, on community, I also predicted there was going to be some conflict around that movement. In my opinion, at least on the email lists and other places where conflict seems to grow, those sorts of things aren’t happening. We’ve got some people who are adamant about losing the labels and mixing and matching different parts of different frameworks. They’re very upset when somebody says, “No, we need to do Scrum or we need to do Kanban or whatever it is.” I think those are pretty safe predictions. They did happen, and they continue to happen. Winners or losers, I failed implementations. I have a client right now in fact, that is doing really well, or was doing fairly well on their own, but told me, “No, we don’t need you,” and then several months later said, “Yeah, would you come help us”? I think that’s happening a lot. Roy:: Perry? Legalism and Frameworks Perry: Yeah, I definitely, I was jumped onboard with Alan on the verbiage. I think we had, my notes show legalism and frameworks. That’s the sort of getting spun‑up on the details versus the real concepts around Agile. We’re definitely making progress. As it grows up, as we get more mature, as more people actually really understand Agile instead of just, “Read the book and try to follow the recipe,” then they’re in a better position to adapt the real principles to what they need to do. I think we’re still making progress there. I also had around community predicted changes in certification. I think we’ve definitely had changes around certifications. We’ve seen the spring up of IC Agile, Scrum Alliance has made some changes, just for example, the CSP has changed from the 10‑page form to that’s now an exam. I think we’re going to continue to see changes in there also. Winners and losers, I had developers who would continue to win in the Agile world. I think there’s no progress in there, but I’m really feeling like that’s still the next big thing to trying not to get into future predictions now. I think we made progress, there’s more progress there. New things, I said exploring lean principles in usability. The lean principles definitely, all of those Agile practices and principles I think are coming together as we mature and usability is still a big thing. I would have liked to have seen even more progress there, but I think we’re making steady progress in those areas. Roy:: Derek, how did your predictions and the beyond? Revolt Against Process, Coaches Derek: I think my first prediction was getting back to the roots of the manifesto not being quite so process focused, and I failed that one miserably. I think I’m about three years ahead of the curve on it. I suspect, in about two years, we’ll actually get there. I think step one Alan and Perry got right on, and that’s now everybody’s just bitching and fighting about which process is the right one. I think ultimately they’ll come to find that it’s really about the routes of the manifesto, and the processes that we use don’t really mean shit when it comes down to it. They’re just tools to implement the bigger things. I think I failed on that one because it was a little too early. On powershifting away from trainers back to coaches, I think that’s starting to happen a little bit. I didn’t accelerate quite as much as I thought, but Scrum coach retreat certainly saw a number of CSTs that are now doing a lot more coaching engagements instead of training. They’re not feeling as fulfilled doing the training, they understand that they’re not seeing the lasting change in organizations when they just come in and train, and there’s not coaching there. I think that’s starting to play out a little bit last year and I think we’ll see a little more of it this year. Winners and losers, I said everyone loses if we don’t have people challenge how we currently do things. I think that we started to have people challenge it. Right now, they’re challenging it by saying, “My framework’s better than your framework, ha‑ha‑ha, I challenge you to prove me otherwise.” That’s starting to unearth deeper and deeper issues with like the Stoos gathering to just recently happened. I granted that was this year, I guess earlier this year. Before we recorded this, they are trying to challenge some of management smother things that are going a little bit deeper then process. I think that there is some challenging happening. Roy:: Jade, how about your predictions? Worldwide Growth, Bottom Up Adoption Jade: I said that there would be a lot of growth of agile outsie of the United States and that is certainly happening. One of the things I personally missed was, I talked about inspiring a lot of bottom up adaption of agile. For me, personally, I have actually been working a lot more with executive teams on top down adoption of agile. That’s quite an interesting thing. [laughter] Productive Conflict Roy:: Alan, you said last year you were planning on working harder to train, encourage and train productive conflict. How do you feel that went for you throughout the year? Alan: I do not think it did very well. The team I had in mind to do that with was disbanded shortly after that podcast and I have to admit that I lost focus on that. It’s an interesting conundrum how to tell people that the conflict is good if you to do it the right way you do it with trust. I just don’t feel like I either haven’t focused on that, or I haven’t felt like I have been on the situation, to focus on that as the hard problem that the team has. The teams that I am working with now have the hard problem of portfolio prioritization and how to get backlog right. We seem to be spending a lot of time with that and I am not sure that I have had the opportunity to do that but that maybe an excuse. Applying Lean Principles Roy:: Perry, you had said that you are going to explore and practice some different lean principles into your work and try to do a very good job to understand the customer and increase its ability. Perry: Lean principles not so much other than just touting, [inaudible 07:45] , and maintaining. The team needs to be aware when stories are backing up and they are completed but not releasable types we have harped on it. Now, what I really want to do there, the usability we have made some progress. It’s more around how do you get from product management having ideas of what to do and understanding, and how to figure out what the customer really wants. We call them the target benefits and what those are. We’ve definitely made tons of progress in that. Roy:: Derek, you said you tried to get teams to value relationships in humanist and encourage creativity by looking bigger than the product. Agile In Education Derek: I think the first one happened on a scale larger than I could ever imagine but not in the way that happened. That was within our own Integrum team. We made a significant radical shift in our team size and what we value as a team. I am on the most human team I have ever worked with, the most transparent and vulnerable group of consultants and I am really proud of that. But that’s not what I meant when I said that. I was actually talking about targeting external teams. I guess being your own dog food is a good thing. Now we know what is involved in some of that and what happens when you get really real. Encouraging creativity by looking outside the product, we are starting to do that and looking to start an engagement that is looking to do this in a fairly radical way. If that works, hopefully next year I would be able to talk about some of the success we had with that. We are doing quite a bit work with education. Work outside of the software industry altogether where the product is actually somebody’s education. It came through seventh or eighth grader and that excites me to be thinking about it in that way. Bottom Up Agile Adoption Roy:: Jade, you said that you try to inspire bottom‑up adaption of agile. Jade: Like I said earlier, because of the shift in the way that Integrum has changed, I ended up actually working with more executive teams, talking about how to make not only their development teams more agile, but the executive teams themselves. Roy:: Awesome. Looking at the upcoming years, what do you guys feel is the most promising thing that is going to happen in 2012? Principles Over Process, Failed Agile Derek: To me, I think a most promising thing is that I think we’ll see more early adopters of agile, realizing that just implementing agile processes didn’t have the results that they really wanted. They had short‑term results, but not the long‑term results they wanted, and that they start to dig deeper to go into the actual principles beyond the process. I think that we’re just going to start seeing that scratch the surface that you’re going to see some companies start to potentially make some significant change outside of process around agile. Leadership Jade: To jump on that bandwagon, I think this is the year of leadership. This is the year that people are really going to start paying attention to how they are leading their teams and how they can lead their teams and their companies well. I don’t think we’re going to make a whole lot of progress during this year, but I think the awareness is really going to bubble to the surface. Creative Workplaces Perry: I see something that perhaps can be tagged as a negative, but I find it promising. There’s a shift, a tide, that’s coming for us. Particularly, I’m thinking of companies in the United States. There’s a lot of companies that continue to work the way it was state of the art in 1970 or 1960, with mentalities about factory workers, et cetera, even though they’re doing creative things, or attempting to do creative things. That has worked for a long time. For several decades, anyway. There’s a lot of things happening in the world that is going to, I think, surprise some companies and shock them. Hopefully, the positive spin to this is that, I think, some people who are not willing to look at agile, or haven’t been willing to look at agile and some of those principles, whether they call it agile or not, they’re going to start looking and thinking about how to create some creative environments for their people to work in as opposed to factories. More Training Alan: I’m not sure if this is what I think is going to happen or just more of a hope, but I’m still back on the training and the education. I see the changes that are coming. I’ve seen Scrum Alliance make changes, the ICAgile outline for additional…I think it’s just deeper training. I think that’s the key, because, like last year, I felt like all we really had was CSMs and CSP. Now I’m starting to see a lot more training. Integrum is doing trainings on release plannings. I’m seeing those very specific, real, just‑in‑time targeted, and I just want to say real ‑‑ again, real training, and that’s where I think the community as a whole will actually benefit from that type of training. Roy:: Speaking of community, how do you think that the agile community will be changing, or what do you think is going to happen within the agile community throughout the next year? Fractured Community Derek: I think it’s going to get more fractured and more tense, at least in the beginning part of the year, and, I suspect, it’ll go throughout. You’ve got three or four different organizations trying to do certification, you’ve got the “my process is bigger than your process,” and everything in between. I think that’s going to heat up and come to a boil before the good stuff comes. I think you’re going to see more of the “choose your allegiance, choose your side, we’re going to war,” David Anderson and Kanban versus [inaudible 14:23] and eXtreme Programming XP, Scrum Alliance, Mike Cohn, whoever, doing their throwdown. I think, overall, most of those guys know that it’s about the deeper principles, but they’ve got empires to, somewhat, protect, so it’s difficult to let some of that go and not be steadfast about your beliefs. I think that it’s going to take a while to shed some of that. Perry: On that, though, because there’s that competition, it will blow up, but they’re trying to leap‑frog each other a little bit. These trainings, I think, are going to be trying to outdo themselves ‑‑ I’m hoping. It may not be this year, but I think that’ll be a good thing, all of that turmoil. Alan: The other shoe, or the other side to that coin, I see a lot of discussion with some people, at least, that I think are leaders in the agile community, not necessarily those that have a vested interest in one framework or another, are coming to realize that the training that’s specific to a framework, or the training that’s just generic, doesn’t always fit. I had a recent discussion online with a gentleman in Europe. He writes a lot of interesting things about agile and some of the things that we live by, but he goes and he researches, finds the source, and discovers that they’re myths. That’s not to break down agile or to tear it down, but he’s trying to create reality around it. We’ve had discussions that point out things like there are literally 100,000, how many there are, CSMs out there, the vast majority of them probably should not have been trained as CSM. They probably should have been trained with CSPO product owner, or they should have been trained as developers, or whatever. The CSM was the generic stamp of agile. Derek: To point to some of those numbers, I was looking the other day ‑‑ they released them yesterday or the day before ‑‑ I believe there are currently 150,000 CSMs, but there’s only, I want to say, 9,000 CSDs. I can’t believe that their management ratio is that high between number of developers… [laughter] Derek: …to number of Scrum Masters or Project Masters, whatever classification they were coming from. Perry: Right. I think people are starting to realize that one size doesn’t fit all. We’ve got to figure out what is best for each person, and then you balloon that up what is best for this organization ‑‑ is it Kanban? Is it XP? What’s the thing that should happen first? It’s not always the generic answer that has been for a while in those people’s minds. I think that’s a positive thing for the community. Roy:: Jade? Jade: I think that, if we look at the Tuckman model, this is the year of storming. [laughter] Roy:: Last year, you made predictions ‑‑ not predictions, let’s call them commitments ‑‑ on what you would do to improve yourself with regards to Agile throughout the next year. Alan, or some of you, what are you going to do this upcoming year to improve yourself? Writing More Alan: I have recently figured out that I was much happier when I wrote more, so I’m going to write more. This is a very individual, personal thing. I think, as I write more, it lets me formulate thoughts and learn them better, so that I can help the people that I’m trying to help. I can help much more efficiently and effectively. I’m saying here, in the most public way I can, that I’m going to write more on my blog and I’m going to write more on my own personal diaries, if you will, that I used to keep a lot. I got away from that this last year, and I need to go back to that. My personal self improvement goal is to use writing as a way to process my thoughts and pass that benefit on to the people that I work with. Roy:: Perry, how about you? Reading More Perry: I wish I could say writing. I’m going the opposite route. I’m going with reading. This year, I’ve set goals right around the 30 number for the number of books that I’d like to actually read this number. Jade: A month? [laughter] Perry: Read this year. I wish it was a month, but for me, that’s an increase. That’d be a good number for me to get to this year. Roy:: Derek? Frameworks Outside Agile Derek: I’ve got a couple. One of the big ones is to explore seriously frameworks outside of Agile that are complementary to Agile, around leadership, systems thinking, human systems dynamic, or the Cynefin network. Other frameworks that people in other disciplines are talking about and to see how to start to map those to organizational or leadership type of roles. Additionally, I really want to make a big push for having organizations gain agility outside of software. I think, one of the biggest problems that we currently have is the only real samples we use are software. We make all these crazy exceptions and do all these really stupid things because it makes sense for software from a process perspective. I think, if we were dealing with something that wasn’t a deliverable product, like software, maybe we would have better definitions of what our beliefs really are. Then, the last one is this is the year that I’m going to make a concentrated effort to try to save the Scrum alliance from themselves. That is, right now, their position to really hold the champion flag for Agile, from a resource perspective and from a number of members’ perspectives, they are really falling down on the job. I’m really going to try to see what I can do to make a difference in that space. Roy:: Jade, how about you? Innovative Cultures Jade: My goals are frighteningly aligned with Derek’s. I think we are very much on the same page there. One thing I would like to do is really talk aggressively with organizations about, “What does it really mean to have an innovated culture”? That’s it really time, right now, to adapt or die. That there’s capitalistic Darwinism happening and now is the time to get ahead of that curve before you’re one of the dinosaurs. Alan: That’s great. Roy:: Awesome. Thank you guys all for joining us. I hope you enjoyed this special edition of the ScrumCast. Bye‑bye. Jade: Bye. Perry: Bye‑bye. Alan: Thanks. Derek: See you next year.

Clayton Lengel‑Zigich: Welcome to another episode of the ScrumCast. I’m Clayton Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Agile Frameworks Mainstream Clayton: Today we are going to the Twitters. We looked up some tweets using the Scrum hashtag. We’re going to just go through those and rapid‑fire talk about them. The first one, this one is the San Diego Times, perhaps, the SD Times who ranks Kanban, Lean, Agile, Scrum among top trends of 2011. What do you guys think? Are these trends fads? Are they just becoming popular? Maybe they are making some mainstream media concept. What do you think? Derek: I believe the SD, Software Developer Times. Clayton: Oh, that makes a lot more sense, though. Derek: Yes, I think in some ways they are trends in the sense of…these stuff that’s up‑and‑coming, will they last? I think that the Agile principles and the values are fairly timeless. I think the process implementations, if they’re truly Agile, people are going to inspect and adapt on them over time; which means that they will be different, and we will probably discover new ones as well. Roy: I think too, that lately I’ve seen a lot of companies that are saying that they want to be more Agile, or want to implement Scrum or LEAN or whatever. I think that a lot of them are just saying that, based out of articles they’ve read, or people they’ve talked to, and don’t really understand what it’s going to take. Oftentimes, it’s going to take some sacrifice from themselves and from the organization in order to reach that end goal. Once they find out that that’s part of the process, they’re going to be disenchanted with the concept. Derek: Kind of like I really want to lose another 50 pounds but I don’t want to stop eating donuts? Roy: Sure. That would be a good way to put it. Clayton: It seems like with any software development stuff, there’s always going to be trends and waves of popularity. But it seems like some of the stuff has been getting a little more mainstream. But it definitely feels kind of faddy, in some degree. But I think you’re right, the Agile values and principles, that stuff will be pretty timeless, I think. Next up, here’s kind of a fun question. What do you get a Scrum Master for Christmas? Scrum Master Christmas Gifts Roy: A box of index cards? Derek: I think you’ve got to practical joke them in some way or another, just not having enough fun. I’d fill their cubicle, if you have cubicles, up with popcorn and peanuts or something. Short sheet them, move their desk into a bathroom, something interesting. Roy: For a while, we were actually collecting our used index cards. Once the sprint was over, we’d collect our index cards and throw them in a box. It’d be great to save up a year supply of those and fill this cubicle with them. Derek: Perfect. Too Experienced For Scrum Master Clayton: Or if they have a sunroof you could pour them in their car, that might be a little more fun. There’s a tweet about someone got turned down for a Scrum master role because they were too experienced. How do you become too experienced as a Scrum master? Roy: I think that it sounds to me like what happened was they didn’t want to hire him for some other reason and they were too much of a chicken to say what the real reason was, so they told him he was overqualified for the position. Clayton: They got that “You’re too experienced” answer? Roy: Right. Derek: Yeah. I think most companies that do that for a position, what they’re really saying is your salary range is beyond the scope of what we’re willing to pay. Therefore it’s easier to say, “You are too qualified for us” than it is to say “You are too expensive for us,” because one makes you sound good and the other one makes us sound cheap. ScrummerFall Clayton: Yeah. I wondered about, I think a lot of companies have a hard time defining exactly what the Scrum master is supposed to do. I would be pretty impressed if there is a company that had a formula, so narrow down they’d be able to tell if you’re overqualified or not. There’s an article that came out and this tweet references it, but it’s about the concept after some time has gone by, most of the agile “projects” are really, the author described them as water Scrum fall. There’s some kind of waterfall implementation of requirements gathering and figuring what it is. Then the work itself is done additively and then there’s some kind of release process that still waterfall it. What do you guys think of the Scrum or fall stuff? Is that real, does that exist? Derek: I think it depends on how you really define it. I think in one respect I think that most Scrum is mini waterfall in the sense of you’re doing all of the cycles within an iteration. You’re only doing enough design, only doing enough architecture, only doing enough requirements definition at the beginning of a sprint planning meeting to last for a sprint. Therefore could you say that because you do that every single time that these aren’t falling to waterfall category. I think the determination for me is the actual process is a little bit different. You’re not saying “We’re spending one day doing requirements definition, we’re spending one day doing development design. One day doing development, one day doing testing and one day doing releasing and that’s a sprint,” or something thereof. I think design and architecture and things evolve over time within a sprint. I don’t think things are set. I can certainly see how people say. You’re doing all these activities in a pressed time period, but in reality you’re still doing them sequentially, meaning I don’t think we could ever do a Scrum where we say, “Hey, we’re going to jump in and we’re going to start testing before there’s code and before there’s actual, the entire stack of the code.” I definitely think we can jump in and say “We don’t even know what the story is but we’re writing code.” That would be irresponsible. Three Types of Scrum Teams Roy: I think the article that linked, as well mentioned a second article that talks about there are three types of Scrum teams. Ones that don’t practice Scrum at all, just say that they do. Ones that practice Scrum to the book and a third team that does Scrum, but they make a lot of concessions due to their corporate structure or whatever other factors in a place like the traditional Scrum buts. The main article that we’re talking about suggest that that approach of doing strict Scrum but them making the concessions where needed might be the most pragmatic approach. Because it’s the easiest to implement and it’s less painful. Looking at that as pragmatic might be a mistake because if you’re doing that you might be ignoring the problems within your organization that strict Scrum is trying to uncover and that you’re avoiding those problems in the name of pragmatism. Derek: Yeah. I definitely think it’s the pragmatic approach in the sense of, the most being for the buck right off the bat. The problem you have is this is where we see the curves that say, your implementations going whether you have a code, you don’t have a code. Your performance going up and then it plateaus and the will drop back down and the will plateau and drop and never gets as high as that or first initial piece. I think that’s because people do make all the concessions. It’s the race to implementations i.e. we know we’re going to do shorter races, we’re going to do some things. We’re making a lot of tradeoffs to get that to happen. What they do is they never deal with the real problems. And so what happens is after the newness of this new process wears off people fall even further back in to the bad way of doing things and performance drops again. Then it’s “OK, let’s get serious about Scrum again or Agile again” or “Let’s switch to Kanban,” whatever the motivator is and then you see an uptake again until that pain reaches. If they’re going to be pragmatic about it when they get to the plateau stage they have to start to say, “OK, now we’re going to start removing the “but” parts. We’re going to start saying how do we get to the real implementation and deal with what it exposes.” Scrum vs Kanban Clayton: The next tweet goes towards some of the Scrum versus Kanban stuff, but it says Scrum as a diet, Kanban as a mirror. This is getting at the Scrum, makes you or suggests that you make some changes to your process where Kanban has got it more, let’s visualize what you’re already doing. This is an interesting anecdote. It’s a great tweet because it’s link BD, it’s been re‑tweeted a few times here. I will say there’s probably a lot of overweight people who have mirrors in their house, but that doesn’t seem to help much. I don’t know what that says about this. Derek: I saw an excellent Ted talk in the last few days that talks about some methodology about a sailor going through where the sirens are located. He wanted to hear the sirens but he didn’t want to be lured in to the sirens. He asked the captain, the crew on the boat to actually tie him down to the mast of the boat so that he couldn’t get out. The theory there is that it’s a commitment post. All the time in life we use commitment post that say we’re going to put something. If I’m losing weight maybe I say, “I’m not going to let any junk food in the house.” Maybe I say that “I’m not going to go to these types of restaurants,” because I know that there’s a weakness there and so I’m going to commit myself to not being tempted by that. At times some of what we do in Scrum would be a kin to that. I don’t know if a commitment post is necessarily a bad thing. If you rely on it long term it’s probably not real healthy. I would pose it, a mirror doesn’t tell you a whole lot in the weight aspect of “OK, maybe I see myself getting fatter.” If I have no clue on how to lose weight, a mirror doesn’t do shit for me. Whereas if I have guide post that say like, “Hey, here are some rules. Don’t consume more than 1,200 calories a day. Don’t eat after…,” whatever those commitment posts are. I rely on them and I start to lose weight now maybe the mirror becomes a better tool for me to say, “Hey, I see myself bulging back up again. Now I know maybe I need to go back to those commitment posts.” So I think doing it the opposite way is just a much longer more painful way of doing things. When To Use Agile Methodologies Clayton: I think this is a funny little anecdote that cuts both ways. I can imagine lots of different ways that I could probably stand in front of the mirror and make myself look different. You still have to perceive it somehow. This is kind of an open ended question, and it links to somewhere. The question is, when do you use Agile methodologies and techniques like Scrum? I think a lot of organizations may be going back to the trends of 2011. A lot of them say, “We have a supper project, and Agile is going to make us go faster, so we’re going to use that.” What are some ways that may be a better way we can think about when should I apply some of these methodologies, and maybe when should I not? Roy: That’s a tough one to give a blanket answer for. Clayton: It depends? Roy: I think some examples of situations in which you can use an Agile methodology like Scrum or Lean but it becomes very difficult is when you get into areas where there are strict compliance regulations, like if you’re trying to do HIPAA compliance, or if you’re trying to do FDA ones or anything like that. Then it gets very difficult because a lot of times those compliance regulations require a lot of up‑front documentation and you have to get that approved or they could potentially turn it down. If you’re doing that as you go, you might end up wasting a lot investment money producing a product that gets turned down by the FDA when you could have caught that at the documentation stage. Derek: For me, I would say Agile methodologies could be used any time you’ve got a team of two or more people. They’re really principles and values for how you work with other human beings. I think that’s vital regardless of what type of work you’re doing. As far as an implementation, i.e. Scrum, or Kanban, or et cetera, I think that’s really going to depend on what kind of product you’re trying to deliver, what kind of project it is, and what things are important for success in that. I think the core methodologies apply to any kind of team. Currently today we’re doing it inside of school districts. We’re not doing Scrum, but we’re applying a lot of these self organization techniques, and really even pushing it down to empower the students in the classroom to do retrospectives with their teachers and get them more involved. I think the principles go pretty much anywhere you’ve got groups of people. Scrum Promoting Generalists Instead of Specialists Clayton: This next one is a good Scrum question, there’s actually two things inside. It says, “Am I nuts to invest in specialization where I get the idea that Scrum is generalizing the team?” Two things. Is Scrum really generalizing the team? And then assuming it is, should you invest in specializing in some certain thing? Roy: I personally am of the opinion that a jack of all trades is more valuable in the long term than a specialized individual. I’m also of the opinion that a specialized individual could be dangerous to your organization. If you’ve got the one guy in there who knows how to do any particular task, let’s say he’s a DBA, or he’s the only guy that knows how to do the build, that means that you now have a bottleneck. First off, your organization doesn’t pass the “hit by a bus” test. The guy could be a total dick and you’d have to keep him around just because he’s the only one who knows how to do that, or he could demand whatever salary. I think that ideally you have a team in which everybody is able from every task. It’s OK that no one of them is able to do it as well as a specialist would be able to. I think the trade off that you get there where you get a huge increase in flexibility is more than worth it. Derek: For me, the big thing here is I’ve been in technology long enough to see how fast it moves. The people that were highly specialized 10 years ago, maybe I’m a Java programmer or a Delphi programmer, I’m a client side programmer. I’m demanding top dollar. I’m totally on top of event driven window programming. I’m the crap. In two or three years it switches to all web platforms, and web platforms now are pushing weave ins, and SQL databases away. The problem is, if your career is going to be 30 or 40 years long and you’re in technology, you’re going to have to relearn a specialization every three to eight years if you want to stay gainfully employed, doing interesting work. Be fairly general, but if there’s something you like, maybe deep dive a little bit into it, but I wouldn’t get so myopic as to be totally specialized. Clayton: I don’t think that there’s anything wrong with having some people on a team that maybe know more about something or may be more of a specialist, as long as there’s some kind of overlap, and you stick to the idea that the team is cross functional. Roy: I think ideally you get a bunch of team members who are passionate about different things and will take the time to go out and learn it. We’ve got Drew on our team who is extremely passionate about JavaScript, and Clayton, you are very passionate about testing. That ends up benefiting the team, not because you guys create information silos and lynchpin yourself in, but because you take every opportunity to teach us about the stuff that you guys know so that you’re able to spread that knowledge. Story Points As A Proxy For Time Clayton: This next tweet, it’s a good one. It says, “I have never met a proponent of story points that hasn’t ultimately described them as a proxy for time.” Derek: This person has never met me. Clayton: Do tell, Derek. Derek: To me, it’s all about sizing, and I don’t think that really has to do with time. I think it much more has to do with effort. I guess at the end the goal is to take velocity and be able to say, “Do predictions.” Those predictions generally have to do with time, but I would not be a proponent of saying, when I’m explaining what story points are to somebody, that we use those to translate to time. I never say, “Three story points translates to X number of hours.” You can make some assumptions about that and say, “Based on prior performance we might guess that that’s the case.” But to me it’s really a matter of what are they in relation to each other, i.e. story points are only relevant to other story points, not necessarily to time. Roy: I think I’ve seen some great examples of this in action where we estimated a project at a specific number of points. We pulled in a bunch of stories that were relatively easy, they were twos or threes. We worked on them throughout the week and realized that what the product owner had intended for those was way more complex than what we thought. We felt that those twos and threes should have actually been fives and eights. Then the following week we got into the fives and eights and those ended up being twice as complex as we thought too. Even though it was twice as hard as we thought and we felt we should double the points, it was actually fairly accurate. It just shifted everything up because everything was twice as hard as we had originally thought. Derek: I think that’s the best way to explain it, Roy. That is that if you’re really doing things relative to each other, if you find out that a three takes you a lot longer than you originally expected, you don’t have to go back and re‑estimate everything. If your stories were actually relatively sized it’s going to come out in the wash in that you’re going to be able to recalculate your velocity based on the level of difficulty being different. I think that where people get hung up on is they try to say it’s a time based thing. The whole reason you use points is because they’re not time. If we estimated everything as ten hours, and then we found out it really took 40 hours we’re going to have to go back and readjust all of our estimates. If we did it as a three and a five and we found out a three took 10 hours, and maybe in our original velocity estimates it would have calculated out to three hours, we don’t have to go back and re‑estimate everything, we just have to adjust our velocity, and that’s going to shift time. Clayton: I think we see this a lot because the team will estimate something using story points and it works itself into velocity, and then everybody comes to that conclusion because ultimately they say, “We did a 20 point iteration and it took us, say our iteration is two weeks. So that means that 20 points equals two weeks.” I think that everybody consciously or subconsciously makes that assessment. Then the people that maybe abuse the system want to try and extrapolate that out, and say, “OK, well that means that, when are you going to be done? That means that that many points takes that long and this story estimate point five takes two days and one takes half a day, or whatever you want to do.” It seems like everyone tries to go down that road but I don’t think that’s the fault of story points. Derek: So going to our earlier conversation, if you have a mirror you don’t need to own a scale. Clayton: [laughs] Roy: In the past, we’ve had some discussions, internal at Integrum, where we were talking about the idea of relative complexity versus relative time. The example I think we used at the time was, it takes me a few minutes to walk across the street, it takes me an hour to walk to work. But they are about equally complex. So when you are estimating those, would you rate those both the same points or would one be significantly more than the other? Derek: No, they would be significantly more than the other because it’s amount of effort. Roy: So you would say that it is amount of relative effort as opposed to relative complexity? Derek: Right. I would say it is a combination of those two things. Clayton: All right, well that does it for the tweeters for this time, so thank you guys.

Clayton Lengel‑Zigich: Welcome to another episode of the ScrumCast. I’m Clayton: Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. Chris Coneybeer: I’m Chris Coneybeer. **Derek Neighbors: I’m Derek Neighbors. Clayton: And joining us today, we have Howard Sublett. Howard, if you could just say hello to everyone and tell us a little bit about yourself. Howard Sublett: Hi, everyone. My name is Howard Sublett. I work at BigVisible Solutions out of Boston. Long time employee of the Scrum Alliance. Enjoy the space, worked with a guys over the years at Integrum and at Gangplank, glad to join today. Shared Resources, Moving People On/Off Teams, Multi-Tasking Commitments Clayton:: It’s good to have you. Today, we wanted to talk about a couple different topics. One is shared resources. How do we manage pulling people off of teams and moving people around? Also multitasking, or being responsible for multiple commitments and people being spread too thin. Right after that, guys, what do you think? If I’m the manager and I have a couple of teams, and I’ve got one person that I’m expecting to be on both teams, is that a good idea, bad idea? Derek:: That’s a sign of dominance with your ability to be highly efficient with resources. Clayton:: Can you break that down into layman terms, Mr. Derek? Derek:: Yes. You’ve just fucked your teams. [laughter] Clayton:: Can you smarten it up a little bit for the podcast audience? Lack of Ownership & Visibility Derek:: Yes. One of the MBA fallacies is that you have to be a really good steward of resources, which means you have to slice them infinitely thin. It’s not uncommon that…especially in silent organizations or organizations where you’ve got very specialized employees. Maybe I’ve got a database architect or a UI person. There’s a UI person for every single team. I now want to slice them across four or five different projects. What you’ll find is that they can’t identify with any of the projects that they’re on. They have no ownership of any of the work that they are doing. They’re generally overcommitted, yet there is no real visibility of that even in the highest performing of teams. Roy: How do you deal with something like that, where you have an architect and he is your primary architect guy and, really, all of your projects need to have architecting expertise, whatever that means, how are you going to deal with that type of situation? Commitment Driven Planning Derek:: For me, some of it is to start to learn with the damage you’re doing. One of the things is why do you rely on a sole person? You’re setting yourself up for the hit‑by‑the‑bus syndrome and what happens that person when they decide to leave your organisation or something happens to them, how cripple do you become? You probably want more than one person to be responsible for it. The other thing is how are you really getting a team to coalesce, if the team is looking to a single person to do a certain part of it? How do you get that ownership? The cross‑functionality to me is a core principal in a lot of ways in Agile work. We don’t sit around and say, “Well that’s so and so’s fault, they’re the ones that were supposed to do that.” As a team we say, “If so and so is not available we will figure out how to do it at whatever level we can do it at to the best of our ability.” Some of that is getting to the point of how do you start to challenge that mentality? This is not going to happen overnight. I’d say the other way that I would combat it is I would make all of the teams to have shared resources on them absolutely positively use a committed‑driven approach in planning so that they know what resources are being committed and at what level. So that somebody who is a shared resource doesn’t over commit themselves. They go like, “Oh, yeah I could do that, oh yeah I could do that,” and then at the end of the session they have over committed themselves to five different teams. If Everything Is Important, Nothing Is Important Clayton:: Yes it may go beyond just the commitment point of view. One thing I have always liked is, “If everything is important then nothing is important.” If am on every team then am I really on any team? What are the team or the people effects of having a senior developer or DBA or an architect or something bounce around? Does that person ever feel like they are on a team or do they ever get to be part of a team? On Multiple Teams, Attend Multiple Ceremonies Issue Howard: I was just having a conversation about this with one of our clients today regarding designers. One of the things we talked about was the ownership. We were having issues with the ownership and also that individual once we started talking to them about the issues. They felt like they were being siloed. They saw how these other teams were trying to open up and they were trying to have more involvement and have better transparency on the team but they felt like they were being put into a silo because they were being treated as this one‑off resource for everything. They weren’t involved. A lot of it came down also in amount of ceremonies. How do we get that person involved with ceremonies when there’s multiple teams being run? Derek:: That’s something I definitely see. I see people that are part of multiple teams when you transition to Agile when you start getting into the thick of it. They get pissed off because they are being asked to go to five different planning meetings, five different stand ups, five different sprint reviews and [inaudible 05:22] says, “I can’t get any work done, I am in meetings all day,” which is the exact opposite of what you try to do in Agile which is you basically have constant interaction and you minimize the amount of ceremonies or meetings that you do by compressing them. But to me that’s a complete red flag when somebody in an Agile organization screams that they are in too many meetings. Is that it’s probably because they are on too many projects. Roy: It sounds like it would be really hard to commit to a project as well, because if I’m hopped onto a project just for the design phase. I’d be on that project thinking like, “Oh I just got to stick it out for two or three weeks until this part of the design phase is done. And then I’m onto the next project so I don’t have to give it my all, I just have to get through it.” Derek:: Plus if you have a design phase, aren’t you Waterfall? [laughter] Too Many Meetings Is a Red Flag Clayton:: That’s a good point. The idea of being involved in a lot of meetings or that kind of red flag ‑‑ that speaks to having multiple commitments. But is there ever a time when it’s appropriate for a person that maybe on a team or maybe an architect or something to have multiple commitments? Is there a low limit or is it a not at all? Or do you think that’s a bad idea in general? Roy: I guess my question would be why are the individual’s making commitments? Because it sounds like the whole team should be making a commitment and if you have two separate things that need to be committed to, then perhaps the team can decide how best to handle that. And the team should commit to getting both things done and then whoever’s available will do the work. Is The Penalty Worth The Benefit Derek:: I’ve seen this done a couple of…I guess I would start with saying it depends. Just like with distributed teams if you don’t follow the prescriptions of Agile, you are going to pay a penalty. The question always becomes is the penalty worth whatever benefit you get in exchange for that. If I say, “Well, I need this security expert, that just knows the in and out of security, up and down.” But I can’t afford a security expert for every single team I have. Therefore they’re going to have to be a shared resource. I’m making a conscious choice to say, the benefit I get from having a specialized security person outweighs the penalty I pay for making them a shared resource. Another way I would think about using those type of resources, whether they be more of the operation IT team, whether it be security team, whether it be architects, whether it be database, whatever. Or maybe you have one or two of them or three of them but they need to be split across five or six teams. I would actually create them to be their own team, and have the other teams treat them like a third party. Which is, I can’t commit to work that relies on them unless they’ve already done the work. If I need a bunch of database changes, those need to be to be done before I go into my sprint, in order to commit to them. Because just like a third party, they’re not committing, so I can’t commit to something that they’re not committing to. Which is another way you can deal with it. Being A Team Member Of Many Teams Howard: Derek, don’t you see that some of the problems come in when the architect is being shared amongst multiple teams. I mean I’ve seen that before in organizations and they have to, they have to share them that way. They can’t afford somebody for every team. But the problems come in is when the teams feel like that they are actually committing as part of the team instead of sitting outside the team helping with guidance documents and stuff, over how they are going to write code over this section of architectures. Derek:: Do I see that? Or do I see a problem in that? Howard: The problem for me is when the architect feels like they’re a team member in every team. Because they can’t really commit to every team because they’re doing nothing but going from meeting to meeting to meeting. Derek:: Yeah, I don’t see very often that they actually feel like they’re part of the team. I usually see that they feel like they’re not part of the team or they identify more with one team than other teams. Generally it’s very hard to be committed to five teams at once. Not only is it a time constraint thing, it’s an emotional constraint thing. It’s very hard to make bonds and have trust with five independent teams that have five different visions, that have five different commitments. That’s very difficult to honor. What About Product Owners Clayton:: We’ve been talking a lot about architects and DBAs and the development side of things. Howard, I had worked with you in the capacity of a Product Owner. Do you think that had you been the Product Owner of multiple projects or multiple teams you could have been as effective? Is the Product Owner role immune to this splitting problem or do you think you would see the same issues? Howard: You definitely would have the same problem. I would assume that unless the teams that you’re working with and the product that your working is so closely aligned that it feels like one to you. I don’t know if we as human beings context switch as well as people make us out to. I think it’s more difficult than what we pretend it is. What About Scrum Masters Clayton:: One thing I see is that some organizations seem to struggle with the idea of a Scrum Master, where if you have, say, five different teams, do you have five different Scrum Masters? It seems like some people have a hard time making that decision, maybe from a budget perspective. Can you be an effective Scrum Master for five different teams, or is that the same kind of thing we’re saying here, where you probably can’t? Howard: For me, I would say it depends. It would depend upon the maturity level of the teams. In the beginning, it would be very difficult to be a Scrum Master for multiple teams. As the teams matured, I think that would become easier. You would have a primary team you’re focusing on and a secondary team you’re working as a coach or shepherd on. Depending upon your skill set and the maturity of the teams, I think that role could work that way. Derek, you may disagree with that. Everything’s A Trade-off, Agile Exposes The Truth Derek:: Again, it goes back to, everything’s a trade‑off. The more ways you slice a Scrum Master, the less effective they’re going to be. It’s a matter of, how much are you willing to pay that penalty? In the case of, you already have high‑performing teams, maybe the penalty’s not all that high, so it’s very palatable to do so. In the case of new teams, the penalty might be extreme enough that you’re not willing to do it. Some of it goes back to the capability of the Scrum Master. A more experienced Scrum Master might be able to balance a team or two, where a new one might not be able to. I think it’s rough. These are trade‑offs that people make, from Product Owner to Scrum Master to database person to security to programmer to testing to you‑name‑it. The real thing that people are talking about is budget. They don’t want to allocate enough budget to do things properly. It’s all a trade‑off. Where are you going to cut costs? The problem is that people aren’t real or aren’t honest about the real penalty about some of the ways they cut costs. They say, “So‑and‑so’s ‑‑ Howard’s a really great Product Owner, so he’ll have no problem being a Product Owner for three different products.” That’s the lie we tell ourselves. Agile’s role is to expose the truth. It does that fairly well in that when you share resources, you get poor results. I think that usually surfaces up. Faster, Cheaper The Real Problem Howard: Do you think it’s, in some ways, the way Agile has been sold? I’ve bumped across quite a few people that really feel that the number one benefit of going Agile is that, number one, it’s faster, but it’s cheaper, too, as well. We can deliver quicker, and it’s less cost than the way we were doing it. They’re going with a mindset of a cost savings, in a way. Derek:: I think there is some of that that happens. I definitely think that we are marketing the wrong things. I don’t think we should be marketing “faster” and “cheaper.” Those are by‑products that happen as part of the process, but they shouldn’t be the necessary endgame of the process. What happens is, yeah, you can move faster, but it’s not immediately. You do have to make significant change to get that speed and quality improvement. Roy: The “you” is the entire organization, not just the developmental team. Derek:: Yes, that’s correct. That’s where I see a lot of, “We made this big change over here in developers, so we can skimp on Product Owners.” No, not really. Or, “I made this really big investment in Product Owners, so we can skimp on developers.” It’s not that simple. People still try to have a “nine babies in nine months” problem. (Mythical Man Month) You can go faster, but you can’t beat physics, so to speak, in some of these cases. That’s what we’re really up against. Clayton:: To wrap up… Howard: The Duggars did… [crosstalk] Clayton:: Go ahead, Howard. Howard: I was going to say, the Duggars beat that statistic, I think. [laughter] Moving People Between Teams Clayton:: To wrap up, is it possible for a team or, maybe, two teams or three teams or whatever to become mature enough where you could move resources around, or is that always going to be a detriment, and that’s something that nobody should really strive for? Roy: I think I agree with Derek that it’s probably always going to be a detriment. You might be able to minimize that detriment a lot by having more efficient teams, but you’re always going to lose something. Derek:: I want to make a small clarification. It’s absolutely, positively possible to move people around within teams, just not within a sprint or within an iteration. If I’m bouncing between three teams within a sprint, there’s going to be a significant penalty. If I’m on one team one sprint and another team another sprint, there is a penalty but not a significant penalty in that. Roy: We had Adam Sroka on a few weeks ago. One of the things he was talking about was software craftsman tourism or something like that, where companies would, essentially, do foreign exchange programs between each other with their developers to gain a new perspective. I think that while you probably get a penalty in velocity and probably a penalty in the team’s cohesiveness, you might get a potential gain in innovation just from adding that new perspective to the team that they didn’t have before. Clayton:: That’s a good point. Howard, as our special guest, you get the last word. Is there anything ‑‑ a tool or anything, really ‑‑ that’s been interesting to you lately, that you’re real hot on and you’d like to share with the audience? Howard: Absolutely not. I can’t think of anything that’s just really, really zinging me right now. Clayton:: The audience gets a view into your boring life, then? Howard: Absolutely. Clayton:: That’s too bad. Howard: Absolutely. Totally boring right now. [laughter] Clayton:: All right. Thanks, Howard. [background music] Clayton:: We appreciate you joining us today. Join us again for another episode of The ScrumCast. Howard: Thanks, guys. Derek:: Thanks. Chris: Thanks.

Jade Meskill: Hello and welcome to another episode of SCRUMcast. I am Jade Meskill Derek Neighbors: I am Derek Neighbors. Roy vandeWater: I am Roy vandeWater Drew LeSueur: I am Drew LeSueur. Alan Dayley: I am Alan Dayley. Jade: All right Alan, so you had an interesting question for us. Why don’t you go ahead and ask the group? Increasing Customer Participation Alan: Well, we continue to encounter the issue where companies and teams talk about how they are able to talk to the customer’s office. They would like, for example, the extremes from, the customer only shows up for a review or the customer proxy, if you will. Maybe the product owner doesn’t really know everything that the customer wants, all the way to, we haven’t seen our customer in six months. What are some of the issues or ways that we can to help encourage customer to participate more. Do they really need to participate more? Are there things we can do to mitigate these sorts of things. That’s been something I’ve encountered just recently. Derek: OK. When you say customer, do you mean end‑user of the product? Do you mean the person who’s paying for the product? What do you really mean by customer? Alan: In the, two cases I can think of at the moment. In one case is the sponsor; the customer that’s paying for it, but they’re contracting with someone to build a app for their customers. In the other case, it’s an end‑user where somebody is paying for a specific development to happen and they just disappear after the initial couple of rounds looking at a product backlog or something. Derek: In both cases there’s a proxy user of some kind? Alan: Yes. Proxy User Challenges Derek: What is the team’s challenge with a proxy user? Is it that the proxy user just doesn’t have enough information, so, “Hey, how do you want this implemented? Do you want it in red and green in the proxy user’s?” The answer is, “I don’t know”? Is it a matter of the proxy user says, “Oh, green,” and then when you go do this print review, the actual customer says, “Why is this green? I clearly wanted this to be red” and then the team is frustrated that they… Alan: It’s more of the latter. There’s a story told to me recently of a project that went on for three months and when it was delivered to the absent person paying for it; the customer, it was considered a failure because just too many things were wrong. Yet the team was frustrated because all along they were asking for participation, and obviously didn’t have it from the right person. I suggested things like, “Well, stop working,” all the extreme stuff. You bring up extremes to make people think and have conversations, but the extremes sometimes aren’t practical to implement. Jade: Did the team know that the person they were dealing with was the wrong person, or were they under the impression that this person had the proper authority and decision‑making power? Alan: I don’t know the answer to that question, in this specific case. Extreme Measures, Really Not That Extreme Derek: I think sometimes the extreme thing is really not all that extreme. What I mean by that is, I’ve seen this a lot in third party development. It certainly can happen in enterprise development as well. If you don’t have the stakeholder or the customer, the person who’s actually paying for the work, really signing off on the work or being an active participant in the work, and you get to the end or at some milestone and virtually all of the work to date that is done has to be thrown out, which is more extreme? Either not getting paid, if you’re a third party developer, for six weeks’ worth a work, which I don’t know about you, but most people would say, “That’s pretty extreme, to work for six weeks and not get paid,” or in an enterprise type of project that you do work for six weeks and it gets drawn out, and now you’ve lost six weeks worth a budget, which is the converse to doing that. Sometimes I think that’s not as extreme. I would say, “Could you use your definition of ‘done’ to help mitigate some of this?” Could you start to say, “Maybe we don’t need the customer in every detail or available every day, every stand‑up, or every planning meeting, but could we get to a point that in order to have sign off it has to be signed off by the actual customer? In that way, we’re never getting more than a sprint’s worth of work done.” What we’ve done in the past ‑‑ we had done some third party development work in the past. One of the things we’d do is a kind of a mini little contract. We say, “When we’re going to engage with you as a team, these are the things that we will do. We will have a planning meeting every sprint, we will have a daily scrum every sprint. We will review the budget as part of the sprint review. We’ll review progress, how we are recording the release planning every sprint. We expect you to do these things. We expect you to be there for every planning meeting for clarification. You don’t have to be there in person, but you have to be available if we have a question, you are there to answer the phone if we need clarification. I think you can say if you’re not willing to live up to your half of the contract, we can’t live up to our half of the contract. Lack Of Presence, Gets Poor Results Drew: I think we’ve tried in the past when we were still doing that type of consulting work. We tried to use proxy product owners every once in a while where the actual person or head of the organization or whatever that was actually paying us to do the work wasn’t able to meet with us and would have a subordinate meet with us. I think it’s…Pretty much in all cases it ended up rather poorly where we either had a problem where the person that got delegated to be our proxy product owner either didn’t know enough about the product to make his decisions, or every time we bring something up in the planning meeting, he’d say “Oh I don’t know the answer to that. I got to go back to the product owner” and we get a response a week later which for us is a whole sprint, or we’d have the other example that Derek gave, where they’d go ahead and make a decision and then we find out three weeks or four weeks down the road when the actual product owner gets a chance to look at it that none of it is the way that he intended. Follow The Money Roy: I think following the money is a important lesson to learn here. Who’s really signing the check and making sure that they’re involved in some way. Especially that there is some feedback mechanism for that person to be able to let you know that, if they have created a proxy or delegated some of that, but that person is actually making correct, informed decisions and if they’re not, there needs to be a retrospective or some time for reflection to help the real product owner understand that that person is telling the team to do the wrong things and that issue has to be has to be dealt with. That’s not the teams fault. They don’t know. They are being told that this person fully represents me and is your product owner, listen to them, but if that person’s not doing the right thing, there needs to be some feedback mechanism between that proxy and the real product owner to address a lot of those concerns. Release Early, Release Often Derek: Even when you have the real product owner being your product owner and you are not going through a proxy, I’ve been on multiple projects where the real product owner made bad decisions because they didn’t get the product out the door fast enough and into users hands. They made all these assumptions about what the requirements were, based off what they thought users would like, whereas if they had released early, like within a month rather than six months, they may have saved themselves five months of development time realizing that the user had no interest in the product or had a significant amount of interest in one feature but none of the others, or didn’t care about certain defects or whatever the case was. I think, even if you have the actual product owner at the development team, you should push the product owner to release his product as early as possible. I don’t know who said it but I really like to quote that “you should be embarrassed about your first release of whatever product that you are working on.” Jade: [laughs] How does that contrast with “you only have one chance to make a first impression”? Derek: That’s a good question. I don’t know. I think that in the past, that was probably more true than it is today. You are seeing with…I’ve seen multiple times now where there are products that are coming out, where they are almost offering data access to users. They get to use it for free or at a discounted rate. You see that with Google, with Gmail when that first came out. You see it with games every once in a while too like, “Minecraft” is a really good example of this. Where users today and especially in my generation, are OK with having an incomplete product, they’d rather have an incomplete product for less or even for the same price but earlier on… Alan: You little kids. Derek: …than have a fully developed product that’s perfect. Alan: The expectation is being set, that you are an early access user. That this is not the final product, right? That’s a clear thing. You are not just releasing the first release… [crosstalk] Derek: …Sure. Alan: Well that’s…that was crappy, so let’s try again. Derek: Absolutely. That should follow with whoever is releasing that product, should do that. I totally agree with that expectation is to be set. You can’t just release and say “This is awesome, it’s totally finished”! We had this exact example with Migo here, right? Where they released this product and they’re like “We’ve got this totally awesome finished product.” Everybody was all excited, go home and play with it and found out that it was still completely in development stage. Which most of the people here would have been completely fine with but it was presented as a finished product and that’s what totally killed it for everybody, I think. I don’t want to divert too much here but I think that one of the things we see is that…A fundamental shift that has happened is, we don’t do box software anymore. The concept of version here is gone. The best example of this right now today is Facebook. I mean, Facebook is probably different every single time you log in to it. It’s got new functionalities shipping nearly every single day. When features come on, they’re not fully baked. They’re not fully where they need to be but people’s expectations are, “It’s OK because it’s going to continue to improve or continue to change.” It’s not the world where you walked into egghead or best‑buy or 2999 and you got version 1.0 and it was going to be another year before you get the next version. People are a lot more forgiving about a current product state than they ever have been in the past. When you’re talking about absent product owners or proxies, for me, the most telling part of a product owner or a customer is their commitment to the product. It is a red flag in every way [inaudible 0:11:11] perform when I see a product owner, a proxy user or a proxy product owner put in place because there is not enough time. It’s really hard to feel important as a team if, “Hey, this is a company’s next big thing. This is what we are bent our future on. This is the most important thing,” but I can’t give you 20 minutes for a planning meeting for questions. I can’t partake in a 20 minute demo to tell you what it is. To me, that is so indicative of how that stakeholder or that customer really cares about the features set. That’s why I have no problem doing extreme. If you can’t show up for the demo meeting on a regular basis and give feedback, we’re done. At the end of the day, you are not going to want to write the check for this because you really don’t care about it. If I threaten that I am not going to do it and you really care about it, you will find a way to get to that meeting or to get your input in, because not getting it done is not an acceptable answer. Drew: Yeah, I totally agree. I think a key concept here is the concept of iteration. If by 1 iteration, be it a week or 2 weeks, we should be able to know that sort of thing. Is the product owner or whoever was put in place to be the product owner, do they care about the product? If it is in their hands and they can see it, they can improve it, “Yeah I like it,” or “No, it’s going the wrong direction.” If it takes you 3 months to figure out whether they really like it or not then your iteration’s probably aren’t real iterations. Roy: This is something in recent… sorry I was co training a Scrum Master class last week. It’s always interesting in those classes when I did the portion that talked about the definition of done. When you turn to the class and tell them you need to create the definition of done, let them expand and keep including stuff until every sprint you can give it to your end‑user. You could see the fear on half the attendees’ audience faces because there is a whole new concept to them to actually deliver something and deliver it often. Jade: I have been told by so many teams that that’s impossible.” How could we ever deliver anything in two weeks? That’s just insane. We could never do that.” You don’t have to release the whole product but, can you deliver something of value in that short amount of time? If you can’t, you probably doing something wrong. Derek: Are you questioning our two sprint release sprint? Jade: Yeah, that’s right. [laughter] Derek: I think it goes back to what Derrick was saying about things like Facebook where you can have incremental value added week by week or even day by day and I think that’s the key. If I can’t spend one week or two weeks, and work on something that has real value that people can really use, then what’s the point of working on that. When you do that and release it, then you’re releasing something real. Jade: I do think we need to be careful with that generalization. That works really great for web software, but in an embedded world there are other constraints to pin on your market world, where that’s not just possible to deliver to the market that fast, but you should be able to have some sort of internal delivery system where you are delivering something that is of value and is of production quality for each sprint. Roy: In the embedded world, I spent a lot of time there. The goal we always have is to be able to do sprint demos such that those few times that we actually had the VP or the CEO or somebody who doesn’t understand engineering, they could still see the demo and see value being produced from that demo even if it was just a prototype word, so that you try to pull all the way down to the end user and the non techie so that the business value is evident. Derek: At least some feedback where they can see that value. Roy: That’s as far as I’ve got with this question at the moment anyway. I don’t expect this podcast will solve those questions forever. [laughter] Roy: We will hear more of it over again. Jade: Yeah, definitely. [background music] Jade: Well, thanks for joining us for this scrumcast and we will catch you next time.

**Jade:** Hello and welcome to another episode of the Scrumcast. I’m Jade Meskill. Roy: I’m Roy vandeWater. Chris: I’m Chris Coneybeer. Management Inbreeding, Why Bad Cultures Thrive Jade: We have a special guest with us, Darrin Ladd, from “BigVisible”. Darrin wanted to talk about management inbreeding, why do bad cultures grow and thrive at large companies, right Darrin? Darrin: Yes, it’s a topic near and dear to my heart seeing that I’ve been working with the same large organization for the last two and a half years doing coaching. Jade: Wow. Why don’t you tell us a little about why do you think this happens? Darrin: It’s a great question. Why don’t we define first off what this means, what I mean by management inbreeding. The idea is this, that within large organizations it becomes, sometimes this feeling of we don’t know what to do with this person. Let’s take a very commanding control Project Manager, who is really upsetting all of the project teams that they are working with and everything. The HR organization and maybe there management doesn’t know what to do with them, sometimes unfortunately they say, “Maybe we’ll just try a new position, maybe we’ll try him as a team manager.” They suddenly get into the position of quite a bit of influence around, how people are rewarded formally and informally. As most people do they have, people are need this person had a strong need to survive. They kind of change themselves and what they do is they start to mold themselves around, how kind of the success that this person defines for them. People who may originally have been very collaboratively minded, wanted to work together, wanting success for everyone, may suddenly become very focused on themselves, very much trying to be the Superman that stands out above everyone else and solves all the problems and makes everyone else look bad. There is all sorts of, of course all the things that we have run into that we have seen that can be negative and suddenly that is, what they are doing to shine for this person. The interesting thing that happens is that this person recognizes that the person who stands out the most or does the most negative things, or it least negative to me, they recognize that as a positive. This is because they see a reflection of themselves in that person and they start to reward that significantly. Soon what happens is that person who was a manager gets promoted to a senior manager or director or whatever your organizational structure is. They start promoting up underneath them the people who most closely reflected their own image. Soon what you have is a whole organizational structure that has been grown up underneath this negativity. It’s very difficult for them to see any other options. That’s what am talking about management inbreeding, this perpetuation and growth of negative views. What happens within this is a self reinforcement because of the fact that as this individuals get promoted up they’ve been successful in this bad way of working, bad way of interacting or negative way. The people above them and around them are like minded to them and therefore they continue to be rewarded for this. That’s really what I’m talking about here. I want to stop talking and open it up to you guys. Jade: [laughing] That’s great and I don’t think that it is limited to just large companies. I’ve seen very small companies that exhibit the same behavior. A lot of that driven by whoever that leader is, the CEO, the President, essentially doing the same thing. Maybe not to the same scale but replicating that same kind of behavior. Inbreeding Tends To Be Worse The Older An Organization Is Roy: A question I have, Darrin, is that you talked about working with some of the large organizations and Jade you brought up small organizations. Do you think that this inbreeding goes deeper and deeper especially if a larger organization is or the longer the organization has been around? Darrin: I see it worse in the larger organization. I definitely recognize that it can happen in a smaller organization. The reason why I feel like it happens more strongly in larger organizations is because the influence of just a couple individuals in a small organization and their seeing things in a different way can be larger. The reason why I say that is even if you think about your circle of friends, if you are together with four other people and you are all having this debate, maybe it’s not even a debate, you are all agreeing on the fact that the current president is horrible or this or that or whatever. Sometimes in that small a group, all it takes is one other person walking over with a different perspective to start to change the conversation. Whereas if you’re in a huge room of a hundred people and you section yourself off into a little group and you start having that conversation and everyone agrees with you and you reinforce that, an introduction of somebody else within that whole organism, within those hundred people isn’t necessarily going to change your conversation, your self‑reinforcement of your own views within that small group. It takes a much larger effort to start changing that larger culture or that [indecipherable 6:07] cultures that happen within larger organizations. Why Are Negative & Not Positive Qualities Propograted Jade: This manager inbreeding, the big promise that it causes that it creates a lot of [indecipherable 6:17] within the company? Because I guess the question that I’m thinking back to is this perpetuation of negative qualities. Is there a particular reason why it is only negative qualities that are perpetuated and not positive ones, like a [indecipherable 6:31] bunch of positive qualities as a manager and I see those positive ones in people below me that I promote for those types of things? Darrin: That’s a great, great, great point. It really points out the whole other side of this that I should have introduced when I started talking about this. Which was, it doesn’t necessarily have to be negative qualities or negative interactions. It really is just a set of people who are all like‑minded. If we look at…I don’t know, large organizations, Nike is a good example of a large organization that had market dominance back in the early 80s. They had market dominance in just men’s sports shoes. If they had stayed with their sweet spot and continued forward, they would have limited their ability for growth and their overall success in the long run. Who knows, maybe they would have even had a downfall and disappeared like some of the other just strictly sports shoes retailers. What they did was they started to realize that having all of these people who were single‑minded in the pursuit of men’s sports shoes wasn’t going to make them successful, and so they said, “We need to get new ideas. We need to get new perspectives. We need to have people in here that don’t think the way we do to challenge what we believe.” So, in the early 80s, they hired their first female director. They started hiring people that previously to that, they never would have thought of hiring. Suddenly, one of the things that came out of that was they started to align women’s leisure shoes which now they are the market leader. It’s the trap of this idea of like‑minded. I’ll tell you, I’m one of the people who do a lot of the interviewing and hiring for my company BigVisible, and it’s a trap that’s very easy to fall into because when you’re interviewing somebody, you’re looking for how easy are they to talk to, how easy are they to work with. You really don’t want that, not on all cases. You want somebody who’s going to challenge the norms. You want somebody who’s going to think slightly differently, give those different perspectives. It maybe feels a little bit uncomfortable to work with them because they don’t see things the exact same way that you do. Injecting New Perspectives Jade: That’s great I think. In Integrum our room, we have no problem with that. We’ve got a lot of very different perspectives. We don’t [indecipherable 9:05] It is a very good point. That’s a very important part of the company culture. I think your example about Nike is a great one. From a company recognizing that they have a problem from the top‑down and taking drastic steps to change their culture and inject new life. What happens when, maybe, you’re a little bit lower in the organization and you’re seeing this monoculture ahead of you, what can you do to try to gain influence or make difference within the organization? External Consultants Can Jumpstart Darrin: That’s actually a really, really tough thing to do, I believe, especially from within the organization, a lot of times, when a culture has built up that’s basically uniform and it has all of those self‑reinforcing antibodies that it’s built up. It’s extremely difficult to start working your way through that and help people to see that there’s a benefit from different perspectives. I’m an external consultant. It’s a lot easier for me than somebody who’s internal within the organization. Hopefully, I guess one of the things is brings somebody in from outside who can start modeling some of the different types of behaviors: questioning things, asking the questions that everybody else is thinking but too afraid to say, because they’ve seen time and time again that this leadership or organizational structure culture beats it down. There’s a safety there that can be very scary, especially in larger organizations. You run into people who have been working for this org for 10‑15 years, and there’s these legends out there of that person who asked the wrong question in a meeting, got on the blacklist, and never saw their career go anywhere, but stayed with the company for another 20 years and languish. Those are the types of things that really hurt the ability for people to feel like they can start to challenge these cultures within organizations. I know I didn’t answer your question very well, because I honestly think it’s extremely difficult to do internally. Modeling Behavior Is Path To Culture Change Jade: Yeah. I think it’s hard. I think one thing I’ve seen that’s successful is start to model those behaviors in the area that you do have influence, even if it’s just you and your peers, and start to show success. That usually gets some attention, and people will at least give you some sort of consideration. Hopefully. [laughs] Darrin: Yeah, that’s a really good point, because what I have seen as well is that, sometimes, the culture isn’t as bad as perceived, so there’s a perception of not allowing certain things, not allowing these types of questions, not allowing doing things differently. Sometimes what you can do individually is find someone maybe higher up that you have an individual conversation with, asking these types of questions or pushing the envelope a little bit, and you find that bright spot. You find somewhere within the organization where it’s like, “Hey, you know what? This person gets it,” and you start from there and you start having that grow virally. You’re right, there are ways of doing it. I was thinking more of that big step forward, which is very difficult, but small steps, absolutely. Jade: Yeah. You can’t go about it with just reckless abandon, because you will end up being blacklisted. Darrin: Yeah, definitely. I call them antibodies, and I use that term very meaningfully, because there really is a whole organism. Examples of Success Jade: Darrin, why don’t you tell us, do you have a success story where you’ve seen this culture begin to change, transform, and turn into something that is vibrant and has a whole new life? Darrin: I have. I do. At the beginning, I said that I’ve been working with a company for about two and a half years, and there are lots of subcultures and larger, grander cultures within this organization. One of the ones that, actually, was really exciting was…there is the tip leadership culture within the organization, was one where everyone was completely afraid of ever questioning, basically, the CIO, the highest‑up person. Any time she was in a meeting, they shied away from making any statements that might be considered even negotiable at all. Anything that might be something that you could go either ways. It was very politically charged. Slowly, what we started doing was actually asking some of those questions ‑‑ not the really tough ones, not the ones where you’re putting anybody on the spot or anything like that, but just started asking, “How do you see that?” or, “Why do you think that way or this way.” The amazing thing that started happening was we started seeing that the CIO, that would sit down and say, “This is the way it is,” in the meetings, she would very visually and very verbally change her mind, show that, given some different inputs, she could change the way that she perceived certain situations. This started to open up the group of executives to start questioning each other in front of her and start questioning her, and not questioning her or each other in a negative sense, but really like, “Wait, why do you think that way?” “What do you see that makes you feel that way?” “Wait, can you expand on that? Because I don’t quite understand.” Suddenly, there was a culture of really trying to dig into things and understand it rather than try and stay safe and cover things up. You ask for a big one, and that, to me, in my mind, was the biggest one, because this was a group of individuals that, up to that point, were playing a major zero‑sum game. If one person asked a good question, everybody else was angry because they didn’t ask that question rather than really trying to collaboratively work together. Is Vulnerability Required Jade: Do you think it takes that person to make themselves vulnerable and show that that strategy can work in order for other people to get on board? Darrin: In that case, I think it did, because, in that case, they all looked at her to see how they should act. There was a very hierarchical view in that case. I don’t think that’s the case in all scenarios. I think there are even situations where you have a group of peers that are very much collaborative in nature and work together as peers, but there still needs to be somebody who starts that, that single point, that single bright spot that starts to show that there’s a different way of acting that could be positive. Jade: That’s great. I’m coaching an organization right now that’s going through some pretty radical transformation. They’re quite large. I see them teetering on the edge of making some of these mistakes. They have some open positions and they’re getting nervous about trying to fill those positions, so they’re just casting about looking for someone to fill in. What would your advice be to an organization that is in this precarious position, where they’re in the midst of a cultural change, but they might pull in the wrong influences that could start this whole management inbreeding all over again? Darrin: That’s something that I’ll tell you my company actually struggles with all the time. Why I say that is because my company itself has more work than people to do the work, or has more opportunity ‑‑ let’s put it that way ‑‑ than people to do the work. As a small consulting company, it hurts every single time you say, “OK. We can’t do this one. We need to get this away to a partner. We need to suggest that they talk to this person or that person.” But what we found is that, that’s absolutely the right call. It’s keeping the integrity of your organization and making sure that you have that right cross‑section distribution of people and that the people that you’re bringing in truly align with your values. Not necessarily of the ways that you might see things, but of your values is crucial. Giving up some market opportunity, giving up some business that you might be able to get to be be able to sustain the culture that you have. Maybe slow down some growth, I think, in the long run will actually make you more successful. That’s my opinion. Do I have a lot of examples of how that’s worked in past and how successful that’s been? Actually, I don’t. I haven’t done a lot of research on that. It’s my gut feel right now. Jade: Once again, I’d like to thank Darrin Ladd for coming on and joining us on Scrumcast. Very much enjoyed the conversations about inbreeding inside organizations. Hopefully, it helps our listeners try to open up their minds and think about, “How can we start to challenge the norm?” Darrin, thank you very much for being on. We hope to talk to you again in the future. Is there any information you’d like to give out for our listeners? Darrin: Sure. First, something I want to say. It’s been a pleasure. Thanks for having me on. Really good conversation. Jade: Thank you very much. Darrin: The company that I work for is BigVisible. You can find us at bigvisible.com. I’d be perfectly happy to hear from people given…if they have some opinions about this or even just to reach out and talk about other topics. So, thanks. Jade: OK. Thank you, Darrin. Thank you very much for joining us. We’ll see you on the next Scrumast. Darrin: All right. Thanks.