Derek Neighbors: Hello, and welcome to another episode of the Scrumcast. I’m Derek Neighbors. Jade Meskill: I’m Jade Meskill. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Chris Coneybeer: I’m Chris Coneybeer. Responsible To Not Test Code Derek: Today, we want to talk about is it ever responsible to not test? [all men gasp] Derek: I had to pick the guys up off the floor but… [laughter] Derek: This has come up a number of times. I remember personally arguing about this with James Shore and a few other people at, I believe it was, Agile Roots probably two years ago, maybe 2009. Then, recently, Obie brought this up in a blog post as he’s doing his own start‑up, and he talks about maybe he shouldn’t be testing for his own start‑up in some ways, shapes, and forms. I just wanted to, obviously, be in a group that’s pretty adamant about testing and pretty focused on quality, what we think about that. Agrument Against TDD Clayton: I read an interesting post the other day that was supposed to be an argument against TDD. It was one of those things where half of it was drawn in, and then the other half of it was, “To prove my point look at how crazy Bob Martin is. When he talks about testing, he’s crazy. That means testing’s crazy.” [laughter] Clayton: It was funny, but there were a lot of people that had commented on it that were like, “Oh, I’m so glad that someone finally came out and said this,” like it was some Oprah show or something where someone was revealing this great truth. I thought that was interesting, but at the same time, no one was really getting into the like, “Well, hmm. Maybe it isn’t responsible to test everything all the time,” counteracting the Bob Martin or some of the people that are really into the test‑all‑the‑effing‑time kind of stuff. There’s something to be said for that. To What Degree Are You Testing Jade: A lot of it is the degree of which you’re testing. Advocating a position where you don’t test at all is very dangerous and completely irresponsible. But do you need unit tests that cover every single edge case, as well as, acceptance tests, as well as, request testing? There are so many levels of testing that you can get into, especially with a web‑based application. When you’re running a Lean Startup and you’re in move‑fast mode, totally experimenting, and trying to figure things out, it can be quite a bit of overhead to do a complete full‑stack top‑to‑bottom, outside‑in testing. Chris: Even if you’re doing your Lean Startup, there should still be some testing in there for acceptance. There should be some testing around what is the core criteria of the application I’m writing for, not of the unit testing, testing out every single line of code. I understand the coverage being a lot lower. But I still think that, no matter what, if you’re doing acceptance tests, even integration tests and depending on what you’re building, what you’re doing, you’re going to think about a lot more things, and have more confidence in that code. Not confidence in being perfect but confidence in your not going too far away from what you’re trying to get to. When you start writing everything with no test ‑‑ I just would have no faith that I couldn’t break something and not be aware of it. Then, if I’m a starter that could have a bad presentation to any end users or people I’m showing the product to. Testing What Is Most Valuable Clayton: I heard a good way of describing testing, and a lot of people think of testing, especially if you read stuff on Twitter, like TDD. It’s all about, “Oh, TDD is so great because I realize that I broke something before I got it to production,” or whatever. So, testing becomes all about making sure you’re not breaking things. The next level of that is, the code I heard was, “You should be doing testing so that you can verify that you’re delivering the value that you say you are with your application.” That would be really important if you said, “From my Lean Startup, I’m going to test the value parts and the rest of it is…” Maybe, I don’t do that. Maybe, not test those things. That could work. What’s An Acceptable Amount of Testing Jade: One of the arguments that came into is, when you’re funding somebody as an investor, the truth is you don’t give a shit about testing. They want, you just don’t care. What you care about is, can you compete in the marketplace? At some point, testing or quality factors into that. But sometimes getting to market or getting to discovery, quality is not the most important thing. So, if I say, “Clayton, I’m going to give you a hundred thousand dollars and I need this list of 15 features. If you can’t get those 15 features done, regardless of what the quality of those 15 features is, this project’s done and we’re not going any forward, and ending. If you deliver those 15 features to me, regardless of the quality, if you can demonstrate on some level that you can complete these 15 features, I’ll give you another million dollars to continue on with this product.” That, in a Lean Startup mode, is where it starts to become a little difficult to say, what is that threshold? Is it OK to go four weeks without tests? Is it OK to go 10 weeks without tests? Is it OK to go 90 days without tests? Is it OK to only have 10 percent coverage or only have the value items covered? I mean, there is a point and you could say the same thing, even not on Lean Startups. When you’re in large enterprises that have millions of lines of code with no test and you want to do new development and it’s not reasonable to go back and write tests for every line of code that’s already written, at some point you have to make trade‑offs to say, “What’s the acceptable amount of testing that is responsible.” That’s a word we use a lot but we drop real quick when we get into our wars, when it’s all testing all the time no matter what. We drop the whole like, “What’s responsible?” Maybe, we could talk about. What are some of the things that we see that are responsible or, maybe better, what we see that is irresponsible? Testing To Solve Problems Chris: For me, I really embrace the core idea that BDD, a behavior driven development, is less about test coverage and the percentage of testing, but more as a technique to help me discover the problem I’m trying to solve. So when I approach it from that angle, I’m not really interested in necessarily ensuring that every single line of code is covered. I’m more concerned about, “Am I creating a quality design that is good enough to solve the problem that I’m trying to solve?” There’s a bare minimum level of test coverage that you can implement when you’re going down that path that is going to cover you in 90 percent of cases, especially, as your software continues to grow and add new features. You have some level of confidence that you’re not completely destroying the application by changing a few things around. So when I’m testing in Rails, I really like to do acceptance testing, some more outside‑in testing. I’m coming in as a user and following the path and making sure that things are working the way I anticipate them, but I can change around a lot of the implementation details behind the scenes without having to go back, refactor all my tests and worry about this whole gigantic test suit. There’s a bare minimum level of coverage that you can get where the testing is pragmatic and simple but good enough for the time being. It really comes down to risk. How much risk are you willing to take and how much risk can the product or project that you’re working on afford to take? If you have a hundred thousand dollars for the start‑up and it’s make it or break it, you can take a lot of risk with your software because the bigger risk is that you don’t deliver anything. If you spend all your money and engineering time doing testing, you’re not going to get to market anyway and it was just a waste of time Derek: On your thousand dollar example, if you treat it as a prototype, people readily acknowledge that you should build the prototype and throw it away. If you can be responsible to do that, you should also recognize that maybe doing a full testing is irresponsible, because that’s something you’re going to throw away. At the same time, I’m kind of torn, because I know that when you get to a certain point, I acknowledge that, there are benefits that you get from, say, TDD that are like architectural decisions. You get other benefits that are not really what you’re specifically testing. Those are harder to get and more people think that they understand those and get those than they do. I could see a lot of people saying, “Well, you know, I do TDD because I have to test everything, because we’ve got all these great TDD benefits,” when maybe, they’re not really getting those and it’s a prototype that they should be throwing away anyway. Chris: How many people do you think have the discipline to actually throw away that prototype? Jade: None. Derek: None. [laughter] Four to Six Week Window Jade: To me, where the argument comes in is what’s that time frame? I mean, I would argue. To me personally, it’s probably in the four to six week time frame, so you can lie to yourself that it’s kind of a prototype for four to six weeks. Once you get beyond that sixth week, if you think of it really in terms of technical debt like financial debt, I might bootstrap a startup with credit cards and that becomes irresponsible to a certain dollar figure. Is that dollar figure $50,000? Is it $100,000? Is it $200,000? I don’t know it’s going to be different for everybody. It’s kind of the same thing. If you’re doing an application without tests, you’re incurring a certain amount of technical debt, or you’re making it more difficult to pay down technical debt that you do occur. At some point, whatever that time frame is, it’s pretty damn short. I want to say less than six weeks, but it really depends on who you are, but then, you’re just lying to yourself. Chris: How could you gauge that? How could you find that limit, that threshold, between test all the effing time and no testing at all? How do you, as a team, determine what that pain threshold is? Jade: For me, after playing with a bunch of test frameworks lately and really pushing through, most people feel that testing makes them slower. When you’re comfortable with your framework, that’s simply not true. Testing often makes you faster, not slower. Even though, you’re writing twice as much code, what you’re doing is you’re thinking much more about the code you’re going to write, therefore you actually end up writing less code in probably a quicker amount of time that produces more functionality. I would say, that a team that is used to testing, this isn’t even an argument, because to them, they don’t see testing as slowing them down, even in a new project, if they’re testing properly. If they’re over testing, 100 percent coverage, then that’s a different story. What I would say is, if I was doing a different prototype and I wasn’t really comfortable with the test framework, what I would do is, I would probably say, if I’m breaking something down into stories or tasks, I would give myself 10 or 15 minutes per task or story to say, “Can I feasibly write a test for this?” If I get stuck, I immediately throw the test away. But I have the scenario, I’ve got the harnessing for testing, so if I come back later, presumably, it’s easy for people to add specs or to add tests in there. Additionally, what that allows is that allows maybe other people on the team that are more comfortable with testing to test instead of just saying, “Oh well, nobody is testing, so I’m not going to test.” That’s a fine line, as well. That’s a reality. Not everybody is really good at testing and testing quickly and making responsible test decisions. Chris: There are a lot of languages and frameworks out there that haven’t yet made it easy for people to do that minimum level of testing. Jade: If you’re choosing those, you’re probably not very Lean Startup anyways. Chris: [laughs] Wow. Clayton: That’s a good point, though, because a lot of the, and maybe, that’s just because we live in this community, but a lot of the, “You’re an idiot if you’re not testing everything.” A lot of that comes from Ruby, for instance, on Rails, where it is really easy to test. If you’re using Rails… Chris: It’s ridiculously easy. Clayton: …it’s like, “How could you not be testing? But if you’re some guy who says, “I have a great idea and all I know is C‑Sharp.” It’s like, “Maybe, it isn’t so easy to get 100 percent bootstrapped and do the testing.” Maybe, that’s why you don’t see that from that community and it’s easy to berate those people. Jade: What do you think, Chris? You’re familiar with the .net community. Chris: For .net community, it’s been building up for the last couple of years. We’ve been learning a lot from other frameworks. Now, it is a lot easier to get up and running and do acceptance testing on there. You have tools available and you have a lot of frameworks. You go out to get hub and search for TDD and for .net, and you’ll turn up a ton of frameworks and a lot of tools that are available for you. You can grab Selenium down and start doing acceptance testing. For me, that’d be the first thing I would want to do. Speaking in this idea of a Lean Startup with 15 things, I want to, as much as I like to do integration testing for contracts against other systems and things like that, I would take those 15 things and start writing that out, putting that into some steps and running that through acceptance testing. That way, I have a contract as to what my user wants. Yes, I’m not getting all unit testing. I’m not getting everything underneath, but I’m using acceptance testing as a type of contract to make sure that I’m going to get back to what is it that I’m supposed to be delivering. I mean, it’s completely possible in .net, no problem. There are a lot of tools out there available and a lot of tutorials and slides available to get you through that. Even if you take a look at the Microsoft stack alone, take a look at Team Foundation. Team Foundation System now has test runners and has all that. You can get that continuous integration right there in front of you. There are open source tools available for that, too. Jade: Cool. Clayton: What’s the verdict? Is it you’re responsible to not test in your Lean Startup? Jade: I’d say, irresponsible. Derek: It’s irresponsible, if you’re not at least having a discussion about why you’re not testing. Chris: I’m going to equivocate on this one and say it depends. Clayton: I fall in the category of I feel like I’m not super slow when I test. If I were doing a Lean Startup, I’d say, it was irresponsible if I didn’t. Jade: I will say, I’m not as fast as Clayton at testing. At this point, I would say, I was irresponsible if I did not do some testing for my start‑up. Clayton: With that, we’ll see you next time. Thanks for joining us.

