Jade Meskill: Hi. Welcome to another episode of the Scrumcast. I’m Jade Meskill. Roy vandeWater: I’m Roy vandeWater. Chris Coneybeer: I’m Chris Coneybeer. Derek Neighbors: I’m Derek Neighbors. What Is The Right Iteration Length Chris: I was reading an article this morning by Todd Landry, called “What is the right duration length?” He was bringing up some experiences that he had in trying to discover what the correct duration length is. He says that when they first started forming an agile team, they were new to the concept. They figured they’d do one week iterations. They’d have a really quick feedback loop and be able to adjust as quickly as possible. He says they did that for a little bit. They felt that the overhead of all of the scrum ceremonies for one iteration, got out of hand, so they increased it to two week iterations. He felt that that worked a lot better for him. He says around the holidays they started an iteration where they said, “Well, we can’t really do a real iteration, so we’re going to start now, and we’re going to end when the last person leaves the building.” It ended up being about a four week iteration, and he says that that was a complete nightmare. Roy: Yeah, it sounds that way. I was about to unleash on that one, but… [laughter] Positives Of One Week Sprints Roy: At Integrum we have done a lot of one‑week sprints, and you guys have all been a part of those one‑week sprints. What do you think, what was the positives from doing one‑week sprint? Chris: I think some of the positives were that the ceremonies were very targeted. We had to learn how to keep them under control. I think that’s something the teams go through is that they don’t do a good job of making sure they keep those ceremonies under control, and that’s why they get so much overhead from them. Derek: Yeah, I tend to agree. The number one thing that I hear from people is that the overhead on one week sprints is too high. The only ceremony that I believe has that amount of overhead is, really, the sprint review including the retrospective. The main reason that I say that is planning should be a rough estimate of a percentage of time in your sprint. If you’re doing a four‑week sprint, you might spend an entire day. If you’re doing a two‑week sprint, you might spend a half‑day. If you’re doing a one‑week sprint, maybe you’re doing two hours. I think that what happens is a lot of teams doing one‑week sprint spend a whole day planning, and that’s where they feel the overhead is. I think they’re just being inefficient in how they plan. I, actually, think it’s poor planning that hurts one‑week sprints, not that there’s too much overhead. We’ve played with this on and off. On the retrospective side of the fence, say, we’ll only do the retrospective every other week, or do a light version of the retrospective, where we at least catalog real quickly some high level frustrations, but don’t dig too deep. Then, on the opposite week, dig a little bit deeper, and spend a little bit more time during that. From a demo perspective, which is really the other element of it, you should be demoing your work pretty much as you complete it. You shouldn’t be building up a whole lot of sprint demo time to begin with, so… Roy: I think there’s a lot of teams that don’t follow that particular piece of advice, where they’re demoing constantly. Jade: But even if they’re not demoing constantly, if they are only demoing one week’s worth of stuff, then their demo shouldn’t take the same length of time. Deploying Is Painful Derek: I think another thing that kills people too is there’s this really bad stigmatism that you have to deploy when you have an end of a sprint. A lot of teams, deploying is very painful, and so that eats up a lot of time. It’s actually getting things deployed so that they can actually demo. It’s why I find, when there’s a poor build environment that, generally speaking, teams are less likely to want to do one week sprints, because the deployment for demoing takes up half a sprint. Roy: I always tell people that they need to unhinge deployment and releases from their sprints. Jade: However, I kind of feel like, if you’re doing the deployment every two sprints, then that kind of builds up a cadence. It does almost feel like it would make sense to… Roy: I think it’s nice, and it’s good if you can get there. But I don’t think they should be solely dependent on each other. Jade: I think in an ideal situation, you’re deploying as often as you’re demoing, which is daily, and you don’t have to worry about it. Roy: I think that’s a pretty highly evolved product or organization that can live in that continuous deployment world. It’s About Improvement Derek: I guess where I get really concerned is, I’m even OK, as much as I might bag on it, on a 30 day sprint, or a four week sprint, as long as a team understands that that’s a segment of where they’re at, not where they should be going. I get concerned when somebody starts with a one week sprint and then pulls back to a two week sprint, and says, “For us, just a two week sprint works better.” Because what they’re really not acknowledging is all the problems that are keeping them from being able to do a one week sprint. I see teams do one week sprints all the time, really, really effectively, which means it’s doable. If it’s not doable for your team, there’s probably other symptoms that are happening. Either you’ve got poor deployment practices. You have bad product ownership. You have poor planning meetings. A myriad of different things can be coming up that are preventing it from it. Sometimes when people kind of roll back to this less‑than‑ideal state, if they don’t do it with a, “We’re only doing this for right now until we can get better at the other things,” then I think that that’s dangerous. Downsides To One Week Sprints Jade: I think that there’s some huge downsides, too, to doing one‑week sprints. I’m sorry. Downsides to not doing a one‑week sprint, specifically when it comes to regards to research tasks. If I’m doing commitment during planning and during my planning meeting, I find out that I don’t have enough information and I need to write research tasks. If have a one‑week sprint, then it’s relatively low‑cost. I spend one‑week doing the research. In the following week, I can immediately do that task. If I have a four‑week sprint, that means I do the research task. That even means it’s four weeks until I do the research task. Then I don’t commit to getting it done until four weeks after that. It’s going to be eight‑weeks until that story gets done. Or I do the research task immediately, but then it would be four weeks before I, actually, address the story. Then it’s four‑weeks between research tasks. Derek: But, if it takes you nine weeks to deploy, that’s all OK. [laughter] Retrospecting Your Way To Better Chris: Something that we’re talking about is that some of these teams that we hear when they’re doing one‑week and then they go to two‑week, how many times do we hear it’s right in the very beginning? You’re talking about retrospecting, realizing, “What do we need to change,” where they’re getting used to this, so it’s probably talking them longer than it would. Are they really retrospecting, going, “Are we getting better at this? Can we stay at one week?” I have some questions in regards of what did the team think of and why did they go to two weeks? Derek: Too much overhead. Consistent Delivery Requires Discipline Roy: I think it’s reduces that pressure like Derek’s saying. Doing a one‑week sprint requires a lot of discipline, and a lot of willingness to introspect and really pay attention to yourself. When you see people getting really uncomfortable with that, it’s because they’re trying to get a little bit more of a buffer to feel a little bit safer. I think that’s OK in the early adoption phase. But like Derek said, if you just get stuck in that rut because, “Well, that’s just what we do,” I think that’s a bad place to be. You should really be trying to challenge yourself, but I think that’s reserved for teams that are a little bit more mature. Jade: With longer sprint‑sizes, you’re increasing the risk in a self‑organizing team. Because when a self‑organizing team comes up into retrospect, and comes up with an idea and they try it, in a one‑week sprint, they can cancel out that new thing to try within one week. But if you have a four‑week sprint, you’re stuck with that for four weeks. That can be devastating to the company. Roy: You could also do retrospectives disconnected from your sprint. Chris: That’s true. Decomposition Of Work Is Critical Derek: I think, as an industry, most people are doing two‑week sprints. I don’t know many people that are really on a 30‑day or four‑week cycle, but one thing I’ll say that I noticed with almost every team I encounter. The teams that like two weeks sprints only can pull in two or three stories, generally, per sprint. When they task out to do their commitments, it’s usually in terms of days. I don’t mean ideal days. I mean, “Well, I’m going to work on this task today. Tomorrow, I’m going to work on that task.” When I see teams that are OK with one week sprints, and actually prefer one week sprints, I usually seeing them pulling in three or four stories, at least per sprint. They’re pulling in tasks down to a 15 minute, nothing bigger than hour or two. I think that that gives them a lot more fine grain control over, are they ahead or behind schedule. It really helps to pick up pace. That’s not to say that people doing one‑week sprints complete more stories. That’s not the goal of bringing in more stories. But, they have a habit of decomposing things to a smaller level which gets them a better accuracy from a standpoint of when something’s going wrong, they know that’s it’s going wrong a lot sooner. It’s not because they’re in a one week sprint. It’s because they’re not having to wait until the end of the day to figure out, “Oh, I’m kind of behind schedule.” They know that by lunchtime of the first day. “I’m an hour behind. Or the team’s three hours behind.” It allows kind of those course corrections to happen within an hour of a sprint opposed at the end of a week, or at the end of two weeks. Shorter Is Better Jade: I think that we all agree that it seems like the shorter the sprint length or, at least in our case, we feel that a one‑week sprint provides the greatest ability to react to change to minimize the risk and offers a lot more advantages. Oftentimes, a desire to go for longer term sprints are a result of other pains on the team. Or other malfunctions within the team that cause them to shy away from that. Roy: I think you need to take the rest of the organization into account as well. I see a lot of challenges, sometimes, for development teams that are willing, and able, to go to one week sprints, but there’s some impediment at the organizational level that’s preventing them from doing that. I think… Jade: Product Managers. Roy: [laughs] . I wasn’t going to name names, but I think that does factor into that as well. It’s important for teams to be cognizant of that. Also, I think, try to work towards solving that. What’s wrong, or what’s happening inside the organization that’s preventing the other part of the team, the product owner, from being as responsive as the development team. Derek: It’s not just product owners, design too. Roy: That’s a whole other Podcast. [laughter] Jade: I think that’s it. Thank you for joining us. Chris: See you next time.

