Roy vandeWater: Hello, and welcome to the Agile weekly Podcast. My name is Roy vandeWater. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Drew LeSueur: I’m Drew LeSueur. Traditional Scrum Roles Roy: Today, we’ll be talking about the traditional Scrum roles, and how you know that you have gone out of the bounds of them. Clayton, you brought this topic to our attention. What drove you to do that? Product Owner Boundaries On Technical Practices Clayton: Just to clarify the three rules we are talking about are the Scrum Master, the Product Owner, and the Developers, or the Development team. I can’t remember what the new Scrum guide calls them. Those people comprise the overall Scrum team. I was wondering, if you go by the “book” Scrum, there’s a lot of things like, that the Scrum Master should do, but one thing I have noticed, no‑one really talks a whole lot about things they shouldn’t do. It’s the same thing with the Product Owner. I had a Product Owner ask me the other day, what they could do to help the team with the broken build. Doesn’t that seem odd? From the standpoint of technical excellence or something maybe you could say that the team is having some eXtreme Programming (XP) practice where they’re using continuous integration and their build is broken. In a perfect world, there would care about that and then want to get it fixed, but for some reason the build is broken. It was causing a problem and was impacting the Product Owner in some way, so they wanted to know what they should do to change that. Roy: Is the question then is the state of build underneath the Product Owner’s authority? Can the Product Owner dictate that the build must pass and make that a requirement? Clayton: Yeah, that was the thing of like, “Hey, how much say should the Product Owner have in how the team organizes its technical practices?” In this case, the fact that the build was broken was causing an issue with being able to deploy something. That’s why the Product Owner was concerned about it. Until the build was fixed, you couldn’t deploy and if you couldn’t deploy, then the Product Owner couldn’t show progress or whatever the case was. Roy: That hails pretty fair for that. Then it would fall underneath their responsibility all of sudden, because it’s seems to be like the Product Owner’s to drive value and if something like the build coincidentally happened, not coincidentally, but like blocks the delivery of value. That seems like a very big problem that the Product Owner should absolutely be able to talk about. Clayton: Yeah, other than maybe just talking about it though, is there anything the Product Owner can really to do? Like they’re not going to get it in and like fix the code? Roy: That’s, that’s true. Like I think that would definitely be over. The Product Owner would definitely be over‑stepping his or her bounds if they started doing something like that. Clayton: Beyond just going and telling the team, the strategy of the time was like, “Hey, the build is broken so I can’t deploy this thing that I needed to deploy so is it OK”? The question was really asking me, is it OK if I go basically yell at them, or like tell them that they need to get this fixed as soon as possible. You know. Roy: I would say that’s totally OK. Drew: Yeah, I think so too. Like, hey, I need to be able to deploy this whenever I want. You know, it should be able to be deployed at anytime. So the build’s got to be passing. Roy: That probably should already be part of their negotiated definition of done. Like a future should be deploy‑able. And if their futures aren’t deploy‑able then that means that pretty much none of the sprint work can be done because they can’t deliver any value. Clayton: Do you think that your opinion would change if you took out of the equation the fact that the deployment and the builds were linked? The Product Owners were just mad because the builds were broken. You know. Like this is the middle of the sprint, basically. Middle of the sprint, the builds are broken, should the Product Owner really care about that? Or is that like, that’s the technical realm of the team? And, the, you know, they have their problems so they can go fix it. Roy: It all of the sudden changes. Think that’s a huge difference. All of the sudden the development team should be passionate about it and should really care that the build doesn’t work. But then all of the sudden it’s no longer blocking the Product Owner directly. If the development team insists on, you know, um, deploying code that isn’t tested or with a failing build. If that’s not part of the negotiated definition of done then I would say that it is not really the Product Owner’s authority to dictate that. The Product Owner may want to renegotiate their definition of done. But unless that’s the case, they can’t. I don’t really think that it’s their place to say anything. Drew: Also, like this issue, maybe why, the question is maybe why is it coming up? Like, are they building their master branch as, like, a check to see if it works? Or should there be another system in place to where they can build it off their computer somewhere else and then push it to master if it all passes? Like sometimes I say that because sometimes we’ll let our build system run our build just because we don’t want to run it all locally. And we can just kick it off and not think about it until it comes back. And it’s just an extra check so if it fails, no big deal we’ll get it to pass. Roy: One big distinction that not everybody uses is that when we’re all talking about the build, we include all of the tests passing in the build. Is that what you are talking about as well Clayton? Clayton: In this case it is a situation where if you take the entire test suite, there’s a series of builds all broken out. So in order to say that all the tests are passing and all the code’s compiling together and to say, “This doesn’t build,” it all have to be green. If two of them are red, then that’s where the situation comes up. If these two things are red, that means we can’t progress because in order to deploy, you have to go through steps 1 through 12, and we can’t get through steps six and seven, so that means you can’t deploy. Roy: In a build environment in which you have to compile something, that’s a little bit different because…A lot of my experience has been with Rails apps or Python app or something like that where it’s scripted and there’s no compilation and linking and all of that type of stuff. But as soon as you have to start doing that, I’d almost say that it’s a good idea to decouple running your tests and building everything and to separate those two ideas. But as a practice, if you’re on a team, I would say ideally a team shouldn’t allow themselves to deploy something that isn’t passing. They should have the self‑respect to say, “We care about quality, and we built these tests for a reason, so we’re not going to deploy this until we know that everything is passing.” If that means that maybe they’re old tests and we got to delete them or whatever, everything has to be green before it goes live. That’s a good quality for a team to have. Scurm Master Boundaries Clayton: To try to jump to another Scrum role, what are some examples or some different indicators that a Scrum Master might be stepping out of their role, like doing too much? Roy: When a Scrum Master starts dictating tasks to the team or assigning stories or tasks to individual people rather than the team. How about you, Drew? Drew: I don’t know. I haven’t been on a team where there’s an official Scrum Master set to me, so it’s harder for me to answer that question. It’s rare that I’ve been on a team where there was a Scrum Master. Clayton: The Scrum Master sometimes acts as a liaison ‑‑ or to some degree ‑‑ between the Product Owner and the development team or outside stakeholders or third party people or whatever. Is there a chance that maybe the Scrum Master would get too involved with one side of that equation? They’re supposed to be the impartial middleman to some degree. So maybe they got too involved in a technical detail, or they got too involved in the product stuff. Roy: I can see them talking to the stakeholders which is part of their roles to protect the development team from interruptions from the stakeholders. I could see them talking to the stakeholders and perhaps promising features or something that the team has not been able to deliver or things that the Product Owner doesn’t consider a priority. I would definitely consider that overstepping their bounds. It’s like a Scrum Master has the authority to say no, but they don’t have the authority to say yes if people are trying to interrupt. Scrum Roles Narrowly Defined Has Problems Clayton: One criticism on Scrum is that the roles are very narrowly defined and is not a good practice. Some people even go as far as, it’s immoral to try and box people into a certain role and say, “Well, you’re only allowed to do this, and you’re only allowed to do that.” How do you guys feel about that? Drew: I can see that. One thing that I sometimes see is people treating the Product Owner as like, “We won’t do anything unless the Product Owner says it. We’re not going to come up with any good ideas on our own.” That’s troublesome. The whole team as a team can come up with good ideas and not just implementation ideas on how to implement what the Product Owners says but even good ideas for the product. I don’t think it’s outside of the developer’s realm to pursue good ideas as part of the team. Roy: It’s definitely within their realm to come up with good ideas and suggest them, but I absolutely think it’s outside their realm to pursue them without checking with the Product Owner because the Product Owner ultimately figures out where the priorities lie. We’ve all been on teams where somebody wanted to work on some feature X that probably wasn’t very important, but they went ahead and insert it in the backlog, made it a top priority, and started working on it. We’ve all been part of bad Scrum implementations where that’s happened, and that’s a huge smell. There’s a good reason why there’s a single person who determines all of the priorities and if you are going to pursue something that it should go through the Product Owner first. With that said, I totally agree that the developer should be free to come up with their own ideas and contribute them. Not just free, but encouraged to. Developer Boundaries Clayton: What about developers that are stuck in their bounds? What’s a good example of that? Roy: You guys hinder that with the backlog stuff. One thing you see a lot is when the expectation maybe of the team or the visibility of the team’s progress is low or nonexistent. I actually know a lot of developers that will take on some pet peeves like some technical desk is a perfect example. Like something in system that they don’t like and they want to make it better. Maybe they’ll get a story done or some task done early or something. Or they’ll come to the conclusion of like, “Oh, I’m blocked on this task and I can’t work on it until I hear from X, Y, Z person.” So in the meantime, rather than go and like help someone else with something else in the sprint or further along the progress of the sprint, they go off and go and do some little pet peeve thing. “I’m going to go rewrite this part of the test suite,” or, “I’m going to go experiment with replacing this library that we have now that we know works with this new one that personally is better.” That’s one example of it, the team getting outside of their bounds and just doing whatever they want without…as not part of the overall Scrum team, like not have the same goal. Clayton: What about refusing to implement a feature or something like that? I felt that a few times, where I thought a feature was just the dumbest idea and I felt like we’ve got to come up with a better solution. Is it within the developer’s authority to say, “No, I’m not going to do that, because that’s stupid.”? Roy: That’s like a two‑way street, because there are some times where developers will negotiate ‑‑ I don’t want to say worse implementation, but they’ll negotiate a less than ideal and maybe a more simplistic solution. The rationality that they would use is like, “Hey, don’t worry about it, Product Owner, because we’ll just do this and then, we’ll ship it and we’ll get feedback. So, it’s OK.” It’s like the same thing is probably true the other way. Maybe you think it’s a really dumb feature, but the Product Owner could say, “Why don’t you guys just do it and we’ll ship it and if it’s really that dumb, then we’ll find out about it, so you can fix it.” Drew: With the first one that you were talking about with the like, “Hey, let’s do it the simple way and get feedback.” The way you said it, put a negative connotation on it, where I’ve always viewed that as a positive thing. Roy: Yeah, I’m saying though like a Product Owner, I think, all the times, the Product Owner unless they are especially savvy or nuance, they hear that as, “We don’t really want to do the big hard thing, but if you let us do the easier thing and then, get feedback.” Some Product Owners will just relent to that, “Oh OK, fine. I can buy that.” Drew: It goes back to… Roy: I’ve totally worked on teams before where the Product Owner thought that I was unspecific with confronting him about it, too, and said, “OK, you’re just trying to avoid the hard work.” Where I felt and I don’t know if I was trying to avoid hard work, so consciously, but I felt like, “Hey, let’s spend a very small fraction of total time and implement this feature to implement the core value you’re trying to get and then, we can build off of that and see if we need all the bells and whistles on top of it.” It was perceived as like I was being lazy and trying to avoid the difficult work. Drew: That’s totally within the developer’s realm to negotiate, “Hey, this is an awesome idea. How about by this sprint, we only get this much done because that’s all I can get done, or whatever, and let’s work on this part of it first because that’s the most valuable part.” Roy: Maybe that’s a good way to frame it as developers like, “Hey, why don’t we do it this easy way first? Then, we’ll get feedback and that means we can also pull in these additional stories.” Now, it’s not like, “I want to do this, so I get less work.” It’s like, “If we do this, look how much more free time that opens up for you to get more stuff done that you want, right?” Then everybody benefits because you do the easy implementation, get feedback earlier and you potentially could deliver more value in that time period. Clayton: More often I don’t really think teams like teams try and jump too far into the other roles. I don’t think there’s anybody on the team that’s trying to be the Scrum Master or trying to make a product decision, not necessarily. [crosstalk] Roy: …if I don’t do enough of that. Drew: We sometimes find that internally like where we take turns being the desk Scrum Master during a retrospective or something. It’s good practice for us to do that. Roy: Yeah, I mean… Drew: Good practice as in it is we’re getting good practice out of it, but not that it is a good practice, you what I mean? Roy: Yeah, I know, and there’s probably a lot of Scrum teams out there where facilitation is such a difficult thing and running a retrospective is so much harder than people think. The Scrum Master probably isn’t even very good at it. Let alone, there’s like some random developer on team. They don’t have all the skills required to effectively do that. Clayton: Makes sense. I thank you for joining us. If you’d like to continue the conversation you can find us at facebook.com/agileweekly. Good‑bye. Drew: Thanks. Roy: Thanks.