Clayton Lengel‑Zigich: Welcome to another episode of The Scrum Cast. I’m Clayton Lengel‑Zigich. Drew LeSueur: I’m Drew LeSueur. Roy vandeWater: I’m Roy vandeWater. Chris Coneybeer: I’m Chris Coneybeer. Which Practice Should You Implement First Clayton: Today, we’re going to talk about a carryover discussion that we had together at a team lunch earlier this week about going into a team organization and implementing either pair programming or a continuous integration system. There was some discussion along those lines. Roy, you were a vocal person on one of those fronts. Roy: Never. Clayton: Never. Roy: We were having this discussion with Derek, who unfortunately isn’t able to join us today, so Coney has decided to take his place. Chris: Hello. [laughs] First Start With Retrospectives Roy: My opinion was that when you’re first starting to implement Scrum, you get the most value, first off, out of retrospectives. As soon as you start getting the team reflection on what they’re doing, that’s when you start to see improvement, because that’s when they get the opportunity to come up with their own creative ideas. I think Derek pretty much agreed with me on that point, and I think you do, as well. Then what the second implement was, Drew and myself are a big proponent of adding pairing. Pairing is something that you can do that’s relatively cheap from an investment standpoint, immediate investment, and something that gets you immediate results. Next Continuous Integration or Pairing? Chris: From my perspective, I’m more on the continuous integration side. The reason being is I do agree pairing has a great value, and should not be looked away from at all. My main concern is that you have repeatability with the continuous integration. You’re starting to have where when code is being checked in, you can insure that the code is in good shape, and also that it’s buildable, and the code is not in a bad state for people. I think that out of that pairing is a big culture change for a lot of shops, and culture is really we want to get down to when we want to change. I think that the continuous integration, and some of the benefits, and also the, what’s the word I’m looking for here? Clayton: Confidence? Chris: Confidence. Thank you. Confidence in the project, and what’s going on. I think that the confidence that CI can give you is a great place to start. Cultural Change Clayton: I agree that continuous integration is great from a pairing perspective. I think that it’s a simpler change that you can implement. Coney, I remember when you talked about cultural change. Culture’s huge, and it can be hard to change. If somebody wanted to implement pairing, they could try pairing for maybe one day a week or a couple hours a day just to try it out. That’s super simple to integrate and to talk about how that went, talk about the pros and cons, what people learned. Continuous integration is a good thing. If you’re talking about one change you could first implement, continuous integration can take a long time. It could take a lot of investment, especially if there’s an existing system that’s really not designed well. There’s no test. It’s hard to deploy, all those sorts of things. Fix The Warning Signs Roy: Right. I think a lot of times, and that’s where something like continuous integration itself comes from, too, is that those things are generally warning signs, right? It’s bad if you have a system that’s hard to deploy, and I can completely understand the desire to address those things. I think that you can address those things better while pairing, and that’s why I’d want to start off with that. Effective Pair Programming Drew: One thing that came up at lunch was while you could probably implement pairing quicker, the argument was you could technically do that, but maybe it would be in name only. Because I think we can all speak from experience of coming to Integrum and actually pairing. That’s pretty hard, and it’s hard to get two people. Even if one person is experienced with it and the other person’s not, it’s hard to do quality pairing. So maybe you could implement pairing quickly, but would it be as valuable if the pairing was not very effective or if the two people that were doing it, didn’t really know what they were doing? Chris: Going to the culture side of it also is that, with the pairing, if people are having good conversations with their pairing. If they’re not having effective pairing like you said, you’re not really changing culture at that point. All you’re doing is setting two people beside one another. You need somebody to help teach them and help get them there. Where with continuous integration, I’m not saying that either. I am more on the continuous integration side, but also, like I said, I see the benefit in the pairing. I think that it is easier to implement, but making sure that it continues to happen. Like you said, Drew, you could say, “Start off with pairing one time a week or two times a week,” but how do you know the next week that people are going to sit down and do one, two times a week? Where if you do put continuous integration in, you make it part of your standard process in what’s happening there. You’ll be able to get immediate feedback on the builds. The team can start to maybe build that culture where they start to have team accountability for the code because pairing gives you that, too, the team accountability for the code. When you have a continuous integration and everybody sees what’s going on, that also gives benefit. The team may start having more discussions as to, “Why are you breaking the build every day, Roy?” And,” Drew, why are you always having to fix it?” Fixing Build Systems May Take Longer Than Starting Pairing Drew: I think we’ve seen, too, on the flip side, where we have seen projects where the projects are massive. The immediate demands to build features or to go back and fix defects is so great, that while we’ve tried to implement a continuous integration solution, it takes us six months or it takes six months and we’re still not done. It seems to me that even starting from no pairing experience at all, getting people up to speed on pairing is much quicker than that. I do think that depends a lot on the existing project and the existing situation. Not in all situations is setting up continuous integration going to be so non‑trivial. If you’re doing a real simple app, start off with continuous integration. Why wouldn’t you? But with another app, it might be a lot more difficult. Chris: Definitely right there. That’s one of those things where you try to pick the easiest thing that’s currently a technical issue. You try to pick that, and you start to attack it. If it is a huge build issue, then that’s the point where I would lay off and say, “Well, do we pick where we can automatically deploy it to death?” Maybe we start there and we set up an auto deploy to that. Maybe it doesn’t run all the tests and everything else automatically, but we start walking towards it. That would be one of those instances where I would definitely look at it and go, “Well, pairing does make sense here, but let’s work on this as a pair maybe,” and you can get that in there fast. Or have people start having that discussion about, “What’s going on? What problems are we trying to work through?” What Is The Culture Pointing To? Clayton: Right. Another thing about pairing, too, when we talk about culture is I bet there are a lot of places or companies that would be uncomfortable or teams who would be uncomfortable pairing where they’re used to working alone by themselves with their headphones on, whatever. There’s a lot of other places, too, where they want pairing, where they feel like pairing is missing, or they feel like they would be pairing if they were able to pair, but they don’t because they’re supposed to be working alone. I come from an experience where I used to not do any pairing, and I really wanted to do pairing. On the few chances where I was able to do pairing, I felt like a total productivity increase. It was awesome to be able to communicate with my teammate. We got things done quick. Also looking at that from that culture perspective, too, where people are needing and wanting pairing. Roy: I think something that’s also like what Drew brings up as far as the siloing is that we have gone into companies before where everybody does work in their own cubicle with their headphones on, and nobody actually communicates. When you start pairing, at the very least you start having those conversations of, “This is a pain in the ass.” The other guy goes, “Really? I’ve been thinking that, too. I just didn’t want to say anything,” right? You start recognizing some of the problems and realizing that you’re not the only one who has them, that it’s not due to your ignorance or your incompetence. These are legitimate problems that everybody’s facing, and then you can start to work together as a team. I think for a lot of teams, too, it finally gives them an opportunity to almost meet their team members because they haven’t been working with them at all. Building Confidence In The System Clayton: What do you say to the proponents of a continuous integration system that would say it’s like maybe a testing, where you could make the argument that if you don’t have automated builds that anyone on the team can run at any point in time, if you’re not doing that, then there’s no confidence in the system. Maybe you’ve developed all these fantastic features. You did pair programming. Everything’s great, and the team all loves the features. But when it comes time to deploy them, it’s a total guessing game. Everyone in the organization gets very concerned, and it turns into a two‑day process of making sure everything went right. Drew: I can completely empathize with that. I have definitely experienced that a ton in exactly that type of situation. I’ve also experienced where doing the deploy has been extremely strenuous even when you’re using continuous integration, although it’s much less likely to be so. I definitely agree that that’s a really a bad situation to be in, and it is something that should be addressed. I just think it’s the next thing on the list. Clayton: You think it’s more important to have paired features than it is to have confidence in the build? Drew: I’d say you gain a lot of confidence in what you’re building when you know that you built it with somebody else. Like if I build a particular feature, I think, “Well, I may have messed up, or I may have been approaching this all wrong.” While that’s still possible with a pair, at least you’re discussing it and thinking about it differently. I find that it’s much less likely that you’ve done that. Building Relationships Chris: Also from the development side of this, so we’re talking a lot about the pairing and developers working, talking, and getting through this. But in Scrum the idea is that we want to build a better team all the way around not just with the developers themselves, but also with the product owners, with the people that we’re building software for. That’s one of the things I like about the CI side of it, is that I’m also able to start to build up. Like you were saying, Clayton, I can start building up this confidence with the people above me, the people that I’m building my product for because we have some testing. We have some confidence in our ability of being able to deploy it because of the CI on there. That starts building a better relationship for the team as a whole. Not just the developer’s side, but also the entire team that may be working on this project such as product owners, management, and other things going on. If you’re able to take where it’s usually two days of crossing your fingers praying and hoping that it works and dealing with bugs and because you’ve been able to do a CI on this, now you know that you can push it out a lot better. Then you start to build that confidence up above. You could start building a better team, a better environment, and a better foundation there. The pairing does give you a better foundation at the developer level. The Testing Rabbit Hole Roy: Another concern that I have is I’ve seen multiple times with people where they hop onto the testing scene, and they start doing unit testing or integration testing. They start developing features in a test‑driven manner, and it’s great and they love it. Then their first build happens, and there’s a bug in their code. It’s like their dreams are shattered, and all of their expectations have been ruined because they thought that they were going to have perfect code because of those tests. Everybody who starts out testing always has that realization. All of a sudden they go, “Oh, crap. It’s not enough to have tests. I have to have good tests and then good code. Even if I have those, shit can still go wrong.” I think that’s something that might be really discouraging to a team that’s just starting out adapting Agile. They’re like, “Well, retrospectives are great, but this testing stuff feels like a waste of time because I spent all this time writing these tests. Then we’ve spent all this time setting up this continuous integration server, and we still have bugs. Like what the hell?” Right? I think that’s something that I’m really worried that people would back off of Agile because of that. Does Testing Come Before Pairing? Clayton: Yeah, so I think that’s one thing that we’ve been missing. We’ve been talking a lot about pairing and CI. Another aspect of that maybe eXtreme Programming XP or engineering kind of stuff is testing and test‑driven development. I would say, there’s probably a lot of people maybe more on the software craftsman side who would argue that testing and test first even trumps CI or pairing, although… Roy: Why do you say that, Clayton? They Aren’t Mutually Exclusive Clayton: Well, I think we should be clear that these aren’t mutually exclusive. We’re talking about which one is the best value. I don’t know that, I would say, that testing is more important than all of them because testing is difficult to do, and it’s difficult to do correctly the same way that pairing is difficult to do and difficult to do correctly. I think that’s probably why I lean on CI as the one, I think, is the best value because it’s something that’s pretty straightforward and clear‑cut, and there’s a lot of institutional issues that get brought up. One of the examples that Chris gave at lunch was the idea of saying, “We want to release this build, but I have to go talk to Joe over here. He’s got special password keys or whatever. He has to go do this thing. Oh, crap. He’s at lunch, and then he has to go to his kid’s soccer game.” All that kind of stuff. That goes out the window. I feel like you get a lot of bang for your buck without having to actually be really good at testing or pairing. Chris: Something just popped in my mind when we were sitting here thinking about it. There is a lot to be said in the fact that pairing and testing and other things have a bad way that they could be done. You can really waste a lot of time, or you can really go down a bad route and cause some issues that then have to be cleaned up or a lot of learning that goes along with it, where CI is more technical. CI, you’re not getting into where you have to start looking for the smells. You’re still going to be doing retrospectives, but with pairing you’re going to have to talk about, “Hey, we didn’t pair that well. Let’s see how we can get better in the future.” Where when it comes to CI, especially if you’re working in Brownfield and you already have something that’s being deployed regularly, you know how to deploy. You know that “blah‑blah‑blah” runs on these different scripts. I can automate this. It’s technical. It’s not getting into changing an environment, changing a culture, changing a lot of things. You’re getting into building confidence as a team. Clayton: Well, I think that might leave the discussion as the “it depends” answer. [laughter] Clayton: Maybe we can pick it up again later after we’ve got some more experience. Thank you.

