Agile Weekly Podcast

Agile Weekly Crew
Agile Weekly Podcast

The Agile Weekly crew regularly discusses topics related to agile, scrum, kanban, extreme programming (XP), software craftmanship, systems thinking, retrospectives, teams, culture and software development.

  1. 04/12/2013

    Do We Need Agile Process Frameworks Like Scrum?

    Jade Meskill:  Hello. Welcome to another episode of the Agile weekly podcast. I’m Jade Meskill. Roy van de Water:  I’m Roy van de Water. Derek Neighbors:  And I’m Derek Neighbors. Agile Process Frameworks vs Individuals and Interactions Jade:  I thought today, we’d talk about something, maybe a little controversial. Do we need frameworks? Roy:  Like Rails? Jade:  Maybe like Scrum. What do you guys think? Derek:  No. Yes. No. Jade:  OK. Roy:  It’s one of those things where they’re helpful to get started by get in your way after a while, but you think they get in your way a lot sooner than they actually do. Derek:  I like to say, if its individuals and their actions over process and tools. Why is it the first thing that we default to add to lists are hey, you need to learn a bunch of process? I think, no, they are not necessary. However, it’s very hard to do things well if you don’t have any discipline. What process does is it allows you to learn how, as a team, to be disciplined about the work that you do. It helps highlight issues that you have that can help you improve. Basically it builds off of work that people have done before. We know that all these things tend to really keep teams from performing well. If you’re not cross‑ctional, if you don’t have a concept of time boxing, if you don’t have a number of these things, you tend to struggle. We’re going to go ahead and put those things before you. Learn how to use them, and as you learn how to use them, you can shed them away and probably still get really good results. I’d say, yes and no, I don’t think you need process. Do I think that it’s hard to be good without having some guide rails to explore how you work? Yes. Agile Process Frameworks as Guide Rails for Novices Only? (Dreyfus Model) Roy:  I think some of it comes down to pragmatic thinking and learning talks a lot about the Dreyfus model and how early on you need rules because you don’t have enough knowledge to make your own decisions. But that rules ruin experts, and all these people that have lots of experience are now hindered by having to follow these rules when they should be trusting their intuition. Derek:  People tend to find themselves being experts far before they’re really experts. That’s another problem there is. I call it the so f*****g agile. We’re so fucking agile that we don’t need to do XYZ. I can turn on the dime. I can respond to anything. I was just like, Yeah, so you’re in chaos. That’s really great. I don’t consider that agile. Never getting anything done because all you do is respond to every stimulus that comes your way does not make you good. It makes you undisciplined. I think that that’s difficult thing. Roy:  I think that’s the careful distinction between thinking that you’ve arrived, that you’re there and that you’ve finished adapting Agile or whatever or finished improving and the idea of, I think I’ve grown these rules but I still need to improve and try new things all of the time because I’m not even close to where I want to be yet. Derek:  Yeah, so the litmus test I use is if somebody believes that the rules don’t belong to them and they don’t want them. They’ll throw a fit if they have to follow rules, they’re probably not really a master. If somebody says, I think that these rules could be bent but I don’t really have a problem with the rules and if it’s going to cause you all sorts of grief to not adhere to these rules, then fine, I’ll adhere to them. I generally find that’s the person that’s probably OK without actually having rules because what they’re saying is, I don’t think the rules hinder me so much that I can’t be effective, but I do think I know the rules well enough that when they need to be bent in certain ways, I could get more performance out of them. Where the amateur tends to say, I just don’t want the rules at all. Any rules at all are going to hurt me. Roy:  I agree with that. Dumping Frameworks on Teams. More Helpful or Harmful? Jade:  Part of my reason for asking this question is thinking about introducing new teams, new people and dumping this giant framework on their heads, let’s say Scrum. If I’m going from nothing to Scrum, that’s a lot of stuff to learn and take in. Does that hinder or help their ability to become more agile? Derek:  I don’t know. So you do count them on if you don’t want to do that. I think that to me like what I’ve been… [crosstalk] Jade:  That’s even a lot to take on. Derek:  Not really. Jade:  To do right. Derek:  The way that I look at it is, what do you want? If you want some immediate results, a framework like Scrums says, We’re going to be opinionated about a whole bunch of stuff because we know it works for most situations so just believe us and do it. The benefit to that is you can actually get real benefit immediately by making those changes. The downside is, you have to make fundamental changes on how you work. For a lot of people that pisses them off and makes them turned off to the process so then, they want nothing to do with it. It doesn’t stick long term the minute that somebody says, OK, you don’t have to do, even if we’re getting great results from it, ultimately, we didn’t decide to do all those things. The framework tools we had to do them so I’m going to throw them away the first chance somebody will let me where I tend to say that people that have a little bit more time, can explore. You do something more like Kanban. Just do what you’ve always been doing, visualize it and start to ask yourself how we can improve, improve over time. That’s a lot less hostile. People will tend to get to the same place that they get to in scrum a lot of times, but they get there over the course of months or years. They totally own it, because they’re the ones that made all those decisions. I had a team the other day. One of them was doing the work of what I would call the scrum master. The other person said, We created our own rule for a Kanban, it’s called the … [inaudible 06:06] Nanny.’ It was the person that was helping organize the work with outside parties and working with the product owner and managing a lot of the stuff that developers didn’t want to really be doing, but needed it to happen. I thought it was kind of ny that after a couple of months of Kanban, they had really implemented the equivalent of a scrum master. Not because they wanted to emulate the scrum master. It was just that somebody stepped into the role of doing that and people could tell there was a different role than the developer. I don’t think it’s necessary. I think it can hurt or help. If you want some immediate gains, if you believe in cross‑functionality and you believe in time‑box and being able to estimate or have some predictable delivery or really important and you want to get that right away. I think scrum can give you those things right away. It might piss people of in the process and turn them off to Agile in general. That’s a possibility. Jade:  When have you seen the best results? Derek:  I see the best results when it’s a hybrid. You don’t necessarily force. You have to do all these things, but you do some kind of principle‑based stuff. I almost think of it like scrum is the best idea of how I would deal with this, but if you have a different way to deal with this, fine let’s deal with this in a different way. I think that time‑boxing of iterations is a really good way to force feedback in some regular thing. If you’ve got a better way than that form of time‑boxing to do something, cool. Let’s look at it. More often than not people, given them the choices, just give a better way to do it. Let’s hear it. Very mature, so they don’t know. They’re like, OK, let’s do that, because I don’t have a better way. Sometimes they come up with a better way like, I think we can do this instead. Jade:  You’re showing them the facts, but then saying, It’s your choice. If you’ve got a better idea, we’ll support the best idea. Derek:  Right. Roy:  That sounds reasonable. It goes really hard to argue with too. Derek:  It’s about not being dogmatic. At the end of the day, we just want results. As long as we’re all OK with the results. Roy:  If you can manage to get awesome results with Waterfall, then by all means. Derek:  To me, with cross‑functionality, people get really hung‑up on it. I like to switch it more toward shared commitment. As long as we’re all shared in the commitment and that any of us are willing to do the work and all of us are part of that, I’m OK with not necessarily calling it cross‑functionality. It’s impossible to get that result and to have shared commitment without having some level of cross‑functionality, but if somebody’s going to get totally hung up on like, I’m a DBA. There’s no way I could do XYZ. Great. Let’s not talk about it in those terms. Let’s just talk about it that we’re bringing in two stories. The three of us are all going to commit in doing those stories. Let’s not predetermine who’s doing the work and we’ll go from there. Roy: It reminds me of something Jim brought up in one of our earlier podcast when he joined us. The idea, “We just care what is effective. The fact that it happens to be what makes people happiest is just a really nice coincidence and side‑effect but really it’s all about getting results.” Where It Goes Wrong? Measuring Agility by Process Adoption vs Results Jade: Maybe that’s where some adoptions go wrong, the desire to state is to be doing scrum, not to be getting results. Roy: Especially when you start measuring how far along your scrum adoption has gone. Jade: I’ve seen a lot of corporate roll‑outs in large companie

    18 phút

  2. 13/11/2013

    The Trade Offs of Organic vs Prescriptive Agile Coaching

    Jade Meskill:  Hello. Welcome to another episode of the Agile Weekly podcast. I’m Jade Meskill. Roy van de Water:  I’m Roy van de Water. Clayton Lengel‑Zigich:  And I’m Clayton Lengel‑Zigich. Prescriptive Agile Coaching Trying a New Approach Jade:  Clayton, you’re trying a new approach to coaching a team you are working with. We wanted to talk about that a little bit. Tell us a little bit about what you’re doing. Clayton:  A little bit of background. The team is this collection, I wouldn’t say misfits, if you’ve seen the movie “Bad News Bears” it’s kind of like that. Jade:  [laughs] Roy:  Wow. I have not. Jade:  [laughs] Imagine that you have. Roy:  Is it like “Breakfast Club”? [laughter] Clayton:  In that there are people in the movie, yes. It’s the same thing. Jade:  [laughs] Roy:  Is it like any of the three “Star Wars” movies? Jade:  [laughs] Clayton:  OK. There’s this collection of misfits and the approach I have been taking was I wanted to be prescriptive about some things. I go back and forth between organic learning or being really prescriptive. I thought I want to be kind of prescriptive because I want to accelerate things, but I don’t want to be prescriptive about stuff like process. I don’t want to say like, “We have to do stand-ups” or “We have to do Scrum” or “We have to have a product owner.” But I thought, “What if I’m prescriptive about the principles and the values?” As far as being prescriptive goes, that has actually gone pretty well. Things like being open about what we’re working on, visualizing the work, collaboration, and all those kind of things. Then the other approach I’ve been taking that’s actually probably had the most benefit there’s two things. One is I’m pretending like they’re already an awesome team. When topics come up, rather than saying like, “I’ll ask a question about something like, “How would a team handle this?” Rather than saying like, “A high‑performing team would do X, Y, Z,” I’d say, “Oh, I think maybe if you guys did this, that would work.” They look around. The next part that comes in is “You can do anything you want.” I always laugh when Jade does the, “You can do anything you want, but there are consequences.” I’ve been trying to get them to believe in this kind of fantasy land where they live in this reality where they’re already awesome, and they can do anything they want. Some of the things that I’ve done on accident that have helped a lot, we set up pairing stations. One of the things that I was being prescriptive about was collaboration. Rather than trying to work on a bunch of these different projects all at once with a bunch of different people siloing, I said, “Hey, let’s set up a pairing station.” I actually did that for them and made it really easy to use them. It worked out in my favor that no one’s machine was set up to work on any of the projects, and the only machine that was was the pairing station. I just grab [indecipherable 2:27] Jade:  This was a team that hadn’t paired before? They were not Clayton:  Yeah, they’d had a little bit of exposure but not really. Part of the pairing station problem that we had was the monitors were really bad. I went out one day, and I just bought new monitors. I came back and they were all like, “Wow. How did you get new monitors? You didn’t go through IT.” I’m like, “Yeah, I just went and bought them”. They are like “you can do that”? I wasn’t trying to make a case on this but I was like “Yes, I can, I’m an adult. I went to the store and I purchased them and there was this transaction and now we have new monitors”. It was totally an accident but that was I think the first time they saw “Oh, wow, you really can do anything, there was this thing that I thought was impossible but then you did it”. All the conversations we have been having around actual code things or technical practices or what ever, I think the barrier of that’s impossible, I have never seen that before is widdled away at this point. They are willing to pretend now, that they can do any of these things. Anything is possible. If You Tolerate It, You Insist On It Jade:  What are the results that you have seen so far from this experiment? Clayton:  They are making good choices. One of the things that I have been trying to emphasize is that concept of if you see a problem it’s your problem now. If you tolerate it, you insist on it. If you see something that you think there is a better way of doing something, then go ahead and do it. Take ownership of it. It started out where the board was disorganized and people were saying, “I don’t understand what the board means”. “OK, then make it better”. “Oh we can do that”? So they went and made it better. The next day “I don’t understand how the board flows, I don’t understand what projects they are”. Then someone said “I think we should color code them”. Great, go color code them. It seems like they are doing what ever they want, but they are really doing the things that are helping them being effective. I have seen a lot of collaboration. They actually are pairing on everything. It’s kind of by necessity. There is not one person who knows everything, so they’ve gotten so much benefit out of collaborating on the work, I think they are falling in to that as just a habit. I don’t they trying to find a way out of it. They are not just doing that because they need to. I think they are enjoying it and having a lot of fun. The other thing I have seen is at the end of the day, they look like they are mentally exhausted from pairing all day and they look like they are ready to go home. Where before there was a lot of idle time and board thumb twiddling. That is a status quote for that organization. These guys seem like they are really engaged the entire time. Autonomy is Largely a Matter of Perception Roy:  It’s interesting because you brought up the fact that, from your coaching experience it sounds like this is one teams you have been the most prescriptive with, yet they seem to have the impression that they can do what ever they want. Clayton:  I heard a conversation that they were having with someone on their team where they said “It’s really awesome, we just get to do what ever we want”, which is really not the case. If they got to do what ever they wanted they would probably be doing something different, but because I am able to guide them along with their principals, if there is an idea and we’re using a decider, so everyone is trying to support the best idea. So when something comes up they are in the habit of saying “OK, I have this idea.” Make a decider or proposal and it passes. If something maybe needs to get tweaked a little bit, we can just make a new decider, and alter it a little bit. Or we can investigate what that behavior is, and get their intention. One example that came up the other day was, they didn’t want to have a rule about [indecipherable 5:48] overproduction code. I think maybe normal coaching stuff would be like, “This person wants to go off and do their own thing, because they [indecipherable 5:55] “ In reality it was, “I want to have more time to learn by myself. The best way to learn is to actually do the work.” “OK. That makes sense.” They wanted to go home, and to do the work on their own to learn. Many other people in the team thought, “Hey, that takes away an opportunity for me to learn.” We were able to negotiate some way, to talk about how we can satisfy all those needs on the team. It’s like the team is doing what they want, but they are still sticking to the principle of overproduction code is paired collaborative code. What Happens If We Just Pretend Jade:  What do think has been one of the most powerful ideas that you’ve tried out? You talked about pretending. What’s one of the other things that you’ve done, that you think has allowed this team to be able to enter into this new reality, and just accept it? Clayton:  A couple other things that have been really powerful, we snapped them out of the current environment I guess. The very first day that we were a team, there was a lot of [indecipherable 6:55] about, “Why we had formed this as a new team?” “What were doing here,” and “Why did I get picked to be on this team, and not these other people?” I said, “I’m going to go on an adventure, and go to Michael’s and buy some supplies to make a physical board. Who wants to come with me?” This was 9:30 or something. There were two people that looked at me strangely like, “You are going to go where? But it’s work time?” We went, and it’s stuff like that. Like those little moments, where I’m just modeling that behavior of reinforcing that, “You can do whatever you want. You can make the workspace better or the work better, or how you are doing the work, better.” Those are the kind of things that have the biggest wins. Jade:  You took on the authority of, “We can just do this. We can go wherever we want. We can do whatever we want, right out of the gate?” Clayton: Yeah. Because from my perspective, obviously my boundaries as a consultant are much wider than theirs are, at least their perceived boundaries. I tried to maximize that and be super vocal about it. Normally, I probably would have done the Michael’s anyway. I wouldn’t have said, “I’m going on an adventure. Who wants to come with me?” Just that kind of thing… [background noise] [laughter] Jade: That was the Jenga board that just… Clayton: Oh, probably. [laughs] Jade: The life size Jenga that just crushed. Roy: That was my fault. I may have built the Jenga tower up to the ceiling. [laughter] Vanilla Prescription Goes a Long W

    17 phút

  3. 06/11/2013

    How Praising Effort Incorrectly Negatively Affects Your Culture

    Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Jade Meskill: I’m Jade Meskill. Derek Neighbors: I’m Derek Neighbors. Roy VandeWater: I’m Roy van de Water. The Love of Lazy Clayton: Today we are talking about my favorite thing, being lazy. Jade: Oh my gosh, that’s my favorite thing too. Clayton: Really? Jade: Yeah. Roy: Do we really have to talk about it? Jade: I don’t know. Clayton: [laughs] I don’t want to think about it. That’s too much. Jade: [laughs] Good thing we can talk without thinking. [laughter] The Obsession with Rewarding Effort and Hard Work Clayton: So many more jokes to be made. This topic, Jade and I talked about this at lunch. It sounds like, Jade and Roy, you’ve been talking about this a lot. The concept stems from a lot of the clients that we’re working with. We see these teams where they do a whole bunch of work, work, work, work, work, work, and they get praised for all their effort. At the end of the sprint they didn’t really deliver anything of any value, they didn’t really ship anything, the customer’s not delighted. But boy oh boy, they worked hard, and everyone in the room is clapping for them. That feels really disingenuous. I think I heard someone the other day talk about how they stayed up till 5:30 AM tweaking these servers. I thought to myself, “Man, if I had to do that, I would be very upset. I would probably find some way to automate it.” Roy: I’d shoot myself in the face. Clayton: Yeah, that was my next way of saying that. The Hero Culture Jade: I remember living in that world, though. I was definitely part of the “Hero” culture. I could always be counted on to work the extra hours, or do whatever it took to get the job done. I’ve wizened up since then. Clayton: I think it’s interesting because I think we have an “Automate everything” mentality, but there’s so much stuff now that…I used to do that, maybe be the hero, or you want to work the extra hours or whatever. It felt good to do that, like you were contributing a lot, but now it just feels dumb. I’d feel stupid if I do that. Jade: I do too. Roy and I were talking about it the other day. I said, “If you find yourself working that hard to get something done, you’re probably working wrong.” It is so easy to get away with automating a lot of things, not having to do that much work. The problem is, there’s definitely a stigma against being perceived as not working hard. Separating Value from Effort Derek: I think my goal in life lately, maybe it’s why I’m a little more interested in robotics lately, is to replace myself with some form of automation. That is the pinnacle. I think what happens is, people do think that, “If I’m not doing something all the time, people are going to think I’m not valuable.” I keep saying, what is it that makes us think this way? I can’t remember if it was Carlos Segura , or a designer of some kind. He’d said something very profound to me, at one point during a talk. They basically said, “I make three million dollars for giving somebody a logo, and that logo only takes me about an hour or two worth of effort, to actually make the logo. My value is in knowing what to make for a logo, and that’s why I’m worth three million dollars.” The guy who makes the Nike Swoosh, we can all laugh at, “Man, that’s so simplistic!” Think of how valuable that is, or the Coca Cola logo, or whatever. We focus on things that are very low value, and we think that we just have to put in a ton of effort to get any kind of result. I like to say that you have to put in a ton of effort to become an expert, and to become good, to know what the right logo is to do. But that’s not the same thing as, then every logo thereafter, you have to put in tons of effort to get there. I think that’s the misnomer, is people just want to work hard, they don’t want to work at getting good. If you work at getting good, then you don’t have to work as hard anymore. No Tolerance For Wasting My Time Clayton: Jade, you’d talked the other day about…Your definition of “Lazy,” I think, was about not wasting your time. It had something to do with wasting your time. Jade: It’s that I have no tolerance for wasting my time. Clayton: I think there’s a big difference. I’m not opposed to hard work by any means. I think hard work is a great thing, and maybe being deliberate with what you’re doing is very important, and busting your ass to get to do that stuff, but I don’t want to waste my time. Jade: I don’t want to work hard at being stupid. It’s Not Fair, That It Takes So Little Work But Costs So Much Roy: There’s still the “Human nature” component of not valuing it. Clayton and I were talking about his eye surgery, because he just got LASIK surgery. He spent a ton of money, and I think the operation, you said it took five minutes? Clayton: Yeah, basically. Roy: It was all automated, the doctor came in, pushed a button, and you’re done? Clayton: Right. Roy: I could totally see myself thinking, “I paid however much money for this? That’s crazy! I should have paid $5 because it took him 5 minutes!” It’s not like I’d rather have surgery for an hour. Jade: You want the surgeon to work really hard on you, for a couple of hours? Roy: Take a really long time, right. [laughter] Derek: I think it’s the value. If you’re spending $100 or $200 a year on contacts and you go out and you have this surgery, and it makes it so you don’t have to have contacts for 10 years or more, the value of that’s pretty high. Jade: Maybe you just hate wearing them, it’s not even a cost thing. Roy: But the weird thing is that I would actually feel less slighted if it took an hour, than if it took five minutes. Praising Effort as the Default Clayton: I don’t know what it is about software teams that it’s so easy to fall in that trap of just praising effort. I think some of it has to do with, nobody in the whole food chain is very clear about outcomes. If the entire maybe organization or department doesn’t have some alignment about what it means to be successful, I think you just default to back‑patting. Jade: It’s the thing that’s very easily visible. If I can look out in the parking lot and I see everybody’s cars here, and it’s 6:30, I know everybody’s working hard. Man, they must be a great team. [laughs] Roy: But there’s a waste factor to it, too. I may have one guy who’s able to do in an hour what the other team takes 10 hours to do. He comes in and works for an hour and leaves. That gets me thinking, “What if I got him working all 10 hours? I’d have 10 times the capacity,” although maybe the magic to why he’s able to do 10 times what everybody else does is because he only works an hour. There’s a lot of that to it. Optimizing for Automation and Future Laziness Derek: I think some of it, too, is it’s like preventative care in healthcare, or in medicine, or dentistry. I think a lot of times people don’t see the value in automation upfront, because there is performance degradation upfront that pays off in the long term. If I go in and spend 10 minutes, I don’t know, once a quarter or twice a year getting my teeth cleaned, and I spend two minutes every night brushing my teeth, I can prevent really costly damage, and all sorts of repeated visits to the dentist down the road. But if it’s like, “Man, I just don’t have two minutes to brush my teeth every night to maintain that,” that’s ridiculous. Jade: We have this happening at our client right now, where they have a build process that takes one to two weeks to run an automated test suite that they have. They have the capability to increase it by at least 100 times performance. Roy: They know it’ll take less than a few weeks. jade: Nobody will give them the time to invest to speed up their process that much. They think they can even take it to 1,000 or 10,000 times speed, but nobody will give them the time to invest. Now they just waste everybody’s time for weeks and weeks on end, because they refuse to invest that little bit. Derek: I think that that’s a great point. I think that really solid engineers don’t ask because what they do is they say, “Look. We ship stuff late all the time. That’s standard for the industry, nobody’s going to beat us too hard. “If we have to take in the shorts for a sprint or two or for a week, or a month, or whatever to get that 1,000, as long as we get that 1,000 times gain, people are going to be amazed with us 4 weeks from now. Fine, let them be pissed off for two weeks, while we fix this.” I’m not advocating people go lie to their product owners or do hairy things, but I think there’s ways. If you truly believe in automation, you just bake it into what you’re doing. You don’t even say, “Oh, we need all this extra time to go do it,” you just bake it into part of the process. Pattern Matching for Future Laziness Jade: What other ways do we try to maximize our laziness besides automation? Derek: I think I put a lot of effort into being good about pattern matching, so I don’t spend a bunch of time rethinking about a problem to figure out a solution for it. I think I immediately try and just go to my library of patterns. “This looks like something I’ve already done, I’m just going to go to that right away.” I think I spend a lot of time doing that. I just focus in on, “What have I done before?” and, “How does this look like what I’ve done before?” Removing the Unnecessary for Future Laziness Roy: I’m pretty brutal about trying to remove anything that isn’t totally necessary. When I’m talking to a product owner, I’ll try to get everything out

    17 phút

  4. 23/10/2013

    Automated Testing, Everything That Can Be Automated, Should Be Automated

    Jade Meskill: Hello. Welcome to another episode of the Agile Weekly Podcast. I’m Jade Meskill. Roy vandeWater: I’m Roy vandeWater. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Derek Neighbors: And I’m Derek Neighbors. [laughter] Automated Testing Struggling to Go Fast Jade: Very nice. Derek, you had something you wanted to talk about. What was it? Derek: Yeah. I’ve been doing the work with a number of teams, and one thing that I’m starting to see emerge as a pattern is the team’s struggle to go fast. They struggle to work particularly within the Scrum framework a lot of times. Not only are they siloed where they got developers and QA that are separate, but where they don’t have a lot of automation. This could be automation around deployment. This could be automation around testing, so maybe they don’t have an automated testing suite. Or if they’ve got some automated testing suite, there’s still some manual regression happening. Even if they have a fully automated testing suite, they’re not running it automatically. They’re not having continuous integration, or it takes an enormous amount of long time to build. What I’m finding is it’s very, very hard for them to see what performance looks like, because they can’t get over the concept of their current reality. The current reality is, “Hey, it takes five days to run the test suite. There’s no way we can have a one‑week iteration. That’s just impossible. It takes us one week just to test, once the developer’s done with a feature.” Have you guys seen instances, where maybe the current reality or the lack of automation makes it so teams just find…I had somebody specifically today, tell me, “That’s really nice that you stand up there and talk about a 10 minute build. Frankly, there’s no way you’ve ever done that before, because I’ve worked for five different companies, and none of them have ever been able to do that. I find what you’re saying impossible to believe.” Jade: [inaudible 02:06] we have a 10 second build? Roy: Yeah. I agree. I’ve struggled so hard to get a build to take 10 minutes. I don’t believe it’s possible. Derek: In their current reality, I understand that. If you’re a manual regression tester, and you’ve got a fairly complicated suite, it’s taking two or three days to run a single test plan. I can understand how it feels impossible that you could, with any level of comfort, run a test suite under 10 minutes that made you feel like you weren’t shipping crap. Roy: We’re working with the team right now, but we’re not working with working microphones. [laughter] Letting Technology Get In The Way Jade: That’s right. We are working with the team right now that a single test takes two weeks of constant computation, a single test. Clayton: I’ve seen that in a lot of instances where, the technology gets in the way. If you’ve got a java applet that loads a Swf, how do you automate testing of that content? That seems like this impossible thing. I think a lot of people say, “It is what it is, throw my hands up in the air. What else are we going to do but, let those hourly regression people slave away at typing in commands and looking at the screen”? Roy: Along the idea of trying to test a flash out, I think that’s one of the first mistakes that immediately causes your test suite to get larger, and take longer, regardless of whether it’s manual regression or automated testing. That’s when you write the test case last, after everything is done. Jade: Yeah. Test Driven Development Helps Reduce Some Problems Derek: When you write the test case first, you end up using solutions that are easier to test. You don’t run into those things. Clayton: That’s one of my favorite things about doing, not even just TDD, but just test first. Where you have to take into account what easy to test and what isn’t. I’m working with a team that has a fairly large fitness test suite. You can, totally, tell the way they went about using fitness to write this acceptance for higher‑level tests, because it was so difficult to test at the unit level, the only thing they could do was test the big black box of spaghetti code. They were all written after the fact. They were trying to do more of a TDD approach or write unit test. It would’ve been so impossible to write any test whatsoever, if they were actually dedicated to that, they wouldn’t have had to solve that problem in the first place. The reason automation doesn’t get more not popular, it’s because a lot of times team get rewarded for effort. Jade and I were talking about this the other day. If you’re using a lot of effort that probably means you’re dumb. You can be so smart and lazy that you can do a lot of things automatically. If you work in a system or an environment where you rewarded for staying up till five in the morning working on some stupid thing that should be automated, what incentive do you have to automate things? You’re going to get clapped for, and pat on the back if you put a lot of effort into stupid things. Human nature wise, that seems to make sense. That’s like irrational decision at that point. Jade: Yup. If you’re putting a lot of effort, it must be important. Clayton: Yeah. Exactly. Relying on Backstops Creates Bad Habits Roy: The part that’s really difficult especially when you go to test after the fact is to justify the expense of writing a test. Because you have this working piece of software that your user could be using right now, why not just release it, and then not worry about the test? Clayton: I’ve heard regression teams be referred to as backstops and people make a baseball analogy metaphor that’s, “The catcher is supposed to be there to catch the ball and that should be fine, right?” That’s what I think what the developers think of themselves as, “We’re going to do this thing where we’re going to write something, and I’m going to look at it, and I’m pretty sure it works. That’s kind of the catcher, but in case there’s some wild crazy pitch edge case that gets past me, at least there’s a backstop.” Pretty soon, they stop trying to catch the ball and everything is just the backstop. I think that’s what happens. Why would you spend the extra time to make sure no bugs or no defects or problems or no nothing ever got to the regression team, because they’re always there? You know they’re going to be there. If something goes wrong, wouldn’t you rather someone blame them than blame you? That’s always… Roy: Then you get into that whole QA developer rivalry, too, where you hate them because they’re making you do more work. You don’t get to work on new stuff, because they keep uncovering the crap that you wrote earlier. Testing vs Checking Clayton: I really like the way that some people in the QA or testing or whatever community talk about testing versus checking. Those are the things that a computer can do. Making sure that this algorithm works properly in these different cases or whatever. I really like that idea where testing is more about heuristics and looking at, “How does the system function, and what do I expect to happen? What people perceive and is it consistent with the rest of the thing?” All the stuff that you, actually, need the human brain for. Those are valuable things that people could be working on, actual people. Everything else really should just be automated. [inaudible 06:56] should be automated testing. The $465 Million Deployment Mistake Jade: You posted a really awesome article, I think at the beginning of this week, about a case where a company neglected to use automated deployment. In this case, instead of automated testing, but another case where something is done repetitively and there was an opportunity for automation that wasn’t taken. In this case, I think it ended up costing that company $365 million. Clayton: Some trading company, right? Jade: Right. We’ll attach the article to the description, but it was pretty crazy. They break down exactly what happened, and it ends up being, “We just didn’t automate something that should have been automated.” Now it’s human error that comes into play. Business Rules So Complicated They Are Untestable Is a Smell Derek: I see some funniness in that one of the things that had come up in some the discussions today, too, was, “Well, one of the things that QA is really incredible for is our business rules are so complex that nobody understands them. Literally, nobody actually understands the business rule.” The great thing is what we do is we have QA, what would happen is you would basically code the story as a developer, and as you code the story as a developer, my fantastic test plan is going to cover every edge case, so that I can actually tell you how you didn’t understand the business rule. When I think about that, it sets the fallacy that this stuff is so difficult that we’re going to have humans try to remember how it works. Like, “I’m a human, I know that doesn’t work.” Clayton: That sounds like the exact opposite of how it should be. Roy: Right, where if it’s super complicated, and you’ve got this thing, shouldn’t you have the computer be checking that it’s the right thing? Then make it happen faster so that I can get immediate feedback. Derek That’s what I was kind of saying is, “The problem is that if I go and I code this thing up and it takes me five minutes, and I hand it to you to run your test plan, and it takes you two days to give me feedback, that’s really irritating. What if I could run a 10 minute build and get that feedback immediately, and make an adjustment? That’s when it just blew up into, “It’s impossible that you could ever have a 10 minute build.” I think the second pa

    17 phút

  5. 09/10/2013

    Agile Team Standards, Finding the Right Balance for Efficiency vs Innovation

    Jade Meskill: Welcome to the Agile Weekly Podcast. My name is Jade Meskill. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Clayton Lengel-Zigich: I am Clayton Lengel-Zigich. The Efficiency vs Innovation Problem Jade: Derek you had a topic that you wanted to talk about today. What is it? Derek: Yeah, something I’ve seen a lot lately is when teams start to really get agility they really start to get high performing. One of the things they tend to do is go around roadblocks. They tend to start to basically, maybe choose some things that the higher powers in a large organization aren’t comfortable with them choosing. There becomes this divide that starts to say, how come you’re not following standards? Whether those standards are set or whether they’re not set. Whether it’s an architecture thing. Whether it’s a language choice thing. Whether it’s a process thing. You name it. At what point does being agile in supporting the best ideas, and moving forward, and having the people closest to the work make the decisions about the work start to compete with centralization and efficiency? The problem is if everybody uses .NET, then we get the benefit of people can jump from team to team, or we get all the benefit of being experts in .NET. But if you’re doing Ruby and I’m doing Java and you’re doing .NET and you’re doing C# and you’re doing whatever, now we lose all of this efficiency. There’s this tension between “We’re trying to be innovative and just go as fast as possible” versus “Don’t you want to be efficient, and have standards that we get benefit, or this economies of scale?” What have you guys seen in that area? Where do you sit on that sort of thing? Jade: When you started talking about this I remember a time when our team had started to deal with some of this, our Integrum team, and tried to standardize on certain libraries, and certain techniques, and things like that. We kind of went through this phase, exactly what you were talking about. From what I recall it was a total disaster. We were even using the same language at that point in time. Derek: If you guys would all just use Emacs I wouldn’t have been such a [inaudible 02:19] about it. Jade: [laughs] It really hampered the ability for teams to make the right decisions that were right for the project that they were working on. It became this whole committee situation, and in the end we completely abandoned it, because it was not functional for what we needed. Alignment on Best Practices to Minimize Pain, Openness to Explore Derek: I see a couple of benefits and problems with it. I think that it’s nice to have things standardized. The thing I can remember at the time was, everybody was setting up servers a different way. When I had to deal with a problem with some client, and I went to go log into the server, shit was all over in different directories. People were using different stuff. When you really talked to them, there was no like, “Oh, we did it this way, because of this.” It was just, “Oh, I don’t know. I liked Apache, so I used Apache even though everybody else was using Ngnix. Great. Add in an extra four hours to me, figuring out what the problem was, because everything was non-standardized. I think one of the things that we started to do that worked really well, was to treat things more like an open source project. If somebody had a good idea, people would support that. If people wanted to fork it or do something else, there wasn’t a whole lot of, “No, you can’t do that.” But if it bit somebody else in the ass, people were not nice to you about it. It’s like, “Hey. If you weren’t going with the best idea that everybody had, fine, that’s great. Do your own thing. But don’t expect a whole lot of support when you’re out on the island all by yourself, and you’ve gotten yourself into trouble.” I remember one distinct incidence where we were talking about moving, I think, to Home Brew or something. Nobody really wanted to move to that. We were a little concerned. Somebody said, “No, I tell this is the best thing ever,” and somebody said, “OK. Well, if something goes wrong, I can punch you in the nuts if it’s problem.” The person said, “Yes, it’s fine with me. I believe in it that strongly.” I think sometimes to me it’s not about having standards in the sense of written rules and policy. I think that’s when you get in trouble. But I think when you have — I won’t say, best practices — but when you have some consensus and some alignment about trying to be good, as long as you have the door open to explore, and try new things, you’re OK. It’s the minute that it’s like, “Well this is the way we do it, and you can’t do it any other way, no matter what.” That’s when it gets really dangerous. Technical Darwinism, The Easiest Path Becomes The Standard Roy: I think the idea of standards — I don’t really like the idea of standards. I think that if you have a particular way that you want something done, and you want to have everybody do it that way, you need to make that the easiest path for everybody. In your example, if I want somebody to use Apache, I’m going to make it really freaking easy to set up an Apache installed the way I want it set up. It’s going to be so easy, that you choose Nginx, but it’s going to mean a lot more work for you. That way I’m not forcing my standard down on you, but I’m giving you a lot of incentives to use my standard. Derek: I think that tends to be the open source model. Which is, if I fork it and make it easier, people will use my stuff instead of your stuff. Jade: It’s technical Darwinism. Derek: Right. But it’s a lot different than saying, “Hey. Use mine, or if you don’t use mine, I’m not going to help you.” Jade: Right. Mine was approved by the architectural control group. Unreasonble Standards Get Ignored Roy: One of the things I’ll say that I see on a lot of new teams too is the opposite of that. What happens when somebody says, “I think that we should have 80 percent coverage, or 100 percent unit tests.” Or, “We should do this instead,” and now you don’t allow anything to come into this source tree that doesn’t have those. Isn’t that a standard? Clayton: Yeah, but that’s a lot different all of a sudden. Derek: Oh, so your standards are OK, but my standards aren’t. [laughter] Derek: Oh, I see you’d think, so I am maintaining a project, and you’re trying to contribute to it, I want to say that I have a standard that says, at least 80 percent source coverage, before I will take your request? That I totally agree with. I think that’s fine. I just disagree with the idea of me enforcing my standards on you, on your project. Jade: I think Darwinism also comes into play there. If your standards are unreasonable, and nobody can give back to you, well people are going to stop working with you, and you’re going to die and wither on the vine. Derek: Right. Standards Help Reduce Wasting Time Clayton: I think it’s one thing for a team to be principled, and have certain values to say, “We want to be technically excellent,” or something, and that means that we’re going to really value test driven development. Or, “We really care about testing,” or something like that. I think that’s fine to have standards like that, because I don’t think those are so much like rule standards as they the values of the team. Do you want people in the team to live the values? I think those are a little easier pill to swallow. I am personally a fan of having things more standardized on it at the team level. I think there’s so much time wasted and dumb on purpose stuff that goes on, around people trying to use different things in their little pet project and [inaudible 07:13] work. Derek: Why is it OK at the team level but not at the org. level, or at the company level? Standards at Team vs Organization Level Jade: I think that at the org. or company level, the values or the influence those have, I think those just get more and more abstract. Clayton: Yeah, they’re too far removed from the problem that’s being solved. Danger in Valuing Experts of the Standard Jade: Yeah, I think if you were to say, “We have to use Java for everything,” that might not be the right thing for everything. If your biggest problem is that you have people that work for you, that can’t work on your Java project, and then go work on the Ruby project, you don’t want those people working for you, right? You’re not losing efficiency because there are two languages. Derek: Why would I not want the expert? Why would I not want the guy that wrote Java to work for me, and he doesn’t want to work on Ruby. He’s got 20 years invested in that. He is the absolute best person ever at that. Jade: Right, but you’re going to get the person that’s the best person at Java, but that’s not really where you’re going to get value out of using some particular technology. It’s not like if you took that person that’s a 20 year Java expert, that’s all they’ve ever done, and you put them on some project, they’re going to instantly make it better. Derek: But what if I believe that the person that knows 20 years’ worth of Java is better than the person who knows six months’ worth of Ruby? To me, even though Java might not be the right tool for the job, this guy knows so much about Java. This girl knows so much about Java, that they’re going to do it better anyways, a better tool to do it, just because they’re more experienced. Roy: I would challenge your beliefs and say that maybe your beliefs are wrong. Clayton: I don’t doubt that that’s possible. I think if you took someone who’s an expert chef and you give them a bunch of crappy ingredients, and a crappy situ

    17 phút

  6. 02/10/2013

    Multiple Commitments and Multitasking in Agile Organizations and Teams

    Jade Meskill: Hello, welcome to the “Agile Weekly Podcast”. I’m Jade Meskill. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Why Do We Fall for the Multitasking in Agile Trap Jade: Today, we wanted to talk about the dangers of multitasking in agile and maybe a little bit about multiple commitments. Roy, we’ve been having some trouble with this lately. Roy: Self-imposed trouble. Jade: Yeah. We should know better but we still fall for the trap. Why do we keep trying to multitask? Roy: I don’t know. I think it’s our arrogance and thinking we’re different, and that somehow it’s going to work for us when we know it doesn’t work for anyone else. Jade: So, because we’re really good at this, we can multitask in agile when all other humans can’t. Roy: Right, even though it’s miserable and no fun at all. Jade: What do you think Derek? Have you struggled with multitasking in agile? The Organizational Multiple Resource Trap of Splitting People’s Time Derek: I’m too dumb to do one thing, much less two things at the same time. I see a lot of teams struggle with it or actually organizations. Well, I see teams and organizations. I see organizations do it with the multiple resource trap. I think of somebody is this logical thing that has 100 percent. Because I think of them as this logical binary bit of 100 percent, I can take 10 percent of them and give them over here, 30 percent and give them over here an 60 percent and give them over there. On paper that sounds really fantastic, but for whatever reason it just doesn’t ever seem to pencil out quite right. I see that trap a lot. Tearing a Person in Half is a Powerful Metaphor Jade: Interrupt you real quick. That reminds of a cool exercise I did once with a group of managers, who were really struggling with understanding why nothing was getting done. I had them write out an individual’s name on an index card. I had them do that for their entire team and then I had them go and layout all the projects that everybody was working on. We put the projects up on a board and then I had them say like, here’s John. How much of John is working on Project X? They said, oh about 20 percent. So, I tore about 20 percent of that index card off and you should’ve seen the look of horror on people’s face that I’m like tearing this person into pieces. I stuck that up by the project and said all right how much is on this and that? We went through and by the time we were done there were these tiny little scraps of people everywhere all over this board. Because they had way more projects than they had people and that visualization of that problem really sunk in, that holy crap we are really doing something very very wrong. The No Projects Movement Time Fallacy Derek: I think that’s becoming a common trend very similar to the no estimates hoopla, I think you’re starting to see a no projects thing emerge, which is… Jade: Is that from you? [laughs] Derek: No, I said it a few years ago and kind of dropped it, but I think people are picking it back up. I think what people are realizing is that when you do things by project. Projects ramp up, and ramp down, and have overlap. You have to start tearing people. Pretty soon when you do that, you get 10 percent of people and the problem is that it’s never that clean. When I say “Jade, 50 percent of your time will be on this, and 50 percent on this other thing, and Roy, 50 percent.” What happens is the two projects both need 100 percent of you at the exact same time. It’s not one week I need 50 and one week I need 50 and it works out great. I need all of you right now, and the next week I don’t need you at all. It never is during the same time, so you just get into this total chaos that starts to ensue. It’s crazy to see how much it helps people to not have that burden, to not be a slave to multiple masters. When they can just say, “I’m doing my best work on this and I don’t have to be constantly thinking about this other thing at the same time I’m trying to be focused on this.” It’s amazing how much freedom that gives people. Which Project is My Priority Roy: There’s another interesting effect that happens there too. Which is when you’re working on one project and the second project normally doesn’t have a whole lot of pressure behind it, but now all of a sudden it does. Even though the project you’re currently working on has a high amount of pressure, I’ve noticed that now relatively speaking the other project feels like it’s way more important because it’s more important than it normally is. It makes you way more willing to interrupt what you’re currently doing to work on the other project, which is weird. Even though both are more important right now, because it’s relative importance relative to its past is higher, you interrupt yourself and you get into this weird thing where you’re interrupting between the two projects, and you interrupt your interruptions, and it just keeps going deeper. Coordinating Availability Derek: I see patterns too…of one style of pattern is that everybody on the team is a percent, so the whole team that is working on this thing, this product or this project, or whatever it is. All of us are some percent of our time working on it. The product never gets momentum because I have to coordinate my 10 percent with your 20 percent, with your 30 percent, and we can never find the time to meet because we’ve got meetings on other stuff. We just can’t even coordinate, it’s a total nightmare. Or the other thing that I see is that almost everybody on the project, or the product, is specifically dedicated to that thing and it’s one or two people are a percentile and then they’re like the outcasts because it’s like, “You’re the bastard we can never, ever depend on because you’re on this “other project,” or this other team. We’re having to compete with you, or for your time, and that’s a burden…” Jade: Which is usually not that person’s fault. Derek: No, it’s not… Jade: But they bear all the guilt, and the brunt of all of that… Roy: Right… Roy: If you insist on it…If you tolerate it, you insist on it, so they bear at least some of the guilt. Using Split Resources as the Scapegoat Derek: Well, I think what happens is they become a scapegoat that they can’t avoid. If I get Jade 20 percent of the time on a product, and Jade is a potential bottleneck for me, I can very easily say “It’s not that my work didn’t get done. It didn’t matter that my work didn’t get done because we didn’t have enough of Jade’s time…We wouldn’t be able to deploy anyways because he’s the Deploy Master, and he wasn’t available anyways, so…” It allows all this weird behavior to start to happen, total victim mentality of “Well, you know, XYZ are roadblocked, so that’s why we didn’t get it done.” Roy: If you’re that guy, though, or the team that doesn’t allow that type of b******t to get in your way, and don’t make excuses, it’s really easy to stand out above the rest. Jade: How many teams have you worked with that are in that condition? Roy: Only a few, but I remember every one of them, and they all stand out, because… Jade: Right…It’s not very common. Derek: The great thing about standing out is it makes it really easy to cut your head off. [laughter] Bucking the Norm Causes Issues Derek: Which is the other thing. When you start as a “Don’t even bother giving me that 20-percent-guy, the 20-percent-release-engineer, because we’ll just do our own releasing.” Now you’ve pissed all over the release teams. When you’ve got a department of 10 people that are the database team, and they’re used to controlling everything about the database, so they give you graciously 6.5 percent of a database engineer to deal with your database stuff. If you’re the team that just says “We’re willing to stand above the rest. F- it, we don’t need the database engineer, we’ll handle our own database,” now you’ve just created a shit-storm because you’ve threatened their entirely livelihood. “If you won’t take 6.5 percent of us, what happens when the next team won’t, and the next team won’t, and the next team won’t…” Roy: Their livelihood should be threatened. Collecting Resources to Build Your Empire Derek: “Then, we don’t have a team.” That causes all sorts of other angst. I think that’s one of the reasons you see this multitasking in agile, or this dividing up of resources. It’s basically empire building. If I can build an empire of this thing, then divvy it out as a scarce resource, I have a lot more power than if I just focus on a small team. Roy: It’s like organizational [indecipherable 8:04] union. Derek: It really is. If I can have a strangle-hold on you, whether I’m an architect, a [indecipherable 8:12] , or whatever, like these siloed groups that “You only get a percentage of my time. You have to plan everything around me, because if you want whatever new thing approved, and I’m the only group that can approve it, and I can’t get you on my schedule, tough to be you,” that’s the way it works. Roy: “F- that. I don’t have time for that. I understand that you’ll be stepping on some toes, and people are going to get pissed off, but tough.” Nobody has time to sit and wait to be the six percent. Derek: I tend to agree with that, but I think that’s how those empires built, as people get fearful of “We don’t have somebody who’s a certified…” Roy: “Or we don’t want to piss off that part of the organization.” Derek: “Or we don’t want to piss off that part of the organization…” Jade: “They may have a lot of power.” Roy: “They may play golf with the boss, or something.” Multi

    17 phút

  7. 24/09/2013

    Asking For Help, The Low Cost, High Value Action Your Organization Is Missing

    Jade Meskill: Hello, welcome to another episode of the Agile weekly podcast, I’m Jade Meskill. Derek Neighbors: I’m Derek Neighbors. Roy VandeWater: I’m Roy VandeWater. Asking For Help Can Feel Silly Jade: Roy, will you tell me what we’re talking about today? Roy: Today we will be talking about asking for help. Jade: Oh! Will you help me figure out the next question? Roy: No. [laughter] Jade: Derek, will you help me with the next question? Derek: Yes. Jade: What’s the next question? When Should You Ask For Help Derek: The next question is, “When should you ask for help?” Jade: When should you ask for help? Roy: All the time. Jade: All the time? You just don’t know anything? When Shouldn’t You Ask For Help Roy: When shouldn’t you ask for help? Why Don’t People Ask For Help Jade: That leads to a good question. Why don’t people ask for help? If you should do it all the time, why don’t people do it? Roy: I think a lot of people are probably afraid to be perceived as not knowing something, as OK as that is. Obviously, there’s nobody in the world that knows everything. Jade: Do smart people ask for help? Derek: Sometimes. Roy: Wise people ask for help. I don’t know about smart people. Derek: I think there’s some cultural baggage around that. In some cultures it’s perceived as if you ask questions it means you’re dumb. Roy: Yeah. Jade: It’s a sign of weakness. Roy: Yeah. I’ve talked to people where they feel they ask questions during a job interview, and they feel like the candidate Googled an answer, for example, then that is looked down upon. That is a point against the candidate, and they’ll probably not get hired. Jade: What do you think it is? Roy: What, Googling? Jade: If somebody did that in front of you while you were trying to interview them? Roy: If they don’t know the answer, and they’ve asked me and I don’t know the answer, and they don’t Google it, I would be like, “Have you not heard of this? Have you been living under a rock?” Jade: [laughs] Roy: If I’m hiring people, I don’t care if they know the answer themselves, I just want them to produce the product. If they rip it all off of Google, as long as it’s legal I don’t care how they get around it. Putting Yourself In Ask for Help Debt Derek: I think there’s some stubbornness involved, also. There’s some people who feel like “If I give you something you have to give me something in return. Therefore, if I ask you for help, then somehow I’m enslaved to you, and you could pull that card out at any time.” Jade: So I’m in “Help debt.” Derek: Maybe I don’t want to get into debt. Being Forced To Help Roy: Maybe the opposite. Because there’s also a lot of cultural baggage around being asked for help. Especially when you look at how people ask for help normally. They say, like, “Derek, please close the door.” It’s not really asking, so you don’t get to really say “No.” By me asking for help, I’m kind of socially obligating you to help me. Derek: If I said, for example, I need one of you to volunteer to [indecipherable 03:13] this podcast, that would not be asking for help? Jade: No, you’re kind of commanding help. Roy: I’ve heard that called being “Volun‑told.” Jade: Volun‑told, yeah. Derek: My immediate reaction to that is, “Screw you, buddy! I’m not going to help you. Don’t tell me what to do.” I know that I don’t like to ask for help. I have a hard time with it. I like to know things, and I like to learn things and figure them out. I’ll definitely Google things, I don’t have a problem with that. But maybe the more subtle or insidious things, that I’m surrounded by smart people who probably have the answer, but instead I’m going to be dumb and learn it the hard way. Missing Trust Roy: I wonder, too, if there is a bit of trust that’s missing. If I ask somebody for help and they provide it, now all of the sudden I have to take their help, almost, because I asked for it. I’m not saying you actually have to, but socially it’d be really awkward if I asked Derek for help, and he gave me help and I said, “Nah, that’s not the help I’m looking for. I don’t want your help anymore.” The Cost of Asking for Help Jade: Yeah, I think that we think it’s this really high cost thing, too. In reality the amount of time it takes me to ask for help is the entirety of the investment, and if I get the help I gained a whole lot for the amount of time that I asked for it. But if I get a “No,” or I get help that doesn’t really apply, I’m no worse off than I was before I asked for help, except for the small amount of time I spent asking for help. I think that we forget that. We forget that it’s a really low cost thing to do, because it takes a lot of courage to do it. It feels expensive even though it’s really cheap. I think for me, a lot of times I’ll be OK at asking for help if it’s present and in my face. If I’m sitting here struggling with a technical problem and the two of you are sitting in the room, I’m probably pretty likely, the minute that I get blocked, to ask one of you two, because I know you’re both really bright and know technology. But if the two of you aren’t in the room, but you’re on the end of a chat channel across the way, and I don’t have that chat channel open and I run into the exact same problem, I might fight with it for 30 minutes before I go, “Oh, wait! I could get ahold of them on IM!” Sometimes I think presence makes it difficult too. If the people that we think are available to be helpful aren’t immediately present, we don’t think about…the barrier of typing an email and waiting 10 minutes for a response is probably still better than beating my head into the wall for 30 minutes. Or we think that people maybe don’t know the answer. Gangplank is a really interesting place, which is a collaborative workspace that we’re in a lot, where we record this podcast. It’s not uncommon, if there’s 50, 60 people in the room, that you might pop up and say, “Hey, will somebody help me by telling me where a pair of scissors are?” That’s really low‑cost, and the reality is somebody probably knows where those scissors are. But if I sit there and look at all 50 people, and I say, “I have no idea which one of these 50 people would know where the scissors are,” I might not ask any of them. I think it’s getting over the barrier of, even when you don’t know who can help you, sometimes just saying, “I need help” is helpful. The person drowning that says, “I’m drowning,” generally gets a life raft. The person that doesn’t say that doesn’t get the life raft. People Like To Help Roy: It’s interesting, because people in general like to help. People like to receive the attention and to take advantage of knowing something that other people don’t. I think there’s even probably a little bit of, I don’t want to say it’s malicious, but a little bit of one‑upmans. Like, “Hey, I’m helping you, because I’m able to do something that you can’t, so that gives me a little bit of self‑confidence boost,” or whatever. In fact, I’ve even seen people help when it’s not even asked for and when it’s not wanted, just to have that either one‑upmans, or just to help out. Derek: One of the things I find very interesting is that people do not like to ask for help, but damn, do they like to give it out, even when it’s not solicited. Jade: [laughs] Derek: We really like to rescue people, but we don’t like so much to ask people to help us, which is really odd to me. You think that it would be… Roy: The other way around. Derek: An even metering out. Roy: Because helping people out has a way higher cost associated with it. It actually takes time. Derek: Something in our wiring makes us want to help people. If we know that we like to help people, even when they don’t ask for it, wouldn’t we think that, when we want help, that… Jade: People who want to help? Derek: People would really want to help, but it’s like we’re wired the opposite way. Creating a Culture of Asking For Help Jade: If asking for help is cheap, and waiting too long to ask for help is very expensive, how do you create a culture of asking for help? Derek: I think the same way you create a culture for anything you want, is you just have to model the hell out of it. I think you have to insist on it. You have to constantly be in a mode for modeling that behavior, potentially even asking for help when you don’t necessarily need it. I think you also have to model that it’s OK to say “No,” so that you don’t create a culture where people feel obligated to help when they’ve got other priorities or other things, and that people don’t get offended when they’re told “No,” that they get a healthy dosage of what it’s like to ask for help and get it, but also ask for help and maybe not get it, or have it delayed, and that that’s OK, too. It doesn’t mean that if I ask you for help and you say “No,” that it doesn’t mean you’ll never help me again. Jade: Or you hate me. [laughs] Derek: Or that you hate me, or there’s something personal, but that it just might be you’re really busy trying to do something else. Roy: Or have no knowledge to help you. Derek: Or I don’t have the ability to help. I think it’s just modeling that a lot. I think you have to model it a lot. I think it happens pretty quickly when you get results. I think when you ask for help and you get help, it feels like you’re cheating. It’s almost like, “Damn, I’ve got the stables easy, but [indecipherable 09:19] smacking this sucker over and over again, and it’s getting easier and

    16 phút

  8. 18/09/2013

    Building Great Products Requires Presence Over Planning

    Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich… Roy VandeWater: I’m Roy vandeWater… Jade: I’m Jade Meskill… Derek Neighbors: I’m Derek Neighbors… Jim McCarthy: I am Jim McCarthy. You got me in here. [laughter] Jade: We found this guy… Jim: A major breakdown in their standards has occurred. [laughter] Jade: …stumbling down the street, away from shelter. Clayton: It’s like the Hotel California. You may enter, but you may never leave. Jim: This is my second time to Chandler. There’s been no trips up to Crystal Lake. I can see that the mass of things…It’s pretty cool down here. Actually, it’s pretty hot. But it’s a pretty cool place to be. I’ve got to admit. So, I’m glad I’m here. Roy: That’s good. Clayton: We’re glad to have you. Jim: I’m going to get you up to Crystal Lake. We’re going to do the pod cast up there, too. How Important Is Prioritizing Presence Over Planning Clayton: Today we wanted to talk about presence over planning. Presence is more important than planning? Jim: I’m willing to talk about that. I was just suggesting that as the basis of our starting this podcast. Clayton: That seemed like a really good idea. I figure we should talk about it. Jade: We are present, and there’s been no planning. What a better opportunity? [laughter] Jim: [inaudible 01:21] could pretend there was planning. We’re doing a boot camp right now. We’re in the first part of the boot camp and it’s just starting to get rich. I get off when they start to get off. I’m excited, enthused, and happy and I’m in. Jade: Welcome. Clayton Welcome Roy: Welcome Jim: It’s beautiful to watch. Jade: That’s awesome. Much better than yesterday. That’s for sure. Jim: It’s amazing how a little bit of time and persistent focus from their boss makes a big difference. What’s The Trouble With Planning Clayton: What’s the trouble with planning? Jim: It’s just fictional. It’s like science fiction. You could write a good science fiction book. That’s something to do about [inaudible 02:12] that’s basically a plan. I have always found, especially when it comes to talking, that your presence will trump your planning every day of the week. I’m in this room. We got four high end or nice microphones. We’ve got a mixer. We got four men, plus me. Whatever that means. [laughter] Jim: I’m looking from my perspective, there’s four men here. Anyway and we are going to talk because we are getting to be friends and its probably going to be interesting cause we are in the middle of this interesting experience. So, that’s what I meant by our presence would probably trump… Jade: Uh, I’ve definitely been in planning meetings where there is no presence… [Others agree] Jade: … those are really terrible… Clayton: It’s going through the motions, but, uh, half the people are thinking about … Jade: …they are just doing work, or… Clayton: …yeah, they’re just trying to get through it. Jade: And the results are usually very poor. An Involved Team Is More Energized Clayton: Yeah, I found that you can energize a team if you get everybody involved in what they are doing, which I think is getting towards having presence over planning, so that they actually feel like their physically there, they feel like their mentally there and they feel like they are actually in, you know, they are in to what’s going on. That makes a bigger difference then any other game or gimmick or technique or whatever anything I would ever really use. Roy: So it’s the specific value that we are trying to get out of both presence and planning. Like, we are saying presence over planning, but in terms of what? Planning Is Not Doing Derek: So to me, like, I almost think that planning is evil. It’s almost like discussion in the sense of, planning is not doing, right, if we are planning were not doing, we are planning. People get bogged down in the, just like they get down in the perfection of doing, so they never ship. If you just do and never ship that’s a problem too. Well if you just plan and never do, that’s a problem. And I think that if, to me, if everybody is present, like really emotionally present and really wants to do great things, great things will happen by people that are present doing things. Roy: So then… Derek: …I think planning kills energy, like, I mean that… Clayton: …as far as a formalized process of planning? Derek: Yeah, like, lets not do anything, lets just sit and complain… What’s Next Instead of What’s Now Mentality Jim: …like ‘what are we going to do next?’ That’s what it’s all about. Instead of ‘what are we doing now?’ Derek: Right. Clayton: If you look at the boot camp, the beginning of it, before people have any alignment whatsoever, and people aren’t really present, it’s all about planning like, ‘when are we going to do the next thing?’ and ‘when’s this going to happen?’ and all that stuff. And then when the people become present, like Derek said they are kind of like emotionally in and invested in it, that I think that’s when the planning doesn’t feel important anymore. It just comes together… Jade: …the facade falls away… Clayton: ..yeah, like you don’t know how it happens, but it happens. Roy: But you still need some kind of urgency, like, you need an urgency to achieve some goal. So, I feel like that’s a really light form of plan. Like, you have to be doing something. You can’t just put a group of people in a room together and say, ‘be great, whenever you get around to it’. [laughs] Jim: …and whatever medium you choose, and, well sort of we are saying that in this thing, but… Derek: …but we are giving them a timeline… Jade: …right, they have been given a goal… Jim: …given a goal by a boss and the boss hasn’t been relenting. The Assignment Is More Important Than The Plan Derek: To me, that’s absence of an assignment. A team needs an assignment. I don’t necessarily know if they need a plan. Clayton: I’ve seen plenty of plans without an assignment. Roy: That’s true. Jim: I’ve seen a lot more plans than achievements. There are tons more plans than achievements, right? Clayton: Yep. Go Do It, Then I Will Talk About It Jim: Michelle’s got this thing that usually annoys me, but she’s always right about it. If she wants to discuss that something that isn’t creative, it’s like, “Oh, I’m not going to talk about that user interface. Go do a user interface and then, we’ll look at it.” But to talk about it as if it had merits of various sides of various arguments and treat it as if it were already done, she just refused to do it. It’s always good advice, so we have a fight. Jade: Well, that’s real and you can fight over the… Jim: It’s not what’s real, we can see the work. Opinions are like butt‑holes, everybody’s got one. Jade: That is the ultimate expression though of having a highly iterative process, not an incremental process, but an iterative process where, “Let’s just create something. Get it out there. See if it actually does what we want it to do. Then, let’s talk about what it doesn’t do and let’s go make that happen.” That’s where a lot of Agile teams get hung up is they focus on going through the motions of following that process instead of looking at the product that they’re creating. Ultimately, looking at themselves as the team being the ultimate product that’s been created. It’s Not About Doing Agile, It’s About Doing Something Meaningful Derek: I don’t know how many times we hear, “How can I measure that we’re doing Agile right?” It’s like, “Who cares if you’re doing Agile off, you’re not doing anything meaningful with it.” Jade: Are you shipping? Are you delivering great products? Then, you’re doing it well. [laughter] Jim: Exactly. What If Everybody Just Trusted Each Other Clayton: Someone asked me yesterday, they just got out of the experience of having this painful process of deciding something in this big group which planning is usually a bunch of people have to decide something and nobody ever wants to, competing interests and everything. They were asking me, “Why is it so hard?” I asked them what it would be like if it were easy. The laughed and they’re like, “The easy answer is everybody trusts each other. People could just go do stuff and it would be OK with the group.” I was like, “Yeah, that’s pretty good.” [laughter] Clayton: That’s how it goes. That is the easy answer, right? You can imagine if you had a planning meeting where the user interface thing comes up, rather than everybody arguing about what it should be, it’s, “Yeah, OK. We got that.” Then, you go do it…. [crosstalk] Jade: I like the idea of not discussing it until it’s been created. Agile Hates Process Derek: Some of that is process starts to become more a crutch for bad behavior. I find myself more and more getting frustrated as people say, these clients tend to ask, “How do we know whether we’re doing Scrum well or doing Kanban well, or doing whatever it is? How do we know our process is working?” I say, “I hate Agile,” because I hate process. In reality, Agile hates process, too. It actually says, “Individuals and interactions over processes and tools.” How do we get to the point where everybody who’s “doing Agile” is arguing about process when we should be valuing individuals and the interactions of individuals over those processes and tools? One of the things I love about boot camp is that it melts all of that away and it just gets down to people. Invariable, whoever

    29 phút
Xem tất cả (141)

4,6
/5
18 Xếp hạng

Giới Thiệu

The Agile Weekly crew regularly discusses topics related to agile, scrum, kanban, extreme programming (XP), software craftmanship, systems thinking, retrospectives, teams, culture and software development.

Thông Tin

  • Nhà sáng tạo
    Agile Weekly Crew
  • Năm hoạt động
    2009 - 2013
  • Tập
    141
  • Xếp hạng
    Thô tục
  • Trang web chương trình
    Agile Weekly Podcast

Bạn cần đăng nhập để nghe các tập có chứa nội dung thô tục.

Luôn cập nhật thông tin về chương trình này

Đăng nhập hoặc đăng ký để theo dõi các chương trình, lưu các tập và nhận những thông tin cập nhật mới nhất.
Chọn quốc gia hoặc vùng

Châu Phi, Trung Đông và Ấn Độ

Châu Á Thái Bình Dương

Châu Âu

Châu Mỹ Latinh và Caribê

Hoa Kỳ và Canada