Drew LeSueur, Roy van de Water, and Adrian Howard discuss: Lean UX Developers and UX designers working closely together Working Software vs Valuable Software Finding and doing what the customer wants Role of the Product Owner The post Episode #86 – Lean UX with Adrian Howard appeared first on Integrum.

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly podcast. I’m Drew LeSueur. Roy vandeWater: I’m Roy van de Water. Drew: Today, we have Raoul Encinas with us. How’s it going Raoul? Raoul Encinas: Hey, Drew. How you doing? I appreciate the invite. Agile Outside Software Drew: No problem. Today, we wanted to talk with Raoul about Agile Outside of Software. It’s something that we are fans of as well. Raoul, can you talk to us a little bit about that? Raoul: Sure. I think that’s an appropriate qualifier. Also, if you wanted to use the term “accidental Agile,” that would also be a fair way of describing it. The environment was a non‑profit organization where we had about 50 to 60 team members. Very few of whom had any visibility into IT processes, certainly none but the software development. It was an exciting way to use the concepts, and the philosophies, and the principles to a virtual work group. Just a little brief on that organization. It’s called Southwest Job Network, and what we do here in the Phoenix Valley is provide professionals who are in career transition with career management skills so, networking, interviewing, how to do your resume, LinkedIn, and so forth. Just a little bit of organizationally the cross section of people in terms of their skills and capabilities was all across the spectrum from HR, to finance, accounting, marketing, and of course there were some IT people there as well. Deliver Something. Early And Often. Roy: One of the important aspects of Agile’s to deliver something that works early, and get feedback on it so you can adjust course. On something where you’re delivering content, or delivering a service, or something like that, how do you deliver part of it? How do you deliver one piece of value, or break it up into small pieces of value? Raoul: That was certainly one of our challenges, and if you think of the product that we’re trying to overhaul. You could think of it as software, because the product itself is curriculum. It’s an educational system where we use this curriculum in modules to teach people how to manage their careers better. We had an existing 1.0 version of that curriculum that was when we passed a need for overhaul. During the course of applying Agile concepts to get our curriculum up to 2.0 we used two‑week sprints. We had existing product. The perfect scenario was that our customers for this product were actually the ones to helping to overhaul it. There was close customer collaboration as you could ever hope for because they literally helped re‑engineer it as we had new deliverables, new content, new terms, new output. Accidental Agile Drew: Awesome. I liked the phrase that you used “accidental Agile.” The team that you were working with on this project and service ‑‑ did they know that they were doing Agile? How did that come about to work in these iterations? Did you encourage that or how did it happen? Raoul: I think we all appreciate the elegant design but sometimes you stump on elegance and just to back up a little bit around the situation or the context. What we had was a workforce of volunteers and you have to put yourself in that mindset of these are not employees. These are not virtual around the world. These are all people here physically who want to contribute. The challenge with volunteers is that if you’ve ever had to manage a project that lasted more than a couple weeks it’s a very fluid workforce. Imagine taking in a large piece of software ‑‑ in this case our curriculum ‑‑ and having to re‑engineer that with a transient workforce. We did compartmentalize and break down all of the pieces into as small of a chunk as possible and those are all concepts that you don’t need to understand software development or [inaudible 04:30] management to know that you break things down as digestible as possible. We had virtual team segmented to different parts of the curriculum but what we were struggling with was continuity from team to team and having some type of reasonable pace of development and progress. Where the teams would be motivated by what other teams were doing. I can’t take any credit for bringing the Agile concepts. I was already doing some things that were around collaboration and self‑directed work teams and those were the things that I brought to bear. I really have to credit Jim Brodie who is our local [inaudible 05:08] executive. He was with Hypercom for a while. An expert in Lean and Six Sigma and all the different approaches. He walked 50 of us through the “Idiot’s Guide to Agile,” and Scrum, and sprints, and so forth. It was a perfect match between what we already had in terms of scoping out the work and breaking out virtual teams and the need to have quick increments and quick cycles on the actual deliverable. Once he brought that knowledge of how to execute the work, how to organize people, coupled with what we already had, it just was fantastic. In the process of six weeks we had 50 people who basically overhauled an entire adult learning curriculum. If you have familiarity with the complexity of that you would not believe that that was possible in a period of six weeks. Again, with volunteer labor, not subject matter experts. Virtual Teams Roy: You had mentioned that you guys were working in…I think you called them “virtual teams”? Was that an actual team? Were those virtual teams actual teams with people in them? Raoul: They’re virtual in the sense that somebody could be a member of more than one team and they didn’t necessarily meet and collaborate in person. Roy: You had mentioned that, because of the nature of volunteer work, that was very transient. We’ve noticed before that it sometimes takes teams a while to really form, and get through their problems, and start to mesh. How does that work if people are constantly leaving and joining the team? Raoul: It was an incredible leap of faith. One of the things, the unique nature of these volunteers are ‑‑ these are professionals. They have a lot of pride in the work that they’ve done, but they’re currently out of work. You’re talking about, these are not recent college graduates, these are people who have experienced being in the workforce. They’re used to working on teams. They’re used to working towards a common challenge. Being out of work and displaced they had a very high motivation to do something, and to collaborate. We were able to tap into that desire for collaboration and the desire to actually boost your own ego and pride by just getting some work done. There was a very natural desire to attack a common problem. One of the things we did, I will say, all modesty aside, from a governance standpoint and from a centralized standpoint, is we did a really good job of defining the boundaries and the framework, or the sandbox, in which these professionals can play. We trusted them as adults, as professionals, to say, “None of us are going to make any money off of this. It’s for the greater good.” People were able to check their egos at the door and really focus on a good design and a good work product. It may have been a fluke or a one‑off but it really was a phenomenal achievement by this team of 50 people. Volunteers Given Freedom Drew: You gave the members of the team a little freedom to do what they want with their project within the certain greater bounds that you put. Raoul: Yeah, and I’ll give you an example. Our originally curriculum had been split into maybe eight modules, or chapters. We started with eight teams, just because you have to start somewhere. What happened is ‑‑ I wouldn’t say after the first two‑week sprint ‑‑ but maybe after the second one, it was pretty clear that some of those breaks, for example between chapters six and seven, were just artificial. There was just no logic or reason for there to be a break there. As we were getting more product back and the teams were collaborating, what happened is teams six and seven naturally wanted to collaborate. They were in the midst, in the details, in the muck, and they realized, “Hey, this is an artificial break. Just because the legacy content was split this way doesn’t mean that this is what we have to continue to do.” It seems commonsense now, in retrospect but, as you know, when you’re in the middle of team meeting and work product with people you never worked before it’s not that easy, necessarily to call out the obvious. They called out the obvious. They collaborated with each other. They broke away that artificial break point and merged those two modules for some better seamlessness. Those kinds of things. There were all kinds of very interesting breakthroughs, a series of small to medium breakthroughs that just made the overall product phenomenal. Mostly our job was to get out of the way of the teams. Working Directly With Customers Drew: That’s awesome. I like what you said earlier about working directly with the customers, the people who are actually going to be using the service, as you developed it. Can you talk a little bit more on that? Interviewee: Sure. Each team had at least three and as many as maybe seven or eight people. One of the framework elements that I pushed for, and we were fortunate enough to have enough of, were we had enough professionals with a background in training, or HR, instructional design, or adult learning, or something. [laughs] It was a little bit of a stretch sometimes but we were able to have each team populated with at least one, for lack of a better term “process person.” And the process in this case was adult learning, or education. We were able to have enough of a cross‑section of maybe, an accounting and a salesperson, or an IT and a marketing person, on other teams, where people bringing this cross‑domain knowledge was quite powerful, quite impactful. The process person provided that framework and kept reminding people to stick to learning objectives, which is an element of adult learning, and making sure that certain things were phrased with very precise verbs. There’s some rules around design in that space. But, within that sandbox, these [laughs] marketing person and IT person collaborating was pretty powerful, in terms of their ability to just share domain knowledge and even cross‑train on some components. Those parts were pretty exciting, again, to see people who had never really worked together before to figure out a way to make it work. Drew: Did you guys, just curious to any sort of retrospectives after your iterations or anything like that? I know one thing that we value as a team is after we’re done with our sprint, which is usually a week long, we’ll get together as a team and talk about what went well and what didn’t go so well as kind of a formal small ceremony. Did you guys do anything like that? Raoul: Certainly not as formal as we could have. We were better around celebrating successes overall, amongst the larger group. There was a core group of maybe just six or seven of us who were more of the governance point. We did that among that group, a little bit more around lessons learned, and what do we need to do, and how are the teams progressing, as different teams would go at different speeds. We did that, I know for certain, around that core group. Given to do it over again, I think it would have been terrific to be able to spread that level of maturity to the further teams, but I think that would have been overreaching a little bit. Especially, since it was in essence a one‑time gig. You Have To Trust It Will Work Drew: It sounded like it was a fun project. What would you say was your biggest take‑away? If you could take away one thing from the experience, what would you say that would be? Raoul: Even thinking about it now, and it’s been a bit of a time since we’ve done this, to a very large extent, and it sounds silly, but you have to trust that it’s going to work. It’s incredibly risky to stand in front of a group of 50 or 60 professionals, very seasoned people with 10 to 20 years of business experience across all these domains, and convey with confidence that this structure and this way of working, which may be very foreign to [laughs] many of you. This style of project management, and this approach to collaboration, to stand up there and have the confidence that it’s going to work. I think we were able to convey that energy and that confidence, and we showed that we trusted each of these work teams through our actions. We didn’t override the decisions that they made. We weren’t looking over their shoulders. To a very large extent, this was a peer‑driven group, and having that trust and taking that leap of faith, basically taking your intellectual property, sharing it with this public group and trusting that it’s going to be protected, and taken care of, and curated, and all these important things, that was an inspiring, emotional, and a rewarding, the most rewarding element, I think, of the entire effort. Drew: Awesome, great take‑away. Raoul, thanks a lot for having us on the podcast, or thanks for joining us on the podcast. If you have anything you’d like to promote, or share with the audience? Raoul: Just since we’re on the non‑profit theme, to the extent that people want to contribute their professional skills in a voluntary capacity, a terrific organization local here in the valley is called Hands‑On Phoenix, and you can use your favorite search engine to find them. Hands‑On Phoenix is a non‑profit organization that brings together volunteers, functions as a broker for other non‑profits, and puts those teams of people to work in a variety of different capacities for the greater good of the community. If you’re looking for a way to contribute and give back, and want to use your professional skills, that’s a great place to start. Certainly, you frequently get back more than what you give in that regard. Thanks for having me guys. I appreciate it. Drew: Thanks a lot, Raoul. Raoul: Cheers.