Jade: Hello. Welcome to another episode of the scrum cast. I’m Jade Meskill. Roy: I’m Roy vandeWater Derek: I’m Derek neighbors. Drew: I’m Drew LeSeuer Jade: This evening we’re going to be discussing vision. When I say that word, what do you guys think of? Derek: How bad mine is? Roy: I was thinking of the phrase that there’s always money in the banana stand. Jade: What does that mean? Roy: I don’t know. It’s from arrested development.. Jade: All right. Drew: Yeah. I think of, something that’s sitting out there that kind of anchors you to where you want to go. Derek: Yeah. To me, it’s really, I guess it’s linked to purpose, right? I think if there’s a solid vision then you understand why you’re doing what you’re doing. I think anytime you’re dealing with teams or having to deal with motivation. I think that becomes a core factor into what and how you do things. Jade: So give me some examples of some organizations or a product that you’ve been on. That’s had great vision. And what were the outcomes? Derek: Early in my career I was lucky that I was on a team that had two different products ship that had really reasonable vision. The first one was they did mortgage document delivery system. They were an all DOS-based system and windows 95 had just come out. Most of their client base which happened to be large banks did not adopt windows 3.1, but they were starting to adopt windows 95. Because of that, they, made significant investments to move, thousands of desktops over to windows 95. And so they were expecting windows applications with that, and so the kind of the product vision was to take the existing product and convert it into a 32 bit a windows version. So there’s a very defined goal, a very defined outcome, very defined, reasons from a business perspective of, large clients that we would lose. If we didn’t get this done and large clients that we would win by being one of the. Companies in that space to actually deliver a product on that platform or native to that platform. And then the second one, same company was in doing a document delivery for closing documents online through the internet. It’s time, nobody’s really doing it. And a lot of people thought it couldn’t be done. Thought there were a lot of securities thought there were no, no way to really anonymously do that and be able to print them in. So there was a very unifying goal of, this is what success is. Not only from a technical perspective, we can achieve this technical thing we’ve succeeded. But also that if we do this technical thing, this is the financial success that comes from it. And I think for me, that’s one of the big things I see missing. Most companies don’t even have a vision, but even sometimes when teams have vision, there’s no business value behind that. So it’s, Hey, let’s add this feature set or let’s ship this particular thing. Where’s the business value. What’s the, okay, great. We succeeded at that, but the company went out of business anyways. Roy: So would you just say that having a vision that doesn’t add business value, which. Any, still some benefit to the team? Derek: I think it’s a huge benefit to the team. I think the team has to have a unified vision or a unified purpose to be able to rally around, to really gel as a team. If you don’t know what the what the, what defines success for you as a team and what’s expected of you. I think it becomes very difficult. To become a team and I think Jade and I, we might’ve had this discussion at one point. I think one of the things that’s difficult about software is there, there is no trophy, right? There is no. Who, how do you determine who wins? Or who gets first place or, there is no world cup, there is no playoff. And in order to push yourself as a team, you have to self-define. What your championship is, right? My championship is, getting into the playoffs is doing X, getting into the championship is Y and winning the entire thing is Z. The problem is that may or may not provide value to the business. So is it important to the team? Absolutely. Does it make a huge difference to the team? Absolutely. But I think a team can totally gel totally succeed and totally fulfill their particular vision. And if the company doesn’t have a vision, that’s in alignment with that. The company can actually fail. Jade: Yeah, I agree. That, that team that Derek is talking about, that’s when Derek and I first started working together and that was one of the first like real software projects I’d ever been on. And I remember being so energized and so motivated by, having that clear vision of what it was that we were going to ship and we didn’t know how we were going to do it. The, like Derek said, some of the technical challenges. Pretty, they’re pretty high hurdles. But having that vision and knowing what the outcome of success was going to be really helped push me to, come up with some pretty innovative solutions. And I think we created some pretty awesome technology with very simple tools. It was very S a very small thing that was easy to manage, but it accomplished a pretty amazing outcome for the company. But that same company, the broader company vision was so poor that I became very disenchanted working there only a year, even though we’d shipped this amazing product and, it was extremely successful. It wasn’t a place that I wanted to work at. Roy: I think we saw to here with Integrum where we were for a while, didn’t really have direction. One of the go where I think you described our company vision, as we build stuff for people. Yeah, or something generic like that, where we didn’t really know where it was going. And it became very difficult to want to put an extra effort or to want to help out the company, because you don’t know how you’re helping the company. Cause you don’t know where the company wants to go. And we also, I think found it. A lot of people disagreed with each other because we realized we’re a lot of people that wanted different things. And I think that moment when we had a had a big meeting and decided what we wanted to do and although we lost quite a few people, I think the people that stayed are much closer and now it’s much easier to rally behind. The organization. Derek: Yeah. I think when you don’t have a vision it becomes very difficult to make even the smallest decisions because every decision has, multiple touch points, multiple pathways that it can take in. So something as simple as, okay, we’re going to tackle challenge a if I’m a designer and I think that everything in the company should be about design. I’m going to focus on every decision to. What’s the best design from a visual design perspective. And if I’m a feel like the company’s all about software craftsmanship, and that’s what we’re really about. I might take this as a reason to try every new technology and spend an inordinate amount of time on dealing with all of the, how the system works or is architected or how it interplays. Where somebody else might say the company is really about doing these amazing, innovative game-changing things. I don’t care as much about design or as much about craftsmanship. I care about, doing this deep, meaningful, product development type of push. And you go into every decision and you’ve got three people on the same team that all have a different goal. Even if they come to a decision, you’re going to have two people that are pissed off the entire time that they didn’t get their way. And that decision where if you come in and everybody says, the goal is craftsmanship or the goal is designed, or the goal is product development or whatever that the goal is, or that the vision is it becomes a lot easier to go, okay this is a simple, like we, we would never go try out this new technology. That’s going to take all this time because that’s not what we’re about. We’re about shipping product, right? So we need to do whatever it takes to ship the product. Drew: That’s one thing I was thinking too vision’s great. And you can have all these great ideas. You’re going to change the world. At the same time. I like what you said about you have to ship it, right? So you’re great vision of changing the world or where you want to be. It has to be coupled with the reality of, okay, what are the steps that I need to take to get there? What days do I need to ship in order to get this released and what do I need to do now to make it so that I can ship on this day? That’s one thing, and in my learning experience with scrum and agile is. That had such an impact on me. When I saw that I saw a contrast between someone who said, yeah let’s do all these great things, but we never released it. Or it took forever to release. And another between, Hey let’s do all these great things let’s release on this day. And if we’re not ready to release on this day, what can we cut to release on this day? And that felt more in line with the envision. When you actually get something. Jade: What you’re saying is that having a great vision also depends on a great implementation. Drew: Exactly. Derek: I think so. I’m trying to think of some samples of where perhaps a business vision didn’t align with team vision or technical vision in some of the problems that come out of that. And what kind of thinking back to two, two projects where I think that from a. Business. Perspective they’re are products that wanted a large market penetration for their particular vertical segment. And they wanted to surpass kind of everybody else that was on the scene, which meant that they wanted a whole lot of features that, we have to have more features than our competitor in order to own the space was the feeling or the vision from the product owner and not criticizing. Saying one way or another, my thoughts on that, but that was their particular vision. However, from a team perspective or I might even say a team perspective. People within the product ownership team had a vision that it had to look better than everything else. And so there’s this constant kind of push yin and yang of, I want to be pixel perfect on absolutely everything. But I need to ship, 10 times more features than the product that’s eight years old in the next two months. And some of, what does that cause? What are some things that you guys have seen that where you saw a misalignment either within the team or from the team and the product owner or the stakeholder that caused impediments to actually getting the work done or shipping the product. Roy: So I think we’ve seen some cases in which companies have been fairly successful already and are now at a point where that they kinda have to choose whether they want to continue to move forward and bring in more business, or if they want to stay where they are at and just keep bringing in the continuing income and not take the risk to go further. And. Actually in situations where there’s been a divide within the company where half the people want to go one way and have two people want to go another way. And that causes a big problem when you’re trying to make decisions because who’s making the decision or, what particular issue is largely decided by those facts. Derek: So that might be, I’m a fortune 500 company. I obviously did some innovation to get, to be a fortune 500 company. And now either within the team or within the company I’m starting to get risk adverse because I don’t want to lose my spot in the top 500 perhaps. But some people within the organization want to move to the top 100. And in order to do that cost cutting or, getting incremental efficiencies, not enough to go from four 50 to 100 you’ve got to do something, bigger, better brighter. But that has downsides. And just even being out of alignment on something as simple as that can cause issues with a development team, what are some of the other impacts that you guys see out maybe outside of the development team or inside the development team? Some manifested manifestations. Roy: So I think we’ve seen in the past, like we clicked Clayton. There’s always in our team championship, a champion for testing. And we’ve seen for quite a while. Some of the team didn’t quite buy into the testing solution. And so they try to find ways around it while the the portion of the team that did believe in testing the things like set up an integration server and set up our our fill board and all of these tools to both both be able to test and also to provide visibility to test coverage and whether or not the test pass. And in the meantime, the other half of the team was trying to find ways around that and trying to find ways to. Accountability and duct needing to do all of that stuff because they didn’t believe in that Derek: any other samples. So I think that might lead for a good segue. Next time I think that where I think we’re talking a little bit about vision and in pragmatism and Obie Fernandez, his recently done a blog post that kind of talks about. And maybe if you’re a lean startup, you shouldn’t test it at all or should radically think how you test then maybe that’s a good segue into that for next time. Jade: Thanks for listening. Talk to you next time.