In this video we talk with Rose Hess-Nunn about what brought her to the User Story Class and some of the challenges she faces. The post Special Episode : User Story Class Interview with Rose Hess-Nunn appeared first on Integrum.

Derek Neighbors: Hello, and welcome to another episode of the ScrumCast. I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Perry Reinert: I’m Perry Reinert. Chris Coneybeer: I’m Chris Coneybeer. Communities In Scrum Derek: Today we’re going to talk a little bit about “Communities in Scrum.” One of the things every team struggles a little bit with is, “How do you get outside of just your team”? Meaning, you can inspect and adapt all you want. But if the only model you have is your own, you probably are not going to inspect and adapt nearly as much as if you were influenced by other teams, other models, coaches, et cetera. How do we get outside of our own insular team, and how do we get into a larger community? How do are you guys seeing people engage in community around Agile and Scrum currently? Chris: For us, here at Integrum, we actually participate in the local user group, the Scrum Alliance user group, which is something where we get to meet people all throughout the valley here in Phoenix that are involved in Scrum and we get to talk to them about some of the issues that they are having their implementation and we get to learn from them. It’s very beneficial, and Roy and I were just at a last week and had a great time. Derek: Scrum communities are great for that type of stuff and even exploring some of the user groups that are for other Agile methodologies, like let’s say you’re doing Scrum, it definitely doesn’t hurt to try to attend somewhat on Lean or maybe Kanban type user groups as well to try to see things from another perspective, even if you have no intention of switching over to something like that. There’s a little bits and pieces or technical practices that you might be able to steal and apply to your team as well. Roy: I know a lot of communities have eXtreme Programming XP groups as well and that some of the bigger metro areas have XP groups. There is usually IIBA, Institute of International Business Analysts and PMI which both are starting to bring on some Agile methodologies. For somebody, that’s a good place, maybe not necessarily to learn as much, but to share some of what’s going on. Especially, if you’ve done a Agile transition recently, probably a lot of people going through similar things to be able to share experience and share stories with. There’s a ton in the way of good conferences and good ‑‑ I don’t want to say coaching opportunities ‑‑ but training opportunities out there as well, the Agile Open Series, the Open Spaces as well as Agile 2011. Maybe as part of that, Perry, you were recently at Agile 2011. What were some of the things that you saw from a community perspective that you really liked at Agile 2011? Agile Conference 2011 Perry: There was a ton of community. Just the way they structured the conference was really built around community. They had different stages. They had all sorts of different specific like birds‑of‑a‑feather type groups. After‑hours events were with those same various birds‑of‑a‑feather groups, and it was really cool from that standpoint. Finding A Local User Group Derek: For people who maybe live in an area where they’re not sure if there’s a Scrum user group, how would somebody go about finding a Scrum user group in their local area? Perry: For us, the Phoenix Scrum user group, it’s really easy. We’re one of the top searches. If you just go out and search for Scrum in Phoenix, you’ll find us on Google. But since it’s a Scrum Alliance‑supported activity, we’ve registered with the Scrum Alliance. Anybody can go out to Scrum Alliance, and they actually have a find‑a‑user‑group‑in‑your‑area link. You can look in your area and find a user group. We have a website, PHXSUG.org, and most Scrum Alliance‑based user groups do have their own website within their city. Derek: Definitely I’ve noticed a lot of LinkedIn groups as well that seem to be regional around Agile and Scrum, that’s another good place to essentially get plugged in as well as maybe looking at Meetup.com and some of other areas or even Facebook searching some events. Being involved a little bit in Phoenix SUG, tell me a little bit about what it entails. A lot of people may not have a local Scrum users group, and maybe they’re a little bit afraid to make the jump to actually run a users’ group. Maybe tell us a little bit about what it took to get one up and running and then what it takes on a monthly basis. What kind of commitment does it really take to run a Scrum user group, and is it worth your time to do it? Effort To Start And Run A Local Group Perry: First of all, I definitely think it’s worth our time, and I’ll back up to the beginning. Anybody can just start a group. Get some friends, start a group, and start marketing. The next step for us was to make it a Scrum Alliance sanctioned user group. What that allows you to do is to advertise on the Scrum Alliance site, post your meetings there, and it also allows you to use the Scrum Alliance logo with your web site. That gets you going. To get a website and have some page where you can post the date and the time and what the meetings are. In terms of the monthly work, what we’ve done is, we have a steering committee. That’s just the original four guys that started. We meet once in between sessions, once between the general meetings. We think about what it is that we’re going to do for the next couple meetings. It’s really about scheduling the next talk. Once you get the next talk done then it’s the marketing. Putting in a plug for InfusionSoft here. We actually have InfusionSoft. It’s an application that manages ‑‑ it’s really made around lead management ‑‑ but that application, we have a web form up that collects people that are interested. They give us their name and address, goes right into the database, and then they’re automatically sent the updates, every month, about who’s talking and what the topic is. For me to manage that is just incredibly…it’s like an hour a month now. Once that was setup, the form on the website to capture name and email, goes right into the database, and the emails go out automatically. Then we also advertise, we have Yahoo! Groups, and LinkedIn. We do some other postings as well. In terms of the actual amount of work during the month, if we all get together, then that’s an hour or so of generally pretty fun discussion about what to do, and we always get on some sort of Agile topic talking also. Then there’s the meeting, which is, we run them six to about eight, once a month. Finding Content For Meetings Chris: When a lot of people are trying to get user groups up and running, one of the questions that comes up a lot of times is content. How are you going to get speakers? How are you going to get somebody to get up in front and present? Are there any tips or tricks that you have for maybe four or five guys who are getting together and trying to start a group? Perry: Yeah. First of all, usually those four or five guys are good for one or two talks each. Get one to kick things off. What we were actually able to do…and if you are a new group starting out, you’ll probably have a good chance at doing this. We actually were lucky enough to get Ken Schwaber to come and give, I shouldn’t say come, he gave the first talk. That was actually a challenging talk. He did it remotely and in the end, for that one, we ended up holding a cell phone to a microphone to handle the audio. So, I don’t recommend doing a remote talk. Derek: A very tight inspect and adapt loop. [laughter] Perry: Yes. That’s exactly what it was. It’s great. If you can do that, and kick it off with a big name like that, that’s great. We had 80 or 100 people at our first meeting. That really helps get the word out and then market it. Our email list now, because we have that web form, I get five people every month that just sign up. That’s been going on for over a year. Plus, we started with a bunch. I think our list is 5‑600 people now that get the emails that say, “Somebody’s come, here’s the talk.” Special Guests Derek: Another thing that we’ve started to do that helps a little bit too is ‑‑ we’ve tried to make relationships with the CSTs that are teaching in the area. Whereby we help them promote their upcoming classes in exchange, at their classes, they let their students know that there is a community here. After they’re done with training that they can plug in to go look deeper is to participate in a group, helps quite a bit. Perry: Yeah, that’s really a good point Derek. It’s one of the things they love to come, give their talk…You’re looking at 20, 40 new people potentially and it’s also easy to get them relatively easy to get them to cough up a free CSM Certification as a giveaway and that’s always nice to have to. Restrospecting As a Group Roy: Something else that helps to, that I’ve seen, you guys have known for the last few meetings is having retrospect at the end of each one. So that the people who attend this Scrum user group actually get a say in how it’s going to continue and what pieces to keep and what pieces to throw out. So it’s not you guys guessing what we as attendees want, but actually listen to our feedback. Perry: I agree. That’s something we’ve incorporated actually relatively recently and it’s really working out well. Everybody likes it. What Are The Down Sides To Running A Group Chris: Speaking about the user group, is there any downfalls that you’ve had over the last year plus and anything that you would recommend? Perry: No, No. There is really no downfalls, the only challenge is that every once in a while you end up where you have a month like when you don’t have somebody scheduled and that always feel like, “Oh, we got to do something, we got to do something.” But like I said, if you start with that core set of guys, and as you start branching out, and if you let people know that you’re looking for speakers…We always have somebody who wants to speak and there’re so many topics out there, on fun stuff, on games, on just all the topics available. We always end up getting it. It’s not always a big name or a CST, but we always get it. It’s funny because a lot of those turn out to be really good ones, because you end up talking about something that local people want to hear and it’s not a canned talk from a CST. It’s real. Derek: Yeah, I would say, two of the best scrum groups I’ve have been to wherein the presenter was more of a facilitator in letting questions coming from the audience and then letting the audience talk about the questions and you’ve got some real scenario‑based takeaways and people got really engaged. I really encourage, even if you don’t have a speaker, just get another practitioners together and talking in a format is extremely beneficial. Perry: You’re absolutely right. Any meeting you can get, however many people, five people and say let’s build the backlog of 5 or 10 things to talk about and prioritize the backlog and pick the first one and start talking about it. You’re right. We’ve done that probably three or four times over the last year or so and those turned out to be really good talks. Derek: Any final thoughts or questions? Chris: Not from me. Open Spaces & Regional Conferences Roy: You’d mentioned earlier a little about Open Spaces and I think you’re talking about the [inaudible 13:42] one, and there’s few other Open Spaces. If you can find one that’s in your area and attend that ‑‑ that is really a great way, where you’re almost forced into meeting a whole bunch of people that are active. That’s where you’re going to find out where all the best user groups are and you’re going to meet a whole bunch of friends where maybe you’ll find out that there isn’t one in the area and you must get a group of friends at it to start one, if that’s what you decided to do. So, that’s really a great way to get started. Derek: There’s definitely one in Southern California](https://agileopencalifornia.com/san_diego.html), one in Northern California, and there’s one in the Pacific Northwest that alternates between Portland and Seattle, every winter, every February. All of them are really great opportunities. Perry: And I was going to add to that also, just get out there, all those user groups, go to conferences, go to open spaces, other users groups that are related that aren’t even necessarily agile user groups. If you go to those groups, you’ll meet people and you’ll be surprised because there’re lots of people going to non‑agile, non‑scrum user groups that are actually really interested in agile, and scrum and those technologies. Derek: One of the things that you think Scrum user group is doing in accordance with the scrumcast is we’re publishing interviews after every one of our meetings and they’re available on iTunes, as part of this podcast. It gives you the idea of who attends user groups and the stuff that is important to them and makes them tick and we’d love for you to share what your Scrum user group is doing, if you got one as well. Thanks very much for joining us then, we’ll see you next time. Perry: Thanks.

In this video we talk with Sandra Bufford about what got her interested in attending the User Story Class. The post Special Episode : User Story Class Interview with Sandra Bufford appeared first on Integrum.

Clayton Lengel‑Zigich: Welcome to another episode of the Scrumcast. I’m Clayton Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. Clayton: Joining us today, we’ve got consultant at Industrial Logic, Adam Sroka. Welcome, Adam. Adam Sroka: Thanks for having me. Software Craftsmanship Clayton: Taking a little back straight to the audience, we met Adam at Agile Open in California few months ago or weeks ago now. You had some interesting things to say about some kind of things in the software craftsmanship, maybe more of the technical side of things, so we’re curious what you thought about that. What do you think of the software craftsmanship movement or how that’s affecting the industry right now? Adam: That’s an interesting question. For the most part, I’m a fan of the software craftsmanship movement. There’re a lot of really good ideas coming out of there and people really pushing some things forward that I think came out of extreme programming that maybe have gotten neglected by a lot of folks in the community as they go other ways. Software craftsmanship is backlash is against that. Although, sometimes I have to admit I feel they go too far the other way, pushing against the Scrum. Kill all the managers, kind of thing. But I think that we really do, as a community, need to focus on being technically competent because it’s so important to what we do. Especially, look at Lean Startup and those kind of things, how they are really pushing the boundaries of what we can do as businesses based on having these technical disciplines. We are going to have to practice those to get them to that level where they are really going to make money for people. Getting Started With Software Craftsmanship Clayton: Let’s say that I’m a developer and I’m working on the Scrum team or in some Agile team or whatever, I am interested in the software craftsman thing, but I don’t really know where to get started. What’s a good first step? If I want to improve my technical skills, for instance, I say, “I realize I may be deficient. I want to get better. Where do I go next?” Adam: There are a lot of good places you can go. I think it depends somewhat on language, what environment you work in because there are some really good books out there. There are really screen casts and stuff where you can watch the way other people work and learn from them. Just as a minimal investment kind of thing, just getting in where you are. Then of course, if you’re willing to travel and go and meet people, there’s some excellent software craftsmanship oriented conferences now. There’re lots of code fests and those kinds of things, so there’s community opportunities to learn from other people. Even people who are really willing to invest a lot, have gotten into this touring craftsmen idea. It really depends how much you want to put into it, but the resources out there are really amazing. Compared to when I first started programming, I don’t really have any of these things out there. I had to figure it out on my own. It’s really cool nowadays. Reducing Technical Debt Clayton: If I flip that question on its head and say, what I am say, a Scrum master or a product owner, or something. I realize my team’s generating lots of technical debt. We have lots of defects, and we were not testing. I hear about all these things when I go to user groups, but my team’s not doing them. What are some ways that you could drive that from that side of the equation to try and help people who are on your team become better in a technical sense? Adam: Sure, it’s challenging. A lot of folks find themselves in a position where they’ve been developing on some project for a really long time. Maybe they more recently adopted Agile, and they feel like they don’t really have a lot of this. They say, “Oh, all this tester and development stuff and everything, that’s really cool. But there’s no way that it will work.” Sometimes you’ve got to build incrementally towards it, and try little things. I don’t know that there’s one right or wrong answer of how to start there. It helps to have some skilled help, to get a coach. But you can do a lot just by experimenting and seeing where you are, and definitely measure it. Pay attention to what you are doing, and measure the results. How long are you spending re‑factoring in the red, and those kinds of ideas. If you invest in figuring those things out, then you have metrics on which you can improve. I think that’s the area that really is pushing the boundaries that we really need to get more into as a community. Touring Craftsman Clayton: A few minutes ago you mentioned a term that I didn’t hear before. You mentioned a concept called a “touring craftsman.” Would you mind explaining a little bit about that? Adam: Yeah. I don’t know where that started, but it’s become popular in the craftsmanship community. Particularly in Europe, I think it started more in Europe. There are some folks around here, Corey Haines, in particular. He left the job and toured around the country in his car going from shop to shop volunteering his time working wherever they would let him work. Now, others have copied that. In Europe, they have this idea of industrial tourism where like two companies will actually just swap people for a brief period of time, so they get exposed to the other environment, get to bring back new ideas, challenge some of their own assumptions about how they should be working, that sort of thing. I couldn’t send you straight to any of the links, but if you look at like the software craftsmanship Google group, there are folks in there talking about doing it. I think some people have even been talking about putting together a website where you can kind of list the companies who are willing to participate in this. Industrial Logic has been doing it for a while, very informally. Anytime you’re up in the Bay area, you can show up at the Berkeley office. If Joshua or anybody is in town, you’re welcome to compare or pair on our code with us, that sort of thing. It takes a lot of different forms, but that’s the idea. Common Technical Excellence Anti-Patterns Clayton: In your experience, doing some consulting, working with different teams, things like that, what’s a common pattern that you see that kind of violates some of the eXtreme Programming XP principles or maybe violates some of the kind of technical excellence stuff? What do you see a lot of teams doing? Adam: There’s a lot of different ways to go with that question, but the one that I guess I’ll focus on because it bothers me the most is your teams adopt Scrum coming from something else, whether it’s just sort of a hacking environment or a cowboy coding type of thing or a more formal like waterfall process, but they come into something like Scrum and they’re told we got to have shippable software every two weeks. Then what they try to do is they try to take whatever they did before and shrink it into two weeks. It just doesn’t work. That’s just not the right way to look at the problem. It’s not the right way to solve the problem. Figuring out how to get to smaller resolutions, when we’re working really the way at least Agile craftsman like to work where it’s truly TDD or BDD, so you’re working very tiny cycles and you can compose those tiny cycles into much larger changes, but they happen very incrementally. That mode of working is so vital to being able to really realize the benefits of what something like Scrum is promising. That’s the thing I wish more people were aware of and more people were focused on. We don’t just want to bang it out in two weeks. We want to get disciplined at working in these tiny increments. Clayton: Yeah, that’s a good point. I think we see a lot of people that are told that they have to start doing Scrum. You’re right, there isn’t a lot of direction from a technical setting. That’s kind of a thing that’s becoming a little more pervasive in Scrum or in other Agile communities. It’s not enough just to say that you’re going to do this methodology. There are some other things that go along with it. That’s a very good point. Adam: I like the way David Anderson puts it from the Kanban site. He made the point that if you estimate two weeks’ worth of work and you expect to get those done in two weeks that should happen about half the time because there should be statistical normal variation in your estimates. Aiming for two weeks’ worth of work is kind of missing the point, need to do something different to get two weeks’ worth of value. Software Craftmanship Gone Too Far Clayton: In the introduction you talked about some people may be taking the idea of software craftsmanship too far. Where do you see the downfall or maybe some pitfalls of software craftsmanship or maybe some things that people who are not as nuanced might be getting misled? Where do you see the problems or the side effects? Adam: I really have a lot of respect for the people who are sort of the leaders of the software craftsmanship [indecipherable 09:49] right now. I think that they have the best intentions and they’re working in the right direction. Where I would caution people, is anytime you get a new sort of movement, it tries to differentiate itself from the thing that came before it. There’re a lot of sort of anti‑Agile or post‑Agile ideas coming out in the craftsmanship community. I try to caution people about that. Craftsmanship really isn’t saying anything particularly new, at least the underlying principles were there in XP since the beginning and probably in whatever came before XP as well. It’s not like, “Throw everything else because here’s this new thing.” It’s another piece of the puzzle. It’s another way of looking at things. It’s valuable that way. But, don’t say, “Oh, you know, I’m a craftsman now, so I don’t need iterations or I don’t need to have a Scrum master or whatever.” That’s taking it a step too far, I think. Introducing Software Craftmanship To The Team Clayton: Looking at it from another perspective of somebody who’s in charge of an Agile team, whether I’m the product owner or the PO of a company, and I’m seeing that they’re constantly producing unstable output that is defect ridden and is causing all sorts of problems. How would you recommend that that type of would motivate their team to start caring more about software craftsmanship? Adam: It’s tough. It’s a complicated question. It’s really a people question. So really you’ve got to get down into the details of, “Why are people doing what they’re doing? Why aren’t they doing something else?” In order to get that, you really need to bring in expert people who know how to uncover those kinds of things. What it really implies is does the company care enough about this idea of producing great software and not having defects and all these kinds of things? Does it care enough to invest the money it’s going to take to really get under the covers and figure out what that issue is? Because I really doubt it’s the fact that you’ve got an office full of professional programmers who don’t want to act like professionals. That just doesn’t seem plausible to me. I think there’s probably something more going on there. Software Craftsmanship Two Years From Now Clayton: Where do you see the software craftsmanship movement or the community? Where do you see that in say like two years? Which, I guess, in this industry is a long time. Adam: I hope to see a lot more of the same. I hope to see that there’s been some interesting movement in terms of tool support in some languages. We’re doing some actually cool stuff in Industrial logic in terms of being able to measure what developers are doing inside the tools and figure out, “When did they re‑factor? When were their tests passing or were they failing?” Some of that’s been around for a while, but we’re going beyond what we’ve had before and hopefully soon building some really new cool stuff. But, that’s sort of the idea, measure what you do. Balance what you’re doing to improve against what the measurements are telling you, you need to improve. That’s what I hope to see more of in a couple of years. We’re already leaning that way, but I think, also, maybe we’ve extended like the [indecipherable 13:24] metaphor as far as it’s going to go. Repeating the same thing over and over again isn’t going to get us what we want. What we want is to really measure it and improve it scientifically. Improving Technically Clayton: From a personal development or professional development perspective, what are some things that you can look back in your career, your experience that you feel really helped you improve either from a technical sense or from maybe the process sense? Is there anything you can pinpoint, any experiences in particular? Adam: Yeah, I think moving around a lot. There are good parts to that and there are bad parts to that. But, I’ve seen a lot in a relatively short career. I’ve been doing this professionally for about 13 years now, so I know a lot of guys who have been doing something like what I’ve been doing for maybe 20 years. But, they haven’t necessarily done more jobs than I have because I’ve just moved around a lot. That helps. It gives you a broad perspective. It gives you that consultant’s mentality of, “Yeah, this is where you are today. But, you could be at a better place if you tried this, that or the other because I’ve seen it.” That I think has been really valuable to me. But, it’s not the path for everyone. The other thing, too, is just continuing to focus on the technical side of things. There have been plenty of opportunities in my career where I could have gone to management side and maybe made some more money, but it has never appealed to me. I always wanted to stay in the details. I’ve been able to make a decent amount of money and have an influence in the community while staying technically focused and I think that if you want to do that, you should do that. Clayton: If someone listening wants to find you online or go to your blog or whatever you have, where would they go look? Adam: You can look for me on Google Groups (software_craftsmanship). I’m particularly active on some of them like the Scrum development and XP, Yahoo Group and I’m all over them. If one of them interests you, hop on there and you may see me. I don’t have a blog up right at the moment. If you Google my name, there’s some old ones out there on the bigvisible.com and a couple of other places. I should have a new one coming up sometime soon, but I don’t know the details of that yet. So stay tuned. Clayton: Is there any tool or a website or person or process or something that you’ve been real hot on or real excited about in the last couple of weeks maybe that you want to plug or let everyone else know about? Adam: I just recently started Industrial Logic, so I’m trying to get up to speed on things going on there. I haven’t been paying too much attention to what’s going on outside of it, but Industrial Logic is worth checking out. Are You Learning is excellent, particularly for folks working in Java, C#, C++. They’ve got some really excellent stuff there. Like I said, it’s moving. We’re trying to move it to the next generation where we’re really measuring what you’re doing and helping to give you useful feedback about how to improve. Clayton: Awesome. Well, we really appreciate you taking your time to do the podcast. We look forward to talking to you in the future. Adam: Yeah, thanks. Thanks for having me.

Alan Dayley interviews Doug Hall after the October 2011 Phoenix Scrum User’s Group. The post Special Episode : Doug Hall Phoenix Scrum User’s Group Oct 2011 appeared first on Integrum.

Jade Meskill: Hello, and thank you for listening to another episode of the Scrum Cast. I am Jade Meskill. Roy vandeWater: I am Roy VandeWater. Derek Neighbors: I am Derek Neighbors. Jade: We have with us a special guest today, Ainsley Nies. Ainsley Nies: Hello. [laughs] Launching Agile Teams Jade: All right. Ainsley has co‑written a book with Diana Larsen called “Liftoff: Launching Agile Teams & Projects towards Success.” Why don’t you tell us just a quick 30‑second overview of the book and what it’s about? Ainsley: Well, as you can tell from the title, the book is about starting agile teams right and projects, of course. We talk about liftoff as the primary way to do that. Liftoff is when at first get together that you have once a project has been initiated. Also, in that, we believe that chartering belongs in every lift off, although there are certainly many other things, activities that you can do during a lift‑off. Starting Project Right Matters. Project Chartering Helps. Jade: OK. Awesome. What was your motivation for writing this book? Ainsley: Well, both Diana and I had done some chartering independently and on our own. We had both found that that’s an important step to take. However, we’ve both been involved in lots of retrospectives. As you know, Diana has written and co‑writes with direct respective books. So she knows a lot about that. But, I also have been doing a lot within HP. One of the things that we discovered in just casual conversation, besides our interest in this, is that we had learned from doing as many. Literally hundreds between us of retrospectives that a lot of the things that come up. Especially repeatedly in retrospectives could have either been eliminated or mitigated had people really started their projects off right. When we say “right” we mean with some kind of chartering effort. We looked around and although, we both know people who have been talking about this for a long time. We didn’t see anything written or any way to share what we knew. So we decided to fill the void. Jade: Great. I’ve read an advanced copy of the book and really enjoyed it and have actually put quite a few of those techniques to use with great success. Ainsley: Wonderful. Project Kickoff Challenges Jade: What do you think are some of the biggest challenges when you are starting off a new project? Ainsley: As we always say, it depends. Many things can get in the way. The first, of course, is communication. For instance, one of the bigger steps in chartering, besides understanding the framework for it, is that the chartering process, itself, really emphasizes understanding, practicing, and communication. Learning to trust each other so that you can have good communication. Some of the steps throughout chartering actually emphasize how to do this. Communication is a big one. If you don’t have clear communication, none of the work you do during chartering itself is going to stick. We talk a lot about communication. We believe that chartering actually catalyzes the interactions needed to accomplish a lot of the project work. It accelerates the team in collaborating and communicating. The PAC Model (Purpose, Alignment, Context) Communication is really huge. There are more specifics, like common misunderstandings about what you are actually supposed to do. Again, communication is part of that. Part of our structure, we have something called the P ‑ A ‑ C ‑ model. The PAC model as part of our frame work. That’s purpose, alignment, and context. In Purpose, that’s where we cover the product vision, the project mission, and project measures. Actually, management tests, we call them. Understanding those three elements of the larger purpose is part of what creates that sense of knowing what you are doing. The discussions that are involved in understanding and developing each one of those elements of purpose also helps create that clear understanding of what purpose is. Purpose is inspirational and it should add be motivating for the project work itself. Part of the reason we focus on purpose is to make sure that people have a common understanding. Chartering Agile Teams Derek: You mentioned that you guys did lift off also addressing creating teams as well, correct? In the book? Ainsley: I’m not sure I got your first? Creating teams? Is that what you said? Derek: Starting off teams or chartering teams. Ainsley: Oh, yes. Because we believe that when a project first launches and all the initial steps are done. Somebody had a vision. This has agreed to finance the resources and the people to do it. There has been a sign off and you are ready to go. A team has been assembled. Then needs to be some and it usually always is some formal start that goes on. That is what we call a lift off. In order really to start the project right, we believe, you can do things like have activities in your lift off, performing skill development, a boot camp or some kind of team building. But chartering, actually that process in composes a lot of the team building work just in the act of doing it. In the specific to teams, besides understanding this alignment of purpose, there is also a larger alignment. That has to do with the team itself. Understanding what are working agreements, what are values and principles, who are we, what makes us up. Those are the three things to go in the alignment element. Not all teams go through this working together to understand this. Sometimes teams often have working agreements, of course, and those are operational things, what is the definition of done. That is excellent work that could go on. But understanding values and principles that the team holds and the project community, actually. It really speaks to the beliefs and ideas about how the work is done itself. Just like the manifesto has some values and principles back it up. It is the principles that really talk about behavior. As I said it is different than working agreements. A principle helps with decision making. If the team is stuck, say “How they are going to manage something or deal with a certain situation”? The principles are often there as guides. One of the principles that we used at HP in the Agile special interest group, in our work, was quality trumps expediency. That is the activity, even just having the team pull together to sit down and have a good discussion about values and principles. Helps align the team and the project community because everyone that has or shared an understanding of the work itself and how it is going to happen. Can Liftoff Help With Organizational Change Derek: I think a lot of people that come into teams do not realize how often an organization adapts something say Agile, Scrum, exTreme Programming (XP). Something that comes up front high, that we have seen in numbers of engagements. We have been into where a management says the want to do a quote on quote the agile and to management that means that stuff is going to get done faster and it is going to cost less money and the quality is going to be up. Then you talk to the project manager or the product development team or somebody doing the work, and they think of it as, “Oh, we get to be self‑organizing, and we get to be empowered.” We had talked to one customer or one client that when asked, “What are the goals of why you guys are even doing agile?” because they didn’t seem to want to actually embrace any of the agile principles or values. So we said, “Why are you even doing this?” Their answer was, “Well, because the CEO says that they want the agile implemented by the end of the year by all of the teams.” So if I’m in a company and I’m faced with implementing the agile by the end of the year, is “Liftoff” something that can help me maybe get the business side of the fence. The CEO, the CIO, and the project management team or the product development team to share its principles, or is it strictly really just for teams themselves? Ainsley: You could certainly do chartering at multiple levels. An adoption, an agile adoption is a project undertaking in and of itself. If people’s answer of why they’re doing it is because the CEO said so, that’s sounds like an adoption that’s going to have difficulty. [laughter] Ainsley: It sounds like there hasn’t been communication, and people haven’t actually sat down together to talk about much. The purpose itself of even the adoption isn’t clear. What was the vision for this? Because purpose is comprised of, as I said, vision, mission, and mission test. I assume it’s some high‑level executive that made this decision. What was their vision for? What did they see as a result of this? Then what’s the mission of this particular work team that’s got a product to deliver? Then what are the tests? How is this executive going to know or the executive team going to have any sense that this adoption has been successful if they haven’t even thought about that when they start? The team has no guidance. Agile Adoption As A Project Jade: I like what you said that agile adoption itself is a project. That’s a great way of thinking about it. Applying the techniques and the process that you outline in the book would be fantastic for a company embracing agile for the first time ‑‑ learning scrum, whatever it is that they’re doing ‑‑ to move themselves towards agility. That would be a great way to help them understand what it is that they’re doing, why they’re doing it, and how they’re going to get there. Ainsley: I agree because in a liftoff, say, for adoption, as I mentioned, you could do many things in a liftoff depending on what the intention is. So you could do some scrum training as part of the liftoff because ideally of course you have people together, physically together. Even though some parts of the team may be distributed, if they’re ever going to be together, it needs to be during the liftoff. So you could get your training done in any other of that team building stuff as well as the chartering. Which helps the team form not just in a standard team‑building exercise way but in a much deeper way because of the things that we cover. The fact that dealing with not just the purpose and alignment…We haven’t even talked about context yet, which is very critical and probably one of the pieces of chartering that’s…The impact of understanding context is probably the less recognized of the other two pieces that I’ve talked about. So you could really design your liftoff to cover a broad spectrum of things while everybody’s there physically together and leverage it to the absolute best. Jade: Yeah, that’s great. I worked with a team recently, like I said, using a lot of these techniques, and when we talked about context and drew out the context map and diagram, it was fascinating. All of the issues that have not been thought of, all the communication pathways we’re just assumed by certain people on the team, and other members of the team had no clue what they were talking about. It was an incredibly useful exercise that was really, really important for that core team. Ainsley: I’m glad to hear that. Jade: I found that very valuable. Benefits Of Understanding Context Ainsley: That’s great. That’s great. Understanding context is so important. It really helps define the limits. The boundaries so much depends on that that people make assumptions about it. Jade: Yeah. We like to talk a lot as a company about restoring humanity and bringing more humanness back into the organization. As I was working with this team who was a newly formed team who had known each other for many, many years but had never really worked on a project like this, I took them through a lot of these exercises. It went from a chore to something that was really enjoyable. Watching them gel as a team over the week that I was there coaching them, talking about shared values and principles was just a really incredible experience. I got a lot out of it. The team got an amazing amount of value out of it. It really set them off on the right foot. The project is moving forward, going strong, and I think a lot of it does have to do with that good solid foundation that they were able to start with. Ainsley: I’m glad to hear. That fits with most of the experience we’ve had using these techniques. I must say hearing you talk about it, my guess is, because this is certainly what I hear from other people too, is that as you facilitate this, you can’t help but start to internalize some of it yourself and take a look maybe at how you think about things, “What are my values about work?” Things like that. Doing the work itself and facilitating other people, I think, also adds value because you get a chance to reevaluate yourself, do iteration through yourself while you’re doing it. Jade: Yeah, that’s great. Do you have a good story or a good experience that you could tell us of a successful liftoff that you’ve been a part of? Ainsley: Mine are pretty old for what I was doing at HP. Diana has a very recent story, so it has used the techniques that we’re talking about here, specifically. What her undertaking was an adoption kind of situation. I can tell you that they had multiple teams because this was a very large project with a number of teams. All the teams sat down, and did a basic charter for themselves. The scrum masters got some training individually about how to facilitate this. They all sat together in one large place as a group, and did their chartering, each team. And then got together afterward, and did a discussion about what each team had done, and how they compared and contrasted with each other. This was in a very large company, and it’s gone on. They are continuing on this project, and it’s been successful so far. That’s kind of an adoption story. Applying Liftoff To An Existing Team/Project Jade: What do you think about if we have a team that’s already been formed, we’ve already been moving forward on such‑and‑such a product or project? How does the advice and the techniques from your book come into play for a team that’s already halfway down the road on this project? Ainsley: In a way, every time, as with many other things in Agile, anytime there’s new information, the charter needs to be updated. It’s a living document, once you’ve created your charter at the beginning, it’s an initial pass. The assumption is it will be updated whenever there’s new information. So as you’re working through, as with working agreements, once you’ve got them down and useful, you usually roll one out and bring in a new one, right? Because you have to remember it, it goes up in your big, visible chart. The same is true with the values and principles, or with anything else in the charter. Your context diagram changes, at least that’s been my experience, as work goes on. You wind up working with new people in different ways, the exchanges are different. Whenever there’s any kind of flow change, you want to change that context diagram as well. Jade: If I have a team that…Let’s say we didn’t go through this at the beginning of our project, do you think we could at some point…Say we don’t have the vision, and mission, and mission tests, do you think it would be a good idea to stop and go through a lot of these exercises to get a better understanding of the project? Ainsley: Absolutely, absolutely. Pretty much any time you see a place where there isn’t alignment, say between the core team and parts of the project community, or even within the core team itself, about the project work, you can go back to take a look at the alignment part of this model. Also, you can re‑charter whenever it’s needed. In the same way people use retrospectives…There are retrospectives that you do on a rhythm basis at the end of an iteration or at the end of a release, there’s no reason you can’t do chartering or work on the elements of the charter whenever there’s a need. It doesn’t have to be on a rhythm, but when something comes up that you need to deal with. It’s not just for the beginning of the project, it’s when the need arises. Jade: That’s great. I think that’s really good advice to teams who maybe even if they did start off on the right foot, and have found themselves in a place where they’re just not getting along, or something’s going wrong. Always reevaluate everything that you’ve got, and take a look and try to identify where there’s an issue. Ainsley: It just has to do with being agile. If there’s new information, did something change? What’s the best way to deal with it? Often that takes you back to looking at pieces of the charter. Chartering Doesn’t Mean Documentation Jade: As we’re wrapping up here, I’ve got one more question for you. What do you think will be the hardest thing for people to swallow from your book? What’s going to be the hardest technique or piece of advice that you’re giving them? Ainsley: [laughs] I haven’t thought about what’s the hardest thing. My experiences is that every group has different people that…And the variety of people each have their own issues with certain parts. So a single part, I don’t know. I think there’s often a misconception which we try and dispel all the time. The chartering means documentation, so that could be very off‑putting or difficult. However, this is really a limited documentation piece of work, and when we do talk about documentation, it’s often, or mostly actually, things that go up on big, visible charts. We’ve tried to keep it in line. I think things having to do with communication and trust, especially if it’s a new team, could make this difficult, but that doesn’t make this process any different than any other kind of communication. Jade: That’s great. When can we see this book? When’s it going to be out for everybody to read? Ainsley: We’re looking at next month at this point. We’re working on some cover art, and a couple of other publishing level things. We’re, right now, looking at next month. Jade: Where are people going to be able to find it? Ainsley: The publisher is called Onyx Neon Press, and they’re in Portland. Jade: How’s it going to be available? PDF? Ainsley: Right now, we’ll probably have some kind of…I don’t know what format it’s going to be, but some kind of non‑paper version. Jade: So Onyx Neon, you said? Ainsley: Uh‑huh. Jade: All right. Well, thank you so much, Ainsley, for you time and for coming on the show with us. Ainsley: You’re very welcome. It was good talking to you, and it was great to hear that you’ve been using this successfully. Jade: Yeah, it’s been great. I can’t wait for the book to get out, and for more people to take a look at it and give it a try. Ainsley: Great. Jade: Awesome. Well, thanks, and we’ll talk to everyone next time. Derek: Have a great one. Ainsley: Bye, bye…

Clayton Lengel‑Zigich: Welcome to another episode of the Scrumcast. I’m Clayton Lengel‑Zigich. Roy VandeWater: I’m Roy VandeWater. Derek Neighbors: I’m Derek Neighbors. Clayton: Today we’re going to be talking about a blog post that Derek sent out to the team. It’s titled “Technical Excellence in Scrum,” from Dave Rooney. Derek, can you explain a little about that post and why you sent it out. Techincal Excellence Missing In Scrum Derek: It was talking about technical excellence missing from Scrum, but specifically there is some talk about leadership. I believe it was Jeff Sutherland who had sent an email at one point ‑‑ or there is a famous email floating around ‑‑ where they talked about the first Scrum team that really was an eXtreme Programming(XP) team that started implementing Scrum in all of the XP practices in some form but were held up during their tenure. When Ken and Jeff decided to take Scrum to the bigger community or to the industry, Ken thought it was worth taking the technical practices or XP portion out of it and focusing just on the Scrum framework ‑‑ not because XP wasn’t important, but because they felt that if you implemented Scrum properly, you would have impediments and when you ran into the impediments, one of the first things that you should do is look at the technical, excellence pieces or the XP principles to help unblock the impediments that you got to. There was a recap at Snowbird recently, a 10 year anniversary, and one of the things that came up from a number of people is that if you are not really gung‑ho pushing towards technical excellence then you are not an Agile leader. That Agile leadership has completely fallen apart from a standpoint of ‘they no longer push the technical practices in the ways that they should,’ and it’s to the detriment of teams and projects. I believe that the author was saying, “Hey, is that really true”? Meaning, do most Agile leaders actually spend quite a bit of time trying to press, push forward, technical practices, but the business and the team pushes back and says, “We don’t have enough time to pair,” or, “We don’t have enough time to test,” or, “It’s too hard to get to continuous integration up.” Is it the actual teams that are pushing back on the technical practices and not the coaches or the leadership that is failing to communicate those practices? That’s the argument. I thought it was relevant because I fall on the side that we don’t talk about technical practices enough ‑‑ we just gloss over them. Why Aren’t Technical Practices Resonating? Clayton: There are two questions here. Is it a case of taking the author’s perspective and saying “Hey we’re working really hard to get these technical practices out there but the teams just aren’t responding”? Is it the way that we’re delivering that message or talking about those things? Maybe that’s not effective. As Agile leaders we need to find new ways to explain those things to teams. Which side of the fence do you guys fall on? Roy: When I was first reading through it and he was talking about “Well I push these things to the team and I’ve been doing it for years. Every time I get the same excuse. I get the, “We don’t have time to test.” I get the, “We don’t have time to pair because we’re coming up on a deadline.” It’s something that I’ve seen a lot in teams as well. Part of what he is saying too is “I keep trying and they keep pushing back. At some point, when do I give up? And is that bad on my part that I kept pushing but I wasn’t able to convince them to actually go though with doing testing or doing pairing or any of the other XP practices”? I think he tries to absolve himself from responsibility. I don’t want to necessarily put those words in his mouth but I feel that you do almost get that as a reader where “Oh, it’s not my fault because it’s the team’s fault that they’re not doing Agile…” That’s a dangerous position to take, no matter what you’re doing. You should always go from the perspective of, “What can I do to make it different”? That said, I don’t think it’s right for a Scrum Master or a product owner to dictate to a team that they have to do everything test driven or they have to do everything paired. I think if you do that the team is going to rebel against it and it’s been mandated from the top and it won’t work. There are other ways to get the team to buy into that. Leadership Impacting Technical Practices on a Scrum Team Derek: I definitely think it’s a leadership problem or a co‑team problem. To me, it’s two‑fold. One is when I look at most people that are currently coaching ‑‑ they’ve not been technical practitioners for than a decade. It’s really hard if the last relevant project I coded on was a C project for a Curses interface and I’m working with a team that’s delivering huge data sets to the Internet via APIs, high availability. It’s really difficult for me to have any kind of respect from the development team when I say, “Well, just test, just pair, and just this,” and I’m not able to sit down and do those things with them. I like to use the Dreyfus model, some people like to use ShuHaRi. I think some of it is the the Miyagi‑san thing. “Daniel‑san, paint the fence.” At some point Daniel‑san blows up and says, “Hey, bastard, why are you making me paint the fence”? Miyagi’s able to show him that painting the fence was a blocking technique that he needed to perfect. We fall into two different categories. One is, we, or most coaches are not able to actually demonstrate the techniques to the team, therefore the team tries it once and says, “Testing is hard, it’s too slow, it’s way, way slower.” When the teams that I’m on and the coaches that I see are highly proficient, testing doesn’t slow them down at all. If I can sit down and complete things as fast as a pair that isn’t testing, that throws out the argument that testing is slower. I can frame the argument as, “Because you haven’t practiced testing enough, you are currently slower. You need to work on your skills as a tester to the point where testing does not slow you down, because it is possible to write tests and not be slower.” If I can’t prove that, it sounds like, “Yeah, sure, asshole. You just want me to work harder and faster and put all this time in and you’re just a liar.” Some of it goes back to these little practices where you might say, “You need to do this because I say you need to do this for right now, because you don’t know better. You’re too early in the Dreyfus model to really know.” The problem is I think we have a lot of coaches who do that, but then they’re never able to pull a team into maturity. When Daniel‑san says, “Hey, I’m pissed off. I don’t want to do this anymore,” they’re not able to go, “Here, let me sit down and show you, based off observation and my skill, what’s happened over the last three weeks when you’ve done this. And this is what you’ve really learned from that.” Instead they just go, “Don’t question me, just keep doing it.” I do think it’s a leadership problem. I think teams have valid reasons why they don’t, but the best reasons are the worst excuses. Pairing Suffers From Similar Issues Roy: I’ve seen the exact same thing happening with pairing, where the Scrum Master, or whoever, comes in and says, “All right, we’re pairing now.” And the two people go to the Internet and look up what pairing means, and are like, “Oh, that means we stick two people in front of a computer.” Then after a week of taking turns coding while the other person plays on their cell phone, they determine that it slowed them down significantly. Well, yeah. No shit! That’s what’s missing a lot ‑‑ if somebody came in and paired with you, taught you the appropriate ways or showed you some different pairing techniques that helped you stay focused, and brought out the benefits of pairing ‑‑ that would make a huge difference. When we see a lot of people who are in Scrum Master positions, especially with a lot of the large organizations that are converting over to Agile, you’re getting project managers have taken that role, or you’re getting organizations that don’t even have Scrum Masters, and product owners which are former project managers. These people haven’t even touched code in a very long time. Derek: I definitely think that contributes to the problem. An Agile Coach and A Technical Coach Need to Be Same Thing Clayton: Right now, at least in the community, there seems to be this kind of delineation between, “I’m an Agile Coach, and I do stuff for the organization,” versus someone who does technical coaching. What it sounds like you’re saying, Derek, is that we cannot afford to have that delineation. If you’re the person that’s going to be doing coaching of an Agile nature ‑‑ I guess this kind of gets to Sutherland’s point ‑‑ you really do need to be up to snuff on your technical skills and you do need to be able to demonstrate pair programming, test first, and those kind of things. I think that’s going to alienate a lot of people right now who are using the phrase ‘Agile Coach’ because they’ve spent a lot of, the last say five years, driving towards the organizational, C level, that kind of coaching. They don’t have any concept. Maybe they weren’t even ever developers, or they were developers 15 years ago. How do we re‑align? What’s the new normal? Certified Scrum Coach No Technical Excellence Needed Derek: Yes. I’ll use baseball here, an analogy ‑‑ I think one of the things that pissed me off more than anything with the Scrum Alliance, is CSC Application Process is their definition, I believe, the way that they look at a coach right now, is a coach is basically a Scrum Master that works with the organization instead of with the team. I think that’s an absolutely bullshit approach to what should be considered a coach. I think you can be a coach, and only work with a single team, and make that team excellent. To me, if you’re working with multiple teams, doesn’t that make you a manager, instead of a coach? So I think we need to reframe a little bit what we consider a coach. I think, if you look at the XP coach definition and terminology, it’s much different than the “Agile” coach or the Scrum coach type of designation. When I look at it ‑‑ I go into the baseball analogy here ‑‑ is I don’t know any manager currently in baseball that doesn’t know all aspects of the game at a pretty deep level. If they see somebody hitting, they know the hitting techniques. Maybe they haven’t played for a while, but they are still up to date on the most current hitting techniques, batting stances, how the pitchers pitch ‑ they’re fully informed, or they have access to staff that is. They have a hitting coach, they have a batting coach. If you go to football, you’ve got a line coach, a kicking coach, a quarterback coach. That’s for a reason. When it comes to technical things, there are certain things that you can only know from experience. You don’t have to be the best software developer, the best coder, or the best tester, but you have to understand the principles about being the best coder, the principles about being the best tester, so that you can get the most out of people who are talented and maybe do a little more. I think we’ve gotten so far removed now that I think most Agile coaches, if you tried to ask them to code an application and do it all test‑driven, they would fall all over themselves. That would be an impossibility for most of them. Lack of Organizational Readiness Roy: I understand where the Agile coaches are coming from by specializing and dealing with the organization rather than the developers directly so much. I think we’ve seen that going into a lot of organizations as well that a lot of the organization’s problems stem at the top. There are definitely technical practices and things you can bring into a team, but, a lot of times, implementing those technical practices is something that’s blocked from on high. Like, you want to bring in something like pairing, and the teams wants to try it, but they try it, love it, and then, all of a sudden, you get management coming in saying, “Why the hell am I paying two guys to sit in front of a computer? I don’t understand.” Derek: I absolutely agree, in the sense of, sometimes a team can’t be empowered to do the technical practices until the organization is ready. So you have an organization that says, “I’m ready to be Agile,” but in reality, that just means, “I want my team to work faster and have less bugs.” Sometimes, it does take some organizational coaching. The quality teams out there, or the quality organizations out there, are ones that have people that have a broad skill set, either have a broad skill set to be cross‑functional, or, if they’re going to specialize, that they have multiple people on the team, just like the baseball team. If I go into engagement, I’m going to bring a technical coach to work with the teams on the technical issues, get CI, pairing, whole‑team collective code after refactoring, get all that stuff under there. Maybe I’ll get another person on my team that is the organizational coach, and he’s going and talking to the CIO and the product development team in another group. Maybe I’ve got another process coach, that’s more about the Scrum framework and how to get the most out of the business value, and those things. So, if you’re going to be specialized, I think, if we’re going to change it, we need to say, “OK, there are multiple coaches.” If you’re not a coach that can coach all of the different pieces, then we need to call coaches what they are ‑‑ I’m a technical coach. I’m an organizational coach. I’m a process coach. If I can do all three of those things, then I need to specifically say what I can do. Coming In To Coach At The Wrong Level Roy: That makes a lot of sense, to split it up like that, because I’ve seen before where we’ve gone into our organizations, where, if you start out by helping developers, it’s almost like you’re seen as a developer as well. That puts you in the wrong position among your social hierarchy of that organization to help out with, for example, executive‑level coaching, where, even if you have the knowledge and the ability to do that stuff, you are almost seen as beneath that role, and you are no longer able to effectively help those people up there. By splitting that up into multiple people, even though those people are able to work across those different fields, it almost makes sense to have those be distinct, different people, just so that they can fill their own slots in the social hierarchy of the company. Clayton: It sounds like we’re agreeing that, to further Agile, that coaching and leadership in Agile needs to be in tune with technical excellence. Is that a fair statement? Derek: Yes. Don’t confuse technical assholes with the software craftsmanship. [laughter] Self Organizing vs Self Managing Clayton: That’s a good distinction. OK. To change gears a little bit, we wanted to go to Twitter and look up an interesting tweet. This one comes from Sandy Mamoli. That’s @smamol. She says, “Dear manager, it’s self‑organizing, not self‑managing. We still need you. Cheers, your team.” What do you think? Managers in Agile ‑‑ do we need them, or can we throw them out the window? Roy: I don’t know quite what the tweet is trying to imply. Clayton: Were you tempted for a second thinking about throwing the manager out the window? Roy: [laughs] I mean that might be kind of fun. Clayton: Cause you to pause for a moment? Roy: I think that tweet almost sounds like a cry for help from the team. I don’t know. It’s hard to tell if the person is the manager that’s saying that. Clayton: No, I think they’re saying that we still need managers. I don’t know if this person is a manager or not, but… Roy: I think that’s a very difficult thing to say, because there are so many different views of what a manager’s roles are. I think that some managers think it’s their role to completely control everything and then figure out who it is that screwed up, and that’s all that matters. There are other people who think it’s very important that they protect the team from the outside, and that they need to allow the team to make their own decisions and provide a safe environment for them to do that type of stuff. I think those are two entirely different roles that can both be called manager. Derek: To me, the two key terminologies they use to sum it up were self‑organizing versus self‑managing. I think that’s something that a lot of people get confused. A lot of times, a team will be given the empowerment to say you’re self‑organizing. The delineation is if you are self‑organizing, you get to choose how to do the work. If you’re self‑managing, you get to decide which work to do. It’s very difficult to be on a team where you get to decide what work to do and you get to decide how to do the work. That is a lot of leeway, and it takes a very disciplined team or a very disciplined set of people to be able to work in that style. I think what this person is saying, and I don’t want to put words in their mouth, is that, when a team that has been given the ability to self‑organize, the management is not stepping up and telling them what needs to be done, they’re just saying, “Hey, man, come on! Perform”! And the team is saying, “We want to perform, but you haven’t told us what you want us to do.” A lot of people have a lot of anxiety. I know, in Integrum, we’ve had periods in our culture where we’ve allowed things to be fairly self‑managed, either by design or by accident, neglect, and I think we definitely saw people’s uneasiness really grow, because there’s a lot of doubt ‑‑ “Am I doing the right thing? Am I supposed to…” So, if you have a structure, but your boss isn’t telling you what to do or what will make them proud, this would be like a parent saying, “Do good, kid”! “What would make you proud, dad”? “Just do good. Just do good stuff, and I’ll be happy.” That’s very difficult to get approval. I think teams crave approval, and you can’t have that if you are self managed. Clayton: One example that I keep seeing come up in a few different places is the question of in an Agile team, or on an Agile team, how do I gauge individual performance? One thing that keeps coming up is that the manager can assess individual performance, even though they’re working together as a team. There’s still a role for management. I think this question is topical. It comes from both sides. There are probably lots of managers who are in organizations that are adopting the Agile, and wondering, “Hey. Where do I fit into this whole thing”? There’s also some people on the teams that are, kind of what Derek was saying, they’re craving that, I don’t want to say approval, but they need some direction. Roy: And feedback probably. OK. Thanks guys. Clayton: OK, thank you.

Clayton Lengel‑Zigich: Welcome to another episode of the Scrumcast. I’m Clayton Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Drew LeSueur: I’m Drew LeSueur. Having A Sense Of Urgency Clayton: Recently, we’re having a discussion on the team. Roy had mentioned that one of the things that he saw was that someone at the higher level of the organization was saying that they think that every… was it ticket, Roy? Every ticket, every emergency, every interruption, everything should be super important and there should be a sense of urgency around everything. Is that accurate? Roy: No. I think it was more along the lines of every ticket should have a sense of urgency. Like every ticket is more important than another. When a ticket is more important, that its urgency should be felt throughout the entire organization. The entire organization should feel like the team is rushing to get it done as quickly as possible because we know it’s important. Clayton: Can you describe what a ticket is just for some context? Roy: In our case, a ticket would be like a story. It could be anything from a defect to a feature that needs to be implemented, just something that needs to get done. Clayton: So everything is super important and there should be a sense of urgency around everything. So everything is urgent? Roy: No. Not everything is important. I think that’s a big thing I took away from that…the thing I brought up to the team here, was about how the things that are important, like the rest of the organization. Like, we have customers that interface with the organization. When they have something brought up, it is important to the organization that that customer knows that they are very important to us and that we are working very hard to fix that issue, and working very quickly, as quickly as possible, because we know that it’s important and they need it now. The Customer Feeling Important Clayton: When I think of “sense of urgency,” I think of if I were, say, in some management position. I could say, “I want my team to have a sense of urgency so they feel like they need to get things done and it’s not just screwing around.” From the customer perspective, “sense of urgency,” it seems like “sense” takes on a different word where it seems like you’re saying, “I want to give the customer the appearance that what they’re saying is very urgent to me. So I want them to have a sense that we are being urgent about getting their things solved.” Roy: Right, exactly. I think sometimes too, because some of our stakeholders are people that are within the company, they also should feel like their stuff is very important. Clayton: Derek, you were at the center, maybe playing devil’s advocate with this one earlier. What are your thoughts? How Should A Team Pace Themselves Derek: I see this expressed a lot of times in terms of velocity. I’ll see a team, “We’re going to commit to 20 points,” let’s say, and they are at 15 points on Thursday and to the outside world it looks like you’re not going to hit your 20 points and you seem to not really care about it. I think I’ve seen this even internally, “Hey, we’ve committed 75 points and so at the end of day one we should be five points burned or zero points burned. At the end of the day two we should be 14 points burned and we’re no points burned.” Yet there’s no visible difference of the team from if they were completely out of track. I think that a lot of time scrum masters or product owners or stakeholders start to say, “Where is the panic? A team should be panicking at this point.” I think that’s something I get conflicted with because in some ways I agree with it and in some ways I disagree with it. The ways that I agree with it are that I think that a high performing team should constantly be pushing themselves to their limit but not overstretching themselves. I would akin this to say a long distance runner. A sprinter sprints all out and then has plenty of time to recoup, a long distance runner has to meter themselves. I think in a sprint you’ve got these…most marathoners I know go by miles. They say, “I want to be running in an x minute mile for the first two miles and the next three miles I want to be running this. They have some pace that they’re trying to get to and if they’re behind pace they’ll try to improve that pace. I think that when teams don’t set a pace or a velocity and they’re not trying to keep in rhythm with that and they don’t have any urgency to that. That’s to me a sign that they’re probably not on the path to be a high performing team. However I think that it’s also dangerous to say that a team should always be panicked. Because most competent marathon runners I know don’t run a race completely panicked. They’re measuring themselves, they’re checking themselves, they’re pushing themselves accordingly but they also know what their bodies are like. They’re very self‑aware, so they’re not panicked all the time. I think that to me, it depends on which direction you’re coming from. If you’re coming from the direction of like, “I’m really upset because my team doesn’t look like they’re panicked all the time. They must not be trying hard,” that’s dangerous. If it’s, “The team doesn’t seem to be pushing themselves” I think that might be valid. How To Encourage High Performance Teams Clayton: Let’s say that I as the manager have decided that…my understanding, it’s not good for me to say, “I want my team to be panicked and I want to rush them along” or something like that. I acknowledge that I want them to be pushing themselves to improve and all those things. What are some positive ways that I can help them or that the team can go towards that type of behavior rather than just being “everything’s urgent and I’m real panicked”? Derek: In going back to the marathon runner, everybody knows what my body type is like, because I’m not a long‑distance runner in any way, shape or form. Some of this is setting goals for yourself, measuring yourself against those goals and then reflecting. This might be, “I’m going to set a velocity of x and my goal is to hit that, and it’s part of if I’m doing a one‑week sprint or a two‑week sprint or a four‑week sprint, whatever that is, I should be able to calculate some interval whether I’m on pace to hit that or not.” A team that says, “We’re going to do velocity of x over some duration of y,” and they do not break that duration down to smaller segments to check themselves velocity‑wise ‑‑ that to me is a sign that they’re probably not a super high performing team, because what they’re doing is they’re hoping that at the end of their sprint, that they got the time or velocity that they’d hoped for. Good, strong teams have some way of saying, and this is where the burndown chart comes in, but I think that people abuse the burndown chart and they just look at it as, well, here’s the burndown chart, and they’re not actively pacing themselves against that burndown chart. Hey, we’re two days into a 10‑day sprint and right now we’re charting to be off by 5 or 10 points. What are we going to do to fix it? Are we going to put in some extra time, are we going to reduce scope, are we going to try to negotiate? What are we going to do to try to be able to finish on time? To me that’s not the same as panicked, but if a team’s not having those conversations, I’m going to suggest that they’re probably going to fail more often than they’re going to succeed. Coaching To Goals Vs Setting Them For Teams Roy: Let’s say I’m in charge of a team that’s working beneath me and I recognize that they’re not performing. Would it be a good idea for me to try to push them by setting goals for them? Derek: I don’t think so. Let me rephrase that. I think that you can ask them ways that they can be more successful. You could probably suggest setting smaller goals within a larger goal and then if they’re not hitting those smaller goals, start to have a conversation about, “Hey, how come we’re not hitting this”? “What could we do to potentially hit this”? You could do that. If you’re actually setting a goal ‑‑ you say you’re going to do 20 points in the next five days, therefore you need to do 4 points a day and if you’re not I’m going to crack the scrum whip on you. Probably not a real effective way to get the team to perform. The Interruption Trap Clayton: One of your other examples that you were talking about, Roy, was that this person who wanted this kind of sense of urgency was talking about it not just for the team, for the development team, but also for the whole organization. In talking to that and having that meeting, what do you see the other people in the organization, maybe the stakeholders or the product owner, how do you see them implementing this new drive toward sense of urgency about everything? Roy: If something comes in that’s very urgent that it gets to cut everything in line that’s inside the current sprint. We don’t really have the concept of a sacred sprint, where nothing can get into it. That’s something that’s been very difficult because every time the development team tries to push for something like that, we get a lot of pushback from the organization because they have demands that need to come in the middle of the week and need to get done right away and they can’t wait until the following sprint before they get done. Clayton: It sounds like “sense of urgency” means let’s break the scrum, iteration contract and sense of urgency really means I get to interrupt you with whatever I feel like is most important at that moment in time, and you have to do it because if you don’t that means you don’t have a sense of urgency. Roy: That’s definitely a loaded way to put it, but it’s not inaccurate. Drew: That’s part of it and even in the sprint there’s a sense of, this has got to get done before the sprint ends. It’s got to get done by Wednesday or something. Derek brought up the burndown chart and maybe it’s Thursday and your sprint ends tomorrow and you haven’t got all your points in. Then you have to have the conversation of, do you scope or do something, what do you have to do to get it done? This sense of urgency goes right along with that. When you have a visibility either with the burndown chart or communication with the stakeholders, then you can talk about things that might not be apparent if you didn’t have that conversation. For example, if there’s this ticket, or task, or story that comes in, and it needs to be done, and there’s a sense of urgency on it. If you’re being visible with the stakeholder on where your progress is then they may be able to say, “Hey, all right. We’re not going to hit the deadline here, what can we cut out”? “Can we remove all the fancy styling? Can we remove all the fancy colors, and just get the thing out”? If you have the visibility then you’re able to have those conversations. If you don’t have that visibility then you might start implementing some fancy styles, or whatever it might be, that’s just an extreme example, without knowing that that’s urgent, or that that aspect isn’t as important. I think a real big part of the urgency thing is the visibility and the human interaction with the stakeholder or the client. Mis-Defined Sense of Urgency Derek: I was just going to say, I really like analogies. I’m thinking back to an analogy from an operational day. I think some of it is that there’s this mythical IT creature, or software developer animal, that a lot of business people have that says, “Really good developers like to slave away in the middle of the night, and be fed pizza and beer, and solve really hard problems, and grind themselves to death.” “By golly, that’s the American developer dream. It’s to just burn yourself until you’ve got nothing left.” I think sometimes the sense of urgency is, “My friends on the golf course talk about the developers that are working until three o’clock in the morning. When they come in from their golf game the developers are just leaving for the day.” I think that what gets difficult for development teams that are trying to have sustainable pace is that urgency is defined in a funny way. The analogy I like to say is I was an operations manager for a Macy’s department store. We had six different escalators in the building. We had one particular escalator that had all sorts of problems. It would consistently seize up and it would throw people, literally, off of the escalator when this would happen. It happened to be in the middle of a chain of three other escalators, so it would impede all traffic going up or down when this thing would go down. We were short‑staffed usually during the highest traffic peaks because the people that would handle that sort of thing were the stock managers and the people that worked overnight and early in the morning. What would happen is we would have one or two guys on‑call. This thing would go out, and they would call in. They would demand, “Drop whatever the hell you’re doing. The elevators are down. All business is down. Get somebody here right away.” My staff would complain all the time, “Every third day we get a call that we have to get interrupted.” Then I would chew them out that they didn’t get their job done. They’re like, “Well, you know, the elevator went down three times, and I had to go run and get the keys.” It was funny to me that it was always so urgent when that happened. But when I would go into the staff meetings, and I would ask the store manager what the update is on calling the Otis repairman to come out and repair the elevator, it was never a priority. It’s like, “Well, which is it”? I think that product owners and stakeholders tend to do the same thing. “Oh, I want this thing right way,” but there’s some other bigger issue that could really solve the problem, other than technology, but that’s beneath them. So what, it’s just a stupid IT guy. Let him go program this or fix this defect. We don’t care about quality to actually go write an automated test, or something, to prevent this in the future.” “It’s not worth our time. It’s not our priority there. But it’s a total priority that you get interrupted and then we scream at you that you don’t get your other work done because we keep interrupting you.” Clayton: I think that does it. Intergrum will be at Open Agile Southern California in the next couple of days. We’re going to record some podcasts. If you’re interested in that and you can’t attend make sure you listen to some future, upcoming podcasts. We’re going to have some material from there. Roy: Won’t that be in the past when this gets released? Clayton: No. Roy: No? Clayton: We’re going to release this one, and then we’ll release the others in the future. If you’re listening to this one then the next few episodes you’ll probably get some content. Derek: He’s not saying, “Join us at Agile Open California.” He’s saying, “If you missed Agile Open California be sure to check in on our summaries.” If you have a time machine you can join us at Agile Open California in Irvine. Clayton: Great Scott!

missing content Clayton Lengel-Zigich, Derek Neighbors, Drew LeSueur and Roy van de Water discuss controversial tweets. @PMOObserver: “Always deliver what you commit to. No more; no less.” @elizabethraley: “Scrum Rule: No Additional Requirements Can Be Added to a Sprint!” @scrumology: “Comparing velocity between teams: Not everything that can be counted counts, and not everything th…” @rslawrence: “In case you missed it over the weekend: ‘Why Longer Sprints Probably Won’t Help’” @rramirez4444: “What are the TWO best qualities of a good Scrum Master? #agile #scrum (non-SM respondants given more weight on this one..)” @alechardy: “Purpose of sprint review is to inspect and adapt. Demo during review is to prompt inspect and adapt conversation.” The post Episode #33 – Agile Tweet Controversy appeared first on Integrum.