Clayton Lengel‑Zigich: Welcome to another edition of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Joining me today, we’ve got Gil Zilberfeld. Gil, can you tell us a little bit about yourself? Gil Zilberfeld: Thank you for having me, first. I’ve been in software for something like almost 20 years now. Currently, I am the Product Manager at Typemock, which is a company that creates tools for unit testing. I’ve been experiencing working in the Agile field for almost seven years, now. Working in a Typemock team, as well, working in Agile and modified Scrum, a lot of experience there, as well. Agile Management Clayton: OK, great. You had mentioned that one thing that was interesting to you lately, was the topic of management. I’m guessing management in Agile environment or Agile organization? You specifically mentioned how managers and developers are growing apart. Can you explain that a little bit? Gil: Yes. You know that managers and developers have for decades been growing apart. There was no trust between the two groups. When the managers asked developers how long it will take to finish the project, whatever the developers told them, they multiplied by three, immediately. From the developers’ side, managers were always keep exchanging everything and harassing them. Let’s say the developer did the screen and then the product manager’s passing by, looking over his shoulder, saying, “That’s not yellow enough,” and “You need to change that.” So there’s a lot of mistrust. Agile was supposed to be the great coming together of things… Clayton: Fix all those problems. Scrum Leaving Developers Behind Gil: Yes. Some of it really does it, if it’s done correctly. But the way I see it, in the last few years we see Scrum taking over as the winning Agile method. I’m not saying there’s a problem with it, but there’s a little bit of a problem. [laughs] And that is, it left developers behind, because Scrum declared that regardless of the Scrum practices which are communication practices the developers should select whatever practices they can do in order to support working software. This was very acceptable from managers because they understood communication practices this is why Scrum actually won because it was easy to sell to managers. But once they accepted Scrum they didn’t do the next step and let developers pick the right practices for them to make sure that they can produce software. For example, I was at a conference a year ago, something like that, and some mini conference something like two months ago. Two separate companies ‑‑ very large companies ‑‑ that one of them decided to go with Scrum as its methodology, the other one decided to go Lean. And both of them, at both times, did not even include developers as part of the process. Again the developers feel that they are left behind and I think we can see the backlash in the way that developers are forming now craftsmanship groups, right? Clayton: Right, yeah. Taking some of the technical excellence practices, or maybe, I see a lot of teams that have adopted Scrum. Usually because it was sold to management and management made them do it, but then sometimes they’ll adopt some Extreme Programming XP kind of practices, maybe continuous integration or pair programming, something like that. They try to augment it a bit. Gil: Yeah and this will actually make Agile work because second statement in their Agile manifesto talks about working software. But if companies don’t do that, they just buy into Scrum and they leave the developers outside they won’t get working software. And that’s because in a few years, unfortunately [laughs] people will start blaming Agile for being snake oil because… Clayton: Scrum, I think they make it clear, if you really read into it that they say you can augment the process with certain things, but there’s so many companies that you’re getting at, that will adopt Scrum and that’s all they do. So, you’re advocating for the developer. If they don’t include the development team, or the people that are doing the work, so to speak, and they don’t have some way to improve their practices then you’re going to end up with non‑working software it sounds like. Gil: Exactly, and these are the software companies. Almost every company today is a software company because software is such a core part of the business. The problem is that, we’ll see in a while, people are just being angry, not only at the people who sold them Scrum, but the developers because Scrum was originated by the developers. I hope this will not happen because basically there is a solution for that. The solution is that companies will understand that Agile is not just Scrum. You need to do all the things you can do in order to develop correctly and get software that works and high‑quality software. Unfortunately, what happened in a very few years is something, basically, if we wanted to succeed, we should have gone another route because processes like this take awhile to get absorbed into big companies. How Can Managers Help Developers Clayton: If I ask you, if I’m a manager and I’m listening to the podcast and I’ve got a Scrum team, by direct reports, I’m a functional manager and I’m realizing as you’re saying all this stuff that the developers aren’t really included and they don’t have any particular practices on their own and they just follow the Scrum rules. They do the ceremonies and all that stuff and I’m convinced that I need to help them to do more or maybe help them with the technical practices, what’s a good first step? What could I do to help get my team started on the right track? Gil: The first thing is to start listening to them because the mistrust we have is because both sides don’t listen to the other side. Specifically, for developers to give them some confidence in the other side and that’s just to remember what happened last time when we tried to implement a new practice. Management needs to take the first step and give enough room to the developers to decide what’s good for them. In terms of practices, XP practices are great, code reviews, pair programming, any testing, everything there is great, but we need to, first, as managers, to make the team, the developer team, feel they’re empowered enough. I don’t like the “empowered” word really, but they are empowered enough to pick practices ‑‑ not for short‑term ‑‑ long‑term, and to keep practicing and make themselves better. Without it, the developers will just think that the managers have the new flavor of the week working for it. They will wait for the winter changes to come about. They won’t really go into stuff. They know it’s going to last. QA on Teams Using TDD Clayton: I know you’ve got a lot of history and experience with testing, unit testing specifically, CV kind of stuff, but in terms of maybe the bigger picture, a lot of sprint teams or Scrum teams, they will have a QA person, maybe have an embedded QA, sprint tester, whatever they call it. How does that person fit into that structure? Most Scrum teams that I’ve worked with that have developers and QAs as separate roles, they do these mini‑Waterfall things where the developers do all the work and, then, the QA people do their work. I’m just curious what your take is on that. How do you think those two roles can be cross‑functional? How can the testers, someone that has more of a QA background, how do they fit into the Scrum team that’s maybe doing TDD that has a very good testing culture on the development side, but maybe not so much on the QA side? Gil: It’s funny because I was something 10 years ago, the product manager in another company. Without knowing about Agile and roles within the Agile team, I attached testers to develop, in an organisation that there was separation before that. I did that because it made sense. The [inaudible 10:03] as developers were doing a unit testing, but it was automated. We were doing some kind of manual unit testing. Of course, manual testing by the testers, but putting them together actually they did talk a lot of things. First, they started talking to each other instead of just blaming each other for “you found my bug” or something like that. They actually sat together, testers and the developers, on the developer’s machine. So instead of waiting for integration, which obviously was painful without automation, instead of that, as the developers developed the screens and some logic behind it, testers sat with them. They saw what they’re developing, and they could redirect them if there was a need. Now beforehand, before we did that, there was some notion that there shouldn’t be any discussion between the testers and the developers because the testers will get polluted by knowing how the software is really built. Looking back, it sounds very stupid to me [laughs] . Clayton: I’ve heard that objection before. I’ve heard that one before. Gil: I know. Let them work together. Today, the boundaries between the developers are blurring because testers that fit into an Agile team learn, have some skills in automation, some kind of programming. It doesn’t have to be at the level of the programmer like a C# developer. He’s doing all the tests in C#. Depending on the tools that he’s using, he can do something like Cucumber or any BDD tool or some kind of big automation tools as well. But the communication between the two sides is the most important thing because, like the developers and managers have their own divide, developers and testers have that too. Once communication channels are open, the goals are aligning and will get a much better product. Mistakes Managers Are Making Clayton: To go back to the manager‑developer, those two groups, what’s the biggest mistake or something that you think a lot of managers are probably doing today, maybe a manager in Agile team, that if they were to change something about their behavior or something that they did that would make the biggest impact, that would make their team more productive or everyone happier or whatever? Gil: There are a lot of examples, but I’ll just say that they need to change their language. For example, saying to the developer, “But you estimated it will take two weeks.” Just listening to this sentence just generates an image in the developer’s eyes that is looking into a pointy‑haired manager, and you know that estimations are taken as promises or commitments. Estimation for example or things like “not enough time to do testing,” these are sentences from the domain of the developer which sounds differently for people with different background. They start, again, seeing the managers as their enemy instead of someone who could help the team reach their goals. Managers needed to learn ‑‑ that’s the same for developers ‑‑ they need to learn the language of the other side. Developers for, I don’t know, a hundred years…We’ve been developing since the ’40s. I’m coming from a development background. That’s why I always say “I” and “we.” We created our own, built our own little language. What we do is we work some black magic and something appears at the end. Management has been there for hundreds of years. Management hasn’t changed much. This new thing of software development, it is new, so the domain is different. We always like to talk about domains and language of domains. Managers need to understand what developers are talking about and what they care about because when the developers talks about quality…Switching back to the developer side, a developer really cares about his craftsmanship so the quality of the code, and the design needs to be very good. The problem is how that it sounds to the manager. The developers need to think in the domain language of the managers as well. So instead of saying, “I need a good design.” He could say, “I have a design that allows us to change the code quickly” because that what is a good design for. The two sides need to learn the language of the other side and start talking in that language. We have a whole lexicon of things that we can try to change the sentences or at least try to understand what the other side means when he talks about using these terms. Clayton: Interesting. I think we’re actually out of time, but I wanted to ask if the listeners wanted to find out more about you or Typemock, where would they go? Also, if there’s anything that you found interesting lately that you would like our listeners to know about. Gil: First of all, a lot of Agile stuff on my blog, on my site at Gilzilberfeld.com. Go to Typemock and download the tools for unit testing. We have tools for mocking for .NET and C++. The thing that I’m actually looking at recently is system thinking. I’m trying to get into this new topic and learn more about it because I understand that when I look at those, there’s a lot of same terms like the thing that I brought up with languages or the sentence. There’s a lot more thing we can learn about going into thinking about this kind of systems and the interfaces between them. Clayton: Great. As always, we invite the listeners to check us out on Facebook at Agileweekly.com. You can join the conversation on the Facebook page. You can chat about this episode or any of the previous ones. I just wanted to say thanks Gil for joining us today. We appreciate it. Gil: Thank you.

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur. Roy vandeWater: I’m Roy vandeWater. Drew: With us we have Derek Wade, who is a collaboration expert and an organizational change expert as well. Derek, tell us a little bit about yourself. Focused People Can Solve Hard and Complex Problems Derek Wade: I started off in the software world and it really grew from a creative bent. I liked to hacking out with my VIC‑20 and Commodore 64. I love the fact that it was basically like painting ‑‑ but not by numbers but with numbers. I could type some keys and follow a few rules and cause things to come into being. Many, many years past through many misadventures, failed projects, and succeeded projects, and succeeded projects that were not terribly interesting and failed in a business sense. I am now basically doing the same thing, helping people be creative, except in a large format. What I like to say is ‑‑ and I just stumbled upon this metaphor a little while back ‑‑ I am really interested in lasers. I am making human lasers by helping groups of people organize, shine their light, their creative light, all in one direction, and get it amplified. We can really cut through some incredibly hard and complex problems, and we can send that energy for a really long distance. This shows up in software, it shows up in education, it shows up in scientific research, it shows up in some civic problems. I’ve been trying to use some of these tenets of, for example, Scrum, towards these problems and it’s been very rewarding. Drew: In reading a little bit about you, one big thing that I’ve picked up is teams and collaboration ‑‑ you’re really big on ‑‑ getting teams to work together. Why such a strong emphasis on that? Derek: It’s probably some kind of neurosis that I have to find out inside myself some day, but ultimately I think that the problems that are really interesting, things like cosmology, things like finding out the secrets of the universe, things like effective markets, things like poverty, things like civic government, things like making really cool, complex, gnarly systems that almost have a life of their own, are not really individual creations. I recently saw “Prometheus,” and no matter what your feelings are of on it, I just don’t think it lived up to the ’79 “Alien.” If you look at “Alien,” it’s not just Ridley Scott’s masterpiece. It’s so many people coming together to make it happen. Einstein and Edison did not work in a vacuum. When people come together and share and align their hopes, and fears, and dreams, and skills, and differences, and arguments, and experiences, and questions, some really magnificent work happens. That’s the problem that interests me. Something that one person can crack on their own, I’m inclined to let that one person crack on their own. Roy: Awesome! Drew: Reading a little bit more, I see that you co‑authored or authored a book having to do with distributed teams. Derek: Paper! [laughs] We can call it a book, but it’s a very, very thin one. Distributed Teams Drew: OK. So, now you’ve got a huge emphasis on teams and working together. To me, the distributed team model seems a difficult thing to conquer. Roy: It almost seems like the opposite of a team working closely, and working really well together. Drew: How do you get all that oomph that you have behind team work, and use it distributively? Derek: Right. It’s very seductive, isn’t it? Wow! You mean, really, I can get all this cool human‑oriented team stuff with people spread out across the globe? In one of my former lives, I was a pilot and flight instructor, and we had this saying about the J‑3 Cub, which was a 90 hp airplane, “That it’s the safest airplane in the world. It can just barely kill you.” Distributed teams are the maybe most effective, barely effective teams that I have run into. That said, people seem to keep doing it. One can sort of take a philosophical stance of, “Don’t do it,” in which case you’re really helping a group of people who are ‑‑ when you’re focusing only on those folks who are willing to put together physically collocated teams ‑‑ you’re really helping them optimize what they already know how to do. When you can work with people who, for whatever reason, and globalization is real, who want to work together across time zones there are still things that you can do that don’t have to suck and that can get that gestalt, that the team is bigger and better than the sum of its parts. I would rather see those kind of teams brought into existence to introduce people to the power of teams over a collection of people, because a team is not a collection of people. I would too strictly live in the world of the collocated teams. Still, it is a bit of an evil. Roy: Have you found any distributed teams that are able to perform as well as a collocated team? It seems to me you run up into a glass ceiling eventually where like… Derek: Yeah, that’s a really good point. The limits are there. If you histogram the number of effectiveness teams along the vertical axis along the different degrees of distribution along the horizontal axis. What you’ll tend to find is that the distribution for collocated teams is higher and you tend to see this clumping towards greater effectiveness for collocated teams. You tend to see a clumping of less effectiveness for distributed teams. That said, probably one of the absolute best teams that I have ever worked with ‑‑ not the ‑‑ but one of the absolute best teams that I’ve ever worked with was spread across three countries. One of the, probably, three or five of the most embarrassing “you’re not a team you’re a time‑bomb,” groups I’ve worked with have been collocated. You see a strong correlation between collocation and effectiveness but it’s not cause. Drew: I’m thinking like, I’ve got a lot of software development experience working with teams that do a lot of pair programming and pair programming is one way to work. When you’re doing a software project and you’re both working on the same project that’s one way to work efficiently and well as a team. At other levels, in the organizations that you work with, what are other ways that people work as teams well that are not specifically software‑related? Derek: Distributed or otherwise? Drew: Either one. Scrum As A Learning Framework Derek: For the most part what I’ve been, as I’ve moved away from pure software teams, the thing is that Scrum, we focus fairly strongly on Scrum because as a friend of mine David Koontz said, “Agile didn’t work, Scrum worked because it was something people could grab and hold onto.” As Scrum has taken hold, people really look at it in a narrow sense as it’s a software development methodology, but it’s really a learning framework. If you consider learning as one or many people navigating and creating a map of an unknown domain and gradually mapping it in pursuit of an objective, that describes change. That describes learning. That describes product development and then finally way down at the smallest subset that also describes software development, but software development alone is a small subset of what we can use for example the Agile framework Scrum for. When you consider that it’s important for people to go through these cycles of having experience, reflecting upon them, making some concepts in their head, experimenting trying stuff out and continually going round through this thing that’s called the “Kolb’s Learning Cycle,” Scrum sets people up for that magnificently. When they’re distributed and working on software they’re going through this cycle between planning, experimenting, trying stuff out, sharing information, reflecting, and getting better and better, meanwhile improving their code. You can bump that up a level, and you can start applying the exact same framework as a means for navigating an unknown domain to problems like organizational change. We are organization X. We would love to become organization Y. We don’t know how. It’s the same kind of problem as we have a list of items in a backlog. We would love the have software. We’re not exactly sure how, but we’ll iterate our way to it. That’s one area that I worked at. It’s basically in agile adoptions, when people say, “Please come install the Scrum for us.” The first explanation is that people’s minds aren’t buckets to be filled. It’s something that we navigate and learn together. So I set up a management team as a scrum team. Another area that I’ve just recently had the good fortune to work in, this has been in instructional design for universities. Instructional designers do things where they take, basically, offline courses from faculty and professors and turn them into some online modules. It’s not as straightforward as you might think. For years, they’ve been treated as a transcription problem. Just like you transcribe software requirements into code, and it’s so easy and anybody should be able to do it, the same sort of myth is present in the instructional design world. By setting up a team to go through these cycles of experience, observation, conceptualizing, and experimenting round and round as they make their work visible to each other on a Kanban board, they’re actually navigating that same sort of unknown domain to arrive at solutions that are better, maybe, than they could have envisioned. There’s also some work being done with Scrum in the scientific research field about how scientific research teams can work together. I’ll say a little more about that at the end, but I’m not involved in that. I’m only peripherally aware of it. I hope to become involved in it, but not quite yet. Organizational Feedback Loops Roy: We’ve definitely had some experience trying to implement Scrum and some of the agile practices in things outside of the software development world, and with some great successes, but we find that, a lot of times, organizations that are implementing Scrum within a development team just want more, better, faster and don’t really understand that a lot of it is an organizational change. Especially with a distributed team, how do you deal with that type of feedback cycle? You mentioned having a team that manages your organizational change using a Kanban board, I believe you mentioned. Who are these people? Are these the management? And then, do they bring it to the teams that they must now try these new things? How do you structure that? Derek: Exactly. Think of it as double reinforcing loops. You’ve got the teams on one hand…ultimately, you need to couple this exploring to reality. There’s way too much abstract conceptualization in our field, in software, designing the perfect architecture before we implement it, designing the perfect process before we implement it. The bad news, or the good news, really, is that, in the scheme of things, reality bats last. When we can have the teams trying to make the code do what they wanted to, and, as they try to do this, they encounter problems, whether it’s organizational issues, code issues, technical issues, and even interpersonal issues. Those problems can become almost the input to these people’s managers, to the people who want [inaudible 14:34] , the stakeholders who want the benefits of more, better, faster. That’s [inaudible 14:37] between their input. When they act on that input, that improves the teams, and they start seeing the more, better, faster. So, on the lowest level, you’ve got the reality of the systems in the organization, the teams trying to wrestle that reality into something valuable, like a website or an iPhone app. Then, as an extension of that, the management team that really ‑‑ their role is to facilitate this change, using the same sort of cycle to help the teams make that change. You can even go up one level above that and into the organizations, starting to discover what it should be. I’ve only had that happen with two clients, though. Drew: Great, yeah, a lot of great stuff here. Thanks a lot. Before we wrap it up here, do you have anything you’d like to promote or tell the listeners? Derek: Yeah. First of all, as I said, Scrum is a learning cycle, and, for a little, tiny bit of information about that, you can feel free to go to a resources site that I set up and I can maybe send this to you later, but it’s kumido.com/resources/scrumbeyond. In there, you can get a little more information about the extensibility of Scrum. I would invite anybody to contact me with challenges, disagreements, debates. I bet we can do it here, because those are the kinds of things that interest me. Drew: Great. Thanks a lot. For the listeners, we invite you to join in on more of that at facebook.com/AgileWeekly.