Jade Meskill: Hello and welcome to the Scrumcast. My name is Jade Meskill. Roy vandeWater: My name is Roy vandeWater. Chris Coneybeer: I’m Chris Coneybeer Derek Neighbors: and I’m Derek Neighbors. Cost Of Interruptions To Teams Jade: All right. Today we will be talking about the cost of interruptions. So why doesn’t somebody start us off with: What do we consider an interruption to the normal scrum daily workflow? Chris: I think that an interruption is anything it’s going to be pulling me off of the work that I’ve actually tasked out and I’ve committed to doing this week. Anything that’s outside of my particular commitment that I’ve already made for the week. Roy: I definitely agree with that definition too. Anything that could potentially harm my my commitment or takes away the hours that I have available throughout the week that I committed to and then reallocates them to something else. You Might Be a Culture Interruption Company If Derek: I was thinking right before we walked in here, that more often than not companies that have a lot of interruptions. Have a culture of interruptions. Wouldn’t it be funny if we went around and said “you might be a culture interrupted company, if” similar to “you might be a redneck, if”. So, let me start with, you might be a culture interrupted company, if everything you have to do is top of priority. Roy: You might also be a interruption driven company, If your interruptions are interrupted. Chris: Yeah. Jade: Yes. That made me think we were like three interruptions deep one time at one of our clients, it was like inception interruptions. I believe is what we ended up calling it. Chris: Wow. Derek: You might be an interruption driven company, if there’s a hierarchy to who can interrupt. Jade: You might be an interruption driven company, if you have a person on staff whose job is to manage the interruptions that you get. Chris: I can’t think of any good ones right now. Derek: So I think those at home tweet out if you can think of a, “you might be an interruption driven culture, if” Jade: Yeah, that’s great. Roy you’ve recently, you’ve been working with a client that kind of has this problem. Tell us what the daily flow feels like while you’re over there working with that team. Hoping For Less Interruptions Roy: So it started out at the beginning. We were going through standup and are expressing, we have a standard where everybody expresses their mad, glad, or sad about something and everything they say must start with one of those three. And even though it isn’t one of those three, we always get the, I hope that today there’s no interruptions or we referred to it as slack. So we hope that there’s no interruptions today. Then sure enough, as soon as standup is over, the first thing we get is an interruption. Then we start working on that. Then we get the next interruption. I would say on average, one of our resources is occupied with interruptions at least the entire morning. Then if you’re that one resource when you get to lunch and you’re like, I haven’t burned on anything on my commitment yet. We’ve got to be behind and oftentimes we are. Jade: What do these interruptions look like? What Do Interruptions Look Like Roy: A lot of times they are things that the person probably knew about ahead of time. They realize now, they need it immediately. I think that’s the majority of interruptions. Jade: In this case, you’re working in a live production system, that is managing a very physical process, right? There’s a lot of money and things are very time dependent. Do you feel that is a major contributing factor to the interruptions that you’re having? Roy: I can empathize with some of their need for interruptions. We see that there are clients that call in with their own emergencies. While I think that we should work towards mitigating those and decreasing those over time. There’s a lot of interruptions that have nothing to do with clients. Because there’s been an interruption culture, interrupting culture is almost bred from the fact that people knew their work wasn’t getting done. So somebody would put an item in the backlog and the backlog item would just sit there and not get done because all of these interruptions were constantly taking place that would precede it, that were higher priority. So if you added something to the backlog, you knew your stuff wasn’t getting done. So a much more, a much safer tactic as one of the stakeholders is to wait until the very last moment. Then say, “Hey, I got this huge priority item right now, and I’m going to throw it in and I need this done tomorrow”, because then you actually get it done tomorrow. The Impact Of Interruptions Derek: I definitely think that’s a huge symptom of a culture that is completely interrupted driven. What starts to happen is all planning goes out the window. So I know I need this deliverable in six weeks, but I’m not going to really say anything about it, or I’m going to casually say, “Hey, I need this thing in six weeks, but don’t worry about it”. It’s not a big deal right now. Then when I’m two or three days out for needing this thing. It becomes, this is the highest priority this has to be done, or the world ends. I think what happens is when you get into that interruption culture, one of the costs is people think that if something’s not on fire, it’s not worth doing. I think most people who deal with their dental health feel this way. Until I need a root canal, I don’t go to the dentist. Where if I was brushing my teeth and flossing on a regular basis, I could probably prevent ever needing a root canal. I think that companies fall into this same kind of mentality. Especially when your mouth is just full of cavities all the time. It’s I don’t have time to get my teeth cleaned or to brush my teeth. I’ve got a dentist appointment I’ve got to get to don’t you understand that? One of the cost of interruptions is people start to stop people, stop being able to realistically prioritize what’s valuable. Chris: Because I’ve worked at a company before that, it was a culture of interruptions. It really starts to break down team because what happens is it starts to become who has the most power who has the most say so, so and that’s a person I’ve got to talk to for my interruption to hurry up and get pushed through. It starts to break down us working together because all of a sudden you’re depending on who has the biggest say so to get my interruption in. There’s no true planning and it throws a whole team into chaos and chaos for this is not good. Roy: It also makes it impossible to prioritize the backlog because everybody’s holding their stories up until the last moment and release them. You can’t really come up with a six week plan. Because during that six weeks, there’s going to be tons of people that are going to come in with stories and say, “I need this done tomorrow”, and that’s going to happen three weeks from now. There’s no way I can anticipate that ahead of time. Derek: Yeah. When we’re talking about costs. I think another huge cost is good decision-making. If you have to make a judgment and you’ve only got 30 minutes and I put a gun to your head and I say, “a or b right now, come on to a or b right now or I’m pulling the trigger”. You’re probably not gonna make a really great decision on that. Jade: Know plenty of product owners that would have been shot by that point. Derek: What happens is by delaying things until the last minute, until they are emergencies, people make all sorts of shortcuts to quality in how they solve the solution, whether the solution really needs to be implemented because it’s, if we don’t do this right now, it is like this person’s going to die. If we don’t cut their leg off, the person could die. Whereas if we were able to treat it six months earlier, could we have come up with a better solution plan that would have prevented them from having to cut their leg off. Chris: Also customer service issues. If you’re talking about, a live environment, when you’re hurrying up, like you talked about in the amount of shortcuts that you take. What am I going to see with my customer when I’m having issues? We made so many shortcuts and a lot of times in that environment, you never pay attention to that data. You’re never looking at that to make better decisions in the future. It’s always just fix it now. How are you affecting your customers? The Vicious Cycle of Interruptions Jade: That becomes a vicious cycle of just absolute destruction. Roy: As a developer, it seems reasonable at first. You’d be like, oh, let’s just an interruption, but the people who are interrupting start to learn from that. They think, oh, this is how it gets stuff done. They keep doing it. Other people catch on and soon all you have are interruptions and there is no longer a process. Interruptions Impacting Innovation and Collaboration Derek: Yeah. And I would say another cost talking about costs are, I think you lose innovation because instead of being able to make good decisions and to be able to get creative. You’re always just dealing with “I just have to get this out of the door”. I don’t really have time to apply any kind of creativity here. I just need to get it done and get it over with and do whatever it takes to get it done. Chris: Creativity and collaboration. Because a lot of times with that, it’s an idea that somebody had four months ago. Like you’re saying, Roy, they waited until the last minute. It never gets vetted. It never works through a team process. So the collaboration’s gone and you have a single person that could be very well pushing through decisions. Visualizing Interruptions Jade: What are some of the things that we can do to expose this? I think a lot of these things happen subconsciously and it just gets built into the DNA and the culture of the company nobody’s doing it intentionally to screw you or try to work around the system. Some people maybe, most people that’s just, “it just is what it is”. So how do we expose that to their conscious mind and, show them in such a way that they realize, oh my gosh, this is what’s happening. How do we fix this? How do we drive people to make that realization? Roy: So initially we tried to just have a whiteboard up and on that whiteboard, we list out every single interruption and how much time. We use a ticketing system. So at first just a ticket number and then how much time it took. Then it grew so that columns kept getting added to it. So who worked on it? A brief description of the problem. Who was notified. Quickly even at the point where it was just an ID, a ticket number and a time, it wasn’t any fun and nobody actually bothered to update it. We’d get to the end of the week and we know we’d been interrupted more than five hours, but that’s all we have up on the board because nobody managed to track it. So one time during team lunch I had a great discussion with Derek and with Clayton. Clayton suggested that we blow up one balloon for every 15 minutes of interrupted time. We tried it that week. Every single time somebody came in and said, “Hey, I need this quickly done”. We say, “that’s fine”, and immediately start blowing up a balloon as we’re listening to them describe it. Then as the first 15 minutes passed by and we’re working we’d set that balloon aside and would add a second balloon. By the end of the week, our entire bullpen, the coworking space where we were working, was just filled with balloons and there were balloons everywhere. Everybody walking past thought it was hilarious that there were so many balloons. It was a great representation. The fact that the entire floor is coated balloons, and the reason why is because we get interrupted so much. Jade: So how did they react to introducing something like that? Roy: As soon as I heard this, I thought it was a fun idea. We went out and bought some balloons and we’re just going to do this. Then when we brought it up with the team nah, we’re not going to do that. That’s silly. What if we have salespeople walking around? Or what if the CEO walks past and he thinks it’s ridiculous. We’re going to have to explain this to him. Wait, we’re spending all our time blowing up balloons instead of working he’s not going to. Jade: And so how did you handle that? Roy: So that’s it, to be honest, we just started blowing up a little bit. We just did it. And then it caught on because the balloons became fun to play with while we were working. While you’re thinking, tossing balloons back and forth, and it sounds like we’re not working, but I don’t feel like there was less work being done because of it. What ended up happening is the CEO actually ended up walking past one day and going what’s up with all these balloons and we ended up explaining. And he’s really? That’s what they’re for. And we’re like, yeah, that’s, we figured we wanted a good way to visualize this. The board wasn’t working. So we started blowing up balloons and he just thought it was the best idea ever. And he was super excited about it. So it ended up not being that big of a deal. And we didn’t end up looking too silly after all. Chris: So I was just going to ask at the end of the week with the CEO and whoever else was involved, did people look at this in the day and gain insight, did management. Roy: I will say that we were able to count up how much slack we had and that allowed us to, because we were just able to count up the number of balloons. So we knew that we had 75 balloons that equates to 18 hours of interrupted time. And so we were able to look at that and say wow, we didn’t realize that all this time was actually being used for interruptions. And so we were able to say it isn’t just five hours a week. It is 18 hours a week. And now that we’re actually taking the time to track it, we can see that this has a huge impact. Derek: I think the nice thing about doing something visual is it’s fun for everybody, right? So instead of being like negative oh man, we’re getting interrupted again. It makes the interruption a little more tolerable for the person getting interrupted, but it also provides an introduction to a conversation point for the person who’s doing the interruption. Hey, why are you blowing up the balloon? It’s an interruption and it’s keeping me from doing what I need to be doing. And so this is how we’re tracking it. Hopefully that person starts to think twice. Wow. I never really thought of it that way. I’m interrupting Roy by coming over here, maybe I need to be a little more mindful of that, whether that happens or not, hopefully, if it was continued, people would start to see okay there’s a real, very real impact. Roy: I think you see that they aren’t the only ones I think a lot of people that come and interrupt us, they only ever see us working and they don’t see us getting interrupted by other. And so they come in and they think oh, it’s no big deal because it’s just me asking for an hour of time of there. Then when they see entire cubicle fields and they’re like, what is up with all these balloons? I thought I was just giving you guys an hour a week. Yeah. It’s you and 15 other people that are also constantly coming. Chris: Are you still continuing this right now? Roy: We’ve been doing it every other week and it’s been noticeable that our successful weeks, and we’ve only done it for three weeks now with two weeks with balloons. And when we close out and it’s been noticeable that the two weeks with balloons have been really successful. I wouldn’t say that it’s because of the balloons, because I don’t have enough data to go on at this point. It’s certainly more fun when the balloons are around and we do a, and we definitely track slack better. Like the second we dropped the balloons, it was back to five hours a day, a week of interruptions Derek: of measured interruptions. Roy: Exactly. Sorry. Jade: So we’ve got just a few seconds left here. Any other tips or tricks that you guys want to throw out there for dealing with an interrupt driven culture? Final Thoughts Chris: I really think sitting down and trying to have some conversations with the people that are making the interruptions. And also guys, that are also behind allowing the interruptions to continue. Because you have the interrupters and you also have the people that are in control that allow the interruptions to continue. And I think that. Especially, not even if you’re working in a scrum environment, I think having conversations about productivity and amount of hours, and then also something visual. I think the idea like Derek said, it’s something that’s fun. It’s something people can, you can give a quick look to, I think that’s really good to do ha have conversations about what it’s like to be interrupted, how many are seeing, and then try to do something visual, try to do something that’s fun. So people don’t feel like you’re trying to attack and push back on work. Just open up the conversation in a positive way. Jade: Great. Thank you for listening to another episode of the scrum cast. We’ll catch you guys next time.

Clayton Lengel-Zigich: Welcome to another episode of the Scrumcast. I am Clayton Lengel-Zigich Ray vandeWater: I’m Ray vandeWater. Jade Meskill: Jade Meskill. Derek Neighbors: I’m Derek Neighbors. [laughter] Mike Vizdos: I am Mike Vizdos. Jade: We have Derek and Mike on Skype with us. The Cost Of Change Clayton: Today we are going to be talking about the cost of change, when I hear that I think of certain things and I am sure you guys think of other things. I am just curious Derek, from your perspective what is the general definition of that so we can get started. Derek: Change or the cost of it? Clayton: What do you mean when you say the cost of change? Who are you talking about and who is involved? Derek: When I am thinking of this, I think of it both on an individual level, I’m thinking at a team level and an organization level, so I think that a lot of times developers or managers might say, “Hey I really want my team to do Scrum because we’re going to get all these benefits,” and they don’t think about the ramifications that’d happen when they do that. A number of things change whether you implement pair programming, whether you have a wide open work‑space. I remember one of the first things to change at Integrum when we really started going full bore is, we went away from personal desks and went to paring station, and just the ramifications of people not having somewhere to put some their personal things, and some of their emotional baggage that came out of that that we had to deal with, was certainly something we never even considered as being one of the byproducts or the problems with that. Ripple Effects In The Organization Derek: What happens to HR when you have totally cross‑functional teams and they’re completely dependent on a job title to determine how to pay somebody or to determine how much square footage they get as an employee. I’m a CEO and now I’ve got an actual team that’s doing an implementation that is starting to expose problems with maybe the way I incentivize my sales people, is actually damaging the organization and now I have to think about how I compensate sales people to be different so that they can be a better part of the whole organization. To me it’s what are those elements of change and what can one really start to expect and how you cope with that. Clayton: Mike is someone whose maybe experienced some more of this stuff in a large organization. Kind of like what Derek was talking about, where you maybe have a group of people that are cross‑functional and it’s hard, murky water to determine pay scales and bonus programs and those kind of things. What are some patterns you’ve seen, or some things where people get it wrong? Getting Human Resources On Board Mike: A lot of times they don’t involve HR right away. Remember HR in a lot of large enterprise organizations have very different priorities than this little scrum team. Maybe that’s starting to take hold. You really have to start to get on their radar early, and often, and understand that any kind of changes are going to be maybe years away. Being able to get HR on board is especially important. Especially when you’re talking about the matrixed organizations where you have scrum teams working in large waterfall projects. Clayton: You mentioned getting HR involved. There are a lot of times where I think a lot of companies have slow moving HR departments. Or just in general there’s some red tape and bureaucracy. How does that contrast with the way that we think of Agile and the way we think of making change, and implementing things quickly and iterating and those things when the typical life cycle of doing almost anything is usually much longer than, say, a sprint? Mike: Part of that involves really, again, getting people on board. Normally when I start teams in large organizations I’ll let them know that they’re probably going to take a hit on their performance evaluations. Like, one in the first year. Because now they’re not being specialized working as cross functional team members, and all of a sudden as a tester, let’s say as a role, they’re being compared to other testers within the functional organization. With the traditional, “Do you play well with other teams, do you have your nice power point presentations, do you do your executive exposure, do you play nice with others, do you have work on 20 projects at once?” You don’t rank that high against other testers that you’re being evaluated against. So being open and honest about this is really important. Performance Reviews Clayton: Jade and Derek, as far as the Integrum we have maybe more feedback than a lot of organizations from the management to the employee level just because we’re so flat, but when you have a traditional organization that wants to do performance reviews like Mike mentioned, and they have a very set way of doing those things and mentioning that stuff, I think one of maybe the benefits of Agile you could get into is you could say there’s extra feedback. You know where you are a lot of the time and those kind of things. What’s the reconciliation between those? The traditional personnel review and that kind of constant feedback and being part of a team, not necessarily an individual anymore? Derek: So I think there’s a multiple problem. So one is, is the content of the actual performance review relevant anymore? Meaning usually HR has a fairly good amount of weight that they’re allowed to put into how you structure your performance review, and it’s fairly standard to‑the‑book type of format. When you start to talk about being on an Agile team, it’s really more about values, principles, and goals and a lot less about individual duties and what your job is specifically. So a lot of times you don’t have an actual performance review that matches what you’re doing. Two other problems I really see with the performance reviews are that they incentivize the individual instead of incentivize the team, which is obviously fairly contradictory to Agile methodologies where it’s really about the team instead of the individual. Then lastly is I think a lot of things that go along with performance evaluations deal with ranking employees and pitting this person against that person. They actually create mistrust within a team. Derek: So the best I would do if I’m in a situation would be to try to hold reviews or have the discussions that are much more honest, much more true, outside of the performance review and then fill out whatever performance review is necessary to turn into HR to placate them and congruently be trying to get HR to change their practice so that they’re more in line with being an Agile organization as opposed to being the dinosaur organization. Individual vs Team Clayton: I agree with what you’re saying, Derek, but I also think that we do need to have some mechanism of dealing with the individual as well. There are a lot of ramifications that a poorly performing or a bad fit can have on the whole team. So creating those mechanisms that can deal with the individual behavior and I think tailoring the reviews and the feedback to the very specific individual person at that level is good as long as you are also dealing with, like you said, more of the team context as well. I think somewhere is a balance between those two aspects. You can’t completely forsake the individual for the team or vice versa. Derek: So I think to me where the problem comes in is that most performance reviews are structured towards the skill that you do, and I think that’s a bad way to do it. So if you’re monitoring me for how good of a software developer I am and it has to do with the amount of code I’m producing or the number of commits and, I don’t want to say necessary metrics but, things related specifically to code, I don’t know if that’s a good representation of whether I’m a good individual for this team. I think it’s Tim Lister. One of the things that they did when they looked at a number of teams in writing their book “PeopleWare” is they asked, “Who do you want to be on your team, and why did you want that person to be on your team?” In almost every organization there was at least one person that was on every single successful project and that, when asked, they were deemed one of the most valuable people on each one of those projects. Derek: But when they asked the people why, nobody could put their finger on it. I think what starts to happen is if you have a review that is simply a skill set, are you good binary at this task, yes or no? Sometimes, you rule out the best people because the best people that make teams successful, are key people that make teams successful, are the people that enable other people to do their best work. I think that, yes, you do need to take things at an individual level and review somebody individually. But, I think, we need to get to the point where we’re evaluating people individually on how they adhere to the team’s values and how they adhere to the team’s principles, not to specific skills or tasks. Meaning that most people that want somebody off the team do not want somebody off the team because they think they do a bad job. They want them off the team because they think they are a bad fit for the team. Jade: I agree. Roy: Because, when they are fit for the team, they’ll figure out ways to help that person become confident in the area that they need to be. Jade: I totally agree. I guess I was going under the assumption that you were measuring and judging the individual on the proper things. I think that’s a good point to point that out specifically. Social and Emotional Costs Of Change Clayton: Roy is someone who has been helping another team kind of adopt some of these Agile principles and things. What are some of the things that you’ve experienced in terms of the cost of changing, people that have been affected and what’s kind of happening there? Roy: What I’ve been kind of seeing is more of the social costs of change or the emotional costs of change is that when you’re restructuring and trying to adopt the Agile process, there are times when you’re going to have to have conversations in which two people are going to go into the conversation and either one person is going to have to change their way of doing things completely or one of the two has to leave. I think that’s a very difficult conversation to go into and that’s a significant cost of change that I don’t think a lot of people necessarily think about when they are going in to doing an adoption like this. They are going in to it thinking it’s going to be great, but then, there’s going to be heads bumping and people are going to have to make a decision on if they want to adapt or leave the company or whatever they want to do. Mike: We actually do find that there is, and I’m not sure where this statistic came from, between 15 and 25 percent turnover when you start to actually implement any kind of change like Scrum. Clayton: Is that because Scrum doesn’t leave a lot of room to avoid the fierce conversations that need to be had? Mike: Yeah, you’ve got to have those difficult conversations and some people do not want to do that. It is a significant cost of change. Clayton: That’s not even on an individual employee level or the developer level, there are managers that don’t want to deal with that either or that get totally freaked out by having to deal with this conflict. Mike: Absolutely. Conflict Comes With Change Clayton: That’s something I hear, “Oh, we’re fighting all the time. It’s horrible. We used to get along. Why is all this happening?” It’s really that you weren’t really getting along, but everything was so shallow and surface level, that there was really no room for conflict. Now that you’re digging in and really trying to work together and get better, that’s where you’re starting to uncover a lot of this conflict. Mike: Yeah, like when they’re going through that whole Bruce Tuckman model of forming, storming, norming and performing. Clayton: Yep. Mike: A lot of times, organizations are stuck in storming and it’s just normal. Mike: Yeah. Jade: They shy away from the storming and they don’t just push through to get to the norming part of it. Clayton: I think a lot of times, they don’t even realize that they are in the storming. Mike: Exactly. Barriers To Change Clayton: One thing, Jade, that you’ve mentioned before is that, you kind of gave an anecdote about, the company wanted to adopt some Agile principle, but they couldn’t get their risk management software to work with the new way of doing things. I would imagine that there are a lot of companies out there, big and small, that have invested a significant amount of time and money and resources into getting some third party tools or processes or anything like that. How do we deal with, when we say, “Well, we’re going to get this new process. This new Agile process,” and that makes, maybe it invalidates or makes this other thing you’ve already spent a bunch of time and money on not effective or useless? Is that something that you think would be a total barrier? A no go? Jade: I think that’s pretty scary for a lot of people, not even just in the software and the tools, but there might be entire departments that need to completely change. So if you have the QA department and the PMO and risk assessment and all of these people that are in these gigantic silos and now, you’re telling me that they all need to be cross‑functional and I need to completely change the structure of our organization to deal with that. That’s a terrifying thing to deal with. Especially, to not know what the outcome of that will be. Mike: On of the ways to really help get around this is to make sure you have some executive fire cover that is able to say, “OK, you know what, it’s a sunk cost. Let’s just do it and move on.” Because, you can’t really have that at like, especially the large companies, the director levels that are really competing against each other versus the vice presidents who have more of the strategic look. You need somebody high enough to go and say, “Let’s do it,” and make the call. Clayton: In your experience, Mike, how often are you seeing that happen where somebody is bold enough to really give the teams enough runway and enough cover to at least attempt a successful change or implementation of Agile? Mike: Very few. A lot of is really that at the highest level, they don’t really buy into it. So that could be a whole other conversation. Clayton: That’s a good segue into the next podcast. I say thanks to everyone. I’m going to stop now. Jade: Thank you. Mike: Thank you. Clayton: Thank you.