Derek Neighbors: Hello, and welcome to an episode of the Agile Weekly podcast. I’m Derek Neighbors. Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich. Diverse Group Of Participants Derek: This week we’ve got Clayton out in sunny Philadelphia, Pennsylvania at the Culture Conference. Clayton, I wasn’t able to make it and I’m really jealous, so tell me about all the awesome fun you had today at the Culture Conference. Clayton: It was a fun event today. It’s a mixed format. The first part of it was some speakers, like normal tracks, like a regular conference. After lunch when we came back we had an open space, which was nice. We were able to have a few sessions there as well. That was the general format. The first few speakers in there…basically, a whole lot of people with different backgrounds. Some of the interesting thing is that now that the [inaudible 01:08] is getting cast a little wider beyond just the Agile, more of the Pronto stuff and talking about the cultures and organizational cultures and changing culture and all that stuff. There is some people there who are not necessarily a part of the Agile community. They don’t have a software background or IT background. It’s pretty interesting to see their perspectives and take on some things. Best Keynote Speaker Derek: Which one of the keynote speakers, for lack a better term or common keynotes, which of the scheduled speakers was your favorite speaker and what was their topic? Clayton: The favorite one I have would probably be Jim McCarthy. The performance he gave, I guess I’d say it’s more about a performance than a talk. Certainly, it wasn’t traditional talk. There is an interesting book I’ve got that describes ten different…is for doing some public speaking. It’s called “Speak Like Churchill, Stand Like Lincoln,” something to that effect. It goes over some certain techniques that you would do for addressing a crowd. I notice right off the bat, there were a few that things that Jim did, so I thought that was not only to share some experience on his part, but he jumps to his topic which was basically, “We have this thing at the tip of our fingertips, and we’re controlling the future, and we can make something of this. It’s something that’s really special that we have. If we chose to squander it, then that would be a terrible mistake.” From a motivational or call‑to‑action perspective, it was pretty inspiring. Also the fact that there were ‑‑ it wasn’t half I would say ‑‑ but maybe 20 percent of the people in the room looked like they had no idea what was going on or they totally disagreed. I felt like that was meaningful that some people were fully taken aback and didn’t really understand what was happening, that it was a provocative talk, I guess. Derek: Yeah, just knowing Jim, one of the things is difficult is his call‑to‑action is so powerful and asks you to do much more than where you are or even when you are already on the edge. Then I can only imagine if you’re not already close to the edge, it seems so monumentally difficult or far‑stretching that it seems almost absurd. That’s certainly one of things I love about the way he speaks is, is he is looking a lot further than a year down the road. Clayton: Especially since when it comes down to…one of the things he said was, you can be the person he wants to be the giant or you can have the mentality of you’re being OK with midgetry. Derek: [laughs] Good Is Getting What You Want Clayton: It is really powerful thing and it sounds like you really have to go all crazy, but then when he talks about, “What’s good? Good’s getting what you want.” Then it’s like, “That seems like a simple concept.” There’s some people that seemed a little confused. It sounds like I should be really doing all these crazy things but at the core of it, it sounds pretty simple, so I’m not sure what to make of it. The Hacker Revolution Derek: Right. I saw on the Twitter streams that Eric Raymond was there as well. I know that a lot of what Jim and Dan have talked about, or I have talked about with them, is that they really see this as being culture hacking. ESR is seen along with RMS, Richard Stallman is one of the original hacker ethos, so to speak on the hacker side ‑‑ may be not on the culture side, but on the hacker side. I was wondering, what were some of the things that maybe resonated or you did or didn’t agree with, with what ESR had to say today? Clayton: The thing I thought that was interesting was, as far as he’s concerned, I certainly wasn’t involved in that community when he was. I was only tangentially involved even at all in that I enjoyed reading “2600 Magazine,” and I listen to “2600 Radio,” and I went to a couple meet‑ups. I feel like that I had in that, some understanding of that community from a hacker mentality. There was a guy in the audience who asked a question about the anonymous group, LulzSec, saying, “What do you think about them”? He had to make the distinction that, that’s not the same group. That’s a different culture, that’s a different group of people. That gets me thinking that while the word “culture hacking,” or the phrase, “cultural hacking,” might be meaningful to people in this community, or meaningful to people that have some history in that community, for anyone outside that doesn’t understand that history, that’s a very confusing term, because it sounds more like, “we’re going to come in and break your stuff.” That’s maybe the conventional understanding of the word “hacker.” “You’re going to come in and disrupt my culture and break it,” which is true, but that might be a misleading phrase. The Hacker Ethos Derek: Absolutely. When people think of hacking, they think of hack and slash, tearing things apart, which is very much part of the hacker ethos. But, I don’t think a whole lot of people think about tearing things apart so that they can make them better or circumvent something bad to make it better. People just think of the disassembly part, the negative side. Clayton: Right. He was quick to point out that the hacker ethos is about building things, useful things and making something, which is an important distinction, but probably lost on most people. Derek: Absolutely. Did you attend any of the open space sessions? And, maybe tell me a little bit about like, what did you see? Did you see any themes about topics, or the topics that you did attend, what were things that stood out for you in those? Software For Your Head Clayton: There was a lot of talk of the Core Protocols and Software For Your Head and that had some degree to do with the fact that Jim and Michele McCarthy were actually in attendance at the conference, although they didn’t participate in those topics. But, there was a lot of talk about that. I thought that was interesting. There were a number of people who had either never heard of the core protocols or had only heard of them at that conference or the “week before” kind of thing. There were a few people who were familiar with some of the ideas, but I was surprised that there were a lot of people who had adopted one or two protocols, specifically “check‑in,” and that was pretty much all they knew and they really hadn’t looked more into it and they were surprised at how helpful that one protocol could be. That was a popular one. Other than that, there were a lot of people who were talking about culture as a competitive advantage or culture as some new thing and, now that we’re all doing creative work and we’re not working in factories, culture is the most important thing now. The one thing that was missing was…although there was one session that I did attend about, “OK, if we acknowledge that culture is super important, how do we get there? How do we transform organizations”? That might have been the part that was missing was there was a lot of acknowledgment that culture is very important, but, not a whole lot of talk about how do I get the right culture and how do I know if I’m ahead or behind the curve on culture and those kinds of things. People Want The Formula Derek: Yes. That’s interesting that there’s not a whole lot…There’s an awareness that culture may be important and that some of the issues are maybe deeper than what process can help. But, there’s not a whole lot of talk or conversation, even in the Agile community that really addresses, how do you identify what kind of culture you have, where do you see your deficiencies, how do you move towards building stronger culture, what are the right types of cultures for what you’re doing. People want to follow the formula. Building culture, you just can’t do that. Steam has this handbook, and it’s a really great thing, and we need to go do that. Or we just need to use that. Or, Tony Hsieh’s got this really great book “Delivering Happiness,” and we need to just do that. The problem is that unless you’re Tony Hsieh and in Tony Hsieh’s environment doing the business that Zappos is in, that culture might not be the best fit for you. It’ll be interesting to see if there’s any continued talk or discussion that starts to elevate about the variations of culture and what’s important and how do you move the bar forward. Clayton: Right. Everyone is very quick to name the handful of companies that they have heard of that have good cultures. Every single discussion that I heard about Morningstar, and W.L.Gore, and Zappos, and whatever other handful of companies there are that have what “good culture” is, everyone’s quick to acknowledge those and throw those out there. But in terms of what that actually is or if that’s the right thing for now or the right thing just for that industry or how that’s going to change or how do you even get there, I think that’s probably still missing, like you mentioned. Most Interesting Person Derek: Who’s the most interesting person you met today? Clayton: The most interesting person ‑‑ It was ‑‑ I believe her last name is Gray. I think it was Vickie Gray. She’s someone that I’ve seen in the Facebook Booted group for discussing the Core Protocols. I’d seen her pop up a lot doing check‑in and things like that. I had a chance to talk to her a little bit about some more technical things about the Core Protocols but got to hear her story about how she got into actually booting people and how she first came in to understand the Core Protocols. It was nice to be able to talk to someone who had also been using them, and obviously more than I have, and talk about the nuance of a few different things. I thought that was very interesting and especially useful for me personally at least. Derek: Sounds like a good future guest. Clayton: Yeah, for sure. Key Takeaways Derek: I’m trying to think here, how are you going to apply what you learned maybe today when you get back into the real world? What are some takeaways, maybe some “aha” moments or insights, that you had? Clayton: One of the thoughts I had, I guess the prevailing thing, one of the things I was suspicious about before I came to the conference, and one of the things that was really reaffirmed, was the fact that there are more and more people acknowledging that culture is important, but no one seems to understand how to get there or what it would take. Just having that insight, for me at least, taking that back to my real work and being able to say, “What can I do to start uncovering the pieces to that puzzle, what are some of the patterns or some observations that I can make in my daily coaching environment to understand what influences certain parts of the organization or certain people have on the culture, which parts of the culture are very ingrained or maybe hard to change”? It helped further answer that question of, “If you are going to make some culture change, what’s really required”? Derek: It’s funny. I’m at a client doing some of this work now. They understand that they’ve got some culture difficulties, and they’re working through them, but what I’m really finding is that, to me, there’s no such thing as culture in the sense of there is no magic animal of culture and you change culture. Culture is just the aggregate of the behavior of the people in a system, and so really the only way to change culture is for the people in the system to change. Because it’s an aggregate, you have to have a majority of the people in the organization actually change, in order to see that manifest as a change in culture. It’s difficult because you need a small number of people to act as catalysts, or instigators, or models, or disruptors, to basically hack that culture and to get it to start to understand it needs to change, but it really takes the people to change. What I’m finding now is that there’s this awareness, that there’s a problem, and the problem’s more of a system problem, but what I find people doing is defaulting to their normal pattern of behavior. They acknowledge the problem, they understand there’s this big problem, but then they understand that they can’t fix it themselves and so then they very quickly start to default back into a pattern of “Well, I’m just going to do what I’ve always done.” I don’t think we’ve got that hack done yet. I don’t know what that hack is to basically get it to where we can accelerate that process for people. Changing Culture Means Changing People Clayton: Your comment about how it’s the culture of an organization is the sum of all the people and various attributes of those people. It’s really easy to talk about how great culture is and it’s a really great competitive advantage, but when it gets down to if you want to change the culture, and that means changing the people, then you feel like all the people are going to find that they’re back at square one. They’re trying to circumvent the hard work of having to change people, which is difficult, and it’s not that simple. Derek: Yeah, if you start to say, “Hey, our culture’s X,” and maybe you’ve got a bunch of people on the bus or onboard at your company that are strongly opposed to X, the only way you’re going to get your culture to actually change to X is to either convince those people to get onboard with that or to get those people off‑board. Clayton: For sure. Derek: To me, when you start to see culture shift when you start to see people get uncomfortable that are fighting against the culture and realizing that they might not fit where they’re at. That’s usually when people default back. “Well, so and so’s a really great person. We could never consider losing him.” We’ve got to placate and default back to whatever behavior we currently have is just so that they’re not upset. Then there’s all this frustration, “Well, we did that but we can’t move forward with culture.” Clayton: Right, exactly. Yeah. Derek: All right, maybe we’ll do another one of these later this week or next week and get a recap. I know you and Jade are hopping on a bus I hear, and heading to Boston, so maybe we’ll get the second half of this to hear how the bus trip in Boston went. Clayton: Yeah, for sure. That would be a good idea. Derek: All right. Thanks for joining us. Clayton: Yep, thank you.