Roy vandeWater: Hello, and welcome to another episode of the Agile Weekly podcast. I’m Roy vandeWater. Drew LeSueur: I’m Drew LeSueur. Roy: Joining us today is today is Woody Zuill. How’s it going, Woody? Woody Zuill: Real good. Agile 2012 Conference Roy: You’re currently at the Agile 2012 conference, right? Woody: Yeah, I sure am in Grapevine, Texas. It’s really, really nice here. Roy: Have you seen anything totally awesome there in the last few days? Woody: Yeah, I’ve gone to a lot of sessions, and they’ve been great. As a matter of fact, it’s really nice to see, in person, some of the people that I’ve read books and followed for so many years. A few of them are old friends now, but some of them I’d never seen before. I think the top thing for me, so far, has been a little one hour session by Robert Martin on clean code. As you can imagine, he’s always good with that stuff. Mary Poppendieck, who her and her husband, I guess, wrote that Lean software development book, which I’ve put to great use over the years and completely worn out several copies. Eric Meade, I just saw a session by him just a few minutes ago on decision making. It’s a lot of eye opening stuff. Overall, I think what I’m seeing is that people are really moving forward beyond just the simple Agile ideas, and trying to figure out some bigger problems. I’m enjoying that a lot. The Development Stage Roy: We had talked to a previous guest, I think that was helping to organize the event, was telling us that there was going to be a much bigger focus on the technical side of things. Have you been seeing that a lot or is it…? Woody: Yeah, there’s a development stage. I think it’s called development practices stage, and I’ve gone to several of those sessions. But I haven’t been able to go to all of them. They were doing like a code retreat today, and so that’s kind of interesting. I wasn’t able to stop in on that, but those are very code and coding practices focused sessions. That’s sort of my focus. That’s where I think I bring the most value is knowing about that stuff and bringing that to my team and things like that. Agile Success Jade: You wanted to talk about Agile success. Woody: Yes, Agile success. Jade: What does that mean for you? Woody: Over the years, I’ve been doing what you might now call Agile since 1998. You add up the years, and when I was first introduced to it the TMI was on. I knew nothing about it except for what I had read, but the TMI was on, what I would consider ultimately successful. They were extremely good at cranking stuff out of extremely high value. As I watched what they did, I said, “I just want more of this.” Then I went out into the real world, and looked for projects that either people were saying they were doing agile or wanted to do agile. I very rarely found anybody being effective. They were either hoping to do agile or wanting to do agile, but they just hadn’t gotten there. I’ve been through a lot of those things. Going to these conferences, and these things like the open agile and all the user groups, I’ve talked to a lot of people who are still trying to figure out, “How do I get this working for me?” I put together a little talk just on what I would consider the main things, which is the agile values and principles. It always seemed to surprise people that these things existed, which really bothered me. That’s sort of where you should start, that’s what you gives you a way to judge, “Is this practice I’m doing helping me? Am I thinking in the right way to get where I want to go?” It’s kind of like something I think I learned when I was a young man, or actually a teenager, and this very, very old guy that I knew, he was in his 80s when I met him, and he was really, really genuinely good. He was good to everybody, he treated everybody nicely. Then I knew some other old people who were pretty crabby all the time. I started noticing they either leaned towards being crabby or leaned towards being good. Not too many in the middle, who were sort of half‑crabby/half‑good. It dawned on me that you kind of gravitate toward what you allow yourself to be, and so I’ve held that through my life. I want to always lean towards the good if possibly can, so, when I’m old people can say, “You know, he’s a nice old man.” That’s my goal in life. That’s sort of what the agile success talk was about, if we lean toward the agile principles, then whatever we decide to do for practices are going to hopefully be agile. If they’re not, we’re going to hopefully, more than anything else, adopt that idea of retrospectives or reinventing ourselves continuously. If you really adopt at least that one principle, you’ll hopefully get better as long as you do it in a somewhat consistent manner. Jade: What were people’s reactions to that proposition? Woody: What happened is the people that were trying to do agile, but hadn’t even caught on to the idea that values and principles are what should be guiding us, although that seems fundamental to me. Once I started doing math talk then people come up and say, “We’re already trying to do all these, but we’re having these other problems.” I ended up, eventually anyways, adding some of my own principles and values. That sort of an important thing is there is the agile values and principles were kind of locked down quite a while ago. We might… Roy: That doesn’t sound very agile. Woody: Exactly. We got to be ready also to sort of adapt. We’re the inventors. We’re the innovators. No less soul than anyone else. We have to take responsibility for our own process where we are headed. I kind of gave myself what I would consider three new maxims. I had to come up with something, because they already were using values, and they’re using principles. I figured I will use some other terms for the moment anyways I’m calling a maxims. But one of them is this. It’s in the doing of the work that we discovered the work we must do. If we trick ourselves into thinking we can figure out what we are going to do before we actually do the work, we’re always going to fail. That to me is a critical maxim, and that is my focus every day as we do the work. We are going to discover the things we didn’t or couldn’t figure out before we started doing the work. Discover The Things We Didn’t Or Couldn’t Figure Out Before We Started Doing The Work Jade: I really like that. Do you have a good story where that maxim came true for you? Woody: Sure. I’ve got tons of them, so don’t get me started. A good example is in a very simple little project I was working on, there was a couple of features that we wanted to do, and they’ve written out exactly what they wanted. I should change it what I just said. Their requirements for this project were dozens of pages. That’s none of my rules. I don’t like to call things projects. We’re doing development let’s say we’re doing software development not software projects. Projects is like making a deck or making a model airplane. All the instructions are there, and you got all the parts, put it together. See, now I’m going on and on. But here is the thing, they put together these huge documents, and the team kind of got blocked on actually getting any work done. They got to the point where they were making no progress, and they were starting to break the already working project that was in production. They weren’t keeping very good control of their source code, so they were really getting into a mess. What we did is we just sliced off ‑‑ I like the term sliced off ‑‑ a little bit of function that will give them some value today. If they could have it today they could be making more money with this little built functionality. I said, “Well, let’s make a little prototype of that.” That’s another thing. You always have to call things a prototype because nobody understands that we’re working on a real project little bit at a time. But if we make a prototype, that makes sense. We made a little prototype. They took a look at it. They said, “We want to change this, and we like to change that.” We have written a little bit of functionality based on their nice instruction in their requirements document. It should have been correct, but this proved to them, I think, real quickly, without of saying anything that those document really weren’t the final say on what this was supposed to be. It was in the making of this little feature, it wasn’t much. I can’t tell you what it was. It’s kind of a proprietary thing, but this little feature that they start discovering what they really wanted to do. But bottom line of that story is after we got about the first five or six really top features all the rest to that thick document went away. They didn’t even ask for even ask for any more it. They switched to another chunk of functionality they wanted to work on. That’s the real value of agile. Maximizing the amount of work that we don’t do, that’s really a wonderful saying. There we go. You want another maxim or…? Drew: Yeah. Roy: Let’s go to the next one. Embracing The Change Is Impossible If Your Code Is Not Easy To Read and Maintain Woody: The next one, I think, what I’ve been seeing a lot is projects, and I hate to use that term, but these are projects where they want the promise of agile. The big part of that is responding to change, but you can’t really do that unless you really have easy to read codes that easy to maintain and easy to grow. My next thing is embracing the change is impossible if your code is not easy to read, easy to maintain, easy to grow and easy to change. I learned that stuff from my little brother, who is also a programmer. Everything else is secondary. If you don’t get that in there, you’re not going to be able to do agile. It’s got to be easy. Because, you know, when somebody comes in and says, “Wait, wait, we’ve got to change this thing.” Have you ever heard this one, where they say, “Well, you should have told me that in the first place, because now we can’t really change it without pushing the deadlines out.” We don’t ever want to have to use that excuse. Does that make sense? Jade: Yeah, that’s great. Question Everything Woody: I always ask that. Does that make sense? It’s probably kind of a faulty thing to ask, because if you didn’t understand, I couldn’t tell. The third maxim is really a simple thing. Remember, this is the advanced part of the course. This is not the basics, this is really advanced for people who are really trying to do this, and this is the maxim. Question everything. The main thing I question is the things that I think are the most true. Whenever I catch myself going, “No, this is the way things is,” that’s the thing I start questioning. Why did I allow myself to get that rigid about something? But I question everything, like we were saying earlier, even the agile manifesto. Not that I need to change it. I just want to make sure I’m on track with it. If something doesn’t bring value I want to discover that. Maybe I can’t discover it, but I can keep questioning. Someday, if somebody brings to me something I am doing wrong, I want to hear it, I want to evaluate it, and I want to change, if it turns out I am doing something wrong. I want to deliver as much valuable software as quickly as possible in a very sustainable manner. Not all projects are that way, or not all companies are that way. I don’t like to call these things projects, because I want to see them going on forever. Let’s keep adding value to it, as long as there is value that can be added. I probably used up our whole time already. Jade: We’ve got four minutes. Drew: The question everything, I like that one. It seems to go right in line with respond to change and also respect and adapt. Woody: Oh, yeah. That’s the inspect and adapt right there. I just did it in different words so I could copyright it. Drew: That’s good though. Back to your 12 page featured document story that you told us you know, that was something that you could have questioned right from the beginning. Woody: Yeah. I would myself question it, but a lot of times when you get in an environment where this is the way they do business, you have to find a story that they can understand. They can’t understand the agile story often. This is the thing, Agile, although it really seems obvious to me, for whatever reason doesn’t seem obvious to a lot of other people. What seems obvious is, “Hey, let’s make our plan and follow our plan, and we’ll get it done.” Everybody is excited about that, they think it makes sense. But I like more, from Napoleon’s rules of war or whatever he called them, the engage and see. Let’s get in there. We’ll get to wherever we’ve got to be. Let’s start a battle, and then let’s see what the enemy does. Then we can decide what we need to do. But until we do that, you know, they’re ready to trick us with something. We don’t know what’s coming down the road. We want them to show their hand before we show ours. This isn’t really a war, but I like to engage, and then see what we get. That’s in the doing of the work. Jade: That’s awesome. Roy: I believe that you are working very closely with the group that’s organizing the Agile Open SoCal that’s coming up, right? Woody: Yeah. That’s a great little conference at UC Irvine, that’s coming up I think that’s September 13th or 14th, that’s coming up pretty soon. You guys were at that last year, I remember. Roy: Drew and I were planning to be there as well. Drew: Yeah, it was a whole lot of fun. That was my first open space format, and I loved it. Woody: Yes, that’s a good point. The first one you go to is always the best, the rest of them are pretty disappointing. I’m kidding. I think I’ve been to 10 or 12 of them now, and the very first one I went to was the scrum alliance, scrum gathering thing, and Diana Larson was the facilitator, and it just floored me at how wonderful it was. Jade: Yeah, she’s great. Woody: She’s great. The whole event was great. Then this one, I got a chance to get involved with it about three years ago, and last year I was the main host or whatever, and I jumped right on board to do it again this year. It’s a wonderful event at a very nice little venue. It’s very inexpensive right now. Through the end of August, there’s the early bird registration so you can save a little money, but it’s cheap anyway, it’s $250. Right now it’s $150 if this thing broadcasts before then. People can take advantage of that. It’s well worth going to. It’s also small enough to really get to know everybody that’s there. I think that’s a wonderful advantage to these nice little conferences. This one here, the Agile 2012, it’s really great, but I’m just overwhelmed by the number of people. It’s huge. I don’t know how many people are here, but at least 1500 or something. Jade: It’s a very different kind of conference. Woody: For a small town guy like me, I get pretty scared. Roy: It sounds awesome. I’m looking forward to being there, and hanging out with you. Woody: This has been great guys. Anything else you want to cover? Roy: No, that’s it, thanks for joining us. Woody: I’m looking forward to hearing this and your broadcast. I guess you go out every week. Jade: Yep. Woody: Excellent. That’s why you’re called agile weekly. Jade: That’s right. [laughter] Woody: Very cool. Thank you, guys. Thanks a lot.