Derek Neighbors: Welcome to another episode of “The Scrumcast.” I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Drew LeSueur: I’m Drew LeSueur. Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich. Benefit Of Having Single Product Owner Derek: What you are talking about today guys? Roy: We are talking about the benefit and also the necessity of having a single product owner. Derek: Is a single product owner really necessary? Roy: I supposed it isn’t really necessary, but I certainly think it helps things a ton. A lot of times when you have multiple product owners on the scene, you get a lot of conflict of interest. You have one guy, who thinks his entire priority queue is the most important thing in the world and another guy, who thinks his priority queue is most important thing in the world. And you have to have somebody that ends up reconciling those two queues. Often times that ends up falling to the developer which really shouldn’t be his responsibility. Multiple Product Owners Means Multiple Problems Derek: So is the number one reason that multiple product owners is a problem is one of priority? Meaning that four product owners, all four think their thing is the most important thing. They all have a number one thing in determining which one of the four number ones is really number one is the problem? Or are there other problems with having multiple product owners? Roy: I think there’s a lot of other problems with it. I find that in my recent experience this has been the specific symptom that’s hurt me the most, but another huge issue to it is you don’t know who to go to for a particular issue. If something comes up, who do you talk to? Do you start tagging every story with one product owner or the other, and who decides when a certain piece of functionality is done? Derek: Have you guys had any instance where a proxy product owner has been deemed for sub‑product owners? So maybe there are four product owners, and everybody agrees that that’s unilaterally a bad idea. So neutral product owners put in place to prioritize or speak on the behalf of the four other product owners. Have you seen that? If so, have you seen it work or what are some of the problems with it? Not Talking To The Source Can Lead To Confusion Drew: I think one of the problems with that is if you’re not talking to the source, then you don’t really get the same power or authority that the source will give you. So if I’m talking to a proxy, he might not understand it the same way that the actual real product owner understands it. So I’ve seen that, and I’ve seen it where when we are talking to the source, everything’s a whole lot clearer. You feel like you can really have the communication that’s needed to figure out what you need to do. Clayton: When you think of the roles that are required for the product owner on the scrum team, when there’s a proxy product owner or more than one product owner, it gets really easy to skirt the responsibility that they have. So, maybe, the development team needs the product owner to do some interfacing with some stakeholders and prioritize the backlog, or do some backlog grooming, or whatever. But when there’s a proxy, it’s easy for them to say, “Well, I would love to do that for you, but I need to go talk to these three people and I can’t really do it.” Or if you have more than one product owner, then it’s like, “Well, that can be Joe’s job, I have more important things to do.” So, the responsibilities of the product owner get wishy‑washy, and some of that gets avoided. Roy: I think, too, one to the defined responsibilities, for both product owners and scrum masters is to protect the development team from the stakeholders and all the people outside of the scrum team. I think that when you start making the stakeholders the product owners themselves, technically they’re not outside the scrum team. Now you’re having all of this outside interaction coming in and interfering with the development team as well. How Do We End Up With Multiple Product Owners Derek: Do you think that one of the problems, I’m trying to think, what are some of the reasons why we end up with multiple product owners? Is it because stakeholders are unwilling to let somebody represent them? Let’s start with that one. In the case where maybe there’s three stakeholders to a product, and none of the three are willing to give up control of determining priority or making sure the direction of the product is going their way. What are some ways that you could effectively potentially use either a proxy or get one of the three to speak on behalf of the others? Product Owner Not Willing To Take Responsibility Clayton: I think if you have a strong product owner, even if they are a proxy, they can still treat the other people as stakeholders, do all the interfacing and prioritization that they need to do, and helping the team define done. They can still do all those things. In my experience I’ve seen, maybe the flipside of what you’re asking, Derek, it’s not so much that the three people don’t want to give up the responsibility. It’s more often than not, where the proxy person doesn’t really want to take all that responsibility on, because they don’t want to stick their neck out and be the single wringable neck, so to speak. They don’t want to take that responsibility and then be accountable to those three people. They would rather say, “Oh, sure. I’ll be the product owner.” And then, when push comes to shove they can say, “Well, I’d love to help you out, but I need to go talk to these guys.” And I don’t think they want to be accountable to the organization. Derek: So could we say a certain smell when you’re using a proxy to try to eliminate multiple product owners is when they constantly defer back to, “Well, I’ve got to go talk to some group of stakeholders or even a single stakeholder. I don’t feel that I’ve got the authority to make that decision”? Drew: Right, I think that’s definitely a smell when you recognize that the product owner needs to have equal parts authority, time, and knowledge about your project. If he’s got to refer to a bunch of other people, then he’s severely lacking in the authority, which doesn’t place him in an ideal position to be a product owner. Clayton: Right. Especially if it’s over every single story. Having to do that, that’s a definite smell. Unified Backlog Against Multiple Products Derek: Now, let me maybe posit a slightly different scenario that I’ve seen in a number of companies, and maybe we can talk about what are some ways to handle this. Maybe I’ve got a development team of five or six developers, and our company has eight different products. They’re all fairly mature products. So the six developers are responsible for all eight products. But each one of those products has a different product manager. It doesn’t make a whole lot of sense to…Each product manager is willing to take responsibility and be a product owner for their product. But how would you go about dealing with creating a unified backlog so to speak between eight products where you didn’t have to interface with all eight product owners? What are some ways you could go around that? Clayton: I think, in general, when you have a bunch of product owners and you want to delegate the responsibility of the product owner and bring it down into one person, it’s generally easier to go up because responsibilities tend to converge when you go up, and also authority tends to be higher when you go up and sometimes knowledge as well. In that example, we have a bunch of different project managers. I would say, “Who’s the person in charge of all of them?” Is there a C level officer who can be the product owner? Although, a lot of times an issue you run into in that situation is that that person doesn’t have the time to prioritize the backlog and do the other responsibilities. Derek: Say that there was a product manager that was over all eight products. Then there was a product owner defined for each one of the particular products or a project manager or whatever you want to call it. If that product manager was willing to say, “I’ll prioritize the queue for you. I’ll make sure that I’ll be responsible for the queue.” They’re probably still not the best person to probably be in the planning meeting because they don’t know all the specifics about the stories. I guess what I’m saying is how would you go about a situation where you had multiple subject matter experts or product owners? Even if you didn’t have an issue of prioritization but you had one of specialization, what would be some potential recommendations that you could do to combat that? Roy: To me, the prioritization in that scenario sounds like the biggest problem, but if we are saying that the prioritization thing is taken care of by the overall, overarching project…

