Derek Neighbors: Welcome to another episode of the ScrumCast. I’m Derek. Clayton Lengel‑Zigich: I am Clayton. Jade Meskill: I’m Jade. Continuous Deployment Killing Project Management Derek: Today, I wanted to talk a little bit about continuous deployment, but I wanted to talk about it in a little bit different of a viewpoint. That is, as we see products like Facebook, like Twitter, where you can’t really tell what version of Twitter are you running, what version of Facebook are you running. You don’t know when the last feature was deployed. You just hear people talking about the “new Facebook,” or the “new Twitter,” and when is it going to show up for you it’s already shown up for me. What does that mean to what we would call right now, “project management”? Are the concepts of projects starting to die? Is software deployment happening so continuously that we can’t really tell where something begins and something ends? What does that mean to agile processes and how we think about projects as organizations? Jade: I think some of the trick here to what you’re getting at is historically we treat products as projects, and I think that’s really where we’re seeing the shift. The Facebook product itself is not a project in and of itself. The Facebook project will never be complete. But I think there are people engaging in project‑oriented work around that product. So there’s some scope of work that has a beginning and an end. It needs to be measured and tracked throughout that work, but that project is just a means to an end. It’s not the end goal itself. Finishing up implementing the new photo layout or photo uploader for Facebook is a project. But that’s not the Facebook project itself. Agile Well Suited For Continuous Deployment of Products Clayton: Yeah, I think that any agile methodology, too, seems like would be pretty well‑adapted for this where you have something that’s out there, say, or even if you don’t, but you’re incrementally improving. You’re deploying something, getting feedback, incrementing on that, inspecting/adapting. It seems like that would be really well‑suited for continuous deployment and not having the concept of, “Well, we have to get all these features in, and then we can deploy. Then we’ll wait six months, and then we’re starting another project and then we’ll deploy it a year from there” and that kind of deal. It seems like it’s well‑suited for any agile methodology. Features Now Are Like Mini Projects Derek: Yeah, I think we definitely went through a phase where the actual product shipping itself was the project, and then I think we narrowed it down to a new version of the product was a project. Then we went down to a minor release version, but now that we have this ability to continuously deploy I guess the crux of what I’m getting at is are we really looking at, “projects are almost features”? Are we really getting to the point where we’re talking for the most part, when we talk about projects in these type of environments, the photo uploader to the new version of the photo uploader is more of a project? Or even more minute than that, a little subset feature within the photo uploader is really how I measured? Do we see people maybe leaning more towards Lean principles or Kanban or other things? What does release planning look like in this type of environment? Approach Depends On Organization Jade: Clayton and I are staring at each other. I think you’re right, and I said that earlier. I think that the feature itself, the photo uploader, becomes the project that we need to manage. We need to look at the scope, look at what is the possible return on investment for adding this particular feature. We need to create a plan of implementation around that. As far as moving towards a Lean methodology, I think a lot of that’s going to depend on the organization itself and how it handles risk assessment and a lot of these things that are not code‑related at all but really more about engaging in that feature. Is it viable for us to try this? Or what is the minimum viable project that we can do for this particular feature to test it out and see how that goes? I think, whether you take a Scrum or a Lean approach, that’s going to depend a lot on your team, the personalities involved, the amount of unknowns that there are out there. Enabling Self-Management Clayton: Yeah, I think it’s interesting, the idea of features as projects. I think one thing that’s really powerful about Scrum I guess, that concept of potentially shippable software. I think that’s personally too soft of a word. But if your development team is able to treat every feature as if, at the end of that feature when it is done ‑‑ done is done ‑‑ it’s going to be shipped to production and people are actually going to be using it, I think that changes the mindset when you’re developing something, that a lot of times people let things get away. It’s easy to be sloppy. But if you have this concept of, “When this feature’s done, I’m deploying it to production, and wrapping that up” I think it’s interesting. If you were to ask some people that may be at the VP level in terms of, you have this project manager that is running this project, they probably think, “I need someone that is going to manage all these different things.” But on a feature‑by‑feature level, if you said, “What if your development team was responsible enough and mature enough to manage themselves for a feature”? I think there probably are a lot of teams that could do that on a feature‑by‑feature basis. If you got to a point where you could do that pretty consistently, it wouldn’t be necessarily one person to manage this whole project, but it would just be the team managing themselves from feature to feature. Competitive Advantage of Continuous Deployment Derek: I guess that ‑‑ segueing into where I really want to take the conversation ‑‑ is, we see all the time, when we work with product owners who are not used to a high‑performing team or not used to agile principles and methodologies, that we find ourselves, basically, working so far ahead of where they’re at that they have a hard time keeping up. That they, in essence, become the bottleneck to delivery of software, because they are not able to work at the speed that the team is. I really question, as part of moving towards continuous deployment, are we really seeing pushback? Not from developers, because I’ve really not met a whole lot of developers that don’t like the concept of working on a feature‑level basis and deploying really, really often. Sometimes, you’ll see some, but for the most part, at least younger developers, I don’t see this. This is part of how they’re already wired, because that’s how they consume software. But what challenges do organizations face? When you talk about a PMO office and having to plan out products potentially years in advance, are we going to get to a point where they’re unable to compete with organizations that are embracing agile philosophy not at a development level, but at an actual organizational, cultural level, where a CEO says, “I’m not worried about the 10‑year plan. I’m worried about, are you continuously adapting to what’s happening in the marketplace”? Radical Transparency Required Jade: I think that’s a really good question. I was talking to a group of people. They were talking about how they were adopting Agile in a very large enterprise and how the biggest roadblock they had was that their risk management software couldn’t calculate the potential financial risk based on doing it in an Agile manner. They just didn’t have a way to understand and represent that to the business, of, what is the potential financial outcome of this thing? They could prove it from a return on investment, that, “Yeah, this is a good product to build, and we should invest in doing that.” But the risk calculations they just couldn’t do, because they couldn’t plug in the made‑up project plan that most people have to get them there. I think that’s going to be the next major roadblock, is looking at the organization’s ability to respond to change. I think as software developers, we’re really leading the way for that type of mentality. I think it’s going to be a really difficult transition for the business itself to make. On an organizational level, to be able to respond to change, to have that tight feedback loop, to have that transparency with the rest of your team, that, “Maybe we don’t know what we’re doing right now. Maybe we’re going to have to figure some of this out, but now, it’s readily apparent that we don’t know how to solve this problem. We’re not the guys with all the answers.” I think that’s going to be really difficult. Quality Required for Continuous Deployment Clayton: There’s definitely a lot of cruft in this status quo, I think, with a lot of people, in how they view the life cycle of a project, where there’s some development, and then there’s testing, and there’s QA, and all this other stuff. I think that because that’s the accepted…that’s the norm for how things go, the idea of being able to say, “My team is going to develop this feature, and we’re going to quickly get it to market,” I think that’s a foreign thing, partly because I would guess that a lot of people don’t feel that their development team…they don’t really trust the team to deliver something that is high‑quality the first go‑around. I think people have been burned in the past, so they just assume that they have to go through all these layers. Whereas, maybe, if we can get some teams that are focusing on code quality and some of the more engineering professionalism stuff, where you get a few wins, and then it lowers all those barriers. If you’re working on those lower cycles, you don’t necessarily have to have some huge risk plan for what happens in ten months, because it’s not a ten‑month thing anymore. Organizational Change is Difficult Jade: But what happens when that’s the way we’ve always done it, and there’s entire departments of my organization that that’s their job. Clayton: Yeah, that’s the hard pill to swallow. It seems like, for a lot of places, where to adopt some of these things, that means that you’re going to have to make these big shifts and changes. Obviously, it’s very difficult for a company to restructure that many people or totally change their roles, even if they’re not necessarily needed in their existing capacity. Jade: I think it’s been easier for development teams to do that, because they’ve done it…I don’t want to say in isolation, but mostly in isolation. I can reorganize us as a development team, but put on the corporate face to the rest of the company and still interface at the expected levels. I can still produce the right reports and all these things that the business needs to pacify them, and then have this really great, agile, self‑organizing team internally, but rolling that up to the organization is really difficult. Consequences Of More Businesses Being Technology Businesses Derek: I think it’s even difficult for software teams. We’ve seen software teams take the first crack at it because they didn’t have a choice, and what I mean by that is, the rate of technology change is so fast that, if you hadn’t changed your technology in the last 20 years, you’d still be running COBOL and the Mainframe. So in order to just keep an organization running, teams have had to adopt new languages, new platforms. Some things stay the same, but it’s really to a point where they’ve had to deal with a large, wholesale change on a regular basis. If you’re a retail store, if you’re Walgreens, if you’re Wal‑Mart, what have been the significant changes in how you do business, short of adding some technology that has really changed? In that space, if we looked at, say, Zappos or Amazon. Those are the real risks to the retail business, not other retail business, for the most part. At what point are we going to get to where 90 percent of business is technology‑driven, that it’s changing on a pace so quick that, if you do not change your organization to be adaptive, that the new guy will put you out of business on a much more regular basis. Adapt or Die Jade: I think the Web was the first shot over the bow of this type culture that you’re talking about, where a competitor can crop up overnight and completely destroy you in no time and you haven’t even had a chance to react to that. We’ve seen that accelerate, especially for Web‑based businesses competing with each other. I could be MySpace, and I’m king of the world, and six months later, nobody even knows who I am. We’re seeing that kind of change in those businesses because it’s survival of the fittest. If you go down to more traditional organizations, they’re not suffering at that level yet. I think some of the economic downturn is some of the first indicators of things have to change. Things have to change with how we run our businesses, but that pain threshold still isn’t there. They’re still holding out hope that we’ve just got to suffer through this and things will get back to normal. It’s going to take something that completely changes the game for a lot of these people for them to be willing to endure the pain of making that type of organizational change. Clayton: Yeah, I think you look at banking, for instance. Pretty much every single online bank I’ve ever seen has been pretty much terrible. Even the best one is still pretty bad. There’s going to be one player in these markets where they can use the technology to, what you’re saying, Derek, to pivot enough. You mentioned the younger crowd. As people are my age, younger, whatever, that are getting to the point where they consume certain services in a way, and they want to be able to use everything that way. Finding the companies that are going to be able to make that organizational shift so that they can take advantage of all these things, which I don’t think are especially difficult. It’s organizationally difficult but not technologically difficult. People that can do that are going to have a huge impact. Derek: With that, I think we’re about out of time, even though Clayto worked in a pitch for a [Simple Bank ](https://en.wikipedia.org/wiki/Simple_(bank) and Square there, so those following along at home, those are a couple of startups you might want to take a look at that might be replacing your bank in the near future. With that, we’ll see you next time.

Derek Neighbors: Hello and welcome to another episode of the Scrumcast. I’m Derek Neighbors. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Elvis: And I’m Elvis. Clayton: Elvis is new to the studio. [laughs] Growing People on Agile Teams Derek: That’s how powerful Agile is. It can bring back Elvis. So, recently attended the AgileOpen Northwest, in Portland. There were a number of really great topics. One topic that seemed to come up in a couple of different formats was the concept of growing people or mentoring people or deliberate practice to get better. I think that that’s kind of one of the tenants of Agile is continuous improvement and really trying to get better and inspect and adapt. I wanted to talk a little bit about deliberate practice in areas that aren’t technical. A little bit about what it takes to mentor and grow people. And a little bit about how do you facilitate developers who care? Clayton: [chuckles] Easy topics. [laughter] Derek: It would hard to find a five minutes’ worth accounting time. Clayton: OK. What was the first one? Deliberate Practice On Intangibles Derek: I think they’re all one and the same. How do you deliberately practice things that aren’t really tangibles? I think you could say, “How do you practice becoming a better coder,” because it’s fairly easy to say, “Here’s what code. Code has an output.” But if you say, “How do you deliberately become a better communicator, or a better estimator, or better at intuition, or better at leadership,” those things have a lot more difficult outcome to predict. How do you go about deliberately practicing them? The second part of that is, how do you mentor good team members? How do you facilitate developers that really care about the work they’re doing, not just the code? Practice Outside Work Clayton: I think as far as deliberate practice for some of those scenarios that you described, it’s hard to do as part of your work day, because the chances for doing that are pretty limited. One that I’ve tried to do is really take it beyond my work, and look for opportunities in general life, where I can say, “OK. I’m going to sit down and I’m going to estimate the difficulty of doing this particular task or whatever it is. I’m going to sit there, and I’m going to actually measure it. I’m going to see how accurate was I at predicting how long it took me to do that or how difficult that was,” et cetera, et cetera. Same with communication is how am I facilitating communication in my personal private life. Am I using that techniques that should make me a good scrum master, a good scrum coach? Am I using those things to talk to my wife or talk to my kids? I think there is plenty of opportunities if you can think outside of the box on ways to practice and exercise those skills. Explaining Things To Others Derek: I think I agree that code is an easier one because there’s some output and stuff. I like Clays idea of trying to take some of that stuff, what you’re learning, and trying to do that in your normal, everyday life. One thing that I found that’s kind of interesting is get home from work and wife and I talk about our days and stuff, and a lot of the stuff that I do is of a very technical nature and what’s kind of fun every now and again is just kind of to humor me, she asks me, “Explain that thing.” So I think it’s interesting to some degree to try and challenge yourself to say, here’s this person who doesn’t know anything about this technical thing I’m talking about, but I’m going to try to explain what the goal is and what the purpose is and all those things. And I think that when we take that for granted because we come across, it’s like you go home and you are like, “My wife doesn’t know much about this technology, but I’m going to explain it to her,” and you’re a nice guy. But then you go to your client and you’re like, “What a jerk that guy doesn’t know anything that he’s so stupid [laughs] .” So I think that’s a good opportunity just in your daily life. I’ve got these friends that, they’re curious, how’s work going and things like that. And they don’t understand anything from a technical perspective that I’m doing, but it’s kind of fun time to be able to like, “We’re working on this cool project and here’s the point of it and what we’re trying to do.” I think seizing those opportunities probably first. It’s hard to realize when those come up, as far as communication, improving your communication. I think just any opportunity you can to speak in front of people or even just answer a question or just anything like that is just kind of finding those opportunities and then doing something with them. I think that’s a really good way to improve on those intangibles. Using Experiments Clayton: I think those are good ways of casual practice. I think experiments are really where you going to able to have deliberate practice, so whether that’s taking a different approach to solving a problem within some work problem that you’re dealing with, or lots of people have a side project or things like that, can you apply these things to your side project or test out new theories in those ways and measure the results that you’re seeing against that? To me, that’s working a little bit more towards a deliberate practice of trying to improve your skills in these areas. Being Deliberate Derek: Yeah, I agree that everyone has their side projects and I think sometimes we get to a point where we have too many side projects. You go out and say, “I’m going to try all these new things and see what they’re like,” and then you’re not really doing deliberate practice at that point, you’re just kind of goofing off. I think that is really challenging to say, “Here’s something that I want to deliberately practice and it’s of some value to me and my normal day or whatever, I’m really going to focus on that, I’m not going to start this project and then two weeks from now hear some new other new hotness and then go strike that one in.” You know then by the end of it, you’ve got like five projects that you haven’t actually done anything on. I think it’s very important that you stay focused if you’re going to try and use a side project or experimentation as a way to practice or learn newer things. Expanding Your Horizon Elvis: I think there’s a couple of pieces to this that are interesting to me. One is that I think that when I look at really high performers, they’ve learned that, to get more performance, they have to start looking at different things. If I’m a highly functioning developer, I’m really good coder, I do really well with software development, to take it to the next level, I probably don’t have to practice code. I have to practice other skills, listening skills, problem solving skills, communication skills, different pieces. I think that, kind of to me, step one is if you’re already a high performer is you have to start saying, “What can be a big boon for me that’s not just like a new way of doing the thing that I’m already doing.” I moved from Java to Ruby. Yeah, you’re going to get a lot of performance potentially out of that, but I would argue that if you’re already really proficient at Java, you’d probably get a lot more performance at learning how to better deal with customers or better understand value of product or do other things that are going to get you a bigger bang for the buck. I think how do we start to get developers to realize that being the best coder or the best at a particular language or a tool, why not an all‑bad thing isn’t always the best way to succeed. I really actually loved Andre Agassi’s book called “Open.” He really talked about this and one of the big things that one of his mentors really pushed on him is, “You only have to be as good as the guy on the other side of the court.” I think sometimes when you talk software development, you only have to be as good as necessary to really succeed more than whatever the competitor is and I think sometimes as engineers, we focus on being perfect instead of being well‑rounded enough to beat the other guy. In his case, the thing that he really lacked was physical stamina. He would pretty much crush everybody through the first two or three sets in a match and he would fall apart in the fifth set. The other thing is mentally he would give up. Mentally, the opponents knew how to get underneath his skin and basically pull him. For him, to win all the titles that he did, he really had to overcome those two things. It really wasn’t about tennis. He was proficient enough at the game of tennis. It was the other two things. I think, within a team, part of that is how do we identify the deficiencies in our team and say, “You’re a really good Java programmer. You’re a really great Ruby programmer, but that’s not what’s really holding you back. What’s really holding you back is not understanding the value in product or you’re not understanding how to communicate well with other team members or you’re not testing well or what is that thing that’s really keeping it.” So that’s part of it, and I think the other part is, in deliberate practice I think that knowing is half the battle, to kind of go GI Joe on it is, I think that if you know what you’re lacking, you can deliberately practice against it. If you just say, “I’m trying to get better,” you don’t. And so I see people all the time with a side project, “I’m going to do a side project and I’m going to try this new technology and blah, blah, blah,” and they have no intent or no purpose. If you took a project you already had and you said, “Hey, I have been testing, but my tests always run really slow.” Over the next week, I’m going to try a bunch of different things to see if I can get my test speed up by 20 or 30 percent, and then you successfully do that. Now, you’ve created a skill set for yourself that now you know that say [inaudible 00:10:00] environment enough to know what gets performance and what doesn’t get performance, which is going to add to that if that’s one of the things you’re looking at doing. I think we’re too much of a generalist when it comes to wanting to get better and we just say, “Oh, we want to get better, so let’s just do more of what we’re already doing.” As opposed to saying, “What’s a very specific thing that I can measure, I can do, and I can say, ‘Did I get better at doing at after I practiced it?’?” Mentorship Elvis: I think you touch on a couple of key things. One is mentorship, and I think that’s something that we forget, is people who are professionals, they have coaches, they have people who are helping them every step of the way to see the things that they can’t see within themselves. I think the next logical step from that is trust. If we don’t have trust on a team, even with our mentors, we’re not really going to listen to what they’re saying, and we’re not going to get better, because we’re not going to do what they say, because we’re just going to blow it off. I feel like, as an engineer in particular, is we are really bad doing that, anyway, listening to people. So how do we build the trust up between peers and our supervisors, or whoever it is that we’re interact with? How do we build up that trust level to say, when you come and tell me, you’re really doing a bad job communicating with the rest of the team. It’s like, “Oh man! OK. What can I do? Instead of getting offended, teach me some techniques, tell me what did I do that made this bad, so that I can start to learn from those things.” I think we’re really bad at recognizing those opportunities. Lack Of Self-Awareness Clayton: I think, if you ask anyone, “Do you want to get better? Do you want to improve?” they will say, “Yeah, sure. Of course.” But then, if you say, “OK. What do you need to improve?” It’s like, “Gee, let me think about it. I’m pretty good at everything.” [laughter] Clayton: I think, when you’re a freshman at high school, the seniors seem totally awesome, and you want to be just like the seniors. But then, when you get to be a senior, you’re like, “Wow, this is nothing special!” Then the same thing happens in freshman college. It goes on through life. I feel, sometimes, people get to a point where they lose sight of the fact that there are people that are better than them, but at some point in time, they just forget about that, like the mentor thing. There’s a guy that’s probably 10 years older than I am. I talk to him all the time about software development stuff, and it’s funny, because there are things where I think I totally have it figured out, I go talk to him, and he’s, “Oh, ha, ha, ha! Let me tell you about 1987.” [laughter] Clayton: It’s like, “OK, I didn’t know about that.” There’s all that stuff. I think that half of it, like knowing [inaudible 00:12:37] , just knowing that there’s a lot of stuff out there that, one, you’re probably not very good at, or, two, you can always be improving. I don’t think anyone’s a total expert on everything. If you are, then you’re so far beyond anything, but as far as I’m concerned, people in my position, there’s always something you could be learning for something else, and just having an open mind and not talking that as an offense. I don’t feel like I have to know everything by the time I’m 30, or something. I’m not worried about that. So I’m not going to be offended if someone says, “Hey, you’re not very good at XYZ.” That’s just an opportunity of, “Hey, you did half the work for me of figuring out what I’m not very good at, so now I can go do something to improve,” but I know people who have that knowledge, or whatever. Being Open To Feedback Derek: Going back to the sports analogies a little bit, I think one of the things that’s interesting in sports, where you’ve got a coach. I’ll go to the Agassi example again. At one point, he stated, “All that’s not true,” when somebody comes up to him and says, “You need to change your game.” Then, when that person can say, “Remember when you lost the US Open to me. I’m telling you right now you’re a better player than I am, and you lost that game because I got into your head.” That was a point that he was able to say, “A, you’re right, and, B, I want to win a US Open, so I’m willing to listen.” One of the things I hear all the time in the software development world is we really need to be intrinsically motivated. I believe in that to a large degree, but I have to ask, is some of our struggle saying our people what’s the motivation for somebody to say, “Why should I improve?” Meaning, if there’s not a world cup to win, a gold medal to win, or something, what do you tell a developer who is really competent and pretty good, but they’re not excellent? How do you get them to move to that excellent point? What’s the driving factor where you say to them, “If you just did these things, Clayton, if you’d really think about how you communicate a little better, if you understood product development a little bit better, what’s on the other end of that for you if you do those things.” What’s Your Motivation Elvis: What’s my motivation? Derek: Is this one of the things we struggle with? Elvis: Yeah. I think that’s true. What is my motivation? Is it I’m going to get more money, I’m going to get a better job? I don’t know. I don’t know what that is at that point in time in my life. Can you even really picture those things? Derek: Is it to get on the Google team? Is it to get on the Facebook team? We don’t have the gold medal of programming. Elvis: The XP Open. The Effects Of Culture And Environment Clayton: I think the reality of it is that there are a lot of programming jobs out there right now, and, if you’re someone that has something like Java or .NET experience, and you’ve got some, maybe, enterprise or corporate experience doing that, you could go make a pretty good living and not really have to extend yourself very much. I think a lot of people just say, “You know what? I’ve got a family, and I really love playing golf and fishing, so I’m going to go to work and do my 9:00 to 5:00, and that’s fine. I don’t need to improve.” I think the reality of it is that there are a lot of people who are in a position where they have to really stretch themselves. Now, if you’re some factory worker, you worked on the assembly line in Ohio making brake pads, and you’re future is in question. You’re going to think, “Gees, I really need to pivot and do something different,” but I don’t think a lot of people in the software development industry are in that position right now. Derek: I definitely think that is an excellent point. The number of open positions compared to the number of people able to fill them is…I think people fill jobs all the time that are not qualified for them, and they’re able to hold them for years at a time because companies just don’t have a choice. So what could we do in our industry to change some of that? What changes need to be made or what can you do as an organization to attract, because money only goes so far. At a certain point, throwing more money at somebody is not going to make them be more motivated. Elvis: No, and, a lot of times, it has the opposite effect. I don’t know. I think that’s a really great question, and I wish I had an answer. What could we create that would motivate people to do better? I don’t know. Clayton: I think culture and environment, it’s probably the big one. I think you would be surprised that people that maybe have a comfortable job that’s in a corporate setting, but, if they had something that had a more lively, robust culture and wasn’t the same old…everything’s a color of gray and beige in the office kind of deal, I think that’s really motivating. People don’t realize that until they’re exposed to it and they compare, “Hey, this is what I used to have, and this is what I’ve got now,” or whatever. I think culture is a big deal. Elvis: I think even that still only goes so far. If you look at the culture of our company, it’s pretty progressive and pretty far‑out beyond what most people are doing, yet we still struggle with the same problems, or maybe struggle with them a little bit further down the road. We might have people who are a little bit better than a Joe Corporate guy, but it’s not going to take us all the way to the next level. Just Showing Up Derek: I think, sometimes, it’s even detrimental. In the sense of, I see a lot of young vibrant companies, radically change culture, in order to attract people. Some of that culture is, working 10 hours a week, and you’ve got a ton of play time. A bunch of things, that are great for the individual, and they may not even be all that bad for the company, but, ultimately, they are not really doing things that are pressing that individual to become better. Really, what they are saying is, “We’re rewarding for being a really great player, so we’re bringing you over to the Pro Bowl. Come, and play, and hang out with some other really great players, and we are not really going to ask you to stretch yourself.” Elvis: You just have to show up. Derek: Correct. Clayton: I think, if you go back to. Some soccer team, from Europe, that plays in the World Cup, or in the Olympics, those guys I think are motivated by the love of the game, and they really want to be there, and they are a great team. But then, you go back to 1990’s Iraqi national team, I get the impression, that they were pressured. Those guys I’m sure, love soccer, but they were pressured into it. There’s some level, what you were talking about [inaudible 00:19:08] . We have this culture, and we are getting there, but you still need to have that unified front. The team aspect, and trust, and all those things, still need to be there, even if you have a fun culture, and video games, and flexible schedules, and all that stuff. You still need some fundamentals, I think. What Is The Goal? Elvis: I think part of that is a goal. I think that’s what you’re driving at, Derek. Really, what is the goal behind doing this? If I’m working at Google, or Apple, there is a goal that I can get behind, that I might be willing to push myself, above and beyond, what I would normally do on my own. So, how do the average, small companies, out there, create goals that are motivating to people that are inspiring enough to say, ” Look, I recognize where I’m at, and to accomplish this goal, it’s going to take more than where I’m at. How do I get there?” Derek: I think we are hitting it right on the head. When I look at Facebook right now, today, look at the number of people that have exoduses out of Google, and jumped over to Facebook. When you look at that, Google has been treading water for the last three or four years, and Facebook has really got world domination on their mind. I think, salary, location, everything. Environment’s almost identical between the two companies. So people are really jumping, not for opportunity, but for the vision of where one is going, versus the other. Even as a small company, it really is about, really stretching yourself towards goals that people envision, that people can get behind, and can get excited about. If I go to this company and I pour my heart, and soul into it, and I stretch myself, that we’re doing something amazing. When we reach that, something amazing, that’s the reward. The reward is not the culture. The reward is not the money that I made, making it. It’s the, “I was part of the team.” If you look back at Olympic teams, if you look back at soccer teams, basketball teams, that win championships, what they talk about, is that shared experience of, “As a unit, we walked through, and we achieve this.” Elvis: I think you even see that in software teams. I was on the OS2 team, or I was on the Unix team, or the C team. That exists in software, as well. Derek: Right. I was part of Xerox Parc. I was part of the original C team, and I think, that that’s what you have to create. You have to create the, “We’re the sense of team, and, this is the purpose that our team has.” As we achieve these purposes that we put out, that every single time, those purposes get bigger, and bigger, and bigger. First, maybe it’s that we have a million users, or that we’re affecting this kind of change. Each step along the way, just snowballs in momentum, and you get more, and more buying, and there’s more interest to say, “I’m willing to stretch, not because I necessarily want to get better, but I want to stretch because I want to reach that goal.” I think that’s really what it’s about, setting goals that require people to stretch, in order to reach those goals. Elvis: I think that’s a good set up for our next podcast. Derek: Yeah. Sounds good. A little stretching. Elvis: [laughs] . All right, thanks for listening. We’ll talk to you guys next time. Derek: See you next time.

Derek Neighbors: Welcome to another episode of ScrumCast. I’m Derek Neighbors. Jade Meskill: I’m Jade Meskill. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. William Price III: And I’m William Price. Derek: Today we want to talk about… Jade: The third. William: The third. Design in Agile Software Development Derek: Design in Agile Software Development. I just want to start an open dialog on, what are some of the challenges, of implementing design in an iterative methodology. Jade: We are talking web design specifically. Derek: Lets start with web design and if you want to go beyond that we can. But lets start there. Jade: It sucks. Hard Transition William: I think my experience with design for a website or whatever is that a designer comes up with some idea of something. It’ like a waterfall. Everyone’s used to the designer comes up with something and makes this nice pretty PSD. Somebody else slices the PSD up and it turns it into HTML and CSS at some point in time, and then that becomes your web app. I think that’s probably like 90 percent of the people out there, their experience with doing design. When you take than and try to put that into Agile, it makes it really difficult to say, “Well, this week we’re working on this set of features, and we need to design for that now or soon or whatever,” because I don’t think that’s how most traditional designers work. They need more lead time than that. Overlapping Of Skillsets Clayton: Yeah, I think from a designer’s perspective the lead time is typically considered the biggest challenge, just the pace. I think a bigger challenge is knowledge and appreciation that overlaps as much as possible between developer and designer. You often hear people say, “Everyone is a designer.” That makes me kind of uneasy, because I think design is a craft. It’s a skill that you have to hone over time. Anyone can hone it. Anyone can learn it. Anyone can learn to draw. Anyone can learn to think well and design. The thing that makes me uneasy about everyone is a designer is that when you say that it’s like, “Oh, so now I’m a designer today, instantly.” As a designer that makes me uneasy, but what I need to do is develop relationships with developers and with product owners where I can appreciate their input and work with them as fully as possible. As a developer, being involved in that process and considering it meaningful I think is often missing. There are some developers that will say, “Oh, yeah. I think that’s important.” But do you spend time learning the fundamentals of design and things like that? Or do you just go by what you think looks good? Then as a designer, appreciating the developer’s input and not just thinking, “Whatever sexy pretty thing I come up with, is the best solution” because it may not be the best solution for the process. It may be a huge nightmare for everyone involved. It may be far more expensive than it’s worth. You might be developing something that looks great, feels great, to the product owner but gets torn out a month later because users don’t use it. Working together and having a tight relationship, that’s the biggest challenge in my opinion. Everyone is a Designer Jade: Well, I think to address something you said. You’re talking about everyone is a designer. Some of that came from a Thoughtbot article that we read as a team and had some discussion about. What I think he’s… Clayton: Or is it, Derek who said as a team like three years ago? Jade: Yeah, yeah, yeah. Where’s your Mike Cohn I‑know‑everything card? Can you pull that out right now? Clayton: [laughs] Jade: Now I just lost my train of thought. Thanks. Clayton: [laughs] Derek: Thoughtbot. Jade: Yes, Thoughtbot. So I think what they’re trying to drive at is not that everyone is a professional designer in the sense that we think but that everyone plays a role and should be conscientious of design, right? It’s not acceptable for developers to just say, “Well, I don’t know anything about that because I just write code” and crank out some really crappy‑looking interface. We should be at least conscientious of the basics of what we’re doing and that it should be professional and not, like I said, some hack job that you know a developer put together because you can just tell. I think that’s what they’re driving at. Sensible Defaults Clayton: Yeah, so I think an analogy would be I wouldn’t be able to figure out a good color scheme and whatnot for, say, my house. I’d probably paint the walls white and leave them some stupid color, and I wouldn’t bother decorating. But when it came to arranging the furniture, I wouldn’t put the couch in the middle of the room facing away from the TV or something stupid. So I think there’s something to be said for maybe you’re not very good with the design theory or color theory or some of the things that may be more traditional design when you think of design are. But in terms of maybe the user interface or how things flow or just sensible decisions, I think that’s the kind of designer that everyone could be. Just take a step back and say, “Does this make sense? Yes or no.” Driving The Car Derek: Analogy wise maybe it’s similar to, I expect most adults to be able to drive a car. I don’t necessarily expect most adults to be able to race formula one, or race NASCAR, or race the Baja 500. I think that there’s definitely a difference of level of, and I think there should be expectation of people who are developing software to understand, like you said Clayto, to not put the couch facing the opposite direction of the TV in a functional living room space where 90 percent of the time people will be watching TV. I think we see developers do that every single day, do things that make absolute no sense. I think to me I’ve got two additional questions on a design in iterative fashion. One is we start to see iterations become shorter and shorter. I know one time in a Scrum that was pretty much a given that a sprint was a 30 day or month long function or iteration, and now we’re seeing sprints down to, a week are pretty normal. Two weeks are probably now the standard. In some days we’re pushing more towards Kanban where it really is a sprint might be, an iteration might be, in a day, or less than a day. How’s it feasible to, not even talking about coming up with the design, but how’s it even functional to implement the design in that quick of a time frame. What are some of the challenges? We’re starting a sprint on Monday, we’re ending a sprint on Friday and we’ve got to go from design implantation in five days. What are some of the challenges around that? Tools Lacking William: I think one of the challenges is the tools. Just to make an excuse for designers, that I think is legitimate, is that the tools suck. There’s been a push to do all your design and development in the browser. Then there’s this push to handle it all CSS3. Do everything you possibly can CSS3. Granted the great designers out there are able to be really involved in the front end development and do minimal stuff in Photoshop. In general to work fast is difficult with the tools that we have. I would love to see that improved. One thing I’ve been trying to get in a project that we would do here from a designer is to as much as possible think on a feature oriented level, instead of a site wide level. To design just for what needs to be designed, you don’t need to design a whole page. If you’re developing a feature and it’s a widget in the corner of a page, the whole page could be a wire‑frame and that widget could be designed. The challenge there is to be consistent throughout, to have a good vision of where you’re going. I think a designer that has good skills should be able to do that, should be able to stay consistent throughout, to keep going within the same vein of things. To keep the look and feel going but be able to turn around a widget fairly quickly and not to get so concerned about the whole page. I’d be really interested to see a project go from conception to launch with that whole process. So far it’s been a challenge to see that. I think that could be a potential solution. Understanding The Big Picture Jade: That’s one of the complaints that I’ve heard from a lot of designers. I need to understand the big picture. I need to understand the world before we can start implementing some of these designs. If we start on sprint one, let’s just say with no design in place, we didn’t do a design iteration or anything like that. How do you see that developing? How do you maintain that vision of the bigger picture and the bigger idea when you’re doing it week long sprints? William: That’s not a rhetorical question? You want me to actually answer that? Jade: No I want you to. William: [laughs] That’s a difficult thing to ask. I think there’s different scenarios. Are we talking about sprint one is a true sprint one and there isn’t this backlog of things that have been predetermined. I think that’s one thing that weighs designers down is when there’s already a whole bunch of stuff predetermined, and they’re saying, “Wait, I can’t think about this. If this is going to happen, I need to think about this.” I think a great example of success is Tumblr, which is founded by two guys who had a division of labor between them, but they had a major overlap. They were both very invested. One was a developer and one did business and design and stuff like that as far as I know. And they worked iteratively. I think Tumblr has a beautiful interface. It’s very usable. It’s very simple. I don’t know what their sprints were, but they worked a portion at a time. They kept maintaining. I think whenever they came to a big impasse, as far as I can tell, where there’s going to be a major shift, that’s where you look at, “Do we refactor design?” I think there has to be a willingness to say, “OK. We’re going along. We’re consistent. We’re going a certain direction. OK now, we’re going to make a big leap in a different direction, or a change. We’re doing something we never foresaw doing, and so that means that we need to go back and rethink what we’ve already done.” I think the big fear is, “We’ll never get a chance to do that, and if we don’t got it right the first time, we’ll never be able to improve.” Jade: I think that’s a little bit easier to accomplish when it’s a couple of people, and you’re personally invested in…You’re not only just the developer. You’re also a stakeholder and product owner and all those things. It’s easier to manage that relationship because the relationship is with yourself. In a typical scrum team of five to nine people, that gets a lot messier and a lot harder to deal with. I don’t know what the answer is to try to do design at the same time as development. You see a lot of people trying to run design ahead of the game, but that leaves some opportunity for mistakes and waste. “If we don’t do that story next sprint, now what?” The world changes, and we’ve got to re‑prioritize the backlog because some new business requirement came up or some new opportunity showed up, and now, there’s no design for that. Now, it’s chaos and panic. Modern Skills Clayton: I think that as we get towards the shorter iterations, the idea of doing work in Photoshop and then slicing it and chopping them off into a lot of stuff, I think that totally goes out the window. The same way that I don’t think you can go forward from, today, being a developer who just writes code, you have to have other skill sets. I don’t think that you can be a designer who doesn’t know HTML and CSS. I think that if you can get to a point where you are getting out of Photoshop as early as possible, that gives you the ability…I think there’s something to be said for having a Photoshop mockup of something to show people because people think that way or they like that stuff. If you can do design upfront or at least do a week ahead, whatever sprint ahead, where you’re not designing specific features that you might not do, but if you’re doing things where you say, “Here is the overall look and feel of the site…” Personally, I think that if we got towards where people are using style guides where you could say, “Here is the overall look and feel of the site, and here’s the style guide for 80 percent of what you’re going to run into as you’re developing the feature,” then the developers can hit the ground running with their iteration, not having specific design for every single feature, but they could have enough to get by where they’re not going to get hung up on something. And if they do, it’s probably just a quick fix. They could just talk to the designer about what’s the best way to handle this. Then, now that that frees up the designer to work on…If there are specific feature things, you could do something where they’re one step ahead of you where the world isn’t going to change that much perhaps. Style Guides and Frameworks William: Yeah, I think a style guide is a great way going back to what I’m saying later about keeping that consistency. You could spend that time upfront developing that style guide of colors and padding and margins and things like that, grid, all that kind of stuff, and then live inside that model, that framework. Designers do great inside a framework. I don’t know a single designer that resents having a framework to work with within. It’s actually freeing. I think another thing that can speed up the process is, I agree with Clayton totally. That you ought to have that ability to be a front‑end developer at least the HTML and CSS and to do that. But instead of spending all your time in Photoshop, maybe spend more time with pencil and paper. One of the first things that they’ll teach you in your design fundamentals class in art college is your first idea usually seems great and almost always sucks. Sometimes your first 10 ideas suck. One of the first assignments I ever did was I had to do a logo of my initials a hundred times, a hundred different logos. It was bang your head against the wall annoying. After 50, 60, 70 of them, you can’t think of any new way to do it. As a designer, you learn to be that way. So if you go straight to Photoshop, it’s a struggle to do that because it takes time. But if you go straight to the browser, it’s even more frightening because it’s like, “Well, if I do all these and I get it but it’s not the best solution, I have to rip it all out and start over and rip it all out and start over.” But maybe if we spend more time as designers with pencil and paper going through that mental process of bad idea, bad idea, bad idea, decent idea, bad idea, bad idea, bad idea, there’s the one, and then go straight to the browser and implement. Or like you said, minimal time in Photoshop creating an element like a tiled background image or an icon or something like that, and then get that in there. I think that could be a great process for a designer where they know their style guide. They know their framework. They hash through all the ideas on pencil and paper. Then they get to the browser as quickly as possible. Usability and Discovery Derek: One thing I thought that was interesting at the beginning, as you said, it’s really difficult when you see the entire backlog and to not think about everything in that backlog. I think that developers fall in that same trap. “We’ve got an architect for the 491st thing in the backlog even though we’re on sprint one.” In the back of my head, I’m wondering, “Is this one of the reasons that maybe Kanban has taken a little bit of frontrunner approach, and that a lot of people are liking it is that it tries to move so quick and obfuscate more than the next 10 items? Does it give a calming effect to designers and developers that they’re only worrying about the next two or three things as opposed to item number 391?” I think it’s part of a different discussion but interesting nonetheless. So product owners hide as much of your backlog from your developers and your designers, and you might see their velocities go up perhaps. It’s a theory. You might try it out, but you might try it out. The next question I have, and this starts to go into a different element of design and what we’ve been talking about here which is probably more of the visual design and that is…I hear a lot of people say and really talk about, “How do you do usability or discovery?” “How are you going to ask an audience of people? How do you really get these questions answered about what the product is really supposed to do and how it’s supposed to work?” I think a lot of people even ask, “What happens to the business analyst?” We used to have this business analyst. Now, we’re in this Scrum team. How does a business analyst go gather data for a particular user story during the actual sprint? If I’ve got a 5‑day sprint, how do we do discovery on what the best way to solve this problem is within a 5‑day sprint or a 10‑day sprint, opposed to being able to gather some of that information up front to understand that? Maybe talk a little bit about some of the challenges or some of the things that we lose by not doing that as much anymore as we used to, or how we can incorporate that into a shorter sprint length or sprint cycle. Clayton: I guess I’ve never really been convinced that…Even if you had a business analyst and you had people that were out doing a bunch of research and interviewing potential users and blah‑blah‑blah, you’re never going to come up with a great solution on the first go anyway. It seems like you have to go take that leap of faith into Scrum or Agile or whatever and say, “I’m not going to get it right the first time, but I’m going to get something out there that we can start working with and gathering feedback on.” I feel like it’s like an “emperor has no clothes” thing, because there’s a lot of people that are probably thinking, “That might work for your project, but, trust me, I really need to know all these details for my project.” I don’t think that is the case in almost any instance. Derek: Let me, maybe, rephrase it to make sure I’m understanding. You’re suggesting a way to combat this is to actually release shippable software as often as possible and use the shipped project as the way to collect that information. Once you get that information, iterate and make the changes necessary, based on the feedback you got from real customers. Clayton: Right. Yeah. Actually use the point of Scrum or some other process. Okay To Not Be Perfect Right Away Jade: I think that’s pretty interesting. Maybe that is some of the source of the problem. We’re OK with not getting development exactly right, right out of the gate, but a lot of the projects I’ve worked with, they’re obsessed with the design being correct the first time out of the gate. “We’ve got to get it right. We can’t afford to mess this up, because then nobody will ever come back and use the system again.” We’re psyching ourselves out, because we feel like we’ve got to nail this thing the first time around. We completely forget to be Agile about the design itself. Excitement Vs Mundane William: Yeah. It’s a lot like the whole Flash mentality of, what, the early 2000s, which was, come out with this Flash app that’s your whole site, that’s so fun and there’s things flying and noise being made. The Internet was so new to people that they went and used it and were like, “Oh, my…You can do this on the computer? This is amazing!” Then, it lost luster because people were like, “I just need to get this data. I just need to know how to get there. I just want to know what the hours are. Just tell me.” Now, obviously, with mobile, everyone knows the implications of that. Point being is there was this ability that people had, developers and designers to shock and awe people and to get them really thrilled. That was mostly because the Internet was so new to most people. That’s over now. It’s done. You’re rarely going to put something out that is going to excite someone just because they looked at it. If you’re a designer, you’re going to look at design and be excited by people’s good work. If you’re a developer, you’re going to look at ideas and concepts in development and be excited by their elegant solutions and things like… Jade: APIs. William: And APIs. Yes. Jade: [laughs] Their sexy, sexy APIs. William: And their fables. Derek: Shiny. Jade: [laughs] William: But your common user doesn’t care. I mean, they do but they don’t. It’s really a combination of everything that matters to them. Can they get what they want quickly? Can they get through it easily? Is it confusing or not? Does it look good? Meaning, good to the layman, decent, not look bad. Does it look broken? Does it look inviting? Does it communicate the brand? Those kind of things are the big pile of influence on whether or not a user wants to keep using it. The big temptation, I think, with design is that a lot of times, product owners that have an eye for design and designers want it to be so attractive and so exciting that anyone who looks at it is going to be really impressed. I don’t even think it’s an ego thing most of the time. It is sometimes, but most of the time, it’s a business value thing. It’s like, “I think that if this gets perfect, then people will be thrilled and excited and think it’s the best thing that’s ever happened.” But it’s not that simple. Users don’t work that way. What Can I Understand Clayton: I think another big part of it is that if you’re the product owner for some start‑up or even just a product owner, maybe you don’t understand the technical details, but you know what looks good and what doesn’t, according to you. I think that’s why everyone gets so caught up on the design stuff. It’s like, “I don’t really know how this workflow should work, and I don’t really understand what you’re doing in the ‘backend,’ but I can look at this and say, ‘Wow, that’s really pretty.’ There’s other websites that I like, and they look kind of like this, too. The people that I want to attract on my website, they look at those websites, too.” It’s just something…It’s simple. It’s a high‑level thing, but everyone has an opinion about it. Product owners generally don’t have an opinion about how you implemented that technical thing, but they have an opinion about how it looks. Jade: I think it’s a trap, too, because it might look really good, and it’s a total disaster from a functional standpoint. It might look shiny and pretty, but when you go to implement it, users just can’t understand it. “But, man, it looked so good on that comp that I got.” Overnight Success Fallacy Derek: I think the biggest trap that people fall into is, everything was an overnight success. If you look at ‑‑ I use an example of Twitter. If you were to look at Twitter today, it looks pretty reasonable. It’s got some pretty sexy UI elements. It’s got some nice UX layouts, where they’ve got some sliding drawers and some techniques that are a little bit more cutting‑edge. If I were to try to create something that competed with Twitter or had functionality similar to Twitter, I wanted a timeline feed, perhaps. And I said, “I need my timeline feed to look just like Twitter, because people will not accept a timeline feed that’s not as good as Twitter’s timeline feed.” What we forget is, rewind back five, six years to when Twitter started and look at what Twitter’s timeline… Jade: Look at the first release of Twitter. Ugh. [laughs] Derek: The new, and I’m doing air quotes here, Twitter didn’t come out until a few years ago, after or, not even a few years ago. Less than 12 months ago, after they’d already taken almost $60 million in funding. I think, with it, that people get obsessed on, “I have to compare myself to the thing that is fully funded and has been out for a better part of five, six years and has hundreds of millions of users on it. That’s my benchmark.” Instead of saying, “We’ve been working on something for three months, and we want to release the first version within the next quarter. We need to iterate over how our users use this product.” I think you’re absolutely right. People get way too fixated on, “We have to ship finished, and we can’t iterate, but code wise, you can do whatever you want. If we need to add a feature here and there, that’s great. But the minute we put a feature out the door, it has to be perfect, because we can never come back and visually make it different, functionally make it different, or aesthetically make it different, or people are going to say that we failed and we didn’t work.” I think that that’s a mistake. Feature Parity Jade: I think there is some challenge in that, though. Because the Internet is moving at such a fast pace, there are some pretty revolutionary things that come out, that do become almost mandatory, that do become expectations of how things should work. I think that is a challenge that we’re always going to be faced with, is how to keep up with the things that are now mandatory, that six months ago were nice‑to‑haves. William: I agree with you, Derek. I think, I would challenge a little bit the idea that people, product owners in particular are comfortable with not having all the functionality as well. Derek: Yeah, I agree that a lot of them don’t do that. William: You go, “I want to go up against this x thing that’s been around for six years.” They’ve had six years to develop all their features. When I come out of the gate, I want to be at par with them, in six months. I think that’s a major issue for design, because what you end up doing is just, as quickly as you can, designing everything. It over‑accelerates the pace of development. You shouldn’t be trying to develop. The one that product owners love to reference, Facebook. Jade: Facebook. Yup. William: In six months. Jade: But it’s already been done, Billy. William: “But it’s already been done.” Yeah. So why are you doing it again? [laughter] Derek: My idea’s different. Understanding The Problem William: Here’s the thing about really great design. Going beyond the skin of it, going beyond even the couch analogy, is, it takes time to really understand whatever your problem is ‑‑ however you want to look at it. Your problem, your problem‑solution analogy, your friend, your creation, whatever. It takes time to sit with it. Going from an iterative perspective, allowing things to come out of the gate less than perfect, and building from the ground up. I’m not talking about slowing down development or doing it deliberately more slowly, but increasing the amount of releases you have, and accepting that you’re not going to make a world‑changing design on day one. What that does is, it allows your design team to really get to know the brand the way the users encounter it, to get to know the way the users want to use it. You get that time to realize, what people are doing with Twitter is not what we thought they were going to do with it. The way people are using this or that product, this was not what we expected, but this is what they believe we are and what they want us to be for. Then, it allows you to go back and do what new Twitter did when they said, “We’re not a social network. We’re an information network. From now on, that’s what we’re focusing on. We’re going to design for that.” Then, you can come out with something that’s sexy and impressive and great. Jade: And functional, and accomplishes the business goals. William: Yeah. It’s not contingent on success, that you come out of the gate at that point. Which is the big fear, is that if we don’t come out of the gate at this level that’s way up here, then we’re going to fail, because no one is going to want to look at it. But you don’t even know where people are at with it yet. Derek: Thank you, guys, for your time. I think, hopefully, in the next quarter or so, we’ll do another one of these on design and talk about some of what we’ve learned and where we’re going with it and maybe invite in a couple of outside guests and see how some other shops are doing it. Until next time, we’ll see you. Thanks.

Derek Neighbors: Welcome to another Scrumcast. I’m Derek Neighbors. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Done Is Done Derek: Today we want to talk about something that a lot of teams struggle with, and that’s the concept of “Done is done”. I guess to start off with Clayton, what do we mean when we say “Done is done.”? Clayton: That’s a hard one to sum up in one phrase. There’re a lot of things that go into it, but I would say that it’s basically, if you want to go with more of a book answer, you want to delivery potentially shippable software. That’s an easy definition for that. Obviously you need to expand on it. Where Do You Draw The Line In The Sand Derek: There’re a lot of exceptions depending on the size of your team, and what team functionality is. You might draw a different line in the sand of what is done. Meaning, maybe I’ve got a Q & A team that is entirely separate from my team so done is done for. My team would be making sure that we’ve done A, B and C, and we’ve handed it off to the Q & A team, and when we’ve handed it off to the Q & A team it’s thereby done. For today’s conversation we want to talk about “Done is done,”, is that a single team is responsible for the entire chain all the way to deployment. What does it mean to be done in order to deploy? What we see a lot is a developer will say “Oh, this is done.” “Mrs. Product Owner, it’s out there. It’s totally ready to go. Go check it out.”, and a product owner comes in and they go to the website and say “I don’t see how to…Where do I get to this”? “Oh. Well, you have to enter like this super magic URL to get there.” “OK.” They go in and they pull out some data, and they press a button, and boom the software blows up, and then there’s a defect. Obviously not done, but thought it was done. Today maybe let’s go over what are some things that hold developers back from being able to give product owners features that are actually done the first time. Lack Of Automated Testing Clayton: Take your maybe less savvy, what you want to call it, developer not doing any automated testing. Those people in my experience…I got into the industry. I’m going to do some feature, and I’m going to spend a lot of time manually going through their entire process. I know how to make a testing, but one way that people go wrong with that is they choose the golden paths. It’s a phrase I’ve heard before. I know that I need to fill in on these fields, and I know that if I put a two highway number in this field, it doesn’t going to work, so I normally put ten in that field. I know that I need to press the submit button, and I know that when I get to the next page, there’s a bunch of [indecipherable 03:18] , but there’s this little link down here. If I click on that, “OK, sweep, it’s done.” They’re just lazy in that regard. They don’t think about it in terms of how someone actually is going to use it. I would say for the more savvy developer, that’s actually writing automated test. It’s really easy to do the same thing when you’re testing. You have different test cases, but you still do the golden path for a lot of those. You don’t think to put in much crazy test cases, maybe you shouldn’t. You don’t necessarily wanting to catch every single edge case, but it’s still easy to do that. Also, you get the false sense of security of while this feature is tested when you actually maybe deployed of that. The product owner is looking at it. They don’t do the same except that you did in your test obviously. You get the ball of the software. Works On My Machine Derek: I definitely think that that’s one of the biggest things that…at least in web development. I don’t even say we see this a lot in mobile development. It’s not actually deploying to target platforms and do the testing. It’s the classic, “Hey! This works in my environment. Everything is great,” the works on my machine syndrome, so going along, blistering along, everything is great, and I handed off, and the product owner complaints that it just doesn’t function at all. You scratch your head and say, “How the hell? I’ve worked on this for four hours, and I’ve not seen anything remotely close to what you’re talking about.” You’re completely crazy. You go to the diversion of the operating system on the mobile device or their particular mobile device where you go to their web browser and you go, “Oh, oh, oh. I forget about that dependency or whatever.” That is probably one of the lowest hanging pieces of fruit that developers can do to get a better done is done and that is, make sure that you’re deploying to a solid target platform. If it’s multiple platforms, we see this as mobile, if you have to support multiple versions of the operating system or multiple versions of a browser, they are actually doing deployment and a test with those and before you ask that product owner, do the same thing. Because invariably, they will pick the one platform that you did not choose to look at, in order to do their testing. An Appropriate Dataset Clayton: Going along with that would be appropriate data set. It’s really easy when you’re developing some feature, and you’ve got your two dummy users in your system, and everything’s kosher. Then you’ve got to deploy it to the target platform, or the staging server, even in production. Everything goes great when I looked at it, all the functionality works, but it’s unusable. A big part of done is done, is that from beginning to end of the whole feature, it needs to be usable in a reasonable way. Not something that requires tricks, excessive waiting, or all those kind of things. You really have to be sensible in that regard. Missing Roles Derek: That’s a big part. Even automated testing sometimes even makes it worse, but regardless, it exists even without automated testing. That’s the whole sensible workflow chain. What does this feature look like from cradle to grave? We get too hellbent on, “We’ve got these great regression tests, so when I go add this new piece of functionality, a feature that builds upon new feature, I’ve already tested the original feature. I’m testing the feature that I’m building that piggybacks on top of this feature, I don’t need to go walk through the visual workflow.” In reality, the product owner gets to it, and they say, “I did this, and I did that, but there’s no way to get to this other thing short of having to go the long way around the fence.” The other one I see a lot of times is missing roles. It works great as an admin, but as a guest it doesn’t work. It’s supposed to work because you’ve built this funky thing on. Making sure the UI and the UX are reasonable is a big part of making sure that things don’t come back. UX Isnt My Fault Clayton: A lot of that, the UI, UX stuff…A lot of developers probably put on their I’m‑a‑developer hat, and they don’t want to get into the front end or UX mentality. Even if you read some basic stuff about UX or information architecture, or whatever those people call themselves these days, even if you knew basic stuff about that, it’s really just a common sense thing. I know common sense isn’t very common, but there’s a lot you can without really having to exert a lot of effort on your part while you’re developing the feature. Most of those things, in terms of the UX stuff especially, and the workflow, comes from communication with the product owner, and planning. That’s probably one of the biggest ones that prevent developers from delivering something that is actually what the product owner wanted. Derek: What I see a lot, especially with people who don’t have as much experience or don’t have confidence, is they’ll have a planning meeting with the product owner, they’ll get some reasonably good wireframe, UX, UI, the designer would get involved to do that. They’ll go to start implementing the feature, and they’ll know the workflow is broken when they’re doing it. Instead of raising the red flag back up to the product owner, or to somebody else on the team who’s responsible for UX or UI, and saying, “This feels really clumsy. You’re asking me to select 100 items here, but if you try to select more than 5, it takes forever. Isn’t there a better way we can do it”? A lot of times, developers shirk that responsibility, and say, “I’m not the designer, I’m not a UX guy. I’m just going to implement what was given to me, and what was discussed.” The first thing that happens is the product owner or the designer might even sign off and say, “Yeah, it looks great.” Then they give it to the first user who actually has to select 100 things out of that 1000, and goes, “This is the worst piece of software, I can’t use this.” The developer instinct is, “I knew that.” If you knew that, you need to speak up. That’s a big part of it as well. Simplest Solution Clayton: More often than not, you probably run into a situation where you don’t wireframes necessarily or lots of well thought out interface elements, and things like that. When you get into that mentality, especially when people feel like they’re crunched for time, they try and use the simplest possible solution. Going back to the Web application example, if you don’t really have a whole lot of design elements in place, or a style guide for instance, and you’re just winging it, it’s really easy to crap out a bunch of stuff on this page. And it totally doesn’t make any sense. Submit button is this thin little thing that’s way off on the right‑hand side. When developers use a site like that, you tell them, “Go use this antiquated government website,” all they have to say are all these terrible things. “Oh, I’m so much better, and I would never do this.” But when they’re crunch for time or even when they’re not crunch for time, when they’re just trying to get the feature done, they say, “Hey sweet, I got the feature done. It totally works. I can click through it,” even though for the product owner or maybe a not so technical person or especially a user, it’s like, “What’s this huge thing I’m staring at? I have no idea how to do anything. I don’t know how to start.” Entry and Exit Points Derek: Yeah. Another part that comes along that is, sometimes we get such tunnel visioned on doing iterative development that we only think about the current iteration, the current feature set that we’re on. We forget those entry and exit points and some of those workflows along it. Maybe I’ve got some form of object that’s got some attributes on it. It goes through some form of a process to do calculations or to do something, and somebody asked for this brand new piece of functionality. He says, “Hey, I need to be able to calculate this new thing. I need a new attribute, and based on that attribute, I need to calculate new values. After 30 days, you need to go check this other attribute and re‑tally something.” So we go, and we add the attribute to the table. We update the calculation. We write this really fantastic test. We ran all of our regression test, and we say, “This is awesome. The feature’s implemented. We’re golden.” Then the product owner goes and says, “Look, I’ll go and check that.” And the first thing they do is, “Um, there’s no way to add the new value to the attribute.” We’ve totally forgotten that, “Oh yeah, we inserted that in the database, and we inserted that in our test without ever having a screen going and updating the screen for that object to allow for that attribute.” Sometimes it’s as simple as asking another person on the team that’s not part of that process and say, “Hey, can you just take a look at this and run through it really quick.” And you find that kind of stuff right away because the first thing they say is, “Where do I put that new value”? Clayton: Right. Two big questions that would be huge wins for most teams would be, when you’re discussing a feature with the product owner, being able to say this question of, “How do I get here, and how does the user get here? Then after they do this thing, what happens next”? You can imagine a system where you built some system that takes a report that someone generates. They type up some values in some text file or whatever, and they are supposed to be able to put this report into the system. Then there’s some black box that happens, and then it spits out some report. People forget to ask, “Well, how do they get the report in the system in the first place”? because that’s the sort of thing that I think developers…They would develop the system, and they would say, “Oh well, I’m going to use my shell script that I wrote to import this file and parse it and blah, blah, blah.” Then they’ll tell this little old lady user who works part‑time, “Yeah, just use your shell script.” “What”? Then when things come out, it’s like, “Oh, your report was generated. Where do I get it”? “Oh yeah, just SFTP into this thing, and find it directly with your username.” It’s like, “Whoa, shouldn’t that get like emailed or put in a public place or something”? Those kinds of things. The, “How do I get here? What’s the entry point”? And then, “What happens next after I clicked the feature”? Those are two very important questions. Planning Meetings Derek: A lot of these things obviously can be addressed during planning meetings, meaning that if you’re asking a lot of these questions during your planning meeting, you’re getting good quality wireframes. You’re having those visual discussions and those entry and exit points, those workflows. It avoids a lot of problems which comes to the last thing and that’s…At least here in Integrum, we do something where we have acceptance criteria, and when we walk through the product owner during planning meeting, we basically say, “What are the terms that consider this complete”? I think that access a checklist at least on a functionality perspective for both the product owner and the developer to say, “I really shouldn’t be telling the product owner that this feature is complete. I know what’s done, these things that we agreed upon at the planning meeting.” It also allows the product owner to say, “Let me go through this checklist to make sure that the developers said what we agreed upon.” Though, I don’t think that’s enough. That’s a really good start, but I still think ‑‑ what we talked about ‑‑ is the design acceptable? Is the UI acceptable? Do we have the proper entry and exit points? Do we have a sensible workflow? Have we tested it on production? Did we have somebody else on the team test it on production? Is it shippable? Is it deployable? There’s a lot to it. I guess what I’m saying is, developers do not be so lazy when it comes to the point. A lot of times we try to push all the responsibility back to a product owner or to a QA team. In 20 years at software this has been problem in every single company I’ve been with. Even with the QA team…The QA team says, “Listen assholes, you guys don’t ever test anything before you give it to us. What’s wrong with you”? I’ve heard product owners say, “Why do you keep asking me to check this out when it doesn’t even remotely close to work”? How do we get to the point where when we got this checklist or this formula of “these are all the things we need to do” that we actually do it? Using Checklists Clayton: That’s a hard thing to overcome in the sense of…Until you see the value that you get from that, it’s difficult to get yourself in that because it is extra work. Most people or a lot of developers have this idea of “That’s not my job. My job is to write code and implement the feature, and your job is to test it or whatever and make sure that it works, QA team people.” But if you look at it from some other aspect of your life…For instance, my wife and I, if I say, “We have all these dishes in the sink, and we need to put them in the dishwasher or whatever.” And I ask my wife, “Is that something you’ll be able to do while I go do this other thing”? And we’re exchanging things. She’s going to be pretty upset if every single dish I’ve ever put in the sink that week or that day or whatever has tons of fruitcake onto it. So there are certain things you’d have to do so that the next person in line…And I know that the benefit I get from taking that extra step is totally worth it. I know that if I follow the checklist, and I make it really easy for the product owner to sign things off, and I make it really easy for them to say, “I was able to go and demonstrate that this feature worked. It looks perfect. It’s just what we talked about,” that’s a huge win for me because now that that feature is actually done, I can move on to the next thing or I can complete some other story. It’s not this idea of, “I’m going to do a whole bunch of work, and then tell you halfway through the iteration, “Go take a look at 80 percent of the work that I’ve completed.” Then you find out, “Oh well, this is broken. This is broken, this is broken,” all that stuff and I have to go back and fix it.” If I have this confidence that when I say something is done, it actually is done, I don’t have to think about it anymore, I can just keep going. So getting people to understand that value, that’s a way that we can get people to start adapting the practice of following that checklist and really thinking about these things. Derek: That’s just a good area that almost every team can improve upon. Again, whether you have a QA team, whether you are the QA team, whether you rely on a product donor or a third party to do verification for you, this is something every team can inspect and do some adaptation to and really improve their quality level, it’s independent a code. It’s really a discipline based improvement and so we just encourage you to check it out. We hope to see you next time. Clayton: Thanks.

Derek Neighbors: Welcome to another episode of the “ScrumCast”. I’m Derek Neighbors. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Agile Just For Teams Derek: Today, we’re going to talk about a couple things. First, we’re going to field a question, and the question is, “Is Agile just for teams, or can it be used for solo workers also”? Clayton: My experience with this is, I’ve done a lot of stuff, just personal projects, goofing around basically on the weekends, and I try and use some scrum process. The thing I’ve noticed is that, I feel like at work I’m a very disciplined person. I have lots of discipline in that regard, and blah, blah, blah. When I try and do it by myself, I feel like either I have no discipline or I don’t have enough. In my experience, I’d say that if you’re not a very disciplined person, it’s difficult to make it work. There are some benefits from it as far as…everyone has an experience with a personal project that just languishes and goes on forever, and you never finish it. There’s probably a lot to be said that Scrum could help you out with, in that regard. I don’t feel like I have the discipline to do it, myself. Derek: A lot of agile techniques work fairly decent. In a solo environment, a lot of the principles do unexpectedly iterate. Using iterative approach, time‑boxing, continuous improvement, all of that stuff translates perfectly. When it gets a little bit more to estimating and doing some of the heavier parts of the methodology, it’s much more difficult to be disciplined about that, in a solo environment. It’s feasible when it works, but you have to have a lot of discipline to do it. Today, I wanted to talk a little bit about pairing. Clayton, as a team lead you do a lot of pairing on interviews, here at Integrum, and you get to see a lot of pairing. I wanted to talk a little bit about what you think are some traits that make somebody a good pair. What Makes For a Good Pair Clayton: In pairing the most important one is being engaged. That’s a broad term that means the concept of being a good listener, paying attention, being interested in not only what’s going on, but also…when’s someone’s driving, or they’re solving a technical problem, it’s easy for them to get in that mindset. You have to be able to switch back and forth, and switch modes. If you’re the person, you’re not driving, you’re the passenger, you need to be able to keep focus on maybe some certain processings, or the non‑technical things. Obviously if you are driving, being able to get into that mode and not worry about those things. Let someone else take care of that for you. I think that’s a big one for me. Outside of that, I would say that being a good pair is one of those things where I don’t think there’s a real good book answer for it. If you were to try and do something by the book or write a list of things that you can do to be a good pair, that would be really hard to come up with that list. It’s more of a matter of good communication, good soft skills, those kinds of things. I think that’s most of it. Pitfalls Of Pairing Derek: What are some of the pitfalls? You get to pair with a lot of people who are new to pairing. What are some of the things…when you see two people that maybe have never paired before and don’t necessarily have good habits, what are some of the common things that you see where people fall down in pairing? Clayton: The driver‑passenger role is one that people don’t do a very good job of. Especially people that are new that say, “I’m a coder; I’m a programmer.” They have this idea of what that means to them. Then when they’re not driving, there are some people that fall in the subset of, “I’m going to micromanage every decision that you make while you’re driving, because that’s not how I would do it.” There are some people that say, “Oh sweet, you’re doing all the work. I’m going to kick back and check my emails,” or whatever. Even in the pairing interviews, we notice that people, obviously they’re there for an interview, they’re trying very hard to be polite and engaged, and all those things. You can definitely tell when they get the keyboard, you mention something, “Oh hey. What about this?” and they can’t even hear you. I think people don’t have that, not listening when they’re driving. Other than that, pitfall wise, people fall into categories of being a bad driver; just going down some rabbit hole ignoring what the other person is saying. The passenger plays an important role in guiding you, especially if they say, “Hey. This doesn’t look like a good path to go down.” Bad drivers just ignore that. The one that we see the most is probably bad passengers. I think body language is a huge thing. If you ever want to evaluate people that are pairing, just look at the driver and the passenger. Usually the driver is leaning forward, because they are using the keyboard. Most of the time, you will find the bad pair who are the bad passengers, are the ones that are leaning back. They don’t have their shoulders facing the workstation, that kind of thing. The people that are leaning forward, have the same body posture as the driver, those are the ones that are probably more engaged. Getting Up To Speed Pairing Quickly Derek: In dealing with a lot of people that are new to pairing and getting them up to speed, what are some things that you found have been successful in getting people up to speed with the concept of pairing in a fairly short amount of time? Clayton: Brief overview of the role of the driver and passenger. A lot of people view pairing as, “Half the time, I’m working. Half the time, I’m watching someone else work.” They don’t understand what really they’re supposed to do when they’re not actually coding. Getting people to understand that is very important. After that, I would say that there are bunch of games that we’ve had some good experience with. Ping Pong Pairing where one person writes the test, say a failing test, and then, the other person has to write the implementation for that to make the test pass. That’s a great way for both people to be engaged and both feel like they’re doing something. Another one would be switching off at predetermined intervals. Say you set a timer for 15 minutes and it’s not this thing where the timer runs out and the person that’s driving says, “OK, cool, give me another two minutes, I’ll finish this up.” It’s literally, 15 minutes is over and slide the keyboard and mouse over and the other person has to just pick right up. You can’t…it’s very obvious that you’re not being effective when the first 15 minute bell goes off and the other person is like, “Oh. What was on the menu?” They don’t have any idea. I think that’s a really good one to keep people engaged. I’m trying to think of some of the other games we played. One that’s good, actually, for a lot of people have a criticism of pairing, is that they feel like, “Well, I’m really good at what I do. I’m a really good developer. I don’t want to pair with people that aren’t very good because it slows me down.” One thing that you can do to improve those people on your team that may be more junior or don’t have your level of expertise, which you probably don’t have any, but you think you do. But, those people, to train them or to help them out, would be to do the distant passenger. A lot of times, I see that when people are in that situation, pairing the person that’s the more senior person will be micromanaging and driving and basically, telling them, dictating what to type. “You should write this method. You should return it this way. You should use the turner in, blah, blah, blah. If you talk at a higher level and say, “Well, we want this model to be able to…we want this instance of this object to build or respond to this method. I want it to return a hash of these things.” When you speak at a high level like that and then, you let the person go do the implementation. Whether or not you’re doing TDD even, but let the person do the implementation and then, maybe set aside some time at the end to do some kind of code review of like, “OK, see how you did that. You solved the problem. Here’s how I would have done it.” Have that discussion. I think that’s really helpful when you have a mix of skill levels. Loud Environments Derek: One of the things we see, obviously, operating on the Gangplank because it’s pretty noisy in here. We’ve got a lot of people pairing in close proximity. One of the things that a lot of people ask me is, “How can your guys be developing in such louder, chaotic environment” Maybe if you could explain a little bit about what it’s like to Pair Program in an environment where you’ve got lots of people Pair Programming in fairly close proximity and whether that positively or negatively affects productivity. Clayton: I’ll give an example, recently one of the guys on the team got everyone little [Nerf(https://nerf.hasbro.com/)] guns that shoot darts. For the past two weeks, it’s been like every day, it’s people shooting darts. You could be sitting there, trying to solve some complex problem and darts whizzing over your head. That’s the nature of the environment. I found that a litmus test for me is if I feel like I’m distracted or I hear people talking about, “I can’t get anything done today,” I feel like that’s not good pairing. Or there’s a problem with their pairing because I notice that when I feel like I’m doing a good job and have an engaged pair and we’re really hammering things out, it’s almost like all that stuff just doesn’t matter anymore. It’s really easy to block it out, probably more than people would think. You’ll notice that when people aren’t pairing, a lot of times people will put on headphones and try and get into the more traditional coder mentality of, “I’m going to go into my own little world, so I can’t hear or see anything. Don’t bother me kind of thing.” When you’re pairing, you, obviously, can’t do that. When you’re pairing, you don’t really need to do that as much, in my opinion. Trantric Pairing Derek: What you’re saying is you like to look deeply into the eyes of your pair and have some tantric pairing going on and nothing else in the world exists except for your pair? Clayton: No, it helps if you have a little mirror, so you can glance at each other’s eyes every now and again. You put that above the monitor and you’re good to go. Pair Setup Variations Derek: I think that’s something interesting. One of the things that I’ve seen people talk about are some different pairing techniques in the way of physically setting up how you are pairing, whether that be some face‑to‑face pairing, some potentially pairing without even a laptop or a machine in front of you to solve the problem. Then, to go to actually pair to implement the problem. Have you tried any of those things and if so, what are some of your thoughts on those? Clayton: I tried the face‑to‑face pairing at one point in time. That was quite a while ago, I would say, before I was…I was trying things out. I don’t know. I hadn’t made my mind up really on pairing yet. I found that to be distracting. It seems like the face‑to‑face stuff would be good and maybe it just was the person I was pairing with, but I found like it was more convenient to be looking up and away from what we were doing and doing a lot more conversational talking. That was probably the down‑side to that. Other than that, as far as different pairing configurations, one technique that I had to do working with someone, this is easy to do when you’re pairing. People have a certain different degrees of personal space and that kind of thing. I had noticed that every time we sat down at the desk, this person would always sit in the middle and so it’s like I found that towards the end of the day, I would be pushed over to the side. We got to a point where we drew some lines on the desk with some tape and we said, “OK, here’s our zone where we need to be and if we drift out of this zone, then one of us is going to be uncomfortable because we can’t see the screen or whatever.” That brought us actually much closer physically together in that regard. Then, we also made a rule that the keyboard had to be in a certain spot on the desk. That was a way of balancing that stuff out so we could say, “We’re slightly off center from the desk and from the keyboard and the mouse and everything, but we’re still comfortable.” That cut a lot of problems out because we didn’t realize how much time we were spending nudging each other left or right and repositioning yourself through the day. Once we set that ground rule, it was easy to be able to get going, keep going. Pairing Station Configuration Derek: That’s a good segue into the physical set‑up. Tell me a little bit about what your optimal pairing station is. Is it a one keyboard, one mouse, two keyboards, two mice? If you’ve tried some different variations, why you prefer one over the other? Is it single screen, double screen, preference of one over other? Clayton: As far as the screens and work station set‑up, personally, when I was maybe younger, there was this dream of like I want to have 10 screens in front of me and that seemed so cool. Then, as I’ve gained more experience, if I just had one…we use iMac. The 27‑inch iMac, that’s got a big screen on it. Sometimes people load up that screen. Traditional set‑up is that screen and a secondary monitor. People load that stuff up with just tons of things. I feel like it’s distracting for one thing. When I’m sitting on the left side of the station, I like big fonts and everything, but I have a hard time reading specific code or terminal or whatever that’s on the complete opposite side of the desk. In that regard, I would prefer to probably have one monitor. As far as the keyboard stuff, I personally like two keyboards. The reason I like that is because two keyboards, two mice. I’ve noticed that when you’ve got someone who’s pretty strong willed and they want to go down their own path, and they’re pairing with someone that maybe isn’t, maybe someone that’s more willing to go along with them, it’s harder for that weaker willed person to grab the keyboard if they want to take control. If they have their own keyboard, it’s really easy to just press a key. It’s amazing how much you can screw somebody up by pressing a key or two keys. It’s kind of, “I don’t think we’re doing the right thing.” “No, trust me this is right. Let me keep doing” You press command‑TAB and switch to whatever the other application is and bring it in focus and then, it’s like…it’s a total…it’s an easy way to have this stopping point of, “OK, put the brakes on. Let’s talk about this.” Without having to physically, grab the keyboard from somebody. Derek: What you’re saying is dual keyboards prevent pair assaults? Clayton: There you go, yeah. Remote Pair Programming Derek: One that a lot of people are probably asking at this point, remote pairing. Thoughts on having to pair remotely. Clayton: Every programmer that I’ve ever known has this ideal that, “My job is totally over the Internet, so I can work super effectively at home.” We tried that when people were sick or people are away or whatever. It’s really difficult unless you’ve got…even with like the screen sharing and remote control that like, say iChat gives you or remote desk software or whatever, that stuff is really difficult because you get a little bit of lag and you don’t realize how much that effects the way that things look. If someone is scrolling a web page and you can’t see things anymore or whatever, that’s really distracting. Then, I would say the good thing about it is that when you’ve got two people who potentially can control the mouse or the keyboard, having like a code order where you actually have to physically stop everything and say, “Mouse,” or whatever, so you can get control because, obviously, two people are remotely doing that, isn’t going to work. I would say that’s nice, but overall, the negatives outweigh the positives as far as remote pairing is concerned. Dealing With Distractions Derek: The last question really is distractions. How do you deal with distractions in two ways? One distraction would be somebody else on the team needs you for something. Instead of just interrupting one person, now they’re interrupting an entire pair. If it takes a certain amount of time to get back on task when you’re interrupted and now, you’re affecting two people. What are some ways or techniques to be able to minimize that? Then, the second one is physical distractions, in the terms of, I’m going to say, near‑term problems, laptops, smart phones, things that, I think, as a passive pair are really tempting to get into. What are some thoughts on mitigating those two things? Clayton: I would say that as far as…that one first, as far as the passive stuff where you…sorry. When people are distracted or tempted to look at their phone or their laptop or whatever, that’s something that is up to the pair. Definitely, you’ll have situations where, especially if you have someone that’s driving that doesn’t really want to be pairing, when the other person looks at their phone, it’s like, “Thank God, I don’t have to worry about this person anymore.” If you’re the kind of person that is…personally, I think that’s disrespectful when you’re pairing, you don’t want the other person just goofing off because then, you get into the mindset of, “Wow, pairing is really useless because I’m just doing all the work and this person’s surfing the Internet.” People try and make a lot of excuses about it where they say, “Well, I need my laptop so that I can do research,” or, “I need my phone so that I can check my email because I don’t want to miss anything,” or whatever. That’s a real concern, but it segues into the idea of solving the first problem where I feel like having some kind of consistent timer, that totally solves that problem. If you say, “We’re going to to set a timer every 15 minutes, we’re gonna switch pairs.” If someone walks over to you and says, “Hey, I’ve a question.” You can reference the timer and say, “Well, I’ve got 10 minutes left.” Usually 15 minutes or less, there’s nothing that’s so important that it can’t wait that much time. If you’re worried about missing an email from a client or something, it’s pretty easy to say, “OK, we’re going to work for every 15 minutes, and then every 15 minutes I’m gonna check.” At most you’re going to go 15 minutes without seeing it. Which for most people is probably acceptable. I’d say that having the timer is really good and that helps solve both problems. [music] Derek: We’ll see you next time.

Derek Neighbors: Welcome to another edition of the ScrumCast. I’m Derek Neighbors. Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich. Community Questions From Twitter Derek: Today we are just going to take a few questions that we have gotten over twitter in the last few days. The first question up is…Do you have recommendations on particular reading materials that are good for people to learn the basics? Resources and Reading Materials Clayton: The basic stuff. I think there’s quite a bit of good information on the Scrum, the Wikipedia entry for Scrum. That gets you some of the glossary and some key terms, and then other than that…What are those two…there are a couple of Mike Cohn books? Derek: Yeah, I think Add, Estimating, and Planning by Mike Cohn and User Stories Applied by Mike Cohn are both great kind of planning and user story gathering books. James Shore has Agile Practices or Art of Agile Practices, something similar to that that I think is a really good overview of a number of different agile methodologies including Scrum. The Agile Retrospectives books by Esther Derby/Diana Larsen is another really great book on retrospectives. The good news is, there is much stuff out there from just a pure content blogs and websites, strong just going to ScrumAlliance.com or just ScrumAlliance.org or any of the XP extreme programming site, both have a lot of downloadable content available. Clayton: Yeah, the interviews and articles, especially the interviews on Infoq.com whenever they do anything with pretty much any technology or methodology. The person that they interview always has to do some introduction, because you know, under the assumption that whoever is watching this episode may be know what Scrum is so that person always will do a good introduction. I found this would be helpful. How Do You Recognize a Dysfunctional Team Derek: The next question. We have got a couple pretty good ones here, so we are trying to target these to be 15 minutes or less, you can catch them right at the end of work or walk around the block. This one might get a little bit deeper, but I think it is something that is good fodder for discussion and that is…how do you recognize the dysfunctional team? Clayton: Yeah, that is a good one. There are lots of different things. One of the things at least in my experience is that, a good sign of a dysfunctional team is when you have got lots of…I guess maybe passive aggressiveness is a good way to say it where team members want to either some problem or something that some team member’s having with another, or with a process or something like that. There is lots of grumbling, all solve your problem and I’ll also make some kind of back handed comment about it and maybe I won’t help you out later when you need something, that kind of stuff. That happens a lot. What about you Derek, what do you think? Derek: It’s Patrick Lencioni has a great book out there: Five Disfunctions of a Team and you can map those directly across to agile principles as well. Anything that exhibits a lack of trust which is hard for some people to tell, that there really is a lack of trust but the one that I see more often than not are…the two biggest I see are Fear of Conflict. Nobody wants to say the hard things or to step out or to make any kind of waves, it’s “I think you’re wrong.” “No I’m not wrong.” “OK, I’ll let it go.” To me that’s a red flag that there’s something deeper going on. The best stuff gets made when people have a healthy debate an argument about how to solve problems. The other piggy bank on to that is the absence of commitment or accountability, like I’ll do anything possible to shirk accountability and all of those are rooted in fear and there rooted in fear because there’s lack of trust for the people around. Clayton: An important part about the trust aspect especially that book just in general Lack of Trust, a lot of people misinterpret that to mean that, that for instance, either I trust or don’t trust Derek to do his job. But what the book, what they’re really trying to get to is that you have the trust required to feel vulnerable so that you don’t feel…if I really trust Derek and Derek trusts me then I’m OK saying, “Hey, you know what? I screwed up” or I don’t know what I’m doing or I don’t have the means to solve this problem. It’s really that’s the important part that other team members can trust each other and be vulnerable with each other. Derek: It’s hard to build that stuff too. I’d like to say that time is one of the only things that can really make that happen. That’s probably one of big things that new adult themes fall into is that they want to gel and to have all of these. They look at this is what a high functioning high velocity team is made up of and they want that overnight, and truth is that those teams get built over sometimes a matter of years in working with people. That’s a tough one to do. Next question, this is one that I’m curious to hear. I’d love to hear even outside opinions of this, so when we post this, if people can comment on this, it’d be great. That’s, “I’m facing having a team with wildly differing work schedules, I’m finding this makes estimating and stand‑ups more challenging. How do you handle that”? Different Working Schedules Makes Things More Difficult Clayton: Having very different schedules on a team is going to make things difficult. A lot of people have that problem mostly because people have this desire to have different schedules. Maybe they’re used to that, or they want certain things. I don’t know that there’s a really easy way to overcome that problem other than to get people on more similar schedules. That’s going to be painful, and some people aren’t going to like that, obviously. It is very difficult, especially when the team’s out of sync. We’ve experienced this. If you’ve got people that are coming in much earlier and leaving much later, there’s this overlap for that. You also have people taking lunches or breaks at different times. You get to a point where the team as a core only has two or three hours out of day where they’re actually all together, working in the same space with the ability to answer and ask questions with each other. That’s really challenging. Derek: My gut reaction is there’re the legalistic answers, and there’s the more fluid answer. The fluid answer is, “What impact is it having on your team”? If you can work all different schedules, and have virtually no impact on the team, then it’s really not an issue. I’ve yet to see anybody really do that, but I don’t want to be facetious and say, “It’s just not possible.” It might be possible on some really highly functioning teams. I’ve seen it tackled one of three ways. Either fear of conflict, and nobody deals with it. The other option is the middle‑of‑the‑road option, the best‑for‑everybody mentality that is to have some form of core hours where you say, “From 10 to 2, or 10 to 3, everybody’s got to be in the office, and everybody goes to lunch at the same time. You can come in earlier, you can come in at 6 and leave at 2, or you can come in at 10 and leave at 7, but you need to be here from 10 to 2.” That can work depending on what your work environment’s like, the type of work you’re doing, whether you’re doing XP pair programming, and the hours of your customer. Are you doing internal product development? Are you doing consulting? A lot of that has a lot of play into it. If you’re dealing with external teams, you have to get on a schedule with some of those external teams. The last way I’ve seen it implemented is a much more rigid approach which pretty much says, “This is the time that the entire team works, come hell or high water. Take it or leave it. We work from 7 to 4, 8 to 5, 9 to 6, or 10 to 7, or whatever it is. It’s expected that you’re there within those times.” There’re pros and cons to each one of those approaches. It depends on what type of work you’re doing, who you’re doing it with, and how you do it. It depends on the pluses and minuses of each of those choices. Let’s see, two more, and they’re really good questions. The first one is, “What is the agile response to a request for a proposal, i.e. RFP, when the true answer is, we don’t know time or cost until we are done”? Agile Request For Proposal Responses Clayton: I’ll let you field that one, Derek. You’ve got more experience in that regard. Derek: It’s really difficult. In the RFP, you can really document or describe your process, and how you handle that. There’s a few estimating techniques where you can take an RFP, and you can derive some kind of high level guesses or estimates on those. You can say, “Do we think we can do something like this based on the RFP that’s been put in place”? What you do at that point is you’ve got the Triple Constraint, so you can say, “We can do it for this price with this feature set in this time frame, assuming that you don’t change anything.” If they’re going to stay completely rigid on that then everything’s good to go, if they need to be able to change, if they need to be able to change the scope, you can do that, but you just have to know that there’s a cost adjustment for that. What we’ve seen some success in, in responding to RFPs, is our approach of user stories and creating a backlog and responding to the RFP with a backlog of estimates and then having lots of language talking about how that relates to scope change, that’s a much more appealing process for most larger companies than the change‑order requirement hell that they’re normally put in from a contract perspective. The hard part of that is getting a contract written that speaks to those scope changes without having to have the inordinate amount of documentation around every little scope change. The last question, what happens when the team is agile but the company is not? What are the first steps to get agile practices at a strategic level? Communicating Agility Up The Food Chain Clayton: One thing that a lot of people on a development team or even at a scrum master, project manager level, they see a lot of success with what they’re doing and people can get stuck in a rut where they can’t think of any ways that translates up the food chain. One of the things, I feel like if you’re on an agile team and you’re developing things and providing lots of good value and doing things in a good amount of time and you’re doing all these things, you’re reaping all these benefits, the benefits that you’re seeing, those directly translate to business goals or some business value. Those are things I think that it’s just a matter of finding some way in your organization that you could translate the successes that you’re having with your product development into, hey, here are things that we’re doing, and here are the benefits that we’re seeing, and this is how those benefit you. That’s one way to drive that change, from the bottom up. Here’s all this great success we’re having. If you guys could make these incremental changes, keeping in mind that you have to make baby steps that would be a good way to drive that change up the food chain so that you can start experiencing that more across the organization. Derek: I’ve yet to meet a CEO that isn’t interested in the fundamental principles of agile. I think the problem that we generally have as practitioners is we have to change the language we use when we talk to C‑level executives. Most of them want to be able to use the word “pivot.” They want to be able to pivot their company in a different direction. I’ve yet to find one that’s not interested in being an innovator or being able to be ahead of the curve. Agile practices allow them to do that a lot more simply. It’s a matter of getting them to say, hey, the same way that we’re able to take a feature backlog and create that feature backlog and break it down into sprints, and to tackle those sprints, and allow ourselves to change as need be, you can do a very similar thing from a strategy perspective. You can say, what’s the goal we’re looking for? Can we break that goal down into smaller segments or smaller chunks and still have a long‑term goal? But if two months into our strategic plan, our biggest competitor does something completely different and out of the water, and we need to change course, we’ve got the ability to do that. A lot of big corporations fall into this. They basically create a five‑year strategic plan and it takes them four years to update it, so they get totally submarined. If you look at a Blockbuster and a Netflix comes along and has a totally different model, the inability to basically pivot and say, can we compete in that market, took them probably three to four years to even get their product out, and at that point, it was so far behind and had become so irrelevant. They spent so much money trying to get that product to market that they basically submarined their stores. Again, I don’t think there’s a single CEO that’s not interested in being able to be nimble or pivot or you name it, but I think we just have to stop talking in technical terms and start talking in marketing terms or in strategic terms to get them to understand that these very same principles can be applied to the work that they do as well. That segways in. Hopefully next time we’ll talk a little bit about scrum outside of software. Can you use scrum to manage an organization? And with that, we’ll see you next time.

Muli-Team Retrospectives Derek Neighbors: Here, at Integrum Technologies, we are a consulting company. We, generally, work in pairs. As part of working in pairs, we generally don’t have more than two or four people per team. But we’ve, generally, got five or six different pairs working together. We do weekly retrospectives. We do them as a team instead of as just the two people working on a project, or the pair working on a project. That brings about certain difficulties in writing the retrospective. I’ve got Chris Young our Scrum master here. We wanted to start doing a daily or weekly podcast, where we just talk about some of the Agile hurdles that we have here at Integrum, that we deal with. This is one that’s bit us over time, so we thought we’d talk a little bit about it. Specifics vs Generalities Chris Young: Hi everybody. Today was the second retrospective that I’ve run. What I try to do is actually ‑‑ like Derek said ‑‑ we have a team, I think there’s 12, 13 people in our company right now. Those are broken down into smaller teams right now of two people each on each team. We’re running into a problem because ‑‑ I won’t say it’s a problem yet ‑‑ I’ll just say when we do retrospectives we have to bring in everybody into that retrospective. The problem that I’m finding is that it’s difficult as a scrum master to address specific team problems when we’re trying to pull information out of the whole team. I think probably, Derek, you can relate to that too. The idea is that you, actually, set up an environment in which problems that maybe you’re seeing throughout the week are bubbling to the surface on their own, certainly requires a lot of courage and openness on your teams. We face this problem, like if I have one team that has a specific problem, for instance if a team is having trouble. Say we have one team that was not meeting the velocity that they had signed up for the week or not meeting the commitment that they had signed up for, and none of the other teams were having that problem, and this is a total hypothetical situation. Do we really want to concentrate the whole retrospective on the one team’s problem, or do we have to hope that it just sort of comes up by speaking in generalities? From what I’ve seen, most of our retrospectives are dealing a lot with kind of generalities, best practices, high‑level types of things, and we’re not getting down to into the data and the directly working with what happened this week specifically. There’s a lot of different hindrances that keep us from being able to do that. Lowest Common Denominator Derek: I definitely think that in doing them you have to play to the lowest common denominator, so you have to play to the weakness or the strength that all the teams as a whole exhibit, instead of being able to target just what one single team is doing. I think the thing that is difficult is trying to do a retrospective with a single pair and an off‑site customer, is nearly impossible. It’s very difficult if you’ve got just one pair of programmers that are part of a project. In doing a project, it’s very hard for them to be brutally honest with each other. Meaning that they either aren’t able to see the problems that they are facing because they can’t see the forest through the trees, or they don’t have the courage to speak up and maybe admit to things that they know are currently going on. Putting them in with several other teams helps create that courage and maybe helps visibility, but the problem is it doesn’t allow you as a facilitator to have that laser‑like focus specifically to a project. I think one of the things that becomes hard is, I don’t know the proper way to address that. We talked about trying to do individual retrospectives with other team. Of course, that’s hard now as a facilitator if you’ve got to run five different retrospectives. Additionally, it’s very difficult for people to have the courage to be honest when it’s basically just you and your pair and a facilitator. You’ve got a three‑man retrospective that is also makes it fairly difficult. Establishing Best Practices Across Teams Chris: It’s difficult also in terms of scheduling, if I were to try to do that. Also we do get a lot of benefit from the whole team retrospective. That’s where a lot of our engineering practices and things are established. In reading in the Agile Estimation Book Retrospectives ‑‑ I’m sorry, what is it? The Agile Retrospectives? Derek: With Esther Derby/Diana Larsen, I believe? Chris: Yeah. That, generally, I’d be coming in with data say, “Hey, our code coverage is dropping.” “Hey listen, our” whatever. I’d, actually, have some data and we could talk specifically to that. Is it sort of embarrassing to say, “Hey, this team. Let’s talk about this team’s problem. Let’s all focus on them.”? I don’t think that’s going to meet with a lot of success either. We did make this move to bring on somebody as full time Scrum Master. I’m realizing more and more that my engaging people during the week is going to more important when it comes to those types of things. I have to have some courage myself to be able to bring people together, and see what we can do about those types of problems. From what I’ve been reading about, generally, the best type of situation is we actually have Scrum Master per team. That’s silly when we’re running two person teams as well. I’m still not exactly sure exactly what the… Derek: That’s one of the other difficult things. I really played with it one time, maybe two weeks where we do retrospectives as entire unit, and inter‑mix the teams, and mix the teams up and try to get some honest courage, hit those lowest common denominator problems and really pick up our engineering practices, and pick up our Scrum practices and eXtreme Programming (XP) practices. Then, maybe every third week, try to do a retrospective that highlighted each team as an individual team as part of the exercise, even though it was facilitated all at one time. The problem is that that becomes fairly difficult to find exercises that work that only have two people providing the input to that data. Maybe, the right answer is we do something like that, but instead of being a data gathering, retrospective, maybe we take some of the data that has been gathered as part of retrospectives over the two previous weeks, plus data that we’ve seen or harvested or discussed, not during retrospectives, and bring that in. Then try to facilitate those one‑on‑one with each team for part of the retrospective, and have it be a little more pointed. Of course, the difficulty is some of these start‑up projects that we deal with only run four to eight weeks. If you’re only doing that every third week or every fourth week, you’re halfway through a project before you’re potentially dealing with issues that could dramatically improve, either the quality of work or the pace, or any number of things, revolving around the project. Agile In Consulting Environment Chris: It seems like we’re having some difficulties mapping best practices in Agile because we are a very traditional consulting shop in a way. We want to do short‑term projects. We want to try to get as close as we can to fix bids, so that we can bring people in and that does make it difficult, having two people teams. If we had something internal, if we were a product company or something like that, then we would have some time to work these things over time to let things play themselves out. It seems like here at Integrum, we’re really, really analyzing. We, really, respect Agile. It’s a deep part of our core values, but finding, almost like a hybrid of certain aspects, so that it can work with consulting, less open‑ended type of release cycles and things like that. Derek: I think that one of the beauties of doing pairs and then, doing either one pair of pairs or two pairs of pairs, and capping it to no more than four people per project, actually, makes this extremely Agile and extremely nimble in bringing on new customers. Even existing customers, big projects, allows us to be really nimble in how we use people and use resources on the team to solve problems. It almost allows us to go so fast that it’s hard to have some of the structure that is required in Scrum to the continuous improvement. Just like if you doubled your velocity, you might drop testing or might drop other good engineering practices. I think, in some ways, by having these very small, nimble, Agile teams, in some ways, we’re not going so fast that we’re dropping ability to have some of those sanity checks to come back and say, “How can we improve, and how can we continue and improve with what we’re doing?” I think those are things that are going to be a challenge for us for the coming months. Getting Out Of Your Bubble Chris: Absolutely! Hopefully as we do this we won’t just be talking about things that we have no idea how to solve, so we can help you guys out. In this case we would definitely like some good advice and help on how to manage lots of small teams in one retrospective. Derek: Absolutely! I think a big part of this podcast for us is to talk about things that we struggle with as much as the things that we are doing well. Anytime you are doing something professionally or as a hobby, you get stuck in your own isolated world, and you don’t know the pain that other people are having, and the solutions they have had. Sometimes you get great answers to problems that you have and other times you hear everybody else is having the same problem. It makes you feel a little bit better that you are not the idiot who cannot figure out how to crack the particular nut. We are hoping we can do a little bit of both, we help you solve some of your problems, and you help us solve some of our problems. At the worst we realize that there is a lot of tough problems out there that have not been solved yet. More than anything we just want to talk about what we are doing and hope you guys do the same thing. [music] Chris: All right, thank you guys. Derek: Thank you.

Derek Neighbors: Welcome to another episode of the Scrumcast. I’m Derek Neighbors. Jade Meskill: I am Jade Meskill. Clayton Lengel-Zigich: I’m Clayton Lengel-Zigich . Software Craftsmanship Programming As A Craft Derek: Today I wanted to talk a little bit about, programming as a craft. Dan North had made a post, (Programming Is Not a Craft), the other day and it kind of lit a little bit of a storm in that agile or at least a Twitter world of Agilists. So I just wanted to get your guys’ take on what you think about programming as a craft. It’s Not The Code Jade: That’s not a loaded question there. So I, I read Dan North’s article. I really enjoyed it. What kind of struck home for me the most is, he talks about, that really programming is just a tool and it’s not the craft itself. It’s not, nobody is appreciating the beauty of your code for its own sake. Like a beautiful piece of furniture or a work of art or a sculpture, something like that. That the product has an intrinsic value. And with code I agree with him that it’s just not the same thing. What I really feel like we should be looking at as we should be. Craftsman of information, right? The information that, that people see the value delivered through, the outcome of the code that we create is really what’s beautiful. It would be like a woodworker idealizing, the tools that he’s using to make the craft instead of the craft that comes out from using those tools itself. So look at my beautiful lathe isn’t it so amazing. Like it can do all these awesome things and has these great features. And I put all this time into building this lathe nobody cares about that, except maybe other woodworkers, really the value is in the product that you’re creating the end result of what comes out of all those. I don’t know. What do you think Clayton? Clayton: Yeah, I like the idea of software craftsmanship in the sense of, taking what you do seriously and, wanting to improve and do things the right way and that kind of thing. But I think you’re a lathe analogy is good. I think a lot of times people get so caught up on the beautiful code thing and wanting to, strive towards that. And you, so easy to lose sight of, what is the actual point of what I’m doing? Am I being hired or am I working for someone to, to write beautiful code when the, the end user, obviously doesn’t see it. They’re not concerned with that sort of thing, what’s the real motivation. So I think it’s easy to get those two mixed up. And I think the, the personality type that trends towards spending a lot of time, perfecting little things and going down rabbit holes and all those things are probably the same kind of personality types that tend to say I’m going to be, do better at my job. If i do these coding dojo, coding, kata things or whatever, and I’m going to spend five hours writing the same thing over and over again. And then, they go to work the next day and they totally missed the point of what the business analysts goal is or whatever, it’s like, those are two different things. I just don’t. I agree that they’re important and I don’t want to totally throw it out the window, but I think you have to be very careful tread that, walk that line and not lose sight of either side. Professionalism vs Amateurism vs Craftsmanship Jade: So you think there’s confusion between professionalism versus amateurism versus craftsmanship? Clayton: Yeah. I would say expand on that a little bit more, but I think I agree with that on the surface. Derek: So a lot of the detractors to the statements that Dan made. Were that he was really calling programming in the sense of the word, using craft and art is synonyms to each other. And, a number of people said if you consider a carpenter, the ability to be a craftsman carpenters can build houses or they can build fine furniture. And a master craftsman that builds a house, it’s still building something very functional, but the kind of the devil’s in the details to, the quality that there. Put forth in that. And maybe the better question, I think there’s a couple of things is, is programming an art. Or to me, the question really becomes what is programming just writing code or is programming solving solutions. Clayton: Yeah. So I didn’t, I’ve never ever thought of myself as an artist. And. I think that speaks to the fact that I don’t think of programming as an art and I don’t think of it as just writing code, but I think it is definitely the solving problem thing, and I think that’s why it’s easy to make the argument of, let’s say that you’re some, a Ruby on rails shop, and you want to do work for some XYZ company and, they all use Java internally, but if you can solve their problem using your technology then with differences and make that kind of argument. And I think there’s a lot to be said for that. It isn’t just writing code, but it is all about solving problems. And however you get to that, I think is there’s so many different ways to do that. And I think those are all okay. And I think it is mostly just about, how am I going to solve your problem? What solution am I going to provide for you that gets you to where you want to be? Jade: Yeah. And I think again, going back to my previous analogy, I think. Programming itself and the languages that we use, they’re just tools for the toolbox that we have. Where I think the art comes in is looking at the finished product. If I build a beautiful web app, that is functional and provides, value to, the people that I’m targeting, whatever it may be. I think there’s definitely artistry in, the outcomes of the programming that we’re doing, but the programming itself. While I think very fulfilling and cerebrally stimulating and all of these really great things. The programming itself, I just don’t feel is an art form by itself But Programmers Are Special Derek: so do you think some of the this is propagated, most programmers, I know think they’re made differently think that they think differently than the rest of the world and that there is somehow I’m special. And do you think that maybe some of that thinking or that elitism leads to, if you’re just say programming is just this tool that, that helps us provide solutions to really difficult problems. That you’re demeaning. The fact that I’m just a tradesman, like everybody else who picks up a tool and solves problems. Do you think that kind of adds to the the intrinsic, like pushing away of the idea of, how dare you say that? What I do is not this creative solution masterpiece, a Magnum Opus of a solution in code. Yeah Jade: sure. The first guy that found fire thought that. Pretty unique and made differently, eventually, everyone learned to understand that technology. And I think that’s where we find ourselves is we are on the leading edge of understanding something that a lot of the general population just doesn’t understand, but that doesn’t necessarily mean that we are. Inherently different from them. It’s just that we have a particular skill with this thing, just like a woodworker or a sculptor has a unique gift and skill for, seeing what’s inside that block of marble and bringing it out. Does that make them better than the rest of the population? I don’t know. There’s certainly egocentric artists that feel that way. Just as there’s egocentric programmers that feel that way. I just, I don’t feel like it’s that special that there’s just something genetically different about us. I do think that, we are imbued with a certain talent and have a particular craft in a way to manipulate this information. But, eventually that’s going to become the status quo that a lot of people are going to understand how to do these things. It’s just going to become part of normal life. Clayton: Yeah. And I think if you’re, if you’re a programmer now and you think about what makes you different than some guy in India or the Philippines or Costa Rica or wherever, and, the only difference is that you don’t have an accent and you’re in a good time zone, then, quit your job and go do whatever retrain yourself. Cause I think you’re right, dude. There’s nothing over time that people aren’t going to be able to, you’re going to be replaced if that’s only you can do. And so I think there’s a lot of elitism in the idea of. I’m a master craftsman because I, in my code, when in reality, I think that, the people that are very successful in the software development industry it’s not, it’s not about code it’s about the people stuff, right? It’s a bit of human communication and the soft skills and those things that’s, I think you become successful. It doesn’t necessarily matter how, as much as you want to inflate your ego or think that you’re different than other people or you’re built differently. And that you’re a true artists slash crap. That’s all fine and well, but I don’t think that’s in the end, what it really separates the good from the bad or the, the best from the good Jade: And something else. I just thought of, you don’t see a lot of people walking around saying that I’m a master Chisler right. Or I’m a master at the drill press. No, those are the tools that they are using. To again, bring out their craft to, to deliver something of value to people. And I think that’s where we just keep getting hung up too many times is on the tools themselves. We, we just want to, nasal gaze or navel gaze at all of these, awesome fun tools that, that we’re getting into. And we just get so obsessed with that, that we forget about the end product. Breakdown Of Software Craftsmanship Manifesto Not Only Working Software, But Well-Crafted Software Derek: So one of the other big criticisms was that the kind of software craftsmanship manifesto was a little bit on the weak side compared to say the agile manifesto in terms of taking a really strong, hard stance. Against the status quo in really trying to separate. There’s just four points on it and I’d want to go over each one of those points and then get your guys’ thoughts about what you feel about those. So the first one is not only working with not only working software, but also well-crafted software what’s the benefit in that differentiation between working software and well-crafted. Clayton: I don’t know. That, that seems like such a vague word that’s like fair or something, geez, I don’t know. Well-crafted giving so many different things to so many different people and then even if you know what I mean, what my standard of well-crafted software means that I don’t know it compiles or something. It definitely doesn’t take a very strong stance, that it’s totally open to interpretation. Even more to that, or, beside that point it’s, maybe working software is well-crafted enough. I don’t know. Derek: Yeah. To me the thing is it sounds more like they’re trying to make it art, right? Like that, working software is just working software, but well-crafted software. You really have to understand the dynamics of software. It, it’s such a Subjective thing, if something’s working and the user thinks it’s working and it provides the function that it provides and it’s maintainable, w what level is, what the hell is well-crafted? Jade: It’s not just painting, but beautiful painting. Not Only Responding To Change, But Alos Steadily Adding Value Derek: Okay. So the next one, not only responding to change, but also steadily adding value. Jade: Wow. If you’re not adding value to what you’re doing, what is the point of doing what you’re doing? Clayton: Yeah, no, responding to change, does that mean, there’s again, the kind of a big thing, there is that like responding to changes in the marketplace, That would inherently be adding value. If you’re saying there’s, some new competitor and they’ve got this thing and we need to add these features, but I agree if you’re not like, I think that they should be flip-flopped, it’s like you should always be adding value and then also it would be nice if you responded to change too in, yeah. Not Only Individuals And Interactions, But Also A Community Of Profresionals Derek: I think they’re playing off of the concept of. Responding to change over following a plan from the agile manifesto. And so they’re saying not only respond to change, but to be able to add value. I think, I guess for me, it like you guys, it’s just a given that you’re adding value otherwise, what are you doing? The next one is not only individuals and interactions, but a community of professionals. Clayton: I think this one’s better than the other ones. I liked the idea of saying that, people should strive towards professionalism having a community of people that, and I guess it’s funny because I don’t think that if you were to ask, say some guy in a marketing department of some corporation, what do you think of the software development, professional or industry? Are they professionals? Are they amateurs? I don’t think anyone would have enough. So I feel like that Jade: I think they’d have an opinion. I don’t think we’d like to hear what their opinion is. Clayton: Okay. Yeah. Maybe fair enough. I think this one, to me at least speaks more towards, how developers look at each other in terms of, how do they, how do we treat the community and what do we do in the community to strive towards professionalism? Jade: Yeah. I I think the problem is just the vagaries of what is a community of professionals and, how do you belong to such community? What are the credentials that include you as a professional in that community? What does that actually mean? Clayton: Yeah. And I think it’s it’s funny cause So I think, all the, software industry, whatever, maybe it has not even has a community though, is I think that so say Ruby, I think Ruby has a great community. There’s a lot as far as like participation and new things and all that stuff, but does, does the corporate.net developer that works nine to five? Does he feel like he belongs to a community? Probably not. I feel like there’s so many people, the majority of people in the software. Are not people that belong or feel that they belong to a specific community. They feel like they do a job. I think they feel that they’re tradesmen, right? Jade: Yeah. That’s a tough one. Not Only Customer Collaboration, But Also Productive Partnerships Derek: Okay. So the next one is not only customer collaboration, but also productive partnerships. Jade: So again, I’ll go back to, if you’re not engaging in something that is productive. Why, what are you doing? Maybe I’m just insane to assume that that’s how rational people behave, but I just don’t, I don’t understand why there’s a need to explicitly call that out. Derek: Yeah. For me, the hard thing is, productive partnership. To me, if you’re collaborating partnership just makes it sound like it’s something way more formal than it needs to be, which I think is a mistake. I think that’s actually going in the wrong direction and productive. If you’re collaborating, I don’t know. I’ve not seen too many instances where somebody says they’re collaborating, but they’re not being productive in that collaboration. So to me, it’s not so much that I think a productive, partnership’s a bad thing. I think partnerships a little formal, and I think by saying collaboration that you’re really talking about being productive to begin with. Clayton: Yeah. I feel can you read it one more time? Derek: Not only customer collaboration, but also productive partners. Clayton: So I feel like if you’re, collaboration you’re doing it right, then it seems like you would just get the productive partnership for free. You, I don’t know what you would be doing that would be I’m highly collaborative with my customer, but our partnership is not productive. Like I, I don’t see how that could happen. Yeah, it just doesn’t seem like it would. Derek: Alright Certifying A Craftsman Jade: sorry. I’ve got one more thing. So the thing I’ve found the most interesting and I didn’t really think about it until Dan North pointed it out was we’re going to have this big craftsmen movement and we’re going to talk about all these things and, it’s the best of the best. So click here to sign up on this web form to be a software craftsman. And that’s it. Derek: I think that is a segue to another episode in the future, which is, when we talk about agile, when we talk about scrum, when we talk about XP, when we talk about certification, I think one of the real problems is figuring out who’s really competent, right? And it’s not as easy as being able to sign up for a form or to take a test that when you really talk about, if you were to say, you wanted to go to a surgeon. How do you tell what, who a good surgeon is? Jade: Especially when you don’t know, you’re not in the industry. Derek: Just because they have an MD just because they’re board certified. There’s things that help a little bit, but again, I think it’s a good discussion for another another episode. So see you next time.

Agile Estimation Clayton Lengel‑Zigich: People treat estimates like estimates, and guesses look in the beginning. Then, when it comes time to do the actual project, they think that the estimates are non‑negotiable. Somehow, if they don’t perform, or they don’t get the velocity done, what they thought it was in the estimation process, now that they’ve talked to the customer, they feel like they’re going to be chastised for that. I think that’s pretty fascinating. [music] Announcer: Have you ever felt tempted to pad time or cost estimations for a project you’ll be involved with? In this episode of “Intergrum Scrumcast,” Derek Neighbors interviews our very own Clayton Lengel‑Zigich, about how agile estimation addresses the fears of both management and developers. Make Makes Agile Estimation Difficult Derek Neighbors: Today I have with me Clayton, from Integrum. Clayton, I just wanted to talk to you a little bit about some of the blog posts you’ve been getting lately. I saw that you did a post on estimation, and some of the lies we tell ourselves about estimation. Why don’t you give me some of your thoughts on estimating? What do you think makes estimating difficult for developers? Clayton: I think there’s a lot of competing roles among estimating. I think, traditionally, a lot of people have experience with estimations, where there’s someone like a project manager or someone like that ‑‑ a manager of some sort. They have certain goals about estimations. Or maybe even a sales person. It seems like they want to try and get a low estimation. At least people get that impression. Developers get that impression. Then developers have a competing interest, where they want their estimations to be padded so that when it comes time to do the project, they are not having to work extra hard to get things done super fast. They think that the estimations need to be broad and, “Let’s give myself lots of extra room. I know that this problem is going to take a really long time, so I’m going to pad this estimation, and give myself extra time to get it done.” You have these two competing interests, and I think they come together and clash. With that, I think developers and your manager or salesperson or project manager kind of thing, they have these competing interests. I think the developer is trying to win out, but usually they just tell themselves these lies to try and win that side of the argument. It doesn’t ever seem to work out. Isolation Of Functions of Agile Estimating Derek: I definitely think that in most organizations, estimation is used in a negative light. There definitely are competing interests, and the person with the money wants the budget to be as low as humanly possible. The person doing the work wants to make sure that they’ve got a commitment that they can drive to. One of the things that I like about Agile estimation and planning done right, is that each phase of the estimation is done in isolation of the other phases. You can go in, and you can estimate a difficulty on something. But it doesn’t have a time value to it. Even if a developer decides they want to pad something, in truth it’s not until you determine your velocity that you’re really putting something in a place that lets you know what your numbers are. I think if you are able to do some of those things in isolation, it shields the ability for developers to pad, and for project managers or planners to be able to dictate the length, and the cost of a project. I find it interesting that people still have knee jerk reactions. One of the things I see a lot is, I’ll see a developer who will be involved in the estimation process, and be completely happy with what they see the estimation to be on a story by story basis. I’ll see them be part of the velocity determination, going into a project where they get an estimated velocity. They seem fairly happy with the estimated velocity. Then, a couple of weeks go by, and they are assigned to a team. The first thing they do is freak out that the velocity is not fair, and all the estimates are wrong, even though they were part of that entire process. Why do you think that some developers fall into that trap? Avoiding The Agile Estimation Trap Clayton: I think part of it is that people do the estimations. They have a different mindset. When they’re doing the estimations, they treat them like they’re estimations, right? This is a guess, this is my best guess. They treat it like they are supposed to for the most part, when they’re doing the estimations. They’re part of a group usually doing estimates is more than one person. When they’re doing that, I think they get comfortable, and they think, “I think this is the three complexity, and so does this other guy. OK, I’m confident with that.” Then maybe they do the velocity, and maybe they are talking afterwards and they say, “Oh, my estimate was I think 20 points for an iteration,” or something. The other guy says, “Yeah, I was 23.” When they do that, I think they are feeling very comfortable, and it doesn’t really mean much to them, because it’s just an estimate. They treat it that way. Then when it comes time to do the project, I think they throw all that out the window. Now it’s like they’re committed to this, and they’re sticking their neck out ‑‑ or they feel that way at least. They feel that if they don’t do it, it reflects poorly on them or their job performance, or even their ability to estimate. That’s something I find very interesting, that people treat estimates like estimates and guesses in the beginning, and then when it comes time to do the actual project, they think that the estimates are non‑negotiable. Somehow if they don’t perform or they don’t get the velocity done what they thought it was in the estimation process, now that they’ve talked to the customer, they feel like they’re going to be chastised for that. I think that’s pretty fascinating. Overcoming Panic Derek: I’m curious. What do you think it is in people that makes them have that change? I think one of the beauties is in doing each of the pieces in isolation, you really don’t think of it necessarily as a commitment. You’re really being true to it being an estimate. When that project goes live, and the switch is flipped so to speak, there definitely is that panic, that reality moment. How do you think developers can overcome that initial sprints, panic moment, looking at a velocity and not letting it paralyze them, and instead let them gauge an accurate velocity for the project going forward? Clayton: I, certainly, think that a lot of that just comes down to when the project starts or maybe they have the initial planning meeting with their customer, they just need to be realistic about what everyone’s expectations are. Maybe if you’re a little kid, and you get in trouble, or you do something wrong and you’re waiting for your parents to come home, and you’re freaking out about how terrible it’s going to be, and you make such a huge deal out of it. When in reality it gets to, as long as you’re honest about it, it’s never as big of a deal as you thought. Same thing with the projects ‑‑ they start out and everyone panics and they get paralyzed. When you have that conversation, and you talk about expectations and then you realize, the s sign of velocity was this. But now that we have had this conversation, we’ve talked about it for a little bit, I can see that some of these stories are more complex, or at least the scale of complexity is a little bit different. We’re going to need to have a conversation about how that affects the velocity in the project, et cetera, et cetera. People don’t ever get to that point. The developers typically get to a point of paralysis and then they start making excuses. They forget all about the fact that they estimated these stories and they were happy with the estimates and now it’s,” Oh, God, I’m on the line for this. I better do something about it. I don’t know what I’m going to do. It’s not my fault. The estimates are bad.” Their excuses start coming at that point. The Bait And Switch Derek: I find it interesting, that usually [inaudible 07:07] when we’re estimating, we talk about simplest solution possible. When we do our story workshops, and we work with customers, we state that going into it, unless they specifically add weight to the story that would indicate that it was more deep than simplest solution possible. I see a lot of times what happens is when the first planning meeting comes around and acceptance criteria start to be collected, the stories quickly balloon out of simplest solution possible. That’s where some of that fear sets. I’m reminded, I believe it’s a bank that has the commercials where a person from the bank goes to the first kid and says, “Do you want to dump truck”? They bring him a little toy, a piece of crap dump truck. They go to the second kid, and they give him the real dump truck. The first kid is, “What the hell, I just got screwed. You didn’t tell me I could have a real dump truck.” Sometimes we look at those commercials and we laugh, because it’s so hilarious, the disparity between the first item that the child was given and the second one, and how there was an extreme bait and switch. A lot of time developers fall into that bait and switch, and the customer upfront says, “I’m totally OK with the little Tyco dump truck.” When they come into the first planning meeting they say, “No, no, no. I’m getting the Cummins diesel dump truck. I’m not OK with the Tyco dump truck.” How do you propose that developers can better negotiate those situations with a customer? Confidence In Agile Estimation Clayton: Maybe the biggest part is just confidence in being assertive. A lot of developers feel or, at least they’re treated in their organization, or they just have a lower opinion of themselves and they feel that their job is to satisfy someone else’s desires in terms of, “OK, you tell me to do this and I’m just going to do it.” There’s a great “bogfest” by Uncle Bob Martin about a professional versus a laborer. He was saying that if you went to a doctor, and you said, “Hey, Doc, my arm hurts. Cut it off.” A laborer would say, “OK, sure.” But a doctor would say, “Hey, I’m a professional. That’s not what I do. I’m going to do the professional thing.” Developers will get into the habit of, in that first planning meeting when maybe the estimate was a simplest possible solution. Now the customers going off this tangent about what they want, they don’t have the confidence to make themselves stand out and say, “I know that’s what you want, but let’s talk about the trade‑off. Let’s talk about how that impacts the rest of the project. If you really do want this whiz‑bang, gold plated feature, then you’re going to have to have these trade‑offs.” I don’t think the developers do a good job of expressing that. The clients certainly don’t understand to some degree, if they do have all these things. I guess everyone understands that there’s trade‑offs, but no one really talks about them until the very end, or until it’s too late, at least. In terms of how do you become more assertive, I think you need to go into the planning meeting with the understanding that you are the technical expert at the very least. You need to make sure that the customer understands that you have their best interests is in mind. You want to look out what’s best for them so that whatever trade‑offs they decide to make, and if they do really do want this certain feature, that they are going to understand the full impact of that and that you know how that’s going to impact the project. Derek: I definitely agree. I think that a large part of doing agile well is confidence. One of the biggest mistakes teams make is they look at Agile as being a surely simple thing, because on the surface it seems really simple. There’s not a whole lot of rules, on the surface there’s not a lot of structure, per se. But underneath the principles are a lot of subtleties. The difference between knowing those subtleties and not knowing those subtleties is the difference between success and failure. When you don’t know the subtleties, but you think you know what you’re doing, you don’t have confidence. When you know the subtleties, it’s very easy to be confident in your discussions with product owners, project managers, with other developers. I really think that makes a huge difference. I love the Bob Martin analogy, and I think in my mind here, the difference between a professional and an amateur is confidence. Obviously, that’s not wholly true but there is some truth to it. Thanks for joining us today, and we wish to have you on in the future. Clayton: Great, thanks.

Chris Young: This time with more confidence, hopefully. Derek Neighbors: More something. Keeping the principle of Agile‑ish would make it simpler and half‑less. Chris: That’s true. Why don’t we timebox this? What do you think? Derek: OK, then will go 10 minutes? Chris: We’re just going to try 10‑minute talk, and will reveal, and see what we did. Derek: Yeah! Chris: OK. Human Driven Development Announcer: You’ve heard on test‑driven development, and I bet you’ve heard of contract‑driven development, but have you ever heard of human‑driven development? Today, Derek Neighbors and Chris Young will discuss this topic on the second episode of ScrumCast. Chris: Just what everybody that we talked to about Scrum and Agile, nobody knows what it is all about anymore. There’s Scrum, there’s Agile, there’s Lean, there is eXtreme programming, there is various incarnations of all of these, so we’re trying to find out what is the one true scrum, if you will or the one true agile. Derek brought up something that was interesting to me, and that’s that the underlying of all of the principles, the methodologies and practices, are human beings. That it could be that by putting our focus a little bit closer to the human, and a little bit less from our procedures you might be able to get to something that sort of will alleviate and remove us from this whole mess of philosophical positioning that we tend to read in books, and get down to actually, me and you sitting in a room trying to make some software again. Essence of Accountability Derek: When I really think about it, at the end of the day, I think Manifesto for agile software development sums it up pretty good, when it talks about uncovering better ways to develop software by doing it and by helping others do it. If you look at most of things they value over the things they put less emphasis on, there’s certainly a humanist to the way they talk about individuals and collaborations, and talk about people. If you look at the declaration of interdependence and if you look at the manifesto for software craftsmanship, you’ll see the same sort of thing if you look at the values and principles back and others put forward and in next piece, see the same thing. I think that as software engineers, that’s the first thing that we throw out the window when it comes to resolving conflict, when it comes to determining the best way to do things. We make everything about analytics and pragmatic choices. At the end of the day, where it really started to hit home for me is here at Integrum. We’re working through a myriad of different issues and refining our process. We’ve squeezed out a lot of the inefficiency. We’re really now getting down to almost really picking nits in a lot of our practices. I find that people generally hold on to beliefs or value systems. Not because they necessarily have the belief or the value system, but because of something internal. I think that sometimes to overcome those roadblocks you really have to get to why does somebody believe that, not the fact that they do or they don’t believe it. If somebody thinks that we should be more lean, and have less process, what’s the real reason behind that? If someone doesn’t like a commitment driven planning approach and would like to be a little less heavy in process or a little heavier in process, or wants to be more accountable or less accountable. What I find is most of the practices ultimately break down to some form of accountability to yourself, and an accountability to a very small portion of teams. I think, if you take accountability and you cut that back one step further, it’s really about trust. I think that as human beings, especially in this day and age, in this society, where things are disparate, often we work on teams with people that can live thousands of miles away from us. Even if they work in the same office with us, we’re not as connected as we were a hundred years ago. Some of these trust systems just aren’t there. We all bring our baggage to the table, from our childhood all the way through to our professional careers. You see somebody act out. Maybe they don’t want to commit to a particular velocity, so they lash out and they get frustrated. Certain team mates can take that as an aggression move. At the end of the day when you really break things down, really that team member that’s lashing out is probably afraid of something bigger than the commitment, and what that commitment brings to it. I think when we start to see each other as humans, and we start to ask those questions like, “Why is it bothering you to commit to this? What’s the real problem?” I think a lot of it goes back to root cause. Root cause is human beings. We all have our fears. We all have our egos. We all have these things in place. When we can start to be human enough to have real conversations, authentic conversations with each other, it really allows us to do powerful things as a team. Building Intimacy Chris: A lot of the literature that I’ve read about scrum agile software development, basically, any sort of professionalism, they talk a lot about leaving your home at home, leaving your problems at home. It’s an interesting line that you’re walking, starting to talk about how people are feeling at work. How do you think that we could start to look at bringing some of those things up into our regular work process? Derek: It’s interesting because for me, those that know me somewhat professionally or certainly personally know that I’m kind of the anti‑feelings person. I’m kind of the, for lack of terms, the pragmatic asshole in most circles. For me, the thing that really sells me that feelings matter in software development is that I’m a firm believer that if everybody in an organization thinks the same way, values the same things entirely, they’re duplicative in their ways. They probably need to go. You don’t need two people that think exactly identically. The very fiber of every human being is different. As part of that, their reactions to things are different. The way their mood affects what they’re doing is entirely different. If we really want to unleash creativity and innovation in work that we do, and we really want people to be energized, we have to understand the people we work with. That doesn’t mean that we need to be best buddies with them. It doesn’t mean that we need to be their psychotherapist. But we need to understand what motivates people, what makes people fearful, and more than anything, build that proper trust train between people. I’m not talking the little trust fall, weirdness, and things like that, but I think that people that engage in that thought process are getting the very similar thing that we’re talking about here, and that is that trust is that important that it can really shape a team dynamic. The question is how do you get there without having… Exposing Feelings Chris: …or without falling into these cliches, because we’ve been trying, obviously, the whole self‑help section at the bookstore. There’s the Myers‑Briggs. There’s this trust falls. There’s hundreds and hundreds of different ways that people have tried to get at feelings. What I’ve seen a lot is this attempt to use feelings to approach our work, but here we’re talking about something a little different which is our work to approach our feelings. Maybe I’ve had a discussion with a developer, and they’ve agreed to try some sort of practice. Then I found out, say the next day, they didn’t at all. I was upset about this, and Derek suggested that I should find out what they’re afraid of. To me, I was thinking about, “Oh, what do you do if somebody’s insubordinate if you will,” Air quotes around that, “on an agile, self‑organizing team?” How do you deal with somebody who just isn’t going to do what they say? I was already to come in and start to, “Let’s go through a logical process and start putting things on the board and catch people in their logical fallacies” or something like that. As I said, Derek suggested, “Maybe just find out what they’re afraid of.” I had a discussion with the person, not directly asking about that, but just like, “Why is it so hard to make this commitment?” By offering myself as a friend, this person felt very open, and was able to express a fear which was immediately resolved. It was actually about fitting in with the organization at all. That’s what it came down to was, “Hey, do I fit in? Am I going to be liked here? Am I going to be performing at the level that you want?” I was able to say, “Hey, listen. Basically, what Derek has just said that having a lot clones and a lot of people acting exactly the same is not going to bring a lot of innovation to our company. We need more people that think differently, not less.” What was great about that, though, was that I didn’t go in and ask him how he was feeling. I asked him at first ‑‑ this is hypothetical ‑‑ but, “Why is the velocity off?” Then from there we got down to feelings, having some knowledge that underlying any sort of actions are people feelings, because that’s the thing that gets ignored over and over again. We’ve had people come and go that had we have a better understanding of them we might have been able to have a better outcome. I’m very interested in learning more about how we could start to apply this. Maybe that’s something that we could talk about in our next podcast. Exactly how we might approach people in ways that could get this information out, so that we could start building better relationships at work that should result in better productivity, and profitability for our businesses? Derek: Absolutely. I think that, for sure, we don’t take enough time to communicate with each other. We talk a lot about customer communication, but I think a lot of times, when the rubber hits the road, we don’t have the real conversations internally as a team. I think it’s a great segue to the next episode of the podcast on how can we address some of those issues. How can we make those conversations start to happen? [music] Chris: Thank you for listening to another episode of ScrumCast, a production of Integrum technology in beautiful and wonderful, better than your city, Chandler, Arizona. Derek: Absolutely. 85225, baby. Good job, man. Chris: That was better. Derek: Yeah.