Drew LeSueur: Hi and welcome to another episode of Agile Weekly Podcast. I’m Drew LeSueur. Roy vandeWater: I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors and with us today is Aaron Eden. How you doing, Aaron? Aaron: Hi, I’m doing great. How are you? Using Agile And Lean Startup Together in Customer Development Derek: Doing good. Today, we want to talk to you about how Agile works inside of a lean startup and customer development methodologies. Aaron, first of all, tell us a little bit about yourself and then maybe talk about about these topics. Aaron: Sure. I’m a product manager for Intuit during the day and also, director for Gangplank Tucson. My background is actually in software development. That’s a part of the reason that I’ve been drawn to lean startup so much, is that a lot of big things that people talk about are like, “Oh, my God. I built this huge thing and found out customers didn’t need it.” As a developer I think back on all the times where that happened to me, and my goal with all of this is really to try and hopefully save some time with developers out there and actually build things that customers want. Drew: Lean startup is something we’ve heard a lot, like the phrase “customer development.” Can you explain a little bit more about that and how that ties into lean startup in Agile? Aaron: Customer development came earlier. Customer development was something termed by Steve Blank out at Stanford, and lean startup is basically the combination of customer development and Agile development methodologies and then sprinkled in a little bit of continuous deployment. Lean startup is those three pillars, so customer development is a piece of Lean startup. Drew: The basic idea is ‑ am I understanding right ‑ to hand‑in‑hand with lean startup, making sure what you’re releasing is something that people actually want. Actually using customers as part of the development process. Aaron: Yeah, either using customers as part of the development process or using rapid experimentation to try and understand the behaviors of your customers so that some of your biggest assumptions built in your product you can test out before actually even writing a line of code. You can test things with sketches and storyboards and cardboard and whatever else. It’s all about getting scrappy and trying to prove that the customers are really going to have the behaviors you think they are before you go and build things that they may or may not need. Derek: When it comes to that Agile methodology side, you’ve got Scrum or KanBan or typical lean type of things, how are you seeing people apply Agile methodologies to something that, a lot of times, when I look at lean startup, a lot of the work is actually not software development. It’s exactly what you’re talking about, where you’re putting out a hypothesis, almost the design thinking. What’s the problem we’re trying to solve? How do we solve it? How do we put it out there? How do we let people give us feedback? There may not be a single line of code involved, and the feedback loop can be fairly tight to fairly big. What are you seeing people use from Agile methodologies and apply to that part of the process, where they’re not really doing development, code? Different Teams For Testing vs Building Ideas Aaron: Yeah, I’ve seen teams using Agile‑esque techniques in those early phases where they’re using a lot of the design thinking techniques and small prototypes and things like that. What they tend to do in those situations is they’re very clearly putting together what the team is going to execute and building their user stories out for that, and then going and executing on that. When they get beyond those early phases where maybe your minimum viable product goes from a storyboard that you went and put in front of customers to a landing page or something like that. Those types of experiments. Usually what teams will do is they’ll split their “lean startup” team into two sub‑teams, one being the Agile development team that’s effectively working on building out whatever the next experiment is, while the other team is off testing the last experiment with customers and basically bringing all the things they learned from those customers back to the development team. Then they go and do their sprint planning and basically go run their next sprint. So you’ve got half the team going and using a tweaked version to go and execute experiments and the other half of the team using very typical Agile to build. Drew: Interesting. Also on the subject. One thing that I’ve run into is management’s fear of releasing something. You know, there’s like, something, I don’t know what it is. But a fear of change or fear of messing something up is. Roy: Or fear of looking bad or something. Aaron: Exactly. Drew: They won’t release anything until it’s all done. Roy: Ask QA and… Overcoming Fear Of Releasing Something Not “Finished” Drew: Right. Now that’s kind of the opposite of the lean startup idea. How do you overcome that when you’re trying to do these things? Aaron: I run many lean startup events inside Intuit. I know about that all too well. There’s kind of a couple different angles that I tend to attack it from. Especially inside a big company, what you tend to find is that when leadership sees how quickly teams can move when they’re applying these methodologies, they realize that this way of operating is much more effective, and some of that fear goes away because they realize that they’re going to accomplish so much more. That it’s not going to be three months to go and fix that bug and that the were worried about not releasing. They see the speed as a way to mitigate some of that risk. The other thing that I see… that by having the teams break things down into small experiments, a lot of times people, when they hear about lean startup and they hear about minimum‑viable product. What they hear in that is some crappy version of the final solution. Or some not completely polished version of the final solution that might have some bugs or issues or those kinds of things. You really have to take to heart the word viable in that acronym. Many teams end up… If the behavior you’re trying to test is that a customer needs a certain thing, or that they really do have a certain problem. In a lot of cases you can test that without going through the final solution. The ways that you can mitigate leadership getting antsy about a half‑baked product going out, or whatever, is that those small experiments, you can leave your corporate branding off of them. In our case, at Intuit, the legal team has actually been doing really great things. They’ve sort of given us rough guidelines that say hey, if you’re playing within this space, as long as you’re testing on less than a thousand customers or whatever it is. I don’t remember the exact number. They basically say as long as you’re within these guidelines go ahead and test away. When you get beyond a certain scale, then that’s the point where you need to start getting legal approvals and that kind of stuff. I think there’s definitely some really positive ways to put some solid boundaries in place and support the teams in moving quickly while still keeping the corporate polish on things. Turning An Experiment Into A Real Product Derek: I think you bring up a great point that I’ve seen a number of really large companies do when they bring in lean startup. One of the things they tend to do is they start to create “innovation laps.” These laps are really targeted at a thousand pers… Exactly what you said right there, they’re very boxed to be experiments, not necessarily be shippable product with the brand flagship name on it, everything else. What I see is a problem with a lot of these teams when the experiments actually go right. That the really struggle with how do they transition to turning them into real products. Meaning they kind of use this lean startup piece to get rolling, get moving, but then they get a thousand people and everybody overwhelmingly says, “Yeah, we want to see this.” Then it becomes, “How do I turn this over to a development team that’s never seen it and they have to pick up the code base, and the support staff has to support it, and legal has to get involved, and marketing has to approve all of these things.” It just gets pulled right back into that quagmire of… it never hits the market because the corporate monster stops it in it’s tracks. Drew: Sounds like in that case, like you were talking about passing it off to a new development team and getting whole new people involved. It sounds like that might be the wrong approach to take, from the stand point that the guys who built it and are passionate about it and have seen what success it can bring, they understand the vision. It kind of sounds like those people are the ones that need to see it through. Now I realize that this may add a disincentive or a reason to try to sabotage your own projects so that you can continue being on the fun innovation labs rather than being the old legacy guys, but I guess I don’t really know the right answer for it. But it sounds like passing it off to completely new people doesn’t sound like it. Then it also sounds like you don’t have to go from thousand to everyone. It could be one thousand to two thousand and slowly scope over time. Lean Startup Teams vs Lean Startup Organizations Derek: Yeah. I think one of the questions that I can have about that is are we taking the wrong approach, and are we creating lean startup teams instead of lean startup organizations? Meaning if we really get organizations to think more like lean startups and that they’ve got lots of groups of people all that are innovative and that are all… Drew: Instead of they’ve all got their own marketing guy and their own financial guy. Derek: Yeah. Can they really start to cut through the crap and really push forward? Instead, I think that what happens in these big companies is they extend a special title to a small number of people who are really excited that they get to work on something fun and new and iterate. But then they’re not actually able to bring the product to market, and it creates all sorts of problems. I don’t know if you’re seeing that in any of the places where you’re at, Aaron. I know you’ve run a lot of lean startup machine stuff and if you’re seeing transition problems even from maybe lean startup small companies that start to grow into bigger companies. Do they start to lose that magic when they hit a certain number of employees or their product has a certain number of users? Aaron: Right. I think there’s a couple of nuggets underneath what you guys were just talking about. Have you heard the term “Horizon Planning”… Derek: Yeah. Aaron: …that a lot of businesses do? Drew: I haven’t. Aaron: Basically your Horizon I products are your core products that make most of your money, and they’re where you focus a lot of your resources in a big company. Then Horizon II is like your teenagers. It’s those businesses that are beyond a certain point. They’re actually at the point where those businesses need to scale. You’ve proven that you’ve got a real customer need that you’re solving and that your solution solves that problem. You’ve got people spending money on it. Now those founders and those people that were passionate about the vision and those kind of things, their skills aren’t as valuable because now you’ve got a repeatable business model that you now need to scale. You need different skills for that. Then Horizon III would be like a startup. It’s something that’s just an idea, and you spend a small amount of resources on those until they get to Horizon II. Then you can increase that. Using that Horizon Planning methodology you can have the right people involved at the right times. I think you guys are on the right track, which is that for those business ideas that are in that Horizon III, you’ve got to have those people that are passionate about the vision, continuing to work on it, and those kinds of things. The other nugget in what you guys were talking about is that in the events that I’ve run I actually have teams that are coming to the events with new business ideas as well as existing business projects. As an example, I had an IT team. Their business idea was that they wanted to create this new monitoring platform. Most call centers monitor the usage of their platforms, their telephony, and their IVRs and that stuff. Monitor it from the inside. Look at how many customers are waiting in the queue and how many agents you’ve got on and all those kinds of things. What this team had a hunch on is that if they’ve monitored from the customer side of things that they’d probably see things going on in the environment that they couldn’t see from the inside. They couldn’t convince leadership to invest the money in it. That was their idea, that’s the business that they brought to this challenge. Applying the lean startup methodologies, if you imagine that they’re a company that’s trying to sell this monitoring platform back to the place they work and treat it like a business, what ended up happening was they executed a bunch of experiments, found exactly what was important to the leadership, and convinced an external vendor to come in and stand up this monitoring platform for a four‑day experiment. Basically found that they could shift net promoter scores in the customer service area by one point in this small four‑day experiment, which in a big multi‑billion dollar company that one shift in that promoter has a huge impact to the business. Derek: Absolutely. Aaron: It’s like you said about that you need to create innovators all over the place that are applying things this way. I think that’s a perfect example of where people can take something internal, apply these same methodologies, treat it like a business, and have some really great success with it. Drew: Great. A lot of good stuff, Aaron. Thanks a lot. Before we close do you have anything to promote? Anything you want to say? Aaron: I’d love it if folks would check out my blog, which is AaronEden.com. Definitely come check out all the great things that are happening down here at Gangplank, Tucson. Drew: All right. Thanks a lot. For the listeners, if you’d like to join in on the conversation, go to Facebook.com/AgileWeekly.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. My name is Clayton Lengel‑Zigich and joining me today is Steve Bristol. How are you doing, Steve? Steve Bristol: Hey, Clayton. Good. How are you? Clayton: Good. Steve, I actually know you, not you personally, but I know of you. I can’t remember, what’s your partner’s name, your co‑founder? Steve: Allan Branch. Ruby On Rails and Lean Startup Clayton: I know you guys from the Ruby on Rails community. I remember you were doing all of that stuff with…Has the company been Less Everything for [inaudible 00:34] ? Steve: Yeah, since the beginning, since 2007. Clayton: I know you guys from that stuff and I remember a lot of the stuff you were doing, so it’s definitely cool to be able to talk to you about some stuff today. Steve: Thanks. Clayton: I was looking at your blog, and you made a post about a Lean Startup. One thing that I’m curious about, and anyone that’s in technology realizes, that things that are old become new again. Do you feel like the Lean Startup is something that is entirely new to you or is that something that maybe you’ve done instinctively with your work that you’ve been doing as an entrepreneur for a long time? Steve: Yeah, we named the company Less Everything because that’s our philosophy. We believe in doing things Lean or as we like to say, “less.” In fact, the whole Lean Startup movement stole all our ideas and they changed it from Less to Lean. In fact, Jason Fried of 37signals got most of those ideas from us as well. But, obviously, that was before the company. We were a big inspiration for the first book “Getting Real.” Clayton: I was an early user. I think I signed up for Less. Steve: In all fairness, it was actually the reverse, Allan and I had both read that book separately and it was a big inspiration for us. In all fairness, [laughs] that was a joke. The Lean Startup people did steal everything from us. The Creation of Less Accounting highr Clayton: I’ve used Less Accounting, a long time ago and it was a big deal when it came out, in terms of we could do all this great stuff and it wasn’t all this crazy overhead. It seems like it captured the concept of doing Lean Startup stuff in general. Steve: Absolutely, Less Accounting was our biggest product, yeah. Clayton: I was going to ask you that. That’s something I would say that seems like it was founded on the same principles and that it seems like it’s evolved from there. Is that a fair statement that you’ve been able to apply that same value system? Steve: Absolutely, we actually came up with the name Less Accounting before we came up with the name Less Everything. The company was founded in January of ’07, but Allan and I actually started working on Less Accounting in November of ’06. We were working on that before we even had a company. The idea was very much making an accounting application that was easy to use, that didn’t have all that stuff that the majority of people don’t need, and don’t understand and just clutters the UI makes it hard to use, and makes it very difficult and to get rid of that and make accounting easy and understandable and doable for the small business owners. Clayton: Is that something that has certainly looks like it has evolved. I mean it certainly looks like there are more features than there were in the past. Is that something has evolved based on strictly customer feedback? Steve: Yeah. I mean including Allan and myself as customers and users of Less Accounting. 100 percent of the features came from one of two places. Either it was user feedback or our needs or if we had an idea of like some of the integration we did more as marketing features than as very useful features. A good example is the Highrise and Basecamp import. Those weren’t really highly requested features, but getting on the Basecamp and Highrise’s integrations page is a good idea for most applications. We certainly have seen a lot of calls from there. The vast majority of features, the nuts and bolts core features, the accounting features, certainly are all based on the needs of our customers and ourselves as customers. Failed Hypotheses Clayton: One of the core things about Lean Startup is treating it like using the scientific method and getting real feedback on data and all that stuff. Can you share examples where you had a hypothesis about something you thought would be a good idea that just totally didn’t work out. Steve: Gosh. You got me on the spot here. Clayton: It’s OK if you’re right all the time and you never get it wrong. Steve: When we first launched Less Accounting, we realized that it’s the accounting system, but since were also doing invoices and proposals, it could also very easily be your CRM system, and so we had this concept of sales leads at the very beginning. We had sales notes, sales leads, contact proposals, invoices, expenses, deposits, all that other stuff. No one really got the whole sales leads thing. It was something that was probably my idea initially, and I don’t think we did a very good job of explaining how to use it. People kept asking for projects. They want projects in Less Accounting. Basically a sales lead was a project, but the name was so off that it didn’t ever quite work for people. So, in the end of the first year and the beginning of the second year we removed the feature. You still had notes. Anytime you send it in to us, for example, we store that as a note so you can see the history of your clients’ interaction, but we removed all the sales notes stuff. We never did actually add projects. We just added tags. A tag in essence are projects. You can change the application, so everything based on just a tag or a P & L and everything else. It gives you a project view of your money. People Matter More Than Process Clayton: OK. Lean Startup is something that’s maybe a little newer as far as the Agile community is concerned. Is there anything else that your internal team or any teams you’re working with that you’re using that are more traditional Agile methods, like a Scrum or something like that? Steve: We’re not big fans of Agile or Scrum or process in general. I’ve been writing software professionally for 16, 17 years. I wrote my first program when I was nine, so I’ve been doing this for a long, long time. One of the things I’ve learned in all those years is that people are much more important than process. That’s one of the tenets that gets dropped in the Agile community and the Agile world. Agile people tend to lean very, very heavily on process and thinking that the process is going to be the key to the successful outcome of projects and getting things done on time and that sort of thing. Certainly, we like a lot of the Agile stuff. We do a lot of Agile stuff ourselves. We don’t ever call it Agile. We just call it how we prefer to work. We were doing that stuff before Agile was Agile. But, if you hire quality people, then process doesn’t matter. You find a process that works best for people. If they’re quality people, they can probably adapt to different process as the process changes with the personalities that come on board. We certainly like a lot of the Agile stuff but don’t really prescribe to any of it hook, line, and sinker. Clayton: Yeah, that’s a common sentiment for surely a lot of teams, especially successful ones. What I’m wondering is, with Lean Startup becoming more popular, do you see that being co‑opted by the those same people who are all about process and if you don’t follow all the rules then it’s not going to work? It sounds like you guys are definitely very true to some of the principles and the values. You’ve been doing that for a long time. Do you see that same thing happening with the Lean Startup community? Or do you think they’ll be OK? They’ll get past that? Steve: That’s probably true of anything, whether it’s Agile or Lean Startup or any new, cool…They used to be acronyms, and now they’re just little slogans, or phrases, or titles. They’re all good ideas. Ultimately, good people who can see through the bullshit, who know what’s going on, who can perform well, and who are smart senior level people, successful people will tend to be successful. Unsuccessful people will tend to remain unsuccessful without some sort of intervention. Agile or Lean Startup or whatever might be that intervention. That might be the thing that, “Oh, if only I had more discipline in this, then I would be more successful.” Or that might be the result even if there isn’t that aha moment. But I don’t think that. I think Lean Startup is just as susceptible to success or failure. It’s the flavor of the day. Most of these things have pretty good principles for their time. I remember once thinking that Waterfall was very, very, good, right? Clayton: [laughs] Steve: For where I was in my career and my development, it was good. It was a better methodology than what I was using before. Of course, I wouldn’t do that today, but it’s all a growth process. For certain people, now’s the time to learn. If you’re good or if you will be good, you’ve got a better chance of being successful than if you’re not. Again, I tend to think about people as the asset, not the process or the rules. Risk Aversion Slows You Down Clayton: That goes with my next question. A lot of bigger organizations, some corporate whatever, insurance company or something are getting this idea that if they have this innovation lab that uses Lean Startup it’ll do all this crazy stuff. Is there anything to be said for…I’m assuming that your team is relatively small compared to a big corporation. In addition to that, probably be of higher trust. You have a certain culture. Do you think that the size of the team and the trust and the culture plays a big enough role that not any old corporation could just go adopt this kind of technique and run with it? Steve: I’d say, the problem with bigger organizations whether they are governments or corporations, scaling things is hard. Since it’s true scaling families, it’s true scaling nations, it’s true scaled governments, corporations, the bigger you get, the harder it is to manage. You get to a certain point, even as the company grows, small companies tend to be very, very agile. They tend to be very ambitious. They’re fearless of risks because they don’t have anything to lose. They are tiny. As the company grows, they actually have something to lose and maybe their shareholders, at some point answer to. One of the things that scale does is it makes people more risk‑averse. Being averse to risk tends to make poor decisions. Certainly, you go to a big corporation and most of the people that work there, their primary job is to not get fired. That’s what they are there to do is not get fired. Everything else is secondary to that. That creates a lot of roadblocks and a lot of stagnation and a lot of problems, in and of itself. That simply comes from scale and from being afraid to risk. I think, taking a portion of people and putting them in a lab is probably a very good idea. Anything a large corporation can do that shakes things up and creates the opportunity to fail and it’s OK to fail where it creates an opportunity to have some…you really don’t care about risk anymore, is great. If they took a development team and they forced them to all work in a bathroom, they’d see increase in productivity. It’s just that changing the climate, changing the nature, changing the culture, and getting out of…you have a stagnant bit of water and you stir it up a little bit and things tend to go better. It clears up. You can see the bottom. We can write metaphors all day long. Clayton: Yeah, I think, we’re about out of time, but if I wanted to find out more about you or about your company, where could I go? Steve: Certainly, you’d start with lesseverything.com. There you can see the blog where Allan and I post and talk about things that we think are interesting. We post a lot of stuff about business. Definitely, check out lessaccounting.com which is our biggest product, for all your small business accounting needs. We, also, have another company that we run called lessfilms.com where we do short videos and animations, generally, for Web applications, but for anyone that wants. If you’re looking for some consulting work, you’re looking for someone to build your rails product, then check out lesseverything.com. We’ve got a great consultancy side of the business that’s still doing great work. Recently, we formed a partnership with cosupport.us. We’re [inaudible 13:39] , so now we can do end‑to‑end. We can build it for you, we can support all your customers while you grow your business. So, definitely, check out their stuff out at cosupport.us. Clayton: I really appreciate you taking the time to join us today. Steve: My pleasure, thanks for having me. Clayton: Thanks.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich… Roy vandeWater: I’m Roy vandeWater. Drew LeSueur: I’m Drew LeSueur. Clayton: Joining us today is Esther Derby. Hi, Esther. Esther Derby: Hi. Management Changes Agile Clayton: Today, we’re going to talk about how management changes with Agile. This is a really topical thing for a lot of teams, right now, a lot of organizations who are in the process of adopting Agile or have adopted Agile. I know this is something…management in general is something that you seem to write about a lot on your blog and reference on Twitter / @estherderby and what not. It seems like something that you’re passionate about. What is it specifically about management and how management fits in an organization that gets you so excited? Drew: I thought you just plugged Agile in and the team members just started performing better and faster. That was it. Esther: Some people seem to believe that that’s true. Clayton: How do you see management’s role in Agile? I think that’s kind of a muddy question for a lot of people. There’s not really a clear answer. Esther: I think there is a role for managers in many organizations. I think we did not do ourselves a service when some of the early pundits said, “We don’t need no stinking managers. Just fire all the managers and I’ll work well.” But I think the role changes. The first thing is that, for many managers, they go from managing a functional group where everybody has essentially the same skills to working with a cross‑functional group. Notice I didn’t say managing. I said “working with”. Clayton: It’s an important distinction, I think for a lot of people. What you brought up just there is something that we’ve seen in some of the work that we’re doing, where maybe someone was a functional manager say of developers, right? They have this very clear cut role of who was on their team and what they did. As the teams become more cross‑functional, you have people from other parts of the organization, maybe over there generating content or something like that, where they are not a traditional developer, but they are still integral in this part of the process for the product that they’re shipping. Now, there’s this kind of, “Well, these people aren’t on my team. I’m not their functional manager, so if I want to beat them with a stick, I can’t do that because they don’t report to me.” That seems to cause a lot of problems for some people. Obviously, beating them with a stick is not your idea of a good manager, but it seems to happen like that. Beating Developers With a Stick Management Model Esther: No, I think it’s an interesting mental model of management. I think it’s actually rather wide‑spread, but I don’t think it’s all effective. It may be effective in sense in that people will do many things to avoid being hit with the stick, but it may not include quality writing, quality software, grading quality products. Clayton: You use the specific word that managers are working with. They’re not managing people. In an ideal Agile organization or one that has adapted Agile and they’re utilizing their managers effectively, what does the managers’ day‑to‑day role look like? Roy: Does it have anything to do with what they learned in business school? Esther: Probably not. [laughter] The Real Power of Managers Esther: Well, I think the real power for managers and the real value they can bring to the organization is working across the organization and not just with one functional group or one team but understanding the organization as a system, removing impediments, and reducing the friction there is in almost every organization to getting quality products out the door. Lean tells us something about that, and systems thinking tells us something about that. A3 thinking tells us something about that, about really understanding what the underlying issues are in an organization and digging deep to understand what the causes are because there’s usually more than one cause and they’re entangled. Then based on deep knowledge choosing action to improve the situation. There’s less impedance for people doing the hard work of writing software. Hierarchical Management Model Drew: Do you still see management as the same type of hierarchical model that it is now where you have managers above the teams, then managers above the managers, and then you have to go like six or seven or however many deep before you actually get to the top? Or is it more flat? Or how does that work? Esther: [laughs] Well, I think that is the dominant model of how people think about organizations and how people think about getting work done is through cascading goals that flow down from the top, and everybody has their objectives. We’ve known for decades that that doesn’t actually work very well, but that is the predominant model. I think it’s very possible to have an organization that functions very well without so many levels of hierarchy. For example, my husband works for a company where they are extremely flat. I mean they do have a level called vice president because those are people who are considered officers of the company and can sign contractual agreements committing this company to projects and so forth. But beyond that their teams are all self‑selecting, and nobody has a manager per se. They have a coach who they meet with and who helps them develop their professional career. I don’t think it has to be a hierarchy to be effective, but that is the model that most people are familiar with. That’s the default that people go to when their company grows beyond a couple handfuls of people. Clayton: You’d hinted at the beginning about maybe the Agile community doing themselves a disservice by adopting the mantra of “Fire all the managers.” What do you think that would mean we could do different, or how can we rectify that so that we get a little more realistic? I think people have found out that you can’t just fire everybody. What can we do to bring the discussion of management and management’s new role into the fold and turn that into something that’s part of what everyone thinks or maybe newcomers think about Agile? Esther: Oh, I think part of it is recognizing that these are people who are worthy of respect. They’re intelligent, and they do have something to offer the organization although it may be something different from what they’re doing now because once we start treating people like they’re idiots or like they don’t have value, then people respond in a fairly predictable way by trying to hold onto what they have. They try to hold onto their self‑respect. They try to hold onto the value they bring. They try to hold onto their position. I think really meeting people where they are and treating them like, “Yes, you do have something valuable to offer” is a good starting point. Steps To Better Management Clayton: If I’m a manager that’s listening to this podcast and maybe I’m becoming self‑aware to some degree that I’m not helping my teams. I’m not empowering them as much as I could, whatever. Is there anything that you would recommend that someone in that position do that they could probably do starting tomorrow that you think would make an impact and would help them become a better manager in that environment? Esther: I think one of the first things that’s helpful for managers to do is to get clear with the team about what decisions belong with the team, what decisions are shared decisions, and what decisions stay with the manager. Typically the pile that goes to the team is the biggest pile of decisions, but then the money has to go with that. For example, if you tell the team, “Well, you’re responsible for your own professional development, so sign up for the training that you think you need,” but then you require them to come on bended knee, fill out a form, get permission, and have to go through an approval process, that sends a very contradictory message. Be clear about where the decisions lie, but also have the authority to make those decisions and carry them out. Go to the team where appropriate. I think training is one that can very often go to the team. I think teams should absolutely be involved in any decisions about who joins the team. I know, of course, the manager has to do the legal stuff there because it is a legal agreement for employment, so that’s a shared decision. Then be clear of the ones that stay with the manager because that’s one of the things where I see a lot of managers and teams get at cross‑purposes, is where the team believes that they have been delegated decision authority and the manager has a different belief about that. The team goes and makes the decision, and then the manager says, “Oh, no. That’s wrong. That’s my decision.” It damages trust. Team Empowerment Mixed Signals Clayton: It sends the wrong message, right? Esther: Pardon? Clayton: It sends the wrong message, right? Esther: Right, exactly. Clayton: On the one hand you tell them to be self‑organizing. Then when they do, you whip them back, right? Esther: Right and say, “You’re empowered and you’re self‑organizing but up until the time you do something that isn’t what I would have done.” That leads to caution. It leads to distrust. It leads to a team that’s risk‑averse. Clayton: It’ll probably lead towards a more homogenous organization to where only the people that think like‑minded are able to stay within the team. Esther: Right, right, right. I heard a really interesting talk last week when I was in Norway by a guy named Fred George. He works for a team that actually doesn’t have managers, and it’s a small company so they’re able to do that. But they don’t have managers. When this particular team decided that they needed to rewrite a particular piece of software, they didn’t have to get anybody’s permission. They just said, “Technically, and in terms of the functioning of this software, this is what we absolutely need to do.” Then they weren’t quite happy with it, so they rewrote it in another language. That’s a situation when most managers wouldn’t have said, “OK, go ahead and rewrite it twice.” But that’s a very, very mature team, and they have a lot of conditions in that company that make it possible for them to function that way. Clayton: When you talk about what managers can do, how about on the other side? You touched on it a little bit. If I am in an organization or I’m part of an organization where there is a hierarchy and it’s not as flat as maybe you’d like it, what can the developers do or the people who make the products do to help empower the managers to help the managers be more like working with as opposed to commanding them? Esther: Well, I think anytime you want a partnership, you have to be able to talk in the language that your partner understands, and this is true of any kind of partnership. You can’t just talk in the terms that are comfortable and familiar to you. I think one of the things that developers, testers, and all of the people involved in writing software can do is learn how to state their case in language that the managers care about and can hook into because particularly if someone hasn’t written code recently, and that happens in many organizations, telling them something purely in technical terms won’t convey the information that will help them be your partner. Learning how to frame things in a language that makes sense to managers, that they can click into, and that they can then take forward in a way that makes the case that the managers above them care about I think is an important skill. It’s an influence skill essentially. Differences Between Generations Clayton: Do you think that there’s anything to be said for…as far as the way management goes now, if it’s anything about a generational thing? Obviously, if you go take an average organization, the management is probably going to be between some age and some age. Do you think that there is anything that they grew up or they went to school, and there’s a certain way they do things? That’s how they’ve adapted that’s how they work? Do you think that’s going to change maybe say 20, 30 years from now that maybe people that are going to be in management roles might have a different outlook? Or is that just the nature of the people that get promoted whether they want to or not into a management role? Esther: That’s a really interesting question because I think sometimes it’s easy to sound critical of individual managers, but it’s actually the whole, as you are alluding to, system of management that predominates in most organizations. It’s a model that actually hasn’t been around forever. It’s only been around for several decades, but it’s very, very entrenched. It’s that hierarchical bureaucracy. Since that’s the only model that many people have seen or experienced, it’s sometimes hard for them to imagine something different. Right now I think most of our schools are teaching that, so… Clayton: Well, it seems like the schools and the organizations. If you’re the elite developer and you’re learning how to be a manager, you’re pretty much going to learn that from whatever your manager’s doing now. It just seems like it’s going to perpetuate itself. Esther: Yeah. Roy: People from that generation are the ones that are teaching the next generation of students, too, so it’s like self‑feedbacking. Clayton: Right. Yeah, it seems like it’s going that way. Esther: I’m not sure it’s generational because I’m probably older than a lot of the managers out there, and I don’t think that way. Clayton: Sure, that’s true. Yeah. Esther: I think it is a matter of perspective and that if you’ve only been exposed to one model it’s sometimes very difficult to believe another model will work, and particularly if your beliefs are that you have to push people to get them to work, and if you’re not on top of them all the time, they’re not going to work very hard. That’s a self‑reinforcing belief because people will work under those conditions mostly to…you’ve reduced the pressure and the stress not out of love of work or great, great products. But when managers who have that kind of mindset let up, people pause and they take a breath. That reinforces the manager’s belief that, “See? If I’m not on them all the time, they’ll slack off.” It’s a hard nut to crack because it is, as you pointed out, a self‑perpetuating system on a number of different levels. But there are some companies that are making choices not to go the route of that sort of hierarchy and that model of management. Clayton: Well, I think we’ve reached our time box here so I… Esther: [sighs] But this is such a fascinating subject to talk about in the rest of the evening. Clayton: Well, I did want to ask if I’m listening to the podcast and I wanted to find out more about you, books you’ve written, or maybe conferences you’ll be at, what could I do? Esther: Well, you can always visit my website EstherDerby.com. I think the one of the things I’m most excited about this summer is the PSL Workshop that is coming up in August. We did one in May, and we had so many people who were on the waiting list that we decided to do another one. This is a workshop I do with Jerry Weinberg and Johanna Rothman. I think this is excellent training for anyone who’s a leader at any level in an organization, and that means everybody. But I think for managers who want to think about organizations in a different way and hone their skills as leaders and see some different ways to help people be effective, that would be an excellent workshop. Clayton: Great. Well, we really appreciate you joining us today. It was a real pleasure. Esther: Oh, it’s my pleasure. Clayton: As always, we like to invite anyone that’s listening to check out the Agile Weekly fan page on Facebook, where you can continue this conversation and other conversations from our other episodes. We wanted again to say thanks. Esther: Well, I really appreciate the invitation. It’s been delightful talking with you guys.