Derek Neighbors: Welcome to another episode of the ScrumCast. I am Derek Neighbors. Clayton Lengel‑Zigich: I am Clayton Lengel‑Zigich. Roy vandeWater: I am Roy vandeWater. Agile Estimates Jade Meskill: I am Jade Meskill. Today I wanted to talk about estimates. Derek: How long do you think it’ll take to talk about estimates? Jade: It depends. Clayton: Have you ever done this before? Padding Estimates Jade: I thought the answer was, “It depends” [laughs] . Seriously, we want to talk about what are the challenges with estimates for your teams, for yourself? What are some of the things that we struggle with? To kick it off, let’s start with padding estimates. How do we feel about that? Derek: Pad them, definitely. All the time. As much as you can. As much as they’ll let you. [laughter] Derek: Unless I’m paying for the work, then padding’s not allowed. Clayton: Padding is something that is ultimately unnecessary inside of an agile framework. For scrum, for instance, if I say I’m going to do this many points this week. I commit to something for this iteration, and then my estimates are wrong, and I get half of it done or whatever. Assuming that everything else went right, then, it’s just instant feedback where I can say, “OK. Now, I know I can only commit to…” It helps you modify things. Ultimately, it’s a moot point. Negotiating Budget, Timelines and Scope Jade: Why do you think it’s so prevalent that there’s certified scrum trainers out there teaching people to pad their estimates? Why do you think that they feel that’s necessary? Derek: It’s because they don’t understand the point of an estimate. What I mean by that is still today, even in a lot of scrum implementations I see we’re really talking about wanting to be precise, instead of wanting to be accurate. There’s this big, “Our estimates have to be perfect, because we’re telling somebody that this is the estimate. When we tell them that this is the estimate, then they’re going to go allocate a certain amount of budget.” When we tell them what that budget is and what that time is, they also expect to get every single feature that we told them as part of that estimate. As Clayton says ‑‑ when we go in and we get an iteration or two, we realize that maybe our velocity is not 20 it’s 15, we have a choice to make. We either have to spend more money, or we have to reduce the scope, or negotiate what it means to be done on the scope that we’ve already defined. People do not like to have those conversations, because it requires being personable. It requires all parties coming to the table and having a discussion between people. I think as practitioners we like to hide behind tools, we like to hide behind code. We like to hide behind every technology known to man, short of having real conversation. I think that product owners and business owners have a very similar problem. Because they don’t understand technology, they say, “You told me X, therefore X had to be true, just make it work. Work twice as hard, or work twice as fast, or do whatever and make those estimates right.” I think it’s because we do a really poor job at the beginning of a project, or at the beginning of working with somebody, defining what it really means to do an estimate using Agile methodologies. What we were trying to is be accurate and be able to do some moderate planning, but we are going to have to inspect and adapt not only the way we’re doing things, but the length and the cost that it’s going to do those things as well. Precise Vs Accurate Jade: Let’s say that I am a product owner and I have a project that I would like you guys to do, and I need to know how much this is going to cost me? How long it is going to take? Here is my requirements, or my stories, or whatever it is that I have gathered for you. How are you guys going to give me any assurance at all that I can plan for this? Derek: My two questions to you would be, how quickly do you need the estimate? How precise do you need the estimate to be? Jade: What’s the risk in getting an inaccurate estimate? Derek: The more precise you want to be, the longer and more expensive it is going to be, to get you an estimate. If you changed your mind on anything, or we discover anything new, we’re going to have to not do those things, or we’re going to have to go out and do all new estimates. Jade: I’ve got a $30,000 budget, and I needed it done in four weeks. Can Scrum do that? Derek: I think Scrum can give you a moderate picture of what the team believes they can do in four weeks on your particular budget, or I guess they could give you one or two things. They can either tell you four weeks what you will get for that budget, or they would tell you with your budget, how many features you can get done. One of the two and I think that you can negotiate a fair amount of that feature set, and then have somewhat a good idea in every week. You will be able to potentially get feedback on how accurate those estimates were. Jade: I want it all. Derek: You should probably go to waterfall methodology then. [laughter] Tips and Tricks for Estimating Jade: Estimation is one of the most difficult parts, I believe of being a good scrum team, is being good estimators. What are some tips and tricks that we can offer people to help make their estimates more accurate, help deal with these questions that come up from products owners? Inspect and Adapt Prior Results Clayton: I’d say that as far as becoming, say better at estimation. I would say really take the inspect and adapt concept, and apply that to your estimations too. I think a lot of times people do the padding thing, because they just pad everything. They don’t ever go back, and they don’t ever try and see, “Was I right?” Or “How far off was I?” Or anything like that. It’s always just, “I’m just going to take, whatever I think it’s going to take, and I’m going to add 50 percent.” That’s their general rule. They don’t ever go back. I did that here with this team, and went into a sprints worth of tasks from every single project I think, and they were 300 or so. Maybe it was two weeks of task, but we were off by an average of like half an hour I think. We were so close to our estimates, but at the time, everyone was saying that we are so bad at estimating, we did everything wrong. In reality, we were actually pretty close. We were way better than I think anyone would have thought. I would say that if we can go back, and come up with some way to look back at your estimates and see either you are right, you went over or you went under, and why. Apply that next time. Don’t Think In Terms Of Hours Derek: I think one of the things that I see most teams do when they estimate, that really hurts them, is they are still way too tied to thinking in terms of hours. I’m trying to map what does a three point story look like in terms of hours? What does a five point story look like in terms of hours? Instead of thinking about them in terms of difficulty. What I always like to say, is when somebody says that they are a bad estimator, usually what they mean is someone, either myself or somebody on the team, or somehow we derived a velocity that we thought was acceptable. We didn’t hit that velocity, and therefore our estimates were wrong. What I like to say is, “Well, perhaps your velocity estimate was wrong, but were your story estimates really wrong?” If I say something is an eight, and something else is a three, and something else is a one. If that three is three times harder than the one, and the eight is eight times harder than the one or a little over almost three times harder as a three, I would argue that your estimates were spot on. Even if your velocity was off by half, or double. That’s really where I see developers really getting hung up. Is that they get way too hang up on the velocity side, instead of how they are seeing stories and relative size. I think if they can nail relative size, you start to learn how to do velocity as you start to work as a team longer, and more together. You start to see what’s common. I think we get way too hang up on that, that’s because we do fixed bid price kind of work, even we do internal work usually as scrum teams. We put a dollar figure on something that relies on the velocity never changing. I think that’s bad. Make Sizing Relative To Reasonable Knowns Roy: I think something we run into a lot as well is that, we had this mentality a lot of times going into doing estimates, where we’ve done a lot of reals application, specifically for us in the past. We start off going in to estimates with this notion that a CRUD operation is automatically a three. Then everything is based off of that. The thing is not every single project that you come into is exactly the same. The skills are going to move all around, because what’s important is that, each story within that set of estimates is relative to other stories within that estimate. Not relative to any story outside of that. Clayton: Yeah, I think the first time that became really abundantly clear to me is, I was working with an embedded engineer, and every single estimate was under a three. There were some things and I was like, “Dude, there’s no way. That’s going to take at least a week worth of work to do that, and you put a three on it.” Then we went through an exercise to estimate the initial velocity, and the initial velocity for a week was five. It’s like, “OK.” You get used to working with a team who the numbers are probably more in the threes and the fives, or the eights, but the velocities are 25 to 30. Velocity really has a big impact to where your sizing story is as well. Padding Skews Your Sense Of Reality Over Time Jade: What advice do we have for trainers who are out there telling people to pad their estimates and use some multiplication factors? Things like that? Roy: I think, ultimately, as a trainer, you’re hurting the team. If you’re doing something like that where they are padding their estimates, then they’re going to think of their estimates in terms of that multiplication factor. If I estimate this as a two, and I multiply that times whatever figure, then when I go back and reflect on my estimates, I’m going to think about it in terms of the multiplied amount. I’ll be comparing the accuracy of my estimates against the wrong actual estimate. Clayton: Yeah. I think it’s to the detriment of the people that are doing the estimations, and also to the people that are paying for the work. What I found is, when someone goes under on a task, let’s say that they thought it was going to take an hour and it only takes 15 minutes. When that happens, there’s never a revelation of, “Hey, I got this done so much earlier than I thought.” But when they go over, it’s always a huge justification of, “Oh, I told you that. This is why our estimates are always wrong, blah, blah, blah.” It’s always like a one‑way street, and they don’t ever cancel each other out. When in reality, I think that’s what happens. It’s to the detriment of the people that are doing the estimations, because they don’t ever find out that they were right some of the time, and even though they were wrong some of the time, it was OK. Jade: Yeah. I think that’s really good. I think that wraps up the podcast for this week. Thank you and we will talk to you again later. Derek: Thanks.

Derek Neighbors: Welcome to another episode of ScrumCast. I’m Derek Neighbors. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Jade Meskill: I’m Jade Meskill. Agile Retrospectives Derek: Today we’ll talk a little bit of retrospectives. Jade: Actually, I have a question for you Derek. You are the one who usually runs the retrospective here at Integrum. Doing that for a while, what are some traps you could fall into as a Scrum master, where the retrospectives are kind of stale, where you are talking about the same thing over and over again. What some negative patterns you have seen, maybe some smells and ways to avoid those. Retrospective Negative Patterns Derek: I think one negative pattern is using the same activities over and over again. I see a lot of organizations or a lot of teams that do the Plus, Minus, Delta. That has pretty much the only tool, no tool box, only activity. I think that teams kind of get into a rhythm of just, “OK, I’m just going to spit out the same kind of thing. I’m not really challenging my thinking.” I think sometimes if you start to go into a little bit deeper activities, you can almost ‑‑ I don’t want to say trick people ‑‑ but you can get people to stop thinking about being guarded about the data that they’re giving, or about the ideas that they’re having. Instead, allow flow to happen a little bit better. I think that the more you can get people out the rhythm of the activity, the more that they tend to be honest or give responses that they wouldn’t normally. Because they are too focused on, “I want to get that activity and not screw it up,” or do it right, “that I’m being more real with my responses.” Whereas, if I know exactly what you’re going to do with the data and how you’re going to respond to it, it’s just like, “I’m not going to add this to it because I know that next step is A, B, C, and I don’t want to deal with whatever comes after A, B, C.” One of the ways, I think, you can really deal with it is to change it up quite a bit. Facilitation Resources Jade: I think the trap that some people fall into is they only think about facilitating a retrospective from an Agile perspective, instead of thinking about being a meeting facilitator. There are tons and tons of resources out there, but really great, smart people who have become very proficient at facilitating meetings, getting people to be creative and lots of games and exercises and different techniques. We buy the “Agile Retrospectives” book and stop there. I think that’s a huge mistake. Derek: I think “Thinker Toy” is a really good book. “Game Storming” is a good book. “Innovation Games” is a good book. There’s definitely kind of a whole industry or segment that really talks about a lot of these brainstorming or innovative ways or game ways to unlock things in your brain. I think that anybody who’s doing a lot of facilitation exercises should really check those out. The Art of Facilitation Additionally, I think there is an art to facilitation. We talked about traps. I think it’s very hard, especially if you are a Scrum Master or somebody who is kind of on the team, it’s hard not want to interject your opinion or to drive things the way you want them to be driven, opposed to being a facilitator who really lets people express themselves. One of the things I would say is, like the “F” word is a dirty word in engineering, and I’m not talking about “Fuck” because we all say that in [inaudible 03:45] . I’m talking about the explicit “F” word which is “Feelings.” I think that a lot of times to, really, unlock change you have to get people talking about how they feel about things, so they can overcome those feelings to move on. I think there is definitely an art, especially in dealing with engineers, in facilitating in a way to not really say, “How does that make you feel. Clayton?” But instead ask questions that pull those feelings out so that they can be dealt with, and so the team can deal with them. I think that’s definitely a trap that’s easy to fall into if you’re an engineer doing facilitation. Taking Too Long To Get To The Heart Clayton: One thing kind of segway into this that I’ve seen, we’ve had this problem and I’m sure other people maybe have this problem on their team, is when you want to get into the feelings, and you want to start talking about those things. But you also have a time box and you want to respect everyone’s time and people have things to do and whatnot. It seems like sometimes you get into the last 10 or 15 minutes of the retrospective, and there is some “aha” moment where you start getting into something deeper, but then it’s almost too late. It seems like that happens more often than not where it takes quite a while. Why do you think it is that it takes maybe the whole retrospective to get into that stuff? What are some things you could do to bring that up earlier? Derek: I don’t know good ways necessarily to bring it up earlier. I think some of it is we have to let our guard down. Sometimes it just takes a little while of that surface level chitter‑chatter. If you think of it like a dating ritual, sometimes you need to break the ice, and relax with each other until you move it to the next level. I think the retrospectives follow a similar pattern. Everybody has been doing the work for the week, so your mind is a little bit burned, you’re a little bit on edge, and it takes a little while to getting a little more relaxed, and get out of the “doing the work” stage to talk about the mental part of reviewing the work, in retrospect, and all that. It takes that time to, say, let the guard down and really do that. I think if you can pick activities, if you know you’ve got a team that’s a slow mover team, if you can pick activities that help break down those barriers, and get it into the mood of being able to share more openly, that you try to do those more often. Inspect and Adapt Your Retrospectives Jade: I also think that you need to inspect and adapt on your retrospectives, and, if you’re always having this problem, maybe you need to change the timing or the length of your retrospective to deal with that. If it takes your team an hour to even get to moving beyond the surface level, maybe your retrospectives need to be two hours. You spend the second hour really digging into the meat of that. I think you really need to pay attention to what’s working and what’s not working with your teams. Clayton: Maybe change format, like the CNN Crossfire. [laughter] SMART Goals Clayton: SMART goals. Good or bad? Jade: Hate them. [laughter] Jade: It’s not very Crossfire‑ish. Derek: I like the concept of SMART goals. I like setting a tangible action to improve. I like the principle of SMART in that it really allows you to keep things where, “Yes, I can do this,” “Yes, it’s reasonable,” “Yes, it’s timely,” “Yes, it’s actionable,” ‑‑ all of those things. I think some of the problems that come out of that is it’s very hard to do the follow‑up on those, and to build upon them. I think, if you’re doing discipline retrospectives, where you say, “Over a period of time, we’re trying to make this change,” and you’ve got multiple SMART goals, it maybe makes more sense. We’ve done them. It’s difficult to follow through, sometimes, all the way to the end. Then, where it’s really been a problem, I think, is the problem with SMART goals is you don’t do the habit setting. You say, “Oh, we’re going to this for the next iteration.” You do it, it works really great, and then you do it the next iteration. Then, it starts to follow across on the third iteration. Then, it’s gone on the fourth iteration. Then, in six more retrospectives, it comes back as, “Hey, we need to solve this problem,” and everybody goes, “Haven’t we already talked about this?” Jade: The problem I have with it is not the actual SMART goals and the follow‑through, like you’re saying. I agree that those are issues. The problem that I see is, in the context of the retrospective, the way I’ve seen it on our teams, it totally derails the good conversation that we’re having, and changes it into, “Well, how do we come up with another stupid SMART goal that fits this formula?” I think a lot of times, it really detracts from some of the more powerful and more honest conversation that we could be having, and now it’s just about creating this formulaic thing. Derek: Right, but I see the flip side of that is people will talk shit to death and never come up with anything actionable. Jade: I agree. Derek: We can have a really great, deep, meaningful conversation, but that doesn’t do shit for improving oneself. Jade: Maybe it’s like everything else that we’re saying. It’s used appropriately and not abused. Maybe that’s where the secret lies, in moderation. Retrospective Pet Peeves Clayton: For each of you guys, who both run a retrospective, what is your ‑‑ maybe not biggest ‑‑ but what is a retrospective pet peeve that you have that you think, if we did away with not only on our team but on other teams, things would be greatly improved? Speaking On Behalf Of The Anonymous Jade: [laughs] One that jumps to my mind is the biggest thing that irritates me when I’m facilitating is somebody speaking on behalf of the anonymous other people who feel this way, “But not me personally.” That drives me insane. I will usually shut that down and say, “Well, if those people need to say that, they need to speak for themselves,” especially if you are not part of that group. If you’re saying, “Well, I think that such and such people might be feeling this way, because I’ve heard about it, but I don’t feel this way,” you need to stay out of the conversation. Maybe bring that up and challenge the people to speak their mind, but don’t give me this big story about how other people are feeling. Refusal To Express Feelings Derek: I don’t really like that one much either. I really hate when people won’t express their feelings. When I say that is they won’t say what’s on their minds. Before retrospective, all during the week, somebody will really belabor and bitch and moan about something with the team. Then, when it comes to retrospective time, and it’s the wide‑open slate to bring up that issue with the team, the person won’t engage. When somebody else brings up the topic, there is no opinion on it from that person. If you ask them, try to pry it out of them, “It’s, oh no, no big deal.” Immediately after the retrospective, they’re right back to the, “Yeah, we’re never going to get rid of problem X, Y, Z that I’ve been bitching about for the last five days.” I just think we should institute the nut punch rule where anybody that does that, you’re OK to punch them in the nuts. Jade: Some of that is being a good facilitator and watching out for some of those things. It is hard when you do acknowledge that, and they still refuse to initiate the conversation. That’s really challenging, but if you’re just watching body language, and watch for the eye rule and draw attention to that, you can solve some of that. Like you said if they still refuse to talk about it, then definitely nut punch. Inverting The Question Clayton: One technique I was actually reading about in the “Coaching Agile Teams” book that, I thought, was really interesting was as a facilitator phrasing your questions in such a way that you’re not actually asking the person. The example was rather than saying, “Hey Derek.” I know Derek has this problem about somebody, but I don’t think he’s going to talk about it. I could say, “Hey Derek, why do you think some people would feel this way?” Now, he’s not talking about his feelings. I thought that was really interesting. As a Scrum Master listening to this podcast, what is something that I could do at my next retrospective, real quick tip that would make it better than the last one? Derek: I would read at the retrospectives by [inaudible 12:05] … [laughter] Derek: …Diana Larson to start with. Lisa Adkins book “Coaching Agile Teams” has a lot of really good points about dealing with teams and good ways in facilitating. There are a ton of books that we don’t talk about on facilitation and coaching that have nothing to do with Agile that those skills are totally transportable, whether you are doing organizational redevelopment, or doing a respective for a team. Facilitation is facilitation. Coaching is coaching. I would say anything you could do to improve on those. Maybe, you’ve got a cat at home that doesn’t like to use the litter box, practice some of your facilitation techniques on the cat. See if you can get it to start using the litter box on a regular basis. Jade: Take a risk, but that’s the biggest advice I would give. I ran a retrospective, at our last one. I’d been reading “Gamestorming” a lot. I pulled out an experiment, one of their games, and just tried it. I had no idea if it would work, but I thought it might be fun to at least try. We got really excellent results out of it. Derek: The other thing, I would say, is add alcohol to your retrospectives. It does wonders for loosening inhibitions as far as the team saying what’s on their mind, and it’s definitely a little dangerous, too. See you next time.