Derek Neighbors: Hello and welcome to another episode of Agile Weekly Podcast. I’m Derek Neighbors. Today I’ve got a guest, original signatory of the Agile Manifesto James Grenning with us. How is it going James? James Grenning: Good Derek! How are you? History Of Snowbird Meeting Derek: Good! You know one of the things that always intrigues me when I get the opportunity to talk with someone who’s kind of been with Agile since the beginning is how maybe you see the Agile community, Agile practices. What do they look like in back in early 2000, 2001 years, a decade later where they are today? Where there were similarities? Where there were differences? Where did things maybe worked out of how you guys intended? Where maybe there some frustrations were you’re pulling your hair out going, that it has been ten years and we still haven’t get this part of it right? James: Yeah, OK. That’s an interesting thing to talk about. Ten years ago, or actually twelve or thirteen years ago now, when we started to get involved with extreme programming, if the time of the Agile manifesto, I was part of the extreme programming contingent community there with Bob Martin and Cat back in Ron Jeffrey’s. I don’t mind at all saying that when I went to it it was like, “It’s in Snowbird? Of course I’m going to go.” That should be a good time. All these good people and then some skiing to boot. At the time we were just trying to see what we had in common. It was an interesting thing, we didn’t have any expectations that anyone would care. Bob Martin, and I believe Alistair, got the whole thing started. Let’s get together and talk about what we have in common. That’s what the Agile manifesto came from. One of the things that was surprising to me at the time, coming through the 90s, a lot of people might not recognize this, but right or wrong, the way we viewed process released kind of the camp that I had been involved in in the 80s and 90s was if we could come up with a better process then the people wouldn’t matter so much. I think that that was, that permeated a lot in the 90s, and what was really different about the people that I was with at the Agile manifesto meeting was that really they were talking first and foremost about people, and that was kind of surprising because of the Watts Humphreys message sounded like, and the way industry interpreted was if you had a better process you could just plug any person into it. Plug a replaceable programming unit and get the same results. That is one very different thing I saw about Agile. You were wondering how it might relate to today, right? Derek: Yes, absolutely. The Technical Practices Didn’t Get Widely Adopted James: I think the engineering practices and such behind extreme programming were what were intriguing to me and to Bob Martin, at Object Mentor. We were really seeing that those are kind of revolutionary. It is really going to help solve a lot of interesting problems. As naive coaches in the early ‘2000s, we thought people would hear them and be enthusiastic about them and what I am still surprised at is that how much resistance some of these what we view as common sense approaches to developing software seem to be still so radical to people. I think it is pretty interesting and cool that Scrum has taken off so big but it is fairly empty. In some of the engineering practices they have done a lot to spread the idea of iterating but they haven’t spread the idea so much of getting the quality up and really relying on high quality to go fast. I know that is Schwaber’s and Sutherland’s intention in Scrum but it is not really the way the industry is going or has gone. That is disappointing. Although it makes lots of opportunities for guy when companies finally realize that they need that because that is the sweet spot that I want to get involved in. Derek: I definitely think it is interesting that I think one of the beautiful pieces that Scrum has allowed is some of the concepts of agility to permeate outside of software development. Where if maybe we just had solely XP, we wouldn’t be able to bring some of the concepts of that is really all about people and working together and collaborating and iterating. Maybe those wouldn’t make into non‑software pieces but I definitely think that one of the downsides has been there are a lot of people picking up what they really believe is Agile in software development and totally missing the whole essence of technical excellence and all of the pieces that are around that. They think that they can be successful with just half of it and I think that anybody that has been around the community for a while understands that if you don’t have good core technical competencies and technical excellence that is really hard to iterate fast. Being Humane And Good To People James: You said half and I would say maybe they’re only getting a third of it. I bet we can come up with quarters next. The third is the mechanics of the interim cycle. There are 150,000 “certified” Scrum masters out there that know the mechanics of a day one Scrum. The other third is being humane, being good to people. This is a thing that was shocking to me in the early 2000s. You just said the better process so people wouldn’t matter thinking, and the people really do matter. The quality really matters and for that you need to really have sound engineering and people they’re not just programming as a job, but programming as a passion and an art form and a discipline, right. Derek: Yeah. I think one of the problems that we’ve had is that for the most part a lot of people are still selling Agile as just a better process. The people that are paying to have it adopted in their company are really taking the very ’90s approach of, “OK, if I spend money and I go get this Agile coach or I get a Scrum master, I implement this thing that I’m going to be able to plug anybody into it and they’re going to go faster and it’s just a better process.” James: Yeah. The engineer in me still wants to behave that way. If I just show them how these good practices work then they’re going to want to do them and unfortunately it doesn’t work that way. History Of Planning Poker Derek: Yeah, absolutely. It’s part of that. I think that we’re seeing a lot of influences from other communities as well, certainly Lean and Kanban and other ways of…People are struggling now to hack processes. They understand that maybe there’s some methodology, maybe there’s some principles. How can they maybe create or roll their own or experiment with different things? One of the things I’ve seen that’s been pretty popular lately, certainly I’m a fairly big fan of Planning Poker or planning exercises to be able to understand where we might sit a few weeks out and have some decision making process before we go and spend money. I know that even Ron and Chet to a certain degree, certainly those in the Kanban camp are leaning more away from traditional, estimating upfront and more taking the approach of “Let’s look at the work we’re doing, measure some of that work we’re doing and then see if we can get predictive capabilities based off of work already done. As some who is maybe the godfather of Planning Poker, what are some of your thoughts about planning now several years later? James: Well, I won’t disagree with any of the things that you just said there. The idea of thinking that at the beginning of a project we can really lay out a detailed plan that’s going to work is, I’m more and more convinced that that’s crazy. How do you plan an invention? Just pounding at widgets would be one thing, but there’s really an invention being created there. Pretty much everywhere that software is being invented or whatever you’re applying Agile or Lean to. I suppose maybe fashion. There’s a disconnect between the flavor of Lean and manufacturing in a flavor of Lean in design. Because one is you need variation in design to come up with creative ideas and then manufacturing you need to be able to do that same thing over and over again with high quality. What about planning, you’re asking me. I actually tell people not to use Planning Poker because I feel like it’s too slow. At the time of that first meeting when I just dreamed it up out of a pragmatic need to get a meeting that was stalled going again, it really helped speed this up. Then we discovered other things within the same year that sped us up even more like using affinity grouping and such, so that we could start to see which things are alike, which things are different. Then do a batch mode Planning Poker and piles of stories. Yeah, we know that those estimates are really wrong and you’re just trying to come up with some guesses to how big something is, so you can know whether or not you should proceed. If you spend two days playing Planning Poker you’re wasting two days. You could do that in two hours using other techniques. I hear what the Lean people are saying, “Why estimate at all?” But my world, in embedded systems, where there’s hardware and software that have to come together, the business is to have an idea of when things are going to happen. We can’t just live in the ideal world of what’s the most important thing to do next. Although we do work on the most important thing to do next, we’ve got to try and create some vision of how long it’s going to take. Derek: I like to tease and say, “We call them estimates for a reason. If they were actuals, we would call them actuals.” But I think I take a very similarly approach in that, really, it’s about estimating as quick as humanly possible and getting something that is accurate, not necessarily as precise as possible. If we know, going in, that it is an estimate, and that the bigger amount of time we’re trying to measure, the more inaccurate we’re going to be, but we like to use if you’re taking more than a minute per story to come up with an estimate, you’re probably taking more time than it’s worth, unless you really need to be precise. James: Yeah, unless you’re about to work on it. If you’re about to work on it, OK. But, if you’re just trying to come up with a release plan, for instance, that stretches out to see how insane we are for trying to do what we’re trying to do. It should be very fast. Embedded Test Driven Design Derek: Yeah, it’s the litmus test. Is this something we could even remotely fathom to do in this amount of time? If the answer is no, we just keep chunking it down until when we get something that’s won’t be right, but at least it will be somewhere in the neighbor of the ballpark. I find that most product managers, that’s good enough for them. They don’t want to be told, “You’re going to get everything,” and then you don’t get anything, so, if somebody can chunk it down to a reasonable piece they can either go out and ask for more money, move dates, or do some things upfront, which removes some of the anxiety from them, really, and gives them the ability to say “Is this worth doing?” I think you talked a little bit about embedded. I think some of the work you’re doing with embedded TDD is pretty fascinating in the sense of, I think, 10 years ago, I don’t think a whole lot of people would have thought that Agility was a place where hardware and software would necessarily all intersect with each other, but I think it’s becoming more and more commonplace in the manufactured or embedded world, especially if move to mobile devices, a number of other things. What are some kind of trends you’re seeing in the embedded world and adoption of maybe some of the XP practices? James: Actually, the funny thing about embedded software is, yes, there are some different things about it, but it really doesn’t matter, because all the techniques and principles…for instance, the solid design principles and having rapid feedback, these are all things that are going to be helpful, whether you’re programming on a microcontroller, an Android phone, or an IBM mainframe, if there is such a thing anymore. The underlying principles are the same. I had this nice advantage of growing up in the embedded world and then spending a bunch of time not in it, and, when I first ran into extreme programming, it just seemed to solve some problems. For instance, one of the challenges of the embedded engineer is that they don’t have hardware usually. What that used to mean to us is that we would code like crazy with no way of knowing if it works. Then, when we finally got the hardware, really close to the deadline, then we’d have to figure out if it works, and, of course, it didn’t. We’d get these high hopes in all of our documents, and everything we’re going to make it so that we just plug it in and it works, but, no, you had to go back and make sure everyone coded the right thing. We’re just pretty much back to verifying each line of code, which, when someone objects to TDD, they’re objecting, “You have to verify each line of code?” Yeah, but you do anyway… [laughter] James: …so don’t pretend like this is different. I am seeing that there’s more interest in applying TDD in embedded, and it’s not just the TDD part, it’s the iterative cycles, it’s the breaking work into vertical slices. All these things are foreign. Engineers are famous for being chopped into their silo and shoved in a cube, and come out several months later and try to integrate something in the… Some people are trying to change that. I’ve been working and trying to change that for the last…if I go back and look at history of going and speaking at the embedded systems conferences, it’s probably 11 years now, I started to try to get people thinking about this. I’m going next week, as a matter of fact. Challenges Between Embedded and Non-Embedded Software Teams Derek: Do you see a lot of the challenges as being fundamentally the same between embedded teams and non‑embedded teams adopting XP, or are there some challenges that tend to be a little bit different? Typical software teams don’t struggle as much with or they don’t even have the problem where embedded teams maybe do they’re a tool setter, the other outline factors that don’t exist for most teams. James: If I’m a Java programmer, and I’m building a program for a computer that the Java compiler and virtual machine run on, I’m building and testing on the machine that I work on. A fundamental difference from that is you’re building a PC, a Linux box, or a Mac, and you’re running your code on something else, so there’s a fundamental difference here. For instance, C is supposed to be portable, so why not write your code in as much as is possible to be portable, so that you could run unit tests and such off the target and then run some of them on the targets. In embedded, they called it the target system, the different processor. But there’s a fundamental difference here. But then, when I think about the techniques, an embedded engineer might say, “I’m special, because I have to interface with a piece of device.” A business program is going to say, “I’m special, because I have a database or UI.” Now, the techniques for breaking the dependencies on devices or databases or UIs are all the same techniques. The problem is that, oftentimes, the embedded engineer doesn’t even know they exist, because they don’t relate to software developers outside of embedded many times. I don’t want to make blanket statements, but, generally, they align more with engineering and maybe electronics, so the awareness of techniques that work and would be useful to them that come from Java, Ruby, or whatever, they’re unaware of and don’t know how to apply them. If they could be aware of them, they could certainly improve aspects of their work. TDD is one of these examples. They wouldn’t know about it if…I don’t want to pat myself on the back too much, but I have been promoting it for over 10 years now. There are people that are starting to do it, and they have been doing it with a lot of success. Derek: Yeah. I certainly even see that within typical software teams, where maybe you have a lot of experience, say, in the Ruby community, and then you move to a Java community, and a lot of the tools and some of the cutting‑edge things that a dynamic language brings you in some of the thought process, and certainly those that use Smalltalk and other languages going back to C. When you get these new insights, they become second nature for you, but you don’t realize that another community that has never seen them before don’t understand some of the techniques and the principles and aren’t able to leverage them. I think some of it is really great to be able to share cross‑discipline, to be able for a Ruby programmer to talk to a Java programmer or talk to a COBOL programmer or to talk to an embedded developer. James: … or talk to an embedded C programmer. Derek: Yeah, exactly. Because you can learn something from all sides. I think you’re absolutely right that they’re more similar than they are different, and we just maybe use different language about how we talk about them or how we see the problems. James: That is exactly true. The kinds of problems people are trying to solve, and maybe the domain languages could bridge both, but the solutions base is very different as far as what things we talk about and how we talk about them in embedded versus other areas. Derek: We’re at the end of our time box. Is there anything that you’ve got coming up that you’d like to share with people? Any books, events, training, you name it, that you’d like to share? James: Sure. Well, you could look at my website. I got a root website, JamesGrenning.com, that’s easy to remember if you remember my name. There’s not much there, but it’s got the links to other stuff I’m involved in for instance…My business is coaching and training. I’ve been quite busy helping embedded developers get started with TDD and deal with their very difficult and challenging legacy code problems. I’ve also got some public training coming up. You can look at my website. Usually, there would be a banner in the corner about that. There’s one coming up in October. We haven’t scheduled the one for the spring, but we’re going to do another one in the spring with one of my partners. I’ve got the Embedded Systems Conference. If you listen to this podcast right after it was published and maybe not before the Embedded Systems Conference in Boston happens [laughs] , and you’re out there, come and see me. Derek: Sounds great. Thank you for your time. We really enjoyed having you. James: Hey Derek, really nice to talk to you. Derek: All right, thanks. James: Yup.

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. Getting Started With Agile Clayton: Today, joining us, we’ve got Peg Haustetter. Peg, you wrote an article about, basically the gist of it was getting started with Agile. That’s a real popular topic with people who are interested in Agile, or listen to the podcast, and things like that that we come across a lot. What was the motivation of writing that article? Peg Haustetter: The company I work for is Systems Evolution. There are a few project managers that were going to clients that had not really been exposed to Agile, and [inaudible 00:46] to do, how to get started. We developed a team, and in that team, we started putting together some slides that they could present at their customer. One thing led to another, and we decided to write an article that we published in our [indecipherable 01:05] . That article took all those slides, and all of those conference calls and meetings that we had, to try to get a little Agile primer to all of our members, and we came up with the article. Clayton: I noticed that you mentioned things like sprints and iterations. The stuff that you’re describing is like Scrum, although you leave some parts out. I was curious if that’s something that maybe Scrum is in your background, or if that’s maybe your preferred methodology that you like to use for projects, or if that was even intentional? Peg: I am a Certified Scrum Master, so those are the types of projects that I have run. We intentionally left it out because we didn’t want to really sell a flavor or a certain methodology [indecipherable 01:58] article, so that people could relate to what they’re currently doing. Or to realize that not every company is doing something that’s purely Scrum, or purely any kind of methodology that a lot of them are mixing [indecipherable 02:17] some of their worth all on trying to do it all at the same time. Hurdles Going From Waterfall to Scrum Clayton: Is there anything that…You mentioned the waterfall, transitioning from waterfall or using that as a benchmark. In your experiences there, are most companies that you find that are trying to transition into Agile, are they doing waterfall now or do they not even have a process? What are those hurdles, the biggest problems that you find that people face when they are trying to make that transition? Peg: I do find that the clients that I have been at, they’re larger companies, and so they generally do follow the waterfall. I think the biggest hurdle is trying to get the business team [indecipherable 03:05] involved. They are all about defining the project, and agreeing to the requirements, and then throwing it over the wall, and “Call me when it’s done.” [laughs] To try to keep them engaged and daily [inaudible 03:22] challenging for the [indecipherable 03:25] to get them in a room to do demo, or let them play around with whatever we’re delivering that sprint. That’s a huge hurdle, if I can get two or three of them in the room. I think that in the end, the team that you’re working with [indecipherable 03:42] happy with the process once they’ve realized how it’s working, but to get them initially engaged is a challenge. Clayton: I had overheard the conversation from a product manager and the product owner of a Scrum team the other day. The gist of the conversation was, “I really like this whole Agile thing and it’s great, but we really need to balance being Agile with getting things done.” Peg: [laughs] Clayton: I thought that was interesting. I was curious if you’ve heard anything like that, or what you’d say to that person? Peg: [inaudible 04:19] is that maybe they’re not [indecipherable 04:22] their sprints correctly, because the whole idea is that you are getting things done, and you’re getting them done quicker, you’re getting them done so you have eyes on them, catching any issues, [indecipherable 04:34] put in the wrong place, the wrong color, some little small thing. People are seeing it right now, if they see that the data’s coming out the wrong way in the field, they see it, you can react quickly and correct it, and then move [indecipherable 04:53] hang around with somebody that’s doing Agile. Go to a class, try something! Hybrid Approaches Clayton: You mentioned in the article that people like taking a hybrid approach, or maybe combining two things together. There is some talk in the Agile community of a “Scrum bond,” or something, trying to combine Scrum and Kanban together. Have you ever seen anything like that be successful? Or are you more getting that as a way to introduce the organization to Agile, they might need to do more of a hybrid of their traditional technique, plus some more Agile concepts? Peg: The things that I have experienced [indecipherable 05:42] methodology, a lot of it is because their compliance departments won’t allow…They don’t really understand the documentation. They still require tons of documentation, tons of certain types of testing, depending on what the product is, and then what sector that you’re working in. I was working in the medical [indecipherable 06:11] sector. Obviously there’s a lot of regulations, a lot of paperwork, a lot of checklists. You still have to do a lot of those types of documentation while your development team is developing in the Agile methodology, but you still have to support all of the traditional [indecipherable 06:35] . In some of those cases, in my case specifically, the PM had to produce more documentation than my team, probably wrote in code in some of those projects. I think it depends on the organization, and its will to let go of some of that. The regulations that drive why we do things [indecipherable 07:02] piece of software. I think it’s learning, and I think it’s learning all the way around. It’s not just for the companies, but if they’re regulated, it’s for the regulators. They have to understand. They need to look back and read all those documents again, and see if there is a more streamlined approach. Starting Agile At Team Level Clayton: Do you have any opinions on starting Agile at the team level, and then growing it from the team level up to the organization level? Or do you feel that starting at the organization level and trying to get the higher‑ups thinking in more Agile mindset is better? Do you have any opinion on that, or maybe you’re still trying those things? Peg: I’ve had more [indecipherable 07:57] both the opposite ways. The medical device company I worked at, we were doing it at an organizational level. It came from the top down, and we happened to be the first project, but they were pushing it across the organization. I think it was six [indecipherable 08:20] everybody was on‑board. There was lots of training. People went to all of the training, the displays, they went to [indecipherable 08:36] reviews and things like that, so they got engaged. Currently I’m at a client that, first they were trying it more on a project‑by‑project basis, doing an evaluation to see if that project fit into that mold. That was a slow burn. Just a few people would try to do it. Now, they [indecipherable 09:05] organization. I think that’s more successful, because when the management is on‑board with it, then everybody gets the right communications and training so that they can move forward with it. The Role Of Organizational Culture Clayton: One thing that we’ve found is that the organizational culture seems to play a very big role. I was curious if you’ve also noticed that, or if you have any techniques or ways that you’ve tried to guide the organization culturally? Maybe they’re used to this waterfall, or more of hierarchical management style, and that transition to Agile can be upsetting from a cultural perspective. Is that something that you’ve noticed? Peg: It is something that I’ve noticed, and it is baby steps. You just have to really spend a lot of time guiding, and getting them used to so much interaction. The first couple of projects that I’ve done in Agile, the business, it was just really hard to pull them along. IT was all for it, we were gung‑ho [indecipherable 10:19] all the meetings, and didn’t want to be involved. It is a big cultural change. You have to just keep guiding them, and showing them all the advantages of being more participatory. Each Role Has a Different View Clayton: The article seems to talk from a…Maybe it’s geared towards a project manager, or someone who has a holistic, or has a higher‑level view of the organization of the project. If me and a couple of other developers are on a software team, and we’ve been reading a lot about it, and we want to be an empowered, self‑organizing team, is there any different advice you’d have for someone that maybe is at that level of the organization? Peg: [laughs] Yeah, there is. If I was writing this article, or talking with the development team, I would have taken a totally different approach. They already know the pitfalls, [laughs] they know that it would be better to have a team that plays on your strengths, and really jumps in and helps each other out, so that you’re not so stuck, spend hours [indecipherable 11:38] . This methodology really does get everybody’s creative juices flowing, and I think developers thrive in this [indecipherable 11:57] . Somebody that you don’t really know how much they’re producing, or how quickly they can produce until they are standing up every day, and telling you everything you’re doing, and it’s contagious. If I was writing this [indecipherable 12:14] mentally different approach. Start With Someone With Expertise Clayton: If there’s one big takeaway that you’d like people to get from the article, the piece of advice that everyone wishes that they knew before they started, what’s the one big takeaway? Peg: I would recommend that, especially your first few Agile projects, that you would bring someone in‑house that has some experience, that can help your, if you have a PMO, depending on the size of the organization, but that can really give some guidance to the department, or the organization of the department that is [indecipherable 12:55] managed other projects. Somebody that, if it’s a consultant, bring them in. Somebody with this real‑world experience, that’s already experienced some of the bruises along the way, so that you can have a more successful [indecipherable 03:14] and a more successful experience. Clayton: We’re getting close to the end of time here. Is there anything you’ve been interested in lately? A book, or a blog, or any conferences or books that you’d like to promote, and let the audience know about? Peg: I always took my training from Mike Cohn and reading Mountain Goat Software website, his blog. There are lots of books that he recommends, and I do find that all the books that Mike Cohn recommends do really help you in estimation or writing user stories. There’s quite a few tools that he has on his site, so I would recommend people [indecipherable 14:03] probably go to Mountain Goat Software. Clayton: Peg, we thank you for your time today. Peg: You’re welcome. Clayton: As always, we invite the audience to check out the Agile Weekly Facebook fan page, where you can talk about this episode and other episodes as well. I think that’s about it, so thanks again, Peg. Peg: Thank you.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. Drew LeSueur: I’m Drew LeSueur. Jade Meskill: I’m Jade Meskill. Clayton: Today, we’ve got a smattering of topics, a potpourri if you will. Jade: [laughs] Are Spikes Or Research Stories A Smell? Clayton: We don’t have a guest. If you’ve been listening to the podcast for a while, you might have noticed that the last 38 episodes we’ve had guests, but not this one. First topic, “Are spike/research stories a smell”? Drew: Jade, you hate spikes. Jade: I do. Yes, I think so. I’m not against them entirely, but I’ve seen people take it too far. Basically, have multiple iterations of a spike, which to me, is a project. Roy: Yeah. That’s just a spike taken to excess. You were telling me earlier about a spike taking six weeks to do. It seems to me that the spike should take maybe one or two hours. But I could totally see the validity of, if you’re going to put up some task and you don’t know if it’s actually possible, you can’t commit to getting it done within your iteration. So, you set aside some time to go and do the spike. If you have a four‑week iteration that poses a problem, because that means you’re doing your spike now. That means your actual features aren’t getting done until eight weeks from now. A spike might be something that you can’t do if you are doing one‑month iterations. Jade: I prefer instead of committing to an unknown, creating a research task or something like that, that we can give a time box or an estimate to. And then use that information to now be able to turn that spike into something that is estimable. Roy: That’s what I was thinking of, when I was thinking of the spike. I guess the spike is supposed to be a prototype that you throw out at the end, right? Jade: Yeah. Research Tasks Roy: I was thinking more along the lines of research task. But I don’t like the idea of doing a pure research task either. If you’re going to spend two hours researching it, why not get started on building it, and improve that as possible. Jade: Yeah. When I say research, that’s what I’m thinking. Let’s prove it out. Let’s make sure it happens. Too many times, I’ve seen the spike become the actual product. Roy: Right, and then you have a whole bunch of people working on it, who have absolutely no concern for good quality, because we’re throwing this away at the end, anyway. By that time, you’re too attached to it. You can’t invest the time to really build it for real, and it’s already about to market. Drew: There’s also a danger in, “We’re just going to see if we can do this.” Even doing it in a sprint or especially if it goes beyond more than one sprint, is sometimes what you prototyped and what you did can be the actual product. I know that that was a pretty rigid, but there’s danger in thinking, “Oh, this isn’t real yet. Oh, this isn’t real yet, this is just a prototype,” and then carrying that on. Determining Is It Possible Roy: Usually to any spike, there’s really one crucial component that you’re wondering like “Is this even possible”? It’s not like the whole spike is…and usually that one critical component ‑‑ and obviously not in all cases ‑‑ but I mean you can probably knock it out in under a day and just prove that that part is possible and that’s all the information you need to estimate the rest of story. Now, I can commit to it. Clayton: Let’s say that you are doing sprint planning and a story comes up that you hadn’t really looked up before. Maybe you glanced at it but you don’t know what it tells. You have never done it before and no one on the team has ever done anything like it before, and you have no idea if it works. What do you do? Roy: OK, there’s a huge difference between “It’s never been done before,” and “I have never done this before and I am not sure if it’s possible.” I have never driven to New York City but I am positive I can do it. Clayton: “There’s some piece of technology I have never worked.” “There’s a third‑party API that I have never used before and I don’t feel comfortable coming into the story.” Roy: Within some limits…I guess it’s up to a comfort level but it’s still reasonable to commit the stuff even if it’s unknown. Clayton: I can’t commit to it. It’s too much for… Jade: It’s got freaking laser beams. Roy: It’s got freaking laser beams. Then I could totally see like pulling in a research story or a research task or whatever, spending an hour to researching it, and building up a prototype of what you actually think it’s going to be with the thought in mind that if this works, this is going into production. I can totally see that, and then at worst you’re wasting like an hour or two. Clayton: If it takes me longer than an hour to answer my question? Roy: Then maybe you should talk to your team and see if you can come up with an alternative solution or something that’s simpler. I don’t know. Jade: Maybe you’re asking the wrong question. Roy: Who is asking wrong question, me or…? Jade: If it takes longer than that to answer your question, maybe you could break that down into some smaller pieces. Maybe you have multiple questions that need to be answered. Roy: Multiple research tasks, I could say that, especially we have the type of team that has gigantic stories, where they take multiple days to finish each one. Jade: You mean that prevents you from getting too far down this path and becoming too attached to this thing that was supposed to be a prototype or something that you are going to throw away at the end? Roy: Right, and the other thing that I would make sure too is with any spike or prototype, I mean that would be specially the stuff that I pair on. Because I could totally see that becoming very quickly into a personal project where, because I am the one who saw the spike through, next week I might just as well be the one that works on it, and I certainly know the most about it. Jade: …and the laser beam expert. Roy: Right, exactly. I am the laser beam expert. You guys are afraid as hell of me and can’t fire me because the laser expert gets it by bus, you guys are screwed. Clayton: When did you just take the approach of saying, “Forget the spike or the research thing, let’s just do the story,” and in part of doing the story, I will do the two hours of research and we’ll just complete it there. We don’t have to wait on the whole other iteration”? Roy: If you’re really that concerned about waiting on a whole other iteration, then it sounds like your iterations are too long. Jade: If you’re willing to take it in to your sprint, then you have, implicitly, given it some estimate. Roy: Yeah, but what if part… Jade: It can be completed inside of your sprint. Roy: Yeah, but I could see a product owner brow‑beating the team into taking the story on, “Hey, we need to get this done by Tuesday,” and you’re like, “Well, I don’t even know if I can get it done this sprint.” “But we need it by Tuesday.” Jade: By bringing it into your sprint, you’ve implicitly agreed that it can be done by Tuesday. Roy: That’s a good point. The team members should feel that they are empowered to refuse to bring that stuff in, unless they honestly believe they can get it done. Jade: You either truly cannot estimate it at all or it’s just hard and you don’t want to estimate it. I’ve ran into very few situations where there is no possible way to estimate the story or whatever it is that we’re faced with. It happens, but very few. I might give it a very large estimate, because I’m highly uncertain. Roy: We’ve definitely seen cases in which we think like, “Hey, there might be a really easy way to do this. We’re trying to develop some feature and there’s a library that Mike did 90 percent of it for us. We’re afraid to commit to it because it could take two days or it could take one hour depending on the availability of that library or not.” I could see that as being a really good case for, “We’re just going to commit to because we know, at most, it’s going to take two days. It’s probably only going to take an hour because a library exists or it probably exists or whatever.” But, at least, you can commit to it. Now, do you leave that extra…do you commit to the maximum amount of time it would take, so you could potentially be leaving almost two days worth of work on the table that you’re not committing to? Spikes During Estimation Clayton: If you change the scenario up a bit, and we say that you are doing a planning poker game, and you have this stack of stories that are loosely defined. You’re not talking about the details of the stories to the acceptance criteria and anything like that, but some stories come up and they sound really scary. How often do you just spike them versus maybe giving them a larger estimate? What do you do? Jade: I’ve been faced with that. I’ve worked with a team that had to deal with that. What we ended up doing was breaking that unknown down into some still large, but smaller pieces. We have this huge thing that we just can’t estimate. We have no idea how to do it. Well, could we talk about things that we could estimate and could understand and simplify the equation? We ended up with some pretty large loose estimates on the things that were pretty big unknowns, but it wasn’t that we could not estimate it at all. Clayton: How do you know when you are spending too much time estimating and breaking things down just for the sake of getting that estimate versus just trying to take the work in or…? Roy: Are you suggesting taking the work in without estimating at all? Clayton: I’m saying, is it worth it if you have some story that everyone on the team says, or maybe there’s one really outspoken person and they want to spike this because they’ve never ‑‑ I’ll go back to the API example ‑ they’ve never worked with a third‑party API, so there is no way they can size it because it could be the most complex thing in the world, so they want to spike it. Is it worth the time to go through and break the story down so that it can be sized better or it to have a whole separate spike story, to research the API? Are you wasting your time giving an estimate at that point? Roy: It depends on how quickly you need to get it done. If you need to get it done this iteration, then the only way to reasonably do that is to break it down into estimable chunks that you can be, as a team, confident that you can complete if before the sprint is done. If the product owner determines that this needs to get done this week or as soon as possible, it’s a top priority story, even if it takes three weeks, “I still need it done as soon as possible,” then you’re going to have to break it down and apply some estimates to it. How Often Should You Use Research Stories or Spikes Clayton: If research stories and spikes are smells, how often should a team be using them? Roy: I don’t know. In the teams, it’s something like it will come up only like once every other month or so. In my experience, it’s not that common for a spike to pop up. Clayton: If it does come more frequently, what does that signal? What could you learn from that? Roy: That’s probably because you’re not breaking stories down far enough to begin with for pulling it into the sprint. Jade: Yeah, they’re either way too large or your team is incredibly inexperienced, that could happen. Roy: Or your team is just really worried that they’re going to be held responsible for their stories. They’ve been burnt in the past by product owners that really pressure them into pulling stories in or pressure them and yell at them afterwards if they don’t… [crosstalk] Clayton: They’re fearful for some reason? Roy: I could see that, yeah. Clayton: OK. Roy: It’s like, “I don’t want to commit to anything because I don’t want to be kept to this,” or, “I don’t trust the rest of my team to actually do it.” Jade: Another thing I could be signaling is that you’re missing a skill on your team. Maybe there’s a team member that you need to have that has the necessary experience or qualifications. There might be something that really they just don’t know how to do. If for a bunch of developers and we need to illustrate something. Maybe we just can’t do it. That would be another indication that we’re missing it, a critical person on our team. Should You Use Storie Points Clayton: We talked a little bit about estimates, but there are a lot of things out there that are doing story point estimating…basically, that’s part of the planning process. Does that seem like a reasonable thing to do? What are some downsides to that, maybe? Roy: I don’t know. I’ve been guilty of being on a team where we do that. It feels reasonable at the time, but I can’t really name any benefits we get out of it. I don’t know. Maybe it’s like double‑ledger bookkeeping that we are confident that our tasking matches up to the point estimates to somewhat reasonable. We’re not pulling in five 13s in one‑week sprint. But, other than that, I don’t really know how much value we’re getting out of it. Drew: On teams where they’re not doing anything with those points, they’re not using it to do release planning, longer‑term planning, or determining velocity, that sort of thing, then what’s the point? But, if they’re actually using those numbers, then, it’s valuable. Being Aligned On The Effort Roy: One huge thing valid that I can see getting out of it is, it very quickly lets everybody on the team that’s part of the estimating process know, that they’re on the same page or not. This is something totally different than you Drew, like, “You threw up a 13 and I threw up a 3, then that means we’re got to talk, because, clearly, we have two hugely different understandings about what this is supposed to take.” That should probably come up during tasking, anyway. Jade: Yeah. There’s some value in that ‑‑ knowing that we’re in alignment. I do think that, if you’re not using them for anything, you’re probably wasting your time. Roy: Yeah. If you’re doing it as part of the planning process, and you’re finding that you’re estimating even one 13, if you’re getting into 8s and 13s, I would seriously consider breaking them down into smaller stories, so they might be useful as an indicator that you need to break stuff down. Because, if you just start tasking, then is becomes like [inaudible 12:30] slowly where you’re adding task to your story a little bit at a time, and there’s not a clear cut‑off point where, “OK, this is too much. We need to break this into smaller pieces.” Estimating Right Before Planning Clayton: If you are doing release planning, you are using the estimates or something somewhat meaningful, does it really make sense to estimate right before the planning? Isn’t it easy to game the system if you do that? Jade: Yeah. I personally think that estimation should happen in some sort of backlog grooming or something outside of the actual planning meeting. You should come into the planning meeting with all your stories estimated and ready to go, because estimation does affect priority sometimes. The product owner might make a different decision depending on what the team thinks it will take to implement a certain feature, and trying to do all that right during the planning meeting itself can lead to a lot of waste of time and confusion. Roy: I agree, but, if you’re just starting to do something with estimates, or you want to start doing with your estimates and tracking the velocity or doing some kind of release planning, at the very least, starting to collect to estimates right before planning allows you to start collecting velocity data, so that, later on, when you are doing backlog grooming and you want that information, you have the data available. Clayton: I think you can still do the estimates way beforehand and still getting something [inaudible 13:50] . Roy: I totally agree. But, if you don’t have a backlog grooming session or whatever, and you aren’t willing to invest the time yet, I don’t know. All I’m saying is, you can still get some value out of doing estimates right before planning, but it’s not going to be as meaningful, or as valuable as it would be if you were to do it before. Jade: It takes the same amount of time, but, mentally separating those concerns is good for a team, to treat estimations separate from planning. Roy: I agree. Should Blocked Stories Constitute Sprint Failure Clayton: One last topic real quick. Here’s the scenario. Let’s say that you’ve got a Scrum team, and, in their spread, they completed every single story, except one story, and, for whatever reason, they decide that they can’t continue on a story, and it’s blocked. They didn’t know something planning, or something came up, and they just can’t continue. The assumptions they made were wrong. Should the team feel bad about that? Should they feel like they failed their sprint? Is it an exception? They did everything they could, so it’s OK? What do you guys think? Jade: I need a research spike before I can answer that question. [laughter] Roy: It should be considered a failure because that means that something went horribly wrong. They did the best they could at the time, but it doesn’t mean we should ignore this and not learn from experience. We should count it as a sprint failure, and it should probably be the biggest topic in the retrospective. Clayton: Yeah, it might be. Jade: Too often, sprint failures are punitive, that we treat them as this thing that we’re going to beat the team up against, like you should never fail. You’re going to fail. It’s going to happen on every team. There will be sprints that you fail for a myriad of reasons. Sprint Failures Should Be The Exception Not The Rule Roy: But it should be the exception. Jade: It should be the exception. If you’re failing constantly, you need to be looking at what’s causing these failures, if you’re overcommitting or whatever it may be. I agree with Roy that it should be the big topic of the retrospective, but it shouldn’t be something that is used to punish the team itself. Drew: Right, like the good and the bad, like, “Hooray, we’ve got all this stuff done! We released this awesome stuff. But, oh, too bad! We didn’t get this one done. In hindsight, what could we have done different”? It’s a success and a failure. Roy: Yeah, because I’m sure there’s something we could have done different to prevent that. In hindsight, you can see like, “Oh well, we should have done whatever to prevent this.” Clayton: We’ve asked this question during planning, or maybe we made these assumptions about how this thing was going to work. Roy: Right. How could we avoid making those assumptions in the future? How could you remind yourself to ask these types of questions that would have caused this particular question to get asked for answers that come forward or something like that? Jade: Yeah, but if you’re being essentially punished for that, you’re not going to think about that. You’re just going to think about how can we never fail again, instead of being open‑minded about, “OK, how could we have done this differently so that we don’t run into this again.” Clayton: Yeah. It’s OK to fail if we use it as a means to… Jade: …a learning opportunity. Clayton: Yeah, right. Jade: And we acknowledge and embrace that failure, and say, “OK, we may have not adhered to a commitment, but we learned a whole bunch about what could be done differently next time around.” And that might not work either, but you’ve got to keep trying. Roy: Right. [inaudible 16:59] twice. They failed two weeks in a row, or two sprints in a row, at what point, you start actually considering it failure. Clayton: All right. That wraps things up. That’s all the time we’ve got. We invite you to check us out on the Facebook fan page at facebook.com/AgileWeekly, where you can continue the conversation on this podcast or any of the others. We’ll see you soon. Goodbye.

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur. Roy vandeWater: I’m Roy vandeWater. Jade Meskill: I’m Jade Meskill. **Drew:** And with us today is Declan Whelan. How is it going, Declan? Declan Whelan: Oh great. How are you guys? Is Demanding Technical Excellence Still Relevant? Drew: Doing good. Today, we wanted to talk about demanding technical excellence. I’ll start off with a question for you, Declan. Why is this still relevant? Why are we still talking about this today? Declan: I think it’s probably more relevant than ever because from my experiences as an Agile coach over the last few years, I’ve seen Scrum become more and more prevalent. Which is great. It’s more like just a framework for project management and as we’ve crossed the chasm in many ways with Agile, I’m seeing a dilution of technical skills. I think it’s kind of ramped up a little bit, because the people that were most motivated for Agile in the early days, tended to be very technically forward looking, and technically adept. That, I think, is becoming less so as we’re moving into larger organizations, where people aren’t quite so motivated perhaps, to be self learners and so on. I think the demand or the need to promote technical practices is stronger than ever. Drew: Great. Technical practices, I think a lot of stuff like pair programming, the XP principles and practices, is that the kind of stuff you are talking about as well? Simple Design Is Just Missing Now A Days Declan: Yeah, exactly. I remember the podcast you had with Arlo earlier this summer, and a lot of that for sure. In fact, he said it so eloquently in many ways, with his metaphor of the train and Scrum just being the steering wheel and the rest of the engine. Or I guess actually the car, becoming some of the technical practices. He didn’t mention explicitly, and it was the subject of a talk I did in Dallas last week at Agile 2012. It was simple design. I found that to be kind of very illuminating that in the version one annual survey that they do, they list the technical practices. They barely get over 50 percent on any of them. They think unit testing might be 70 percent, and then all the rest of the technical practices are maybe 50 percent, but most way down like 12 to 20 percent, but the really strange thing is that simple design does not appear anywhere. It is not even on the list. I find that quite fascinating. Jade: I came into the whole agile world and ecosystem through Extreme Programming (XP). I’ve always wondered why it didn’t quite get the legs or the following that Scrum ended up really capturing. Why do you think that is? Declan: I don’t know for sure, but my suspicion is that Scrum is just so much easier for organizations to grok. It can fit on a single page, it doesn’t look too hard. I think just that, and I am sure the Scrum certification models had a part to play in it. I think it was mostly just the simplicity of the model. Roy: Is it maybe the centralized nature of something like Scrum? If you get a product owner Scrum Master that is properly trained, they can kind of disseminate that amongst their entire team, but if you want to practice a lot of these technical practices, you have to have an entire development team that is able to do all of them. Do you think maybe that plays a part? Declan: I am not so sure. I think you’ve got a good point. This is perhaps a little more specificity in terms of the roles that might make it easier. We’ve got project managers, so we can make them product owners, and we’ve got project managers, we can make them Scrum masters and that’s not too hard. Whereas with maybe the titles don’t fit quite so cleanly with XP. It disappoints me that XP has not become more popular than it is, but the odd thing is that teams are doing Scrum really well are actually doing all the XP practices anyway. Jade: Yeah, that’s what we’ve found as well that for teams that we’ve been on or coached that as the maturity of the Scrum implementation came along so did that desire to implement much higher quality technical practices. Scrum As A Way To Build Technical Debt Even Faster Declan: Yeah, that’s great when it happens. I am not so sure that that’s going to happen consistently with some of the newer organizations taking on Scrum. I hope it isn’t, and believe me, I’ve been thinking a lot about what can I do to help make sure that happens? Because, on the flip side, I’ve seen Scrum provide teams with the tools to build huge mounds of technical debt faster than they ever could before. Jade: Yeah, that’s true. Declan: My mention of demanding technical excellence came up from a meeting that the signatories of the Agile Manifesto had last September. They, basically, came up with a plan directive. They felt that over the next 10 years, we really need to crank up the technical excellence throughout the industry. I believe that, too. It’s not that there aren’t other important things, it’s just the thing that really strikes me as having waned since the last five years. Jade: How does one demand technical excellence? Declan: [laughs] I don’t know. One thing that I’m really excited about is that in Dallas, I’m the newest member of the board on the Agile Alliance. I feel that that gives me an opportunity to explore that a little more deeply. In terms of pulling from people like you and other passionate people about what it is as a community can we do to perhaps…I would choose the word “foster” technical excellence. The “demand technical excellence” was just Sutherland’s term. I might choose slightly different terms. Look for ways, certainly, with teams. In terms of what you’ve described. You’ve been able to demand technical excellence in the sense that fostered teams moving from Scrum into extreme programming practices which is awesome. Some things people have suggested, bringing back the original XP conference. Certainly, the software craftsmanship movement has something to say about technical excellence. At this point, I’m really just getting tuned into the idea and I’m quite open to how we, as a community, coped. Fostering Technical Excellence Jade: I’ve often thought about it in that, I feel like, I can demand technical excellence from myself because I understand what that means. I like your idea of fostering into others. I think those two go hand‑in‑hand. If I am relentless about demanding it of myself, hopefully, that is creating that desire in other people to want to follow that example. Declan: Actually, the things I’ve done as an Agile coach, pair programming, certainly, is a great way, in and of itself, is a technical practice, but it, certainly, fosters the spreading of knowledge and skills that deepens the more technical aspects of good design. Expanding the definition of “done”, having regular retrospectives, promoting learning. There are lots of things that can be done, certainly, at a team level. I’m thinking, also, that more, on a wider level, how do we do that as a community as well? Drew: As far as the technical excellence stuff goes, you being an Agile coach, is it ever hard for you that you’re focusing more on team related stuff or on other things that are apart from just maybe sitting down with somebody and pair programming and doing test‑driven development with somebody? Is that ever an issue with you? Declan: It is. I, certainly, have this stance as an Agile coach that my job is to provide teams the best help that I possibly can. I work hard to be tuned to find out where they pain is and where I can have the most leverage, and I focus there. As I’ve moved up into larger organizations, less and less of the time do those points of leverage ended up being technical. I’m OK with that as a coach in doing my job and as my role. But, as a software developer for 25 years, I do find it difficult because I just find if I’m not coding on a regular basis with this…there’s kittens that die… [laughter] [crosstalk] Declan: …my brain, right? As a professional, I don’t have an issue with it. But, personally, yeah. I really want to keep coding on a daily basis. Drew: In my experience working with teams, I’ll pick one of the XP practices which is pair programming, which I really love, and I do a lot. I’ve been on a team where that’s been hard for some people, where they’ve gone their whole program career not pair programming. Then, all of sudden, somebody comes in, like a coach or somebody else, who wants them to do that. Transition‑wise do you have any advice or anything you would like to tell us? Running Experiments Declan: Some of the things that Arlo mentioned are things that I really believe in. Certainly, running it as experiments, making sure that it’s viewed not as a team commitment, but as something to explore, and making sure that the team feels they’re in control. I’ve sometimes done it the other way, where I just get teams to agree to pair program for a short amount of time. I’ve, perhaps, had a different experience with Arlo. I find I get benefit even if the teams pairing some of the time. That’s quite a bit better than not pairing at all. Maybe getting them to do full immersion pairing might be too difficult. I certainly have found cases where it’s too difficult. It may not be because people don’t want to. It can be the culture or the organizations, so it’s actually mostly outside of their control. Certainly, I think going moving with empathy [laughs] and with giving people a choice and putting out offers rather than them trying to force it down anyone’s throat. Jade: I have to follow that up with a confession. When I first heard of pair programming and some of the XP stuff, I thought it was the dumbest I’ve ever heard of. I was a developer and I was managing other developers. I thought what a waste of time having two people sitting at one computer. This is the dumbest thing in the world, until I experienced it myself with someone who was very good at actually doing pair programming, and including me in that process, really brought me along. Totally converted the way I viewed that practice. Now, I’m a huge advocate of it. Love it. But, I was highly skeptical at first. Declan: I think that happens a lot with a lot of these technical practices. And too, another thing that I’ve become more attuned to as well is using games. I think Joshua Kowalski came up with a pair‑drawing game, which is a great way to introduce people to the idea without having them commit to it in any way, but experiencing some of the benefits from it. Jade: That’s cool. Drew: It’s cool talking about your transition, Jade, right? Seeing when teams start to capture the vision of some of these practices when they’re excited to write tests or when they say, “Oh, let’s write a test for us here,” when maybe they wouldn’t have before. Or get excited about pairing on something or, “We’re going to pair if we want to get this done faster.” Those types of things are exciting to see with teams. Declan: What I’ve learned the hard way as well to really look for where the energy on a team is, so if the energy happens to be when I’m doing more testing or refactoring or pair programming and moving, even though as a coach, I might feel that they might get better leverage from pair programming over something else. I tend now to move towards where their energy is because that’s more likely to be successful. If they’re showing energy before something and it’s not pair programming, I’m OK with that. [laughs] Drew: Great. Yeah. Good stuff. Thanks a lot for joining us, Declan. Do you have anything you’d like to share with the audience? Declan: I would. I’ve had a very interesting couple of months, being the newest member of the Agile Alliance Board, which I’m very honored to have. I welcome any insights or suggestions people may have for me in that role, particularly, towards promoting technical lessons. Another thing that I’ve done the last two months is I’ve co‑founded a start‑up called printchomp.com. Chomp as when you’re chomping on something good. We’re using Lean Startup and Agile and you can find us at www.printchomp.com. We’re going to be launching in mid‑September, so sign up and we’ll keep you informed of how that goes. Drew: Awesome. It’s been a pleasure. We appreciate you joining us on the show today. Declan: Thank you for having me, my fun. Drew: All right. Talk soon. Jade: Bye.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Drew LeSueur: I’m Drew LeSueur. Roy vandeWater: I’m Roy vandeWater. The Leadership Mindset Clayton: Joining us today, we have Christopher Avery. We’re going to chat a little bit about leadership and specifically, the leadership mindset. When I hear the phrase “leadership mindset,” that to me, I think about getting in the mindset of being a leader. But it sounds like that may be something more specific to you. Can you maybe expand on that a little bit? Christopher Avery: Sure. Thanks so much. I appreciate being on your podcast. This is fabulous. Leadership mindset to me…Chris Matts in the Agile community is pretty famous for saying “more leadership, less leaders.” That’s been a theme of mine for probably 25 years in the work on collaboration and team‑building. To me, leadership could be defined as “any behavior that moves a group towards its goal.” Which means, for me it starts with an individual taking ownership, feeling a sense of ownership for some space, some opportunity, some outcome, some needs, some initiative. Just call it a space ‑‑ taking ownership for some space, and then moving themselves into that space in a way that causes others to want to go with them, to get something done. For me, the leadership mindset is a mindset of personal responsibility, and understanding how powerful we are when we truly sign up to make something happen in some space. Maybe I’ll stop there, and let you tell me where you want to go with that. Roy: It sounds like it’s not really an assigned position ahead of time. We’ve seen instances in which the leadership role can almost be a floating position, where whoever just seems to take the reins on a particular topic, it becomes the de facto leader until somebody else does. Is that what you’re talking about? Christopher: Sure, that’s what I’m talking about. Absolutely. The issue is that the words “leader” and “leadership” can mean so many different things. Because we have hierarchy, and we have people with assigned authority and power positions, and people we look up to as called, “our leader,” a President or a boss, whatever. To me, those people don’t necessarily demonstrate this leadership mindset. I hope they do. But sometimes, even the position of power or authority is an impediment to true leadership. We see that in self organizing. When there is no one person who seems to have the authority to say right from wrong or prioritization or value, then, there is much greater personal ownership on the part of the whole team in terms of discussing such things. Haven’t you seen that? Clayton: Yeah, I was going to say that. I felt there is times where, may be, someone is like the senior developer on some team and there is supposed to be this cross‑functional team and people are supposed to look to them and there is the hierarchy of the traditional organization and what it means to be a leader and they take all that stuff. They maybe not have the personal responsibility, or all the other aspects that you mentioned before and they just assume that whatever I say goes because I am the person who is supposed to be the leader. So, why isn’t everyone following me? Roy: That sounds like if that person, who was the leader of the group, and if they actually had good leadership qualities, it sounds like that could be a very strong force for the team as a whole. I understand the benefits of self‑organization, but there is also a lot to be said for somebody who has a clear mind on the future vision and keeps everybody focused towards that. Clayton: Yes, I guess I have to agree with that. I really did like what you said Christopher, but the idea of a leader being someone who takes something, picks it up and then takes the team with them but not necessarily in the context of you have to have a certain role or a title or anything like that. Those were the things and I guess I like to ask practical questions on this podcast. There are a lot of people out there who are not the leader on a team, would like to have them appointed leader by management and they don’t have the personal hierarchy and they have been there the longest, but they are very passionate about something and they will be willing to take the responsibility. What would you suggest for someone that’s in that position, how do they demonstrate leadership mindset? Is it something that is just going to happen over a period of time? Leading When You Don’t Have a Leadership Role Christopher: That’s a great question. What I’d recommend there is, I’d recommend stepping forward, I’d recommend putting your foot in your mouth, I’d recommend trying, I would recommend anything worth doing is worth doing purely at first, I’d recommend going for it and being shut down even but willing to go forward again. And if you find yourself in an environment where it’s not wanted or needed then, that means, may be its time for you to take your desires to make a better contribution somewhere else. I’ve had the luxury of doing, actually having an academic background, is studying the science of leadership. There are three paths worth talking about in the science of leadership. One is worth rejecting. The one worth rejecting is the idea of traits. Every list of the traits of a leader has been debunked. Multiple times, people have done correlation studies where they’ve taken all the various, six traits, eight traits, 10 characteristics, of a leader and cross‑referenced them all and what they’ve found is there’s no correlation. Saying that a leadership or leader is a certain type of person is debunked. That ought to be great permission for everybody. The three parts of leadership study that are really valuable, first, I would say, is situational leadership. Situational leadership says that true leadership is, actually, an intersection of a problem or opportunity and someone who seems to have a sense of what’s needed right now for that. What that means is not everybody has the leadership mindset in every situation. Which is why, I think, in especially Agile and the collaborative approach to things is where we are always willing to pass the ball to somebody who is inspired at the moment or has some clarity at the moment about how to move things forward. I believe in situational leadership at the micro‑level. What that means is, also, we don’t want to have a scarcity idea about leadership, like we think of leadership or leaders as only some people can do it. This idea of situational leadership and even micro‑situational leadership is an abundance notion. Everybody can contribute something, some time, in this situation. I’ve got two others that I’ll talk about, but I don’t want to take all the air space here so I’ll shut up for a minute. The Integrity Police Clayton: Let’s go on a tangent real quick. There’s something that you folks had recently called the “integrity police.” Christopher: Right. Clayton: The idea of having someone on the team, I like the way you describe them as they remember everything, all the explicit and implicit things that everyone said and did and they can call things up. I guess, they are like the fact check people. I’m curious to where that idea came from and you’ve got any negative feedback because a lot of people, I could imagine, they would think that’s like the “jerk” person on the team that no one actually likes. I was curious if you had anything negative from that post. Christopher: Sure, where it came from was, actually, from qualitative research back in the 1990s in supply chain partnering between customers and suppliers in the semi‑conductor industry, when the US tried to regain market share that was sliding overseas. The issue was that in Asia, the supply chain was very tightly integrated and in the US, it was very ragged. The strategy was to create trusting relationships at the boundaries of customers and suppliers. I did a tremendous amount of work in the arena. Simply by interviewing people about what was working, this story kept coming up, over and over, about people who would say, “We can’t screw them that way,” or say, “You can’t do that to us.” Somebody called it the “integrity police,” one of our interviewees, so it was simply a phrase that stuck. One piece of negative feedback about someone, they love the idea, but didn’t like the word “police.” Clayton: I guess, I could see that having some negative connotations in some realms, so that makes sense. Drew: Christopher, you talk about one pathway to leadership is somebody having some clarity on a specific thing and taking responsibility and ownership of that. What are those other two paths that you talk about? State Research And Leadership Christopher: That path is of situational leadership and it’s one of the extremely promising arenas of leadership study over the last 20 years or so. The other two are state research. Remember I said, “Traits have been debunked.” Clayton: Right. Christopher: …it’s their qualities. State research says that there are more mental states that are more resourceful and mental states that are less resourceful. The state research on leadership says that people that exhibit leadership tend to get into a mental state of the leadership mindset, which I… Christopher: …responsibility process, which I call taking ownership, getting to that place of feeling a sense of ownership for something that you may not have assigned. It may not be your accountability. Like you guys… Christopher: …at least at Gangplank, you guys have taken ownership of changing the way societies or communities support entrepreneurship. Nobody assigned you to do that. Nobody gave you the authority to do that. It’s a sense of ownership. The state thing is useful. That’s where my responsibility process and what I call the leadership gift comes in. That is that you can actually change your mental state to one of more self‑leadership if you want to. The third area is servant leadership, which we all know pretty well… Christopher: The servant leadership research is really quite strong. Those would be three areas that I would recommend thinking about, in terms of developing your own leadership, is situational leadership, is “Where are you drawn in terms of having some clarity about what needs to be done”? Follow that. Who knows? Follow your intuition. Follow your inspiration. Follow your initiative. Secondly… Christopher: …learn how to move yourself to a resourceful mental state where you can feel free and powerful and generate choices. Then third, servant leadership is… Christopher: …notion that there are no more problems in the world. There’s only messes. Today’s opportunity is find some huge mess that you can spend the rest of your life trying to help this world clean up. That’s called servant leadership. Clayton: It seems like situational leadership is something that occurs naturally in people and the state leadership might be one that’s a little harder. Roy: Isn’t situational more one of awareness of what the situation is? There’s a great quote by Susan Scott in “Fierce Leadership,” where she says, “The person within a group who is able to stay at the closest version of reality to the truth, often becomes its leader.” Is it like that where you’re just really aware of what’s going on and are able to generate insights and draw that out of people? Christopher: Absolutely, and that’s a section of situational leader… Christopher: …and state leadership… Christopher: …because… Christopher: …leadership is somebody gets to that point of clarity. That point of clear thinking. State, the best case of reality, or however you said it, I love that because I agree with that. Situational leadership is not something that you can design or plan for like, “Well, that guy, Roy, is going to be perfect in that position.” No, it’s an emergent thing. We find out that Roy was perfect in that position, only afterwards. We thought Roy would be perfect in that position and Clayton… Christopher: So situational leadership is, actually ‑‑ it’s never predicted. It’s an after‑the‑fact recognition. Drew: The state one is more something that is predicted or planned for or that you can work on. Is that what you’re saying? Christopher: Yeah, something you can work on as an individual. I believe that 90, pick a number, but 95, 99 percent of leadership is self‑leadership, where you are getting in touch with our integrity, your own truth, your own authenticity. That makes you more powerful, more clear, more in touch with reality. That makes other people want to follow you into that for that to work. I’m really tired of all the focus on leadership about being influence and persuasion and getting people to do what they don’t want to do. I think, that is very industrial‑aged, mechanistic‑aged, kind of stuff. Clayton: We are about out of time here, but if someone wanted to learn more about all the stuff we’ve been talking about or more about you, where could they go and what would they find? Christopher: Well, thank you so much. I’m pretty easy to find. My website is christopheravery.com, or just search on my name Christopher Avery and the word “leadership” or the “responsibility,” and my results will fill the page. I’d like for people to get in on the leadership program, free preview webinar. So just go to my website, find in the resources section the free previous webinar and sign up. You can, also, download a free responsibility process poster. We’ll be doing a webinar somewhere mid‑September… Christopher: …and tell people about that program. Thanks very much for allowing me to share that. Clayton: Sure, and as always, we invite the guests to check us out at the Facebook Fan Page at facebook.com/agileweekly. You can discuss this episode and past ones as well. We just wanted to say thanks again, Christopher. We really appreciate you coming on the podcast. Christopher: Well, thank you, Clayton, for what you’re doing at Integrum and, also, at Gangplank. It’s just fabulous, so thank you very much. Clayton: Thanks.

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly Podcast I’m Drew LeSueur. Jade Meskill: I’m Jade Meskill. Roy vandeWater: And I’m Roy vandeWater. Drew: With us today we have Peter Armstrong co‑founder of Leanpub. Hi Peter. Peter Armstrong: Hi nice to be here. Drew: Hi. Peter we’ve read a little bit about you. We like the idea of Leanpub and how it fits in with Agile. Can you tell us a little bit about Leanpub? What it is? Why you started it? What Is LeanPub Peter: Sure. I’m the co‑founder of Leanpub. Leanpub is a way to self publish in‑progress eBooks. At Leanpub we believe that the way most books are made today is pretty broken and that Lean and Agile approaches should be applied to the process of writing and self‑publishing an eBook. So that’s why we created Leanpub. Drew: Great. Reading a little bit about you, you’ve got a software development background. Is that right? Peter: Yeah, I was a programmer in Silicon Valley for about eight years, and I live in the Vancouver, BC area in Canada. Drew: How did you catch on to Lean or Agile software practices? Peter: In terms of Lean for software I sort of, being sympathetic to the Agile, I mean I read the “Agile Manifesto” along with everyone else, you know. As a software developer you realize pretty quickly that lots of the ways you build software Agile makes a lot of sense for. When I started writing my first book, “Flexible Rails,” I sort of used similar approaches where I’d self‑published it in Progress, and I sort of hacked together my own workflow that made sense for that. I had a secret URL where you could download it. I had a GOOGLE group for feedback. I self‑published it in Progress, kept updating the book at the URL. I basically cobbled together a workflow that I felt made sense and that let me iterate, let me get feedback from my customers, who are my readers, and do something similar. Nothing existed like that in the book space when I was writing my first book, so we’re sort of fixing that with Leanpub. Drew: Cool. Even before Leanpub existed, you wrote your first book in the Leanpub way, is that right? Building Tool Out of Own Needs Peter: Yeah, I did. Leanpub was kind of the tool that I wish had existed when I wrote my first book. Because when you think about it there’s lots of do‑it‑yourself approaches, like even back then or now. I used Lulu because Lulu, obviously everybody knows it for print books, but they also sell pdfs, since I was like it’s 20 percent for a store front, but whatever, I don’t feel like building my own storefront just to sell a download, right. Of course now of course, if you want to sell a download yourself there are services such as Gum Road, you know, E‑junkie and all of the equivalent that do a good job of doing that, right. But there’s a lot of stuff you have to do if you want to sell an in‑progress book. You have to, provide updates, you have to build a community of readers, you have to do all these things, and you also want to produce a book. Back in 2006, writing a book, the tools were pretty terrible. I used Open Office on a Mac, and I’m not sure, you sort of laughed… [laughter] Peter: You can imagine how bad it was in 2006. My book got to about 200 pages and I could maybe edit three pages before it would crash. Then I switched to Word and that was really…I mean, Open Office had the benefit of, you know you could make a table of contents and stuff. When I switched to Word, I could not really, there were all sort of separate files for chapters and the whole things was a mess. I mean, this is 2012? We’ve had books for about 500 years, we’ve had computers for decades, and like there’s no good way to write a book? It’s pretty terrible. At “Leanpub,” we’re kind of everything…we want to be sort of the offices of the keyboard, but with their laptop, we do everything else, and then there’s a reader. Everything between the author and their words and the reader should just magically happen, right. For us the best way to write is Markdown, and we’re like why can’t you write a book in Markdown? OK, well one answer is like you want to have lots of files. OK. Have a list of files, call it “book‑dot‑text.” Tada! There’s your book. Right! You should be able to just sit there, write in Markdown, click a button, a book appears and then you click another button and it’s for sale. That’s how easy it should be. Jade: Awesome. Peter: You really boil it down to that. We tried, we iterated a lot with “Leanpub.” At one point we were using Git and GitHub, and you’d add us as a deploy at GitHub, and that is a little elitist because if I have to explain that I’ve immediately eliminated 98 percent of humanity. [laughter] Peter: The other two percent I’m going to have to support Git? Like, no, sorry we’re a bootstraps start‑up. So, figure out, write in Markdown, sync with DropBox, click a button. It’s like, yeah, that’s the way books should be made. Drew: Yeah OK, that’s the way books should be made. That’s pretty cool. Have you experienced doing that like developing a book as a team, as well? That seems to me like in the past you’d have to email a word document around. Peter: I know one of our authors he’s doing a book with a lot of collaborators and he’s doing a new version. Dropbox seems to help him a lot he’s very big in the Agile community. For me, I’m kind of, I don’t like writing in a theme for me, writing is like more individual than coding. Like coding, if you want to do anything meaningful you do it as a team because it very rare that one person can grade something. But for me, writing I tend to write by myself don’t know it more…yeah. I mean drop box is great for sharing. Some authors have wanted to experiment with collaborative editors like for example using Google docs to collaborate. But then like right now there’s no good way of sort of live editing documents. I’m not going to claim that Leanpub makes that awesome. Like drop box is OK if like you and I are sharing a document and were kind of taking turns and what not. But if we are all going to be in there you know what was that line from the “Fantastic Mr. Fox?” Cluster cuss? I think would be the right word. Drew: All right, so I think it is great you’ve taken the Agile principles and applied it to something that traditionally people wouldn’t think of with book publishing. In your life or your experience have you applied it to something else and seen good results. Peter: Let’s see, well, we researched the company that created Leanpub we’ve used those approaches. We’ve evolved. We’ve used those approaches in our consulting. We like to use Agile approaches which is our client work. In my own life, well in some ways if you think about you know when I went to university I started off, I changed majors a lot. I was everything from psychology to philosophy to economics before I ended up with a double major in computer science and psych. I sort of…if I did well at it, I tried and sort of pivoted my way through my degree. Like I ended up three elective short of two complete separate degrees. I had so many electives. I took like six years worth of classes in five years, you’re only supposed to take four years. In my career I found that I’ve never once been able to predict where I’ll be five years from now. If you develop a five year plan of what you’re going to do you sort of lock yourself in. Then you’re going to miss all the opportunities it’s like “pump man” being up‑winded. I think that’s what he called it. So we try to be pretty opportunistic with you know how we’ve grown lean pub and how we’ve if we think something’s the right thing to do, we do it. If I say something and then a day later I say something that is completely opposite, we change our minds a lot I have to change my mind at lean pub it an idea meritocracy. We do what we think the best thing to do is and if that means that were doing something and then we decide it’s wrong we do something different and that’s OK. Drew: So how do you think that embracing a Lean thinking and Agile philosophy, how’s that helped you in developing the actual lean pub platform itself? The Community Is Powerful Peter: One thing I really like is our Google group. We have a community of authors on a Google group and we have a couple of ways people can communicate with us. We have a whole email that goes to everyone at lean pub and we have a Google group for us. I think I’ve found the Google group has helped us so much. We get a sense of not only what is important to our authors but what you get from whole and lean pub as well. But you see people offering suggestions developing. People come up with all kinds of things like offering coupons to the Leanpub authors like doing like sharing ideas. We found that having a community around your product is so important. We’ve had a couple people ask us, “Hey, can you do one of those web‑based tools that lets you prioritize feedback?” We’ve said, “Yeah, we understand it,” but we resisted it because you go to a group right now for us. So it gives us I think the sense of what the community wants and where they think the product should go. We have our own sense of where the product should go, and they’re pretty similar. We use Pivotal Tracker internally for our backlog, but we have a gigantic backlog. I don’t think anyone’s solved that problem of backlog management really well. It’s an icebox. We’re a gigantic icebox. [laughs] Yeah, so trying to figure out what to do next, we have pretty good clarity of what the most important things to do in the next month are. But what will we be doing six months from now? I’m not sure. Drew: So what would be some advice that you might have for, say, I’m an author and I want to get started writing my wonderful work that I’m going to share with the world? What advice would you give me that falls in line with your manifesto and your Lean thinking? Stop Delaying and Start Starting Peter: The biggest advice is click the publish button. There are some in Leanpub that would sell, that have people queued up waiting to pay and that are really good and should be read right now. They haven’t been published yet. Let’s say you’re writing a programming book. If you have a programming book that you think will save someone who’s relatively good a couple hours, click the button because if it’ll save them a couple hours, it’s worth it right now. Even if you’re hit by a train tomorrow and you never write another word, right? Because if they bill their time, saving them two hours is worth a book, and in an office you’ll save them 20 hours. Also, if you publish really early, I’m talking when you have two chapters written, then you evolve it in public. You get early adopters for your book because your book will probably go in some directions that you hadn’t planned. The feedback will help you pretty clearly understand. Are you targeting it right? Is it too advanced? Is it too basic? Are you annoying readers with explanations of stuff they know, right? Are you not explaining something you need to? If you publish it really early and it’ll iterate in public and get feedback, you’ll get a better book out of it. Also, as you go, Twitter’s a wonderful thing, right? Readers will be tweeting about your book. You’ll get momentum. When you think about when a company open‑sources something that they’ve worked on for a long time and it fell flat, like thud…like “Oh, here’s this big thing,” and you compare that to, say, Linux, right? You think about if you’re going to get a community around it, you need to release it when it’s really early, like before it’s even good. [laughter] Drew: I like that. Before it’s even good. Roy: Yeah. One of the XP guys had a great quote that says, “You should be embarrassed about your first release.” Drew: [laughs] Yeah. Peter: Minimum viable product, right? Drew: Yeah. Peter: When it’s really early, really rough, but contains the core of…if someone reads this you’re being credited with releasing something that you don’t plan to…you’re not some scammer. You’re not watching a title page. You’re watching something with actual content there and a direction, and you want people on board that will be interested in where you’re going. That’s I think the biggest advice. Launch early. Roy: Great. I think that’s awesome advice. All right. Well, thanks a lot, Peter, for joining us today. Do you have anything to share with the listeners? Peter: Well, OK. At Leanpub.com we just put a video up actually. If you just scroll down, we have a bunch of videos. We have a cartoon with cartoon animals talking about making books, and we also have a new video about why Leanpub exists. This has the honor of being the first Leanpub video with any production values at all. Drew: [laughs] Peter: Audio for once. So yeah. Check it out. I’d be curious to see any feedback on that. Yet, also just join the Google group. If you’re interested, even if you’re not writing a book, go and sign up. Go to Leanpub, find the Google group, and join. It’s an interesting place. Roy: Great. Drew: Awesome, thanks.