Roy vandeWater: Hello, and welcome to another episode of the Agile Weekly Podcast. I’m Roy vandeWater. Drew LeSueur: I’m Drew LeSueur. Derek Neighbors: I’m Derek Neighbors. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Roy: Joining us today is Tom Mellor. How’s it going, Tom? Tom Miller: It’s going well. Right in the middle of teaching a scrum master class in the middle of Kentucky, it’s going well. I’m winding down for today. Managing Traditional Culture Roy: When we contacted you to be on you had asked to talk about managing traditional culture. Can you kind of give us an example of what you mean by that? Tom: This is something that comes up in our classes all the time. We can’t do this where we’re at or we’re having difficulty doing it. We run into traditional management, and so a lot of what we talk through is how you deal with management that is versed in traditional nomenclature. They’re used to talking the traditional development processes. They’re not familiar with terminology, actual terminology. I was just looking through, over the last five or six years, and invariably at every gathering there was two or three presentations given on how management receives scrum, what people did to allay fears, and helping to be supportive of work in the organization, and so forth. That’s really what I was trying at when I suggested the topic of the podcast today. Roy: Are you concerned more from a perspective of how to make these changes work around the existing company culture, or is this more from a perspective of trying to change the company culture to meet the changes? Tom: There are a couple of perspectives on this, or a couple of considerations. One of them is how stoic the company is, how entrenched it is in a culture already. The younger companies, the startups, the companies that have been generated ‑‑ I’m going to say in the last 15‑20 years ‑‑ those cultures grew up around a lot more progressive thought. That’s how I’m going to couch it, in management and in organizational structure, behaviors, and so forth. Companies that are older tend to be larger. They’re more entrenched in a culture that’s developed over decades, some of them. For instance the company that I work for it just celebrated its 90th anniversary. That’s quite a period of time to develop and entrench your culture. When you’re introducing practices that arguably will cause the culture some trepidation, cause the people that have been in that culture for quite some time some fears and some apprehension, then you have to consider how you’re going to support that. I did a presentation on this back in 2008 or 2009 at a scrum gathering in Florida. Some of the advice that I gave people at that time was you can’t simply go out and carte blanche challenge the culture of the company without providing some explanation and some actual evidence of why such a change in the culture would be beneficial for it. I’ve been reading a book I probably should have read a long time ago, called “Change the World” by Bob Quinn. In it, he says that transformational change for societies, and for companies, and for all kinds of large groups of people are very difficult because of the diversity of the population. Entrenched Cultures Derek: I’ve got a little bit of a question. Certainly we see in the work that we do that it really has nothing at all to do with Agile, and nothing at all to do with process, and the 99 percent of it is culture. The original signatories of Agile and early developers of Agile frameworks, whether it be Extreme Programming XP or Scrum ‑‑ you name it ‑‑ I think what they were trying to do is say, “Within the current crappy culture that I have, what can we do as a team to start to change the way we work and move the bar forward.” Now that we’ve seen a number of companies from big to small adopt these processes or these frameworks, what they all tend to do is hit a ceiling to where their performance gets impeded, because the culture around them won’t let them really take it to the next level. From a Scrum Alliance perspective or a CST perspective, are we doing people a disservice by still trying to sell them process opposed to really trying to get people to understand that it’s a much bigger change than process? Tom: We might think that a culture is crappy, or we might not be satisfied with the cultural nuances that we see unsupportive of doing work in a progressive way. But for all of us that feel that way, there are other people that feel strongly oppositional to that. It’s not like suddenly we’re the new thing, and everybody’s going to come on board. Roy: I’ve never been brought into a company that wasn’t having problems. There are certainly camps that say, “We don’t need this fandangled agile stuff” or, “We don’t need the address our culture to deal with the fact that we’ve had slumping quarters for the last 15 quarters, and our quality sucks ass.” But I’ve never been brought into a company that was high performing, market leader, totally kicking ass going, “You know, I really think we need some culture or some process changes around here.” Are we doing a disservice by companies that are seeking help by short selling them that, “Hey, improve your teams and start there, and that’s a really great place to start”? Drew: That might still be a great way to start though. Organizational Readiness Tom: This is a generalization and may be not supported actually by observation, but I think there can be a tendency to go in naively. If you come in and consult these companies, companies [inaudible 07:27] to feel that you have an answer. Why would you be there? To your point, if I’m doing well and taking [inaudible 07:34] at the market, and putting out [inaudible 07:36] products, I’m probably not bringing people [inaudible 07:40] improvement anyway. But if I’m trying to resurrect a company that at one time maybe didn’t perform well or maybe got bit by complacency ‑‑ any number of those really bad things that can happen at companies ‑‑ then there is a propensity to reach out for a silver bullet. Yet, there is a hesitation on those companies to invest into thorough changes that will be required if they’re actually going to recover or progress. It’s interesting because Gerry Weinberg has written for years that you can’t manage change in the same way that companies think that they can manage products, and manage people, and do all that. There’s even a model called the ADKAR change model that supposedly systematically and mechanistically structure your organization to manage change. He and Virginia Satir work very closely together for years, and the dynamics of the change are much more aligned to Virginia Satir’s change model, which there’s some kind of foreign element that’s introduced into a company that creates chaos over some period of time. That’s where support for change whether you introduce the agile practices or you’re introducing different engineering practices, however you want to characterize it, there’s got to be support in those organizations. The organizations have to want to have that support, and they got to reach out and bring that support in, in the form of coaching, or in the form of really good guidance. Otherwise, it’s a waste of everyone’s time if you’re just going to give a lip service, and you’re not really going to invest in the change. Clayton: I’m sure that you guys see a lot of people at your classes that have this problem. Maybe they are coming for refreshers, CSM, or whatever. They’re wondering how they can either change or just manage traditional culture and facilitate agile. What have you seen have been effective for those people. To someone listening that’s maybe in that same boat, how would you recommend that they manage that stuff? Organization and People First Tom: I took a fortune 50 company through that process, and I can tell you that I have scars and wounds on my body that resulted from people who thought I was crazy. The thing is that you have to put the organization, and the teams, and the people first. If it becomes about individuals, in any sense, then it will break down. If somebody goes in and introduces this, and sees themselves as heroic, or solely instrumental, or that sort of thing, there’s going to be a lot of animosity and resentment towards such a person. You’ve got to reach out. It’s in the terms of what Quinn wrote in “Change the World.” He used Christ, and Gandhi, and Martin Luther King as examples of people who didn’t have positional authority, and yet they created huge, transformational change. It survived them. It’s the same kind of thing that you have to go into organizations with. You can’t go in there thinking you’re going to be a hero. Those three people didn’t do that. They came in with a passion, and a conviction, and something that they felt would lead people to a better place. You have to bring people along with that. You have to reach out and appeal to people’s fears. You’ve got to be able to mitigate those fears. You’ve got to engender trust. It’s tough. People look at me in classes and they go, “Who’s going to do that?” I go, “I don’t know. It’s got to be somebody in your company.” Otherwise you’re going to have to do this surreptitiously forever, and eventually you’re going to be discovered. You’re either going to get discovered because you’re doing something against the grain, or, like was in my case, you actually get results and people can’t avoid seeing it. They’re going to look at it. They’re going to say, “How are those teams he’s working on getting good results?” Then the cat’s out of the bag. Once the cat’s out of the bag, you have to really think, from a therapeutic perspective, how am I going to take the organization through this? I’m not going to do it by myself, so I have to find allies out there that are going to help me. No Silver Bullets, But Lots Of Pain In Change Clayton: I think it’s a very good point. I think there are a lot of people that get really excited and passionate about this stuff, but they are expecting that kind of silver bullet. Or, they think they can be the hero and do it behind the scenes, and then it kind of blows up in their face. I think it is good to reiterate the point that there isn’t that silver bullet there. Tom: You have to have structural support. Otherwise, it will just become a fad. There won’t be any legacy to it. Roy: Tom, is there anything that you are currently working on, or any upcoming things that you’d like to share with the audience? Tom: I’ve written quite a bit about this. I have a blog called “Helping Pigs Fly.” That was the title of the presentation that I did several years ago at The Scrum Gathering, I just created a blog on it. One of the thing I focus on in the blog is how do you handle these kinds of cultural issues, and that sort of thing. If you Google “helping pigs fly” the blog comes up right at the top. There’s not too many things called helping pigs fly I guess. Clayton: If I wanted to take Scrum training from you, how would I go about finding a class? Tom: You can go on the Scrum Alliance site. Go to the training tab, and then search it. You can search by parameter. Tom’s Upcoming Courses Roy: Thank you for joining us. Tom: It was my pleasure, and I really enjoyed it. Thanks for having me on. Clayton: Thanks a lot. Roy: Thank you.