Jade Meskill: Hello and welcome to another episode of the “Scrumcast.” I’m Jade Meskill. Clayton Lingel‑Zigich: I’m Clayton Lingel‑Zigich. Alan Dayley: I’m Alan Dayley. Mike Vizdos: And, I’m Mike Vizdos. Agile Certification Jade: All right. We got a couple guests with us today and we are going to talk about the exciting topic of certification. Hold your breath. Let’s start out with a softball. Should we be certifying people? Go. Alan: A softball? [laughter] Jade: It’s fast pitch softball. [laughter] Human Resources Usage Alan: I debate this in my own mind. Certification is valuable, evidently, to HR people. Therefore, perhaps, valuable to people who hold the certification. Where it’s not valuable is when the certification doesn’t have meat to it or it’s too easy to get. And so that’s where it gets called into question. So, personally, I wish the whole world didn’t need certification. That somehow there was a way that you could demonstrate capability without a piece of paper or someone else signing a piece of paper. But maybe that’s too hard to do in the business world. I don’t know. Jade: Right. When you’re screening thousands of candidates, how do you deal with that? Clayton: I think we should certify people if the certification…When you say, “I am ‘X‑Y‑Z’ certified”, and people say, “Wow. Really?”, and you say, “Yep!”, and they think that’s really cool. I think that’s when we should be certifying people but when it gets beyond that, I start to call into question if it’s worthwhile. Alan: So if I say, “I’m a certified scrum master”, and somebody says, “Wow, that’s really cool” then that’s good? Certification Prestige Clayton: I think that…Well, that depends on who’s saying that. I think that if you can…If the certification elicits that kind of response from the, maybe you could say top of the industry or people that may be important…not like total newbies. Then I think maybe that would be…maybe there’s some value in having the certification when it’s hard to obtain and it’s awe‑inspiring. But when it’s something that is very easy to get or, kinda like you were saying, just a matter of someone signing a piece of paper Jade: So if I come in telling you I got my A+ Certification, you’re not going to be impressed? Clayton: CompUSA is out of business, I’m sorry. [laughter} Clayton: Where are you going to find a job? Jade: But was that valuable at some point in time to somebody? Clayton: Yeah Jade: So how do you know when you’ve crossed the threshold of it’s no longer awe inspiring and cool? Alan: I don’t know how to cross…well, it takes a little bit of research, I would hope. In other words, you hope that managers, HR’s, hiring people that look at a resume and say, “Oh, look. There’s a certification here.” That somehow, they would either know or research a little bit what that certification actually means. Jade: Do you think that really happens, though? Alan: No. Jade: They’re told to look for keywords. Alan: In general, it doesn’t happen. I don’t know. Certifications Frowned Upon By Agile Community Clayton: I think certifications will probably always be valuable in the HR community. I think where they start getting frowned upon in the actual community of the people that are using them are when people start thinking that it’s less about learning something and showing that you’re qualified in some certain skill and more about money making or prestige. Or just something that is not directly related to how much you know about a certain topic or how qualified you are in that certain area. Alan: There needs to be, perhaps, a meta something. I don’t know what it is. Some of the higher certifications, most of my experiences with the Scrum Alliance and their further certifications beyond ScrumMaster tend to have a little bit of meat behind them. They have some peer review and things like that. Somehow, if you could do that more, then it has more meaning. Jade: So what do you think, Mike? You’ve been awfully quiet so far. Mike: I’m a good listener. It really does depend, I think, on who is doing the certification. The actual certification. I do think people have to do a lot of research before they jump in and take a class to do whatever. If anybody’s really in the market to just “take a class to take a class” to be able to get certified, does that really mean anything? Bad Apples Can Still Make It Through Alan: Yeah. It’s a tough conundrum, because I’ve met bad doctors in my life. Medical doctors. They’ve been certified many, many times in different ways, and yet I find them unacceptable. You can have all kinds of structure around a certification and still have bad people, as it were, get through. It’s a hard problem. Mike: There is a demand for it, still. Jade: Yep. Do you think that will always be the case? Mike: There will be a demand, yes. Clayton: Do you think that demand is driven from the more, like what Alan mentioned, the HR side, where people are saying, “We just need people that have this buzzword,” or is it driven by people saying, “There’s a lot of value in this for what I’m doing, so I want to go seek out that certification”? Mike: I see a percentage of both of those types. Pros & Cons of Agile Certification Jade: My personal fear is, with certifications like the Certified Scrum Developer, we were just talking about people who are going and taking those certification classes that aren’t actually programmers. Are they going to look better on paper than someone like myself who doesn’t have that certification but has been doing this professionally for 12 years? What are the pros and cons of that type of a world? Clayton: There’s always something to be said for, if you’re a company and you’re hiring people just because of their certifications, then, obviously, there’s going to be some downsides to that. As much as I think some people would want to say, “We can’t certify,” and, “Certifications are meaningless,” and all that stuff, at the same time, if they really want to go down that road, they know that the stuff that really is important ‑‑ if they think that that stuff is really important, then they’ll maximize that. I think they’ll stand out even if they’re not certified. I think people usually just like to complain about a certification. They want to say it’s totally not important, but they love to talk about it. If it’s not important, then you’re fine. Alan: Your question and your statement segues into the content. If I’m not a programmer and I take the Certified Scrum Developer class, is there a way to bridge concepts like pair programming and continuous integration or other such practices that are part of that course? Can they be bridged into other fields? Can I do pair programming on marketing design? Can I do continuous integration on whatever job I do? Can I come up with a way to do that sort of concept in my field? Jade: I think that’s a really hard analog, especially compared to the Certified ScrumMaster training, where it is fairly generic and is a framework that can be applied to everything else. Once you start getting into engineering practices, I think that becomes a lot harder to translate or make generic. Alan: I agree. How Will Agile Certification Scale Jade: This leads to the question of, how do we scale this? If Scrum’s the new hotness for certification, what happens when we need to certify 10 million developers? What does that world look like if…? A hundred trainers can’t do that. Or we’re going to do Scrum in India or China, and there’s millions of developers ready and eager to embrace these certifications. How do we do that? How do we scale it up? Alan: I don’t have a full answer for that. Obviously, I’m not trying to solve that problem in my own life or in my world. The danger, of course, is, it becomes some kind of mill, a certification mill, if you want to really pump the numbers through. I’ve always been curious about the academic side of things. In other words, why aren’t there Scrum classes at universities? Why aren’t there Scrum classes more often in engineering schools, or other types of Agile certifications or classes? That has always perplexed me. I haven’t understood why they don’t pick that up. Then, it could even, perhaps, turn into a college degree or part of your degree. Since you already have millions of people going to schools, there would be a place and a venue to scale it, but I don’t know how that would work. Unvirsities Are Lagging Behind Jade: Isn’t that a function of, it’s not being demanded of them by employers, by people who are working with these universities? If they’re not saying that, “We need Scrum‑certified people coming out of this university,” why would they go teach that class? That’s what drove a lot of Java‑ and .NET‑type classes into the university system, was the demand from employers to have those type of skills. Alan: Go ahead if you want to say something. I think there’s a disconnect that I don’t understand. Maybe you do, Mike. Mike: And, actually, I’ve seen a lot. I speak a lot at universities around the world and one of the strange things about academia is they’re almost a generation behind. They’re still being taught stuff that was taught 20 years ago. And they’re coming out of university today thinking that they don’t have to work as team members. They don’t have the skills to be able to communicate effectively and they think that they can go and get a job and just do one thing for the rest of their life. And they’re actually being told that communicating with a customer is a bad thing. [scoffs] This is the stuff that I hear as I go around the world taking to universities. What Would Meaningful Certification Look Like Jade: Great. So, you know that, but that leads back into my question of if we want to build a good workforce for the future and these are valuable skills that we’re training people in these certification classes, how do we get them involved? How do we get them into the system while keeping it meaningful, relevant and worthwhile? Alan: There has to be the right person, the right bridge. In the Scrum email list and so on, there’s a few people that work at different universities or work with universities who have successfully integrated some of these types of topics into the universities that they work with. But these are individual efforts in single engineering schools or programming schools and I haven’t seen it spread at all. I suspect there’s going to be somebody somewhere that’s going to write the right Ph.D thesis or be a teacher of Ph.Ds who will suddenly launch on this and become a focal of it and maybe create it and get it in. Maybe the way Java and .net did, I don’t know. Academia is not my world, so, it puzzles me. Mike: And with the whole scalability thing, somebody will eventually jump on it and drive down the cost and the value of any kind of certification. Jade: So, then what happens at that point? Does a new breed of certifications come out on top of that and rise to the top? Certification Just Marketing Mike: Absolutely. Absolutely. But if you look at something like Scrum, it was purely a marketing ploy, at the beginning, to get HR dollars, to spend money. And it did help create an entire new industry and bring Agile into the forefront, like it or not. Clayton: I think that’s an interesting thing to keep in mind that maybe you’re upset with the fact or maybe you have the world view that certification is a money maker and that’s all that it is. But there is something to be said for the fact that a lot of that maybe did help bring it to the forefront. The fact that you can use it in your company today is you benefited from that, too, one way or the other. Mike: And nobody is forcing anybody to do any of these type of classes. But if you’re anti‑certification, continue doing what you’re doing and do some research on whatever class. If you’re interested in getting certified, do some research into who you’re going to get taught or facilitated with. Jade: Yeah, and that world’s always existed, right? There’s always been companies who preferred to have, let’s say, an MCSE, right? Mike: Mm‑hmm. Jade: But if you could prove that you’ve had the experience, you didn’t necessarily have to have that particular certification, but it makes it harder to get your foot in the door with certain organizations. And I think that we just have to accept that as a reality, right? If you choose to not participate in the certification world, great. That doesn’t mean you’re not worthwhile, but expect to have a little bit harder time dealing with, especially larger organizations who are filtering that way. Mike: And I can see, really, the validation of the whole certified Scrum Master kind of path with the PMI jumping on the board now and rolling out Agile certification. So, it’s going to be, it is mainstream. Like it or not, it is. And something will come next. Jade: I look forward to seeing what the new hotness will be. Alright, we are out of time. [background music] Thank you everybody for your opinions and we will catch you next time on another Agile’s Scrum Cast. Clayton: Thank you. Mike: Thanks. Alan: Thanks.

Derek Neighbors: Welcome to another episode of “The ScrumCast.” I’m Derek Neighbors. Jade Meskill: I’m Jade Meskill. Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich. Step Away From The Tools Derek: Clayton, earlier this week you had posted on a blog post, about “Step Away From The Tools.” We gonna started a couple of discussions and came find around here. Maybe it’ll give us a little bit of background, the post, the reason why you post it and can’t find…some of the discussion around that. Clayton: Yes, the headline was grabbing, kind of inner results to separate from the tools linking, frustrating this industry. It’s so cut‑up and their tools, stupid little things. That was just interesting…I clicked on it. It was interesting to me because, I’ve been lot of thinking lately about the way they we did Behavior Driven Development (BDD). What is the meaning of BDD and all those things. I think for a long time Cucumber came along and the rails community and it was, “You can do BDD if you use Cucumber” and “OK that’s great.” Then things like Webrat and Capybara came out and it was like, “Look at our cool web steps where you can fill out this form.” In her post she makes reference to a post by Dan North about understanding the domain language and how it’s pretty easy to write, you could write a test that seems like you’re doing BDD but you’re really not and it should be at a higher level and substance, just been interesting me lately. That’s why it stuck and there had been a few people on the team I’ve been talking about that whole concept with. That would be fun to share with everyone. Too Focused On Tools Derek: Yeah, I thought it was interesting because one of the things that I picked up from Liz (Keogh) last time she was out here that I really liked was that Agile is the hope killer and hope is what basically prevents projects from shipping on time. I think that sometimes when we get too focused on tools, the problem that tools are like hope. If I only use this Cucumber thing or I only do BDD using these tools then I’m just going to develop better software. The hope is that as long as you’re writing scenarios that you’re writing good software. I definitely agree that Dan’s focused discovery or deliberate discovery is…most of software development is about having conversations about what software to actually develop. As developers we like to dive right into the meat and say, “Let me code. Get out of my way and let me code. Just tell me enough information to let me start writing the first line of code and get out of the way and let me do it.” In reality that’s where all the problems start coming in, whereas we do some of that discovery of “Oh, you mean there’s just other role that doesn’t have access to this and this and this is how it works?” When we find those things out four weeks into after a feature’s been flipped and then we have to basically un‑plumb everything and add something new, this is where defects get out of control and we just get this kind of crazy, spaghetti mess by not really listening. I think that that’s definitely… Clayton: That’s where the resentment starts to build up, too. “Well, don’t you know how much time I put into this thing? Making this awesome ivory tower?” Derek: “Why didn’t you tell me?” Clayton: Yeah. Yeah. Conversations Help Us Discover Things Derek: “How come you never told me that there was this user?” The takeaway there from the post for me was that conversations help us discover things. I think that too often we really want to write code more than we want to have conversations. BDD really, to me, isn’t about testing, it’s about having conversations. User stories aren’t about requirements gathering, they’re about creating opportunities to have future conversations. For me, what the title of that post really started to spark was, what are some other examples of places where we’re too focused on tools and not focused enough on the reason why the tools exist in the first place? Code Coverage Tools Clayton: Code coverage is another good place to go from there. A lot of times, teams that do get a lot of benefit out of BDD start to get obsessed with “Well, how much of my code is covered?” and what does that really mean? It’s really easy to lose sight of that. Is 100 percent coverage attainable? Is that even the right thing to be doing? We get so caught up on trying to get these numbers in place, the same with…losing my words here…like complexity analysis… Cyclomatic Testing Tools Jade: Oh, like flog and flay, or whatever… [crosstalk] Clayton: Yeah. Cyclomatic checks, things like that. What do those numbers really mean to you? What are they trying to tell you? How do they further the conversation instead of become this place where we get all obsessed about the statistics of it? Jade: Yeah. It goes back to when you have something like that ‑‑ like a flog or a flayer, some score, some number, or something ‑‑ it just makes it easy to throw that other stuff by the wayside. It’s like, “I don’t have time to have that conversation. I’m trying to get my code coverage up.” It’s just like this thing and everyone can drive towards that, and then you get to a certain point and people are kind of standing around like, “Hmm, wait a second. Are we doing something wrong here?” There’s a cycle for every different kind of team. Maybe it’s every six months or every three months, or whatever. People realize, “OK, these tools, they sounded really cool three months ago, but I don’t know. What are we really getting out of them?” I think everyone has some 20/20 hindsight every now and again. Process Tools Derek: Yeah. One other item for me is tools around process. I don’t know want to name names, because I’m not trying to sway one product versus other. I think most digital tools to deal with a Scrum process, track user stories, points, velocity, and backlog management, a number of those things. What I see a lot of teams do is they get so obsessed on the tool that they do one of two things: they either want to use a tool because they want to lose accountability. If you put everything on index cards, and you create some, I want to say, “ritual” around it, but there’s some visibility, and there’s some tactile kind of writing and some wiring of the brain happening, a lot of people back off of that and say, “I really don’t like cards,” either, or, “It hurts my hand too much to write them all out,” or, “That takes too much wall space,” or, “They’re just going to be recycled, and you’re killing trees,” whatever. But I usually see the teams that start to do that, they really focused on trying to either shirk accountability, like, “Don’t treat me like a kindergartener and make me write on a stupid index card with a giant sharpie and put it on the wall for everybody to see. I’m not in kindergarten anymore.” Or they like tools so that they can legalize behaviors. They can start to say, “Oh, you’re trained in this,” and they want to steer the conversation onto the fact of your average velocity over the last 39 sprints has been X and get legalistic about that, opposed to saying, “What’s the root cause of that?” or, “How can we improve to deal with that?” It’s more of the, “Let me see what you’re doing, and let me compare myself to what my team is doing to your team.” What are some of you guys’ thoughts about using digital tools and process? Jade: I was actually thinking about this the other day. I’ve had the same kind of experience, where I was trying to have something out with someone, and they were complaining about, “Oh well, we’re just wasting these cards, just wasting time, because this is really simple stuff, blah, blah, blah.” For whatever reason I never really went down the path of, “This is a waste of time.” I just took it as, “This is a reasonable idea, whatever. Just go with it.” I was thinking about the digital tools that exist now, could you still do this process 50 years ago? 100 years ago? If you’re just doing cards, writing things down, and having conversations, go back to ancient Egypt. You could still do the same thing. But, if your process is dependent on, “Well, in order to be successful or have some measure of this or that, then we need to have these digital tools that require us to keep track of this, do these calculations.” It just seems that there’s so much overhead, but, again, if you go back how we started this, if you go back to the idea of, “Well, let’s just have this tool, and, if something is going wrong, look at the tool,” I think people will get too far into that, and they forget that there really can just be really simple stuff. You could just be having conversations and writing something down on paper. It sounds so simple, but what else do you need? Clayton: I don’t want to manage a Scrum team in ancient Egypt. [laughter] Derek: I don’t know. The pyramids were a pretty successful project, if you ask me. Jade: Yeah. You could whip them, too. [laughter and crosstalk] Clayton: That’s true. Jade: …with a Scrum whip. [laughter] When The Tool Is The Limiter Derek: For me, the determining point was when I heard somebody say, “Well, we couldn’t do that, because our tool doesn’t do that.” I don’t remember what it was. It was like, “Oh well, mark that as zero,” or, “Change to a Fibonacci sequence,” or, “Put your estimates in ideal hours,” or something, and the response from the person was, “Well, but our tool doesn’t support that.” Jade: That’s why I love digital tools because it gives me something to blame other than myself. [laughter] Tools Are a Distraction Derek: To me, our tools are just a distraction, for the most part. I think back to what you’re trying to get to Clayton, is, when we really get to the roots of what we do, how we do it, and why we do it, I think anytime the tools become a significant part of the conversation, I have to question, are we using them as a scapegoat of some kind, either blaming them for something, or “Look! A pony”! If we should use vim instead of Emacs. Let’s stop talking about what’s really important and start talking about something that’s… Jade: I came across a blog post this morning that was like, “We’re this successful web shop,” or whatever. It was a blog post on how you get set up with Z shell, rvim, blah, blah, blah. All these other tools. I’m picturing someone going to that site and being like, “Whoa, this is totally awesome!” Then they’re going to spend five hours getting all that shit set up, and then they’re going to go back to work and be like, “Hmm, OK. What was I supposed to do today?” Clayton: And, “I don’t know how to use any these tools at all.” Jade: Right. Clayton: Now I’m going to spend the next month figuring out how to become an expert at these tools, and then maybe I’ll get some work done. Good Tools Are Important Derek: I’ve definitely gone through that cycle in my career. I definitely think that good tools are important and understanding your tools is important, but this is one of the things, for me, on the craftsmanship side that I get a little worried about. A lot of people, when I look at the (software) craftsmanship movement, they really start to say, “Well, in order to be a good gardener, I’ve got to have the perfect shovel. In reality, I think, to be a good gardener, a really good shovel helps, but I think you can be a really damn good gardener just using your hands. Clayton: That’s like you need an expensive guitar to be an awesome guitar player. That’s not necessary. Competing Tools Make Noise, Find Moderation Derek: Right. To me, how I interpret craftsmanship is being able to tell the difference and the caliber of the guitar is important, but being able to say, “Well, I can’t do good work because I don’t have a good guitar,” to me, it starts to sound like a cop‑out. It starts to sound like an excuse. We’ve come to this place now that we’ve got so many different competing processes, frameworks, and movements at foot that I think, right now, sometimes it’s hard to be a good software developer, because there’s so much noise that it’s hard to get distracted. You’re either paying too much attention to the process or you’re paying too much attention to the tools. What we’ve forgotten is that there’s a customer and there’s a value that we’re trying to deliver. I think that, to me, how do we get back to the roots of saying, “That’s what it’s really about. It’s about the people, the conversation, and providing value.” Clayton: It’s about moderation. It’s about finding those points where, “Yes, this is helping us solve a problem.” Maybe some of our team is on site, so having some sort of digital tool in place is required, because that helps facilitate communication better to our distributed team. That is a perfect reality in these days, and it would be a good reason to go down that road. But it’s about finding that balance of, “Well, let’s not try to run the entire business and the entire process through this digital tool. Let’s use it to communicate the things that are hard to communicate at a distance, and everything else, let’s make sure that we keep those things, because that’s the most effective way.” When managing the tool takes more time than getting the work done, that’s where you have a serious problem that you’ve got to deal with. Jade: Yeah. If you imagine a Venn diagram where one circle is introverts and the other circle is “I wrote my own something”… [laughter] Jade: …they’re basically on top of each other. Clayton: I want to see that. Taking The Easy Path Jade: Yeah. To be fair, a lot of software developers, when they hear about, “Here’s this new process,” and the process is difficult, because it requires things that I’m not good at or things that make me uncomfortable, the way I can make it easy is if I make a tool that bypasses those difficult things and, “Now I’m doing kanban, and I don’t have to talk to anybody,” or whatever. People go towards that route because that’s how they make the process easy, even though that’s not actually going to make the process easy. Clayton: Right. That’s how they deflect. Jade: Sure. Yeah. Assume You Got It Wrong Derek: The last thing Kennelly just posted that really was interesting to me was, “Assume you got it wrong.” I think that that’s a good life principle if you always operate. It’s, “I’m the stupidest guy or gal in the room, and I’m probably doing this wrong.” To me, it sums up the whole “Inspect and Adapt.” If I’m constantly thinking, “I’m doing this wrong,” I have to constantly be asking myself, “OK, what am I doing wrong?” What are some of you guys’ parting thoughts here? Jade: I’ve had countless number of times where I have been at the end of a planning meeting, and I thought, “Well, I totally understand what they’re saying.” Then I repeat something back, and it’s like, “That is totally wrong,” and I’m like, “OK.” [laughter] Jade: It’s just going over things, and that kind of mentality, even when you think you really got it right, just using different language too, I think, a lot of times, you think you got something right because you’re thinking about it in a certain way using certain words. Then, if you say it back, ask a question, or phrase it differently, then there’s some new little thing that comes out, but I think that’s just great advice in general but also for any actual process. Clayton: Yeah, I agree. Just repeating things back and explaining them in your own terms, the way you understood it is one of the best ways to gain that clarity from all aspects of this process. Interpersonal communication on your team, to dealing with the product owner, all that stuff, it really is all about that communication and finding effective ways to communicate. [music] Derek: Until next time, we’ll see you. Jade: Thanks. Clayton: Thanks.