Jade Meskill: Hello, and welcome to another episode of the Agile Weekly podcast. I’m Jade Meskill. Drew LeSueur: I’m Drew LeSueur. Roy vandeWater: I’m Roy vandeWater. What Is The Agile Alliance Jade: We’ve got Mitch Lacey here with us on the Agile Weekly podcast. Great to have you here, Mitch. Thanks for coming on the show. Why don’t we get started by…I know that you are involved with the Agile Alliance. Maybe you could tell our listeners, who might be unfamiliar with the Agile Alliance, what the Agile Alliance does, what it represents, and how you’re involved there? Mitch Lacey: My job with the Agile Alliance is in the Conference Chair for the Agile 2012. The Agile Alliance itself is a non‑profit organization whose primary goal and focus is to advance Agile development principles and practices, and it supports this in a variety of ways. The conferences, probably its biggest way but it manages and hosts local user group meetings, supports for those, talks, community groups, the website has good resources and event listings. Agile Alliance, its primary focus, Agile software development, and the big source of revenue to supply that, those endeavors, is the Conference. Agile 2012 Conference Grapevine, Texas Jade: Maybe you could tell our listeners also about the Agile 2012 Conference that’s coming up soon. Mitch: Agile 2012 is going to be in Grapevine, Texas this year. I’m really looking forward to it. We tried some new things this year with regards to our keynotes and to a new stage called the “No‑Bull Know‑How” stage, where we have a bunch of known industry experts that’ll be there, not giving a talk, but they’re actually going to be answering questions that people can submit on the website, provided they’ve registered for the Conference. Then come up on stage to have, as intimate as you can be with a couple hundred people in the room, an intimate conversation around large topics of choice at hand. We’re really looking forward to that. The Conference itself, we had over 800 submissions this year. We had to accept 20 to 25 percent of those, so we have a little over 200 submissions that came in. One of my big charters for this year, one of my goals and objectives, was to be able to increase the amount of technical content, as compared to traditional management or program management content. Increase the technical content from last year, it was at 10 percent, up to 25 percent. I didn’t totally hit that goal but I brought it up to 15, little over 15 percent. That is something I’m pretty happy with. Increased Technical Content Drew: When you say technical content are you talking about more like developer‑oriented stuff, like XP stuff? Mitch: Correct, yeah, developer‑oriented stuff, eXtreme Programming XP stuff. For example, how are people doing Agile for iPhone and iPad development? How are they doing Agile for embedded systems? What are some good modern practices around TDD? What are people doing? What are the emerging trends? They’re just bringing it back from a more program management, leadership focus to making sure that the technical content is included because you guys know that’s where it started. Drew: Right. Mitch: I don’t want to get that lost. I don’t want to see that be lost, so I had some very passionate conversations last year with some individuals at the conference who wanted to get involved and I took them up on it and I think we’ve got a pretty good program this year, I’m pretty happy with it. Jade: What’s one of the sessions that you’re looking forward to seeing, especially given that you’re really putting an emphasis on the technical side of things. Mitch: [laughs] It’s funny because I’m not even sure I’m going be able to go see any sessions. [laughter] Technical Sessions To Attend Mitch: There is a session on Monday with Eric Smith and Eric Meyer around “Make your iPhone Agile with automated iOS Testing” which, to me, sounds pretty cool that I want to see. We also did something different this year. Corey Haines is doing a full day Immersion coding development workshop on Wednesday, which, if I had a full day to go I would go to it. I’m really excited for that. I think that’s going to be a fantastic program for people to come in, get their hands dirty, and do stuff. Bob Martin will be there. He’s doing a session on Clean Code, which is great. Liz Keogh will be there doing a session on Behavior Driven Development which is going to be great. There’s one session, and I remember this one when we were laying out the program which made me laugh and the title of it is “Does pair programming have to suck”? [laughter] Mitch: It’s obviously funny because when you start out at those you actually learn how to do it. It gets significantly better and easier. Dave Bernstein is doing a session on Writing High Quality Code that I think is going to be pretty exciting and fun. The coaching stage also has a lot of good stuff on it as well. Dave Hussman is doing a session over there. Sam Laing and Karen Greaves are doing a session on Brain Science on Monday ‑‑ the first day. It’s a three hour session I won’t be able to go, that’s one of the ones that I’m recommending to people just because it’s interesting, really cool, really exiting. From a program standpoint it’s pretty challenging to find a session that you want to go to knowing there are so many other good ones. I was on the phone with somebody earlier saying, “Hey I am a first timer. I don’t know what to see, I don’t know who’s who, what should I go see”? I spent about an hour on the program with her diving through it and she said, “So you recommend everything.” and I said, “Well, yeah.” [laughter] Mitch: I do, why don’t you go look at it and let’s talk again next week and you pair down the list a little bit and I’ll give you my thoughts on your paired down list. Jade: Awesome, sounds like some really great people. The Venue Is Amazing Mitch: Yeah, it should be a lot of fun. I’m really looking forward to it. The party on Thursday night is at the Glass Cactus Nightclub which is there on the Gaylord compound overlooks the reservoir, the Lake Grapevine. It is a beautiful building. We have a great band called the Emerald City band and a comedian that is going to open up for us as well, should be pretty fun. What Has Your Attention Jade: Awesome, looking forward to that. Shifting gears a little bit, what is something that you seen lately maybe a recent development in agile technical practices that’s got you exited, or frustrated, or what’s got you hot and bothered in the technical realm? Mitch: I can’t say that I have stumbled across anything new but the thing that gets me hot and bothered in fact I had another conversation with a person today about this. She was a customer, a friend of mine, she was telling me that in her organization you’ve got management who’s bought off which is, they’re saying, “Let’s go go go let’s do it whatever resources you guys need to make this happen.” Then you got the middle management which was surprisingly was bought off and supported and you had half the team, the testers, ready to rock the traditional project managers ready to rock and you had the developers saying, “Yeah I’m not sure I can build anything in a month and have it be potentially shippable, it’s going to take a six month to design the system let alone to actually get anything written probably a year and half.” It drives me bad when I see that behavior because it’s so well known ‑‑ at least for me I think it’s pretty well known how that stuff works. We’re constantly ‑‑ as people in this industry ‑‑ we constantly have to re‑sell and re‑sell that message, of people have done it before us, it does work, you have the right mindset you’re are going to be fine, if you don’t it’s not going to work. I know it’s not really a development practice you have under focus for some developers today, but I just bang my head against the wall time and time again and it just, I’m sure you guys do when you hear, “That can’t work here,” story or “That doesn’t work in the real world.” Obviously when people say it doesn’t work in the real world I won’t know what world they’re in… [laughter] Mitch: …because, in the world I live in it works great. As far as I’m concerned we are all in the same planet but maybe not. Broken Mindsets Jade: What are some of the techniques that you might use when you end up in that situation where you, going back to your scenario we can’t even design it in six months let alone deliver something in a month that’s just impossible? What do you do from that point? Mitch: At that point I really focus, what I do is try to focus on the past. And say, “OK. Hey, you’re right. Walk me through how you’ve done this. How would you go about and do this”? And of course they’ll start out and like to this day it wasn’t a development team, they that they are thinking of. The development team wasn’t on the phone. It’s like, “OK, let’s walk people back and say, ‘What have you done in the past’”? They lay it out there and say, “Now, tell me when all the problems surfaced in that area.” Of course, they always surface at the end. Telling people doesn’t work. Telling people, “This is the way you should do something,” doesn’t work because you have to paint the picture inside their head and show them what it is they’re missing or what it is that needs to be seen for them to have the light bulb go off and go on, “Ah, now I understand everything you’re talking about. I still don’t believe it, but, at least, I understand it and I’m willing to take a little bit of a leap of faith on this to be able to drive it forward.” That’s when having somebody there to help comes into play. I’m a big fan of painting the past. They can paint in the past, highlight in the failures and go, “Great. If we keep doing the same thing, we should expect those results.” Drew: Great stuff. When a developer has that mindset, “There is no way we can do this in this amount of time,” what do you think it is? Are they afraid to release something because then they’ll have to be held accountable for it? Or is it they’re just used to procrastinating and not really releasing anything? What do you think causes that? Mitch: It’s both. It’s procrastination. It’s accountability. It’s the fact that people have been trained. You get trained in school. You got to school, you learn development. You won’t learn project from the get‑go. There are very few schools out there that are teaching that stuff. Most of the people, like my next‑door neighbor, he’s a computer science major and he’s learning that you go off and you do your design up front. You go write all your codes, then, you go write all your tests. Jade: Right, it’s the same continuing… Mitch: He comes next door and he goes, “Mitch, how does it work at Microsoft? How does it work here? How does it work here”? I tell him, I say, “This is what I advocate. This is what companies do.” I gave him a copy of my book and he read it and he’s like, “I’m not learning any of this in school.” It starts at that ground level foundation because you’re teaching somebody how, if they’re right‑handed, you’re teaching them how to be left‑handed. You’ve been right‑handed all your life and now, suddenly, somebody’s telling you to be left‑handed. That doesn’t really work that well, especially if you’re expected to learn it overnight, which a lot of management teams really drive. Because of that, you see a lot of resistance with development teams. You see a lot of resistance with management in the fact that they say, “We can’t do it.” That’s part one. Part two is the fact that people look at a holistic solution and think that they have to build the framework and then, they have to build the UI and they have to build all these things and, hopefully, it all comes together at the end. As you guys know, everybody in our space is a big advocate of, “Let’s build the smallest piece first, smallest thing, validate functionality and direct forward with it.” Of course, that creates the mindset that you have to have this throw‑away work and organizations, often, frown upon throw‑away work because as development teams, we should get it right the first time. [laughter] Mitch: The problem is we’re not going to get it right the first time because software is a creative process and it’s artistic and the IDE is like the canvas. You’re going to paint and you’re going to repaint and you’re going to repaint again. It’s impossible to get it right the first time. You have to go through and do some sketches, do some prototyping, create some GIFs and user stories that working so you can get feedback from the customers. If they change their mind, that’s a good thing. A lot of companies think that’s a bad thing because they have everyone sign in blood. [laughter] Jade: That’s right. What do you think our responsibility is as those people who have found this new way and we still look to the traditional university environment and other things that are teaching people that this outdated way of developing software? What should we do about that? Mitch: What should we do about it? First thing, let me back up, I’m not necessarily sure it’s an outdated way, it’s just a different way. I’m a big advocate of Waterfall. I think Waterfall is great. However, if you’re in an environment that’s going to change and if you have customers that are going to change and if your business is changing and it’s changing so rapidly that you have to be able to respond to it, then Waterfall is not a good solution. Traditional approach isn’t a good solution because you pick any one of the Agile practices, one of the core penance of those is the ability to respond to change, to be able to manage and respond to change to build what your customers mean, not what they’re asking for. All responsibly in that is to help build trust with customers and stakeholders because as an IT industry, we’ve been breaking their trust for the last 30 to 40 years. Every time we say that we can go do something, we deliver late, we deliver with low quality and that degrades the trust. Then, of course, our business puts more controls on IT and says, “OK, you must commit to this. You must do this. You have to have very precise estimates.” It’s a really evil cycle that we have to deal with. It’s part of our responsibility to train management, train leadership and, most importantly, train the customers to help them understand that we do have their best intentions at heart and we don’t want to screw them over. In order to do that, we have to work together. We can’t promise the world because we know what we want when we see it. We know that when we see things they will change. Jade: Mitch, as we wrap things up, is there anything that you’d like our listeners to go check out? Where can they read more about you, pick up your books, all of those things? Mitch: Definitely, it’s in the Agile 2012 conference. It’s going to be a kick‑ass event. My website is mitchlacey.com, pretty easy. Amazon has got the book up there. I’m very proud and happy. It’s up to 33 positive reviews. 31 of those are five stars and two of them are four, so people are reading the book. People are liking the book. I couldn’t be happier. Conference, awesome. Great website. Scrum Alliance, which we didn’t talk about. Lots of good stuff of that website as well. Good content, people should go read up there. You guys have some good content as well… [crosstalk] Mitch: …and podcast, everyone should go listen to them. Jade: Thanks so much for joining us on the podcast. Good luck with Agile 2012. We’re really looking forward to seeing all the great content coming out of there. Thanks for joining us. Mitch: I think Derek’s got one of those invited No‑bull sessions. Jade: Yeah, he does. Roy: For our listeners, if you’d like to continue this conversation, you can join us on our Facebook page at facebook.com/agileweekly. Jade: Thanks, Mitch. Mitch: Thanks, Jade. Jade: Talk to you next time.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Derek Neighbors: I’m Derek Neighbors. Drew LeSueur: I’m Drew LeSueur. Clayton: Joining with us today, we have Arlo Belshee. Arlo, can you tell us a little bit about yourself, where you are, where you work, what you do, kind of thing? Arlo Belshee: I’m in Seattle. I work for Microsoft, and I’m currently working on the OData Protocol, Wexford Web Services, and Protocol Definition, Open Web Protocol. My background, whole lot of background with all sorts of things extreme programming XP, been doing it for a decade or so, coaching teams. I bounce from company to company and project to project to find the ones who really want to do awesome, and help them do so. Extreme Programming XP Practices The Engine Of Delivery Clayton: We wanted to talk to you about some XP practices and I guess at a high level. What is it about XP that attracts you to that versus some other agile methodology? Arlo: It does the part that matters [laughs] , certainly what it comes down to. The way I think of it is, assume that our objective is to get to Chicago, and we’ve got a bunch of different ways that we could do so. One of those options is traditional development style. I’m going to lay down some track, like a big plan, build it and build myself a little hand cart. I’m going to lay down all this track, build myself the hand cart, climb on it, start pumping, and, I will get to Chicago. Other practices do parts of a different approach. All the agile practices, you’re basically going towards, we’re going to drive there. Instead of doing this pre planning, we’re going to respond to the information as we go, and navigate the roads. We’re going to build ourselves a vehicle that can respond. Great. Then, let’s look at what are the practices, and what parts of the car do they apply to. Scrum, that’s the steering column. That’s basically what’s in Scrum. No matter how good my steering column is, I’m not getting to Chicago with just a steering column. XP I like because it talks to the technical practices. The technical practices are the engine. You can get really, really far with XPs technical practices and a waterfall planning practice, that’s called a locomotive. It will get you to Chicago. [laughs] That’s what attracts me there. I also do really like the Lean thinking stuff. The learning practices from XP and the Lean thinking practices align very well. I think that’s also a very critical part of it, but fundamentally, XP is the one that gets that all the rest of Agile is enabled by doing good engineering and it tells you how to do so. Which Extreme Programming XP Practice Is First To Implement Clayton: I’m going to kind of set you up here. We’ve had some discussions internally about, you know, if you look at some XP things, what’s the most important? There is only one thing you could adopt, so we’re going to ask you that question. If there’s one thing that a team could adopt, some XP practice, whether that be pair programming, or continuous integration, or whatever it is, what’s the one thing that you would suggest? Arlo: Part of the thing with XP is that there is a one thing that’s a good answer to this. But it’s well broken down in all the descriptions of XP. In a description of XP it shows up as like five different parts. Clayton: What if I said the first thing? Does that change it, if you say the first thing you would suggest? Arlo: It’s the one thing that I would do is continuous learning and reflection on your code. That shows up in XP books as a combination of TDD, sit together, pair programming and refactoring, because it talks about all the pieces. But, those aren’t individual pieces. The individual piece is really that continuous reflection, and understanding, and learning, and improving of the code. The other things are they are windows on the tool [laughs] you can use to understand with. If I had to choose one thing and I can identify a thing, it’s that. If I have to choose one of the practices out of a book, then I would probably say it’s pair programming, assuming sitting together. Clayton: OK. Arlo: But, really that’s part. Extreme Programming XP Practices Compared to Software Craftmanship Clayton: You mentioned a lot of the technical stuff, and I guess, maybe this a side bar, but I have to ask, where do you stand on that software craftsmanship stuff? Is that good, bad? Arlo: The movement or the thinking? I, personally, don’t much buy into the movement. I don’t see problems with it, but I do see some places where it misses its mark. A lot of that’s in how it talks about things, and how it thinks about learning, on the intent that what matters is doing good code. To do good code you learn to do good code. You work with other people, and no holds barred, we’re going to do good code. Totally agree with all that stuff. Common Pairing Programming Problems Clayton: A more practical question. In terms of pair programming ‑‑ that’s an important one, I think. I, certainly, enjoy pair programming and all the benefit out of it, and everything. What are some common problems that you see that teams have, or maybe people have, when they pair? Arlo: There are a couple of different sets of problems. There are the problems that are related to learning to pair, transitioning to pairing, all that sort of stuff, and there are the problems related to actually pairing. I find most teams have problems not with pairing, but with the transition. There are problems that show up with pairing as well, but I think the more interesting ones are the transition. Just like transition to Agile is very different than doing Agile, transitioning to pairing is very different. The way I think of it is learning to pair is, fundamentally, your learning a different language. You think differently, you learn to think in pair, and it is a very different way of thinking. It’s critical to develop subconscious filters that are filtering your environment differently, so that you’re not being destructed by the noise but are subconsciously noting it. When something comes up, when a keyword gets mashed your subconscious mind fills in the last 15 seconds of conversation, just like when somebody says your name. The closest match we have is learning another language. I really encourage teams to do that transition both as an experiment and like they’re trying to learn a language, which means that you define a period of time that we’re going to try this experiment. It’s got to be at least three/four weeks because we’re talking about training the subconscious. That doesn’t happen quickly, takes a month. [laughs] You got to be three/four weeks, you got to expect that it’s going to look really awesome the first day, it’s going to be sheer hell by the end of the first week. You’re not even going to be able to think straight. Basically, your mind is now trying to think in two different languages at once, and everything is blocking itself. That’s what’s going to happen in the second week. I see a lot of teams don’t know what to expect, in that transition period. They get into that first couple of weeks, go, “Oh, God! Stop doing a hundred percent pairing,” and they say, “OK, we need to back off.” Then they do 50 percent pairing, which becomes 25 percent. We’re pairing certain types of tasks. At that point, you’ve now switched from a more mature learning of a language to learning of a language in a high school classroom. You’re never going to get the accent, and it’s going to take forever. You’re never going to see the value that you do, if you can actually understand what immersion learning is going to be like, be willing to accept that, and then make it happen. Introducing Pair Programming Derek: I’ve got a question on getting to the transitions. Let me give you two scenarios, and tell me how you would approach them, and whether it’d be the same way or apparently different. One would be, I’m a development manager, and I’ve really started to read about this XP stuff, or maybe I’ve worked in another company, and we’ve done XP before. I really believe in it, except none of my developers currently want to pair program.” How do I start that process with that transition? Is it OK to just say, “I’m going to demand that you all pair program, and deal with it. Let’s talk about it in three weeks?” The other scenario would be, “Hey, I just joined a new team. I came from an XP team, I really miss that, and I really want to do that.”Maybe there’s another person or two on the team that are interested in it, pair curious or XP curious about things. How would you go about coaching that person to moving to transitioning to pairing? Arlo: The meta‑approach is the same, and then the details vary by the context. The meta‑approach is to understand that people decide emotionally, and then justify rationally. Rationalization is called that for a reason, is the only way we use the rational mind. If you want to get people to make a decision to try pairing, it’s an emotional sell, because they’ve got an emotional commitment to the current one you’ve got to change to that, which means inspire for [inaudible 10:02] . Some of the things I have done here, I did a code retreat. There was a set of people. That was the right thing. We got together, and a code retrieve, you are doing everything paired. Also most of the people around here don’t have great tools. I’m showing them Resharper, and I’m showing them End Crunch, and I’m showing them all sorts of stuff that they can’t work in their daily work, because they’re working in C on really old Legacy systems. Bring all of those things together in a room. Now pairing is something fun that I got to do for a day, which allowed me to learn simultaneously this language, and solve the problem, and learn four or five tools, and, holy cow, it was a successful day. There I’ve inspired. That one works. Another one is, I can do a demo and show some of the things that are going to result, and that can be another good way to inspire. We did an exchange program for a little while, which will be starting up again soon. Where team could go visit teams from other companies. Smilebox is just down the street. They have a really good XP shop. They do a lot of pairing, and it’s full collaborative style with everyone in one room and the devs and the marketing people and whatever can overhear each other and all the goodness. When I could take people from the teams here over to visit that, suddenly, without having to learn pairing or commit to pairing, they could see the value that comes from the collaboration and the learning. Then we come back and we talk about how we will do that transition. [laughs] Clayton: I thought it was very interesting you hit on that transition part. I think that’s a very good point. There’s a team I’d been working with where one of the guys was like, “I’m so mad at Derek, because he writes all this terrible code. I’m so mad at Drew because all he does is goof off all day.” He and I had done some pairing, and I said, “Oh, well this would be a great opportunity for you to promote some pairing. You guys have your desks set up for it. This would be fantastic. You can solve all these problems of you just do something…” “Well, I don’t know,” and it turn into it was very much that, I don’t want to get into the transition thing. I can’t even imagine how that would work, and it was too much of an emotional blocker for him, I think. I thought that was very interesting. Let’s Try Some Cool Stuff Arlo: I found that the emotional block is huge, and it’s especially huge if it in any way sounds like you are trying to sell a change to pairing. But if I tell people here’s some of the advantages, and especially get them to experience one of those little experiments of, “Hey let’s try some cool stuff,” I’ll often sell the pairing by getting them to try GDD and refactoring. “Let’s go play with these cool tools. Oh, to help people learn the cool tools we’re going to do pairing with rapid pair swaps,” and then they see the advantage of the collaboration. I’ll do that, and then the second is pitch the transition purely as an experiment. The ground rules I start with are ‑‑ we are going to do it for three weeks, we agree and understand that it’s going to be painful, and we are going to do that. We also agree that at the end of three weeks we’re going to stop. We’re not going to pair in perpetuity. We’re going to gather data of whatever data we think is relevant to this, measure the result of that experiment, and then discuss the results of that experiment. We aren’t going to do anything more than that. If as a result of doing that experiment, now people want to do a transition, we can talk about doing a transition to pairing permanently. That no commitment thing really helps. Extreme Programming Practices XP That People Struggle With The Most Clayton: Just kind of a last question here to wrap up. Is there a particular technical practice or maybe a particular part of XP that you find that teams are pretty much always bad at, and they really need to spend some time improving? It’s kind of universal across all teams. Arlo: Yeah. Unit TDD. There are a fair number of teams that do TDD. There are very few teams that actually do Unit TDD. They write short span integration tests, or long span integration tests, they don’t understand a unit. They won’t re‑factor the code, be unit testable. Instead they’ll use mocks. I hate mocks. [laughter] Mocks and dependency injection, which I also hate, to allow them to test otherwise un‑testable code. Those tools are great for Legacy systems, because you got stuff that’s intertwined, and you want to test it anyway. Wonderful. But if it’s not Legacy re‑factor it, so it’s not intertwined. Now you don’t need the tool anymore. They’re crutches that can really get in the way. A lot of teams just don’t understand what a unit is therefore they can’t do Unit TDD. The closest they can get is unit like TDD with mocks, where things are sort of units during testing, but they’re not actually units in the product. They aren’t getting any of the design advantages. Most of the bug elimination and that sort of thing from TDD actually comes from the design, not from doing little verifications and validations. [laughs] That’s the technical practice that I think everyone needs to learn, and it’s also an interesting one, because it’s the one that everyone who’s practicing assumes they already know. Clayton: That’s an interesting point. I think we are out of time here. If I wanted to go find you on the Internet, or learn more about you or the stuff that you are doing, where would I go? Arlo: Twitter handle is []@arlobelshee](http://www.twitter.com/arlobelshee), and I also do a blog, @arlobelshee.com. Clayton: Is there any books or anything like that, anything that you’re involved in, any project that you would like to suggest for the audience? Arlo: Yes and no books. The project I’m working on, if you’re interested in restful web services, and all of that sort of stuff, by all means, go look at ODATA. My agile stuff is mostly talking at conferences, the blog, and occasional tweets. Clayton: As always, we’d like to invite the audience to check us out on Facebook at facebook.com/agileweekly, where you can talk about this episode, and all the other episodes, a little bit more in detail if you want to continue the conversation. Arlo, we really appreciate you joining us tonight. Thanks a lot. Arlo: Thank you.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton. Drew LeSueur: I’m Drew. Cognitive Bias and Estimation Clayton: With us today, we’ve got Jim Benson. I might know him better on Twitter as ourfounder. We wanted to talk today about the cognitive bias and estimation. Jim, I see that you’ve written an eBook or Kindle book about plans and cognitive biases, under just biases in general and plans. Could you give us an overview of what it was that prompted you to write that book? Jim Benson: Sure. My career actually started in Psychology and as I worked my way through being an urban planner where I built really, really large things, like subway systems and freeways. Later, when I came to software development, it was incredibly obvious to me that people just couldn’t estimate their way out of a paper bag. Most of the breakdowns in projects regardless of what they were or who they were for, generally centered around problems with the estimates. I started to look into reasons why that was and I started finding clues in psychology. The psychology of how we approach problems, how we gather information, how we make decisions, all of those combine to really muck‑up our estimates. Estimates Are Wasteful Clayton: OK. You know one thing, I don’t know if you are a part of this camp, but a popular mindset nowadays seems to be that estimates are wasteful. No one ever gets them right, so why bother doing them? Where do you stand on that? Jim: Eisenhower said that planning was important and that estimates for it and plans were useless. I believe that the same thing is true, that estimation is indispensable and that estimates are useless. Going through the exercise of estimating is actually rather important. When you change it to an active word instead of a physical object, going from an estimate to estimating, then estimating becomes something that you do constantly throughout the project and that’s much more helpful. Clayton: That is an interesting way to think about it. Obviously there’s a lot of teams that, probably experienced the idea, they do some estimates and that gets held against them or something like that. But I agree that there is something important about that mental exercise. Now, in terms of some of the biases or some of the more psychology things you hinted at, what are some examples there that you could give us about some things that some agile teams might face? Availbility Heuristic Jim: I’ll just start to cherry‑pick and I’ll come to the big one, maybe third. The first one is something called the “availability heuristic.” When you look back on things that have happened and we pick out exemplars of either our fears or our hopes, and we then start to make decisions based on those exemplars. The worst part of this is an exemplar can be status quo. What we found is that the error in estimates follow almost a perfect Pareto curve, or almost a perfect power curve. We start to feel that we’re very good at estimates because we actually do get them right, about right, or excusably right, about 80 percent of the time. The other 20 percent of the time, we perceive that we are dead wrong, so we say “If I could just get that last 20 percent right, everything would be fine.” But it’s actually a natural power curve, it’s a natural law, especially in software development that we’re always going to fall prey to because there’s too much variation in our work for us to estimate accurately, a 100 percent of the time. Clayton: Take scrum as a methodology that puts a lot of emphasis on predictability and timeboxes. Usually in most of the training literature there’s a lot of emphasis on the estimates, specifically Planning Poker. On a scrum team, do you think they just need to find some way to overcome some of those biases and problems, and just deal with it? Or should they find creative ways to avoid those issues, or creative ways to do estimates differently? Planning Poker To Eliminate Group Think Jim: I’ll start this by saying it is dangerous to ask me about Planning Poker, and then I will try my best to state this as distinctly as I possibly can. Planning Poker itself was devised to get around groupthink and other cognitive biases to play teams. The theory behind it was, if you got people together and they in silence and at least cognitively separated from each other came out with like an opening bid for what the number of story points were for a given story, or a given task, or given feature, or whatever you are estimating against. That will overcome the bias. What happens in teams almost uniformly is that as they do planning poker over time, the teams’ estimates become more uniform. People see that as a good thing because they see that the team becoming more accurate. But what’s actually happening is that the team is learning how everybody else learns. There’s a heuristic that is being developed within the team that says, when we as a team sees this, we do these things. The individuals stop acting like individuals and they start acting like a team and our time planning poker becomes less and less useful because the individual is sublimated to the will of the group. A lot of people will argue with me about that because it’s a hard thing for you to swallow as an individual because you don’t feel like you’re doing that. But the actions of the coalescing of the estimates of the teams are very good indications that that indeed is what is happening. Clayton: Is that something that, if you go back to the a typical or particular size scrum team, if they are coalescing on those estimates, does it really matter if the estimates are kind of…if they can come full circle with the group think thing…if they are using their velocity, maybe their estimates are all close to each other because they are all kind of learning maybe subconsciously however on those estimates. But does that really matter in the overall schema of things or is that something that they should avoid? The Esimtate May Not Be Wrong, But The Commitment Likely Is Jim: It doesn’t matter because they are still going to be wrong 28 percent of the time, not because they’re wrong, so I want to make this clear that the people doing planning poker are not wrong. The estimates that they are doing for at least…say you have a three‑point story and you have six of them and four of them are right. Let’s say the three‑point story takes three hours to complete. They do 3,3,3,3, and that’s fine, and the next one is 7 and the next one is 11. That is a valid distribution on our Pareto scale. All three of those different time signatures or time stamps are all valid for that three‑point story. The problem is our commitment, the sprint commitment, does not take that into account. One of those three is going to end up taking 11 hours. It’s going to make people blow their sprint commitment and people are going to feel bad about that and then they’re going to wonder why and they’re going to try to fix it the next time but it’s not really valid to fix, because statistically that was a valid distribution. Clayton: I would question that a little bit, Jim. You’re absolutely right if you look at probability theory you roll a dice, a three‑six‑sided dice or a six‑six‑sided dice and the number of times you’re going to get a distribution curve that’s just like what you’re talking about. But if the team were to do a commitment driven approach to planning I would argue that they would know that one three‑point story was 11 hours and one three‑point story was 7 hours before they actually made the commitment. Teams Lack Self-Awareness Jim: And that’s awesome. That’s completely awesome and I’m happy with that. The thing is that right now, this conversation we’re having is about a hypothetical team that is operating at a hypothetical level self‑awareness and most teams A, aren’t that self aware and, B, don’t have the luxury to backpedal when they find out that there is variation in their system. Yesterday’s Weather Is Dangerous Clayton: Yeah, I think that the real problem is that we’ve propagated for far too long on this community that yesterday’s weather is a good way when using story points to predict tomorrow and then actually ask teams to make commitments against yesterday’s weather. And as any weathermen would tell you that they’re not probably willing to bet their jobs on yesterday’s weather and I don’t think that sprint teams should be doing that either and so how do we start educating people that if you’re going to take the time to estimate and if you’re going to take the time to use velocity, that you use the proper techniques to actually make it meaningful. I would almost argue, to most teams, it is not even worth them taking the time to estimate, because they’re not doing release planning. They’re estimating for, I guess, just to make their boss feel they’re doing as much work as they say they can do, but it’s not being used for anything meaningful, so it almost defeats the purpose. Jim: Yes, I would agree with that. I do want to make it clear that my dislike of the measure of story points doesn’t really have too much to do with agile or the act of estimating. It has to do with creating a system that doesn’t translate well from one part of the organization to another. Story points end up being integers. Those integers are communicated to people who try and interpret them, and they’re going to interpret them incorrectly, because, for the team, it’s a relative measure of what ideally would be bizarreness. That’s a 13‑point story, because it’s really quite bizarre. But other people are going to uniformly interpret those as either money or time. That’s very dangerous, and it leads to a lot of unnecessary conversations and unnecessary meaning. I actually think that the active estimation is awesome, but the creating an artifact that can be so easily misinterpreted is dangerous. Estimates vs Absolutes Clayton: Is it really dangerous, or is it just being used improperly? One of the things that I would argue is that, I think, the reason why teams should probably use points if they’re going to estimate is because they are integers, and they can be used for things. The problem is the people used them incorrectly for a time. If I try, as you stated earlier, say, how many hours is three points equal to, that is very, very dangerous, because three points, by itself, is going to be very highly variable. However, if I’ve got 100 three‑point stories in my backlog or in my release plan, I can probably get some normalized numbers out of there. If I say, “Hey, for the last X number of sprints, we’ve been doing roughly X number of story points,” while still an estimate, I can predict the future to a degree ‑‑ several weeks or even a month or so out ‑‑ to be able to say, “I should be able to get roughly somewhere in the neighborhood of this.” I think people get in trouble when they make them absolutes, when they don’t have the discussions around it, and then they take those numbers to be, “Well, you said you could do 30 story points, so I took 30 story points times 10 iterations, and, by God, you’d better give me 300 story points.” That’s dangerous. Jim: Exactly. Drew: You talk about the state of estimating. I’m wondering, what does that look like? If it’s not story points, what does that look like? Also, how did you apply that with the bigger projects like subway systems, or whatever, that you did? Hofstadter’s Law Jim: I will answer that by skipping forward to [inaudible 13:28] , because, if we’re having a cognitive bias conversation, I should probably say something about cognitive bias. The one I’ll talk about really quickly here is the planning policy. The planning policy is exemplified by something called Hofstadter’s Law. Hofstadter’s Law states that, when given a task, people will uniformly underestimate that task, even when they are aware of Hofstadter’s Law. [laughter] The Planning Policy Jim: The planning policy basically says that, that we, as individuals, are really lousy at estimating, we’re extremely lousy when estimating for other people, we’re unbelievably lousy when estimating for ourselves, and we’re just super incredibly terrible at it when estimating for ourselves with witnesses. When you get into a situation where you’re estimating, we have a lot of natural tendencies to underestimate the thing that we’re estimating. This has been tested by psychologists, social scientists, and behavioral economists around the world. It’s been shown to be a cross‑cultural, universal human condition. Part of the reason for that, I believe, is that we don’t understand the role of variation in our work, so we don’t understand that Pareto distribution all along a three‑point story. Therefore, when we promise things to people, we promise them like, “Every time I do this task, it will take me three hours.” In software development, we do not have that luxury. Our work is way too variable. What I replace that with is either cycle time or lead time with some sort of visual control. It might be a Kanban and it might be something else, but, if you have a system that can measure when you start working on a task, or a feature, or a user story, and, to the point that you finish it, that’s it ‑‑ cycle time. It doesn’t care what excuse you have about why it took longer than you thought it would. What it will do is will say, “That task was a three‑hour task that I got interrupted four times, so it took me 12 hours.” I’ve got bad news for you. For deliverable standpoint, it was a 12‑hour task. Replacing story points with actual statistical measure of what is completed and how long it takes to complete that thing is extremely powerful. When we do that, we get an added benefit. We used to have to say, “Well, this is a two‑point story,” “This is a three‑point story,” “This is an eight‑point story,” and so forth. Now, we can say, “That story is too big,” or, “This story, I can do. I don’t care if it’s going to take me an hour, if it’s difficult, or I don’t care if this can take me 13 hours,” because, over the course of the project, the distribution of those stories from small to large is going to be relatively stable, is going to be relatively like it was in the last project. We’ve been finding that that distribution is uniform or fairly uniform between projects, and, when we start to distinguish between things like a three‑ or a five‑point story, we run into something that’s called distinction bias, where human beings love to figure out what the difference of nearly identical things are. When I’m doing this before a crowd, I can hold up two green pens, and people instantly, everybody in the room who’s looking at me, are trying to figure out what the differences are between the two things that I’m holding in my hand, and they’re both the same green marker pens. So using a statistical measure that is impartial to our excuses and immune from a couple of these biases ‑‑ not all of them, but a couple ‑‑ helps us build more predictable models. Cycle Time Requires Doing Work First Clayton: The one thing that I could say that could be a potential downside to that is it requires you actually do the work. If you’re trying to say, “Here’s a project that we might want to tackle, and we’re not sure how feasible it is. Developers, could you give me some ballpark so that I know am I looking at something that might be 6 weeks or something that’s 60 weeks. I don’t have to be precise on it, but I need a rough ballpark to know if it’s something I want to go, grab funding for.” How do you do that in the cycle time model? Jim: There’s two things, if you’re starting and you don’t have a cycle time, then you do a traditional estimate. If you’re starting and you do have cycle time, then you use your cycle time. You can only start from where you are and the fact that you don’t have data yet doesn’t mean that you can’t collect that data. I’m particularly well known for hating metrics. I don’t like to use that many of them. Basically the only numeric metric that I use are the two that we’re talking about, and the reason for that is that most metrics are lagging indicators. Right now, the question that you’re asking me is, “If I get this metric, that’s all well and good, but is it best going to be a real‑time indicator and more likely is going to be a lagging indicator.” If you’re starting a big project, everybody is going to need to get around and they’re going to need to figure out what the level of effort assumed is for that project. After you have this information and perhaps before if you could run some spikes, you can start to figure out what that cycle time is and then you can say the things like, “I believe that the project you’re giving me or we agree that the project that you’re giving me is made up of these 50 initial user stories.” You’re now buying an option from this team on 50 user stories. We agree to deliver 40 or 50 user stories. Between now and the completion of the project, which we anticipate given our current cycle time is going to be this date. We will do 50 user stories for you, and frankly, we don’t care what they are. As we move through the project, we’re really not worried about what the specific user stories that are coming up are because we as software development professionals know that over the course of the project 80 percent of the features change anyway. They’re basically buying a block of work as opposed to a product and assuming that their product will be able to be done within that block of work. Clayton: I think we’ve definitely stepped into a very interesting conversation, but unfortunately, we’ve run out of time here. If people listening wanted to find out more about you or if there’s any books you think they should read or anything like that they should check out, where would they do that and what kind of suggestions would you have for them? Jim: OK. The self‑serving parts are my name is Jim Benson, and I’m at ourfounder on Twitter, and I’m ourfounder on just about everything else that has ever been put on the Web. We currently have three books out at Modus Press, one is “ScrumBan” by Corey Ladas and other is “Personal Kanban” by me and Tonianne DeMaria Barry and the third, which is specifically about these cognitive biases is called “Why Plans Fail,” and that’s just an eBook, it’s a little $2.99 eBook. The Personal Kanban website, which is personalkanban.com has tons of blog posts and free information. My personal blog is ourfounder.com, and my company is Modus Cooperandi, which I’m not going to spell for you, but that’s what it’s called. Clayton: We’ll use Google Suggest, how about that? Jim: Yes. Clayton: We also like to invite the listeners to check out the Agile weekly Facebook page where you can continue the conversations for these different podcasts and one that we have. We wanted to say thanks for joining us today, Jim. We really appreciate your conversation. Jim: Thank you guys. This is fun.