Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Product Owner Availability Clayton: We’ve got a few topics today. The first one we start out with is Product Owner Availability on a Scrum team. If I’m a product owner, how available should I be to the team? Should I be sitting there, waiting for them to ask me something? Roy: In my perfect world, yeah. You’ll be sitting with the rest of the team, not necessarily waiting to be asked something but you’re available if something is needing to be asked. In the mean time, there’re some of the other things that you can do, like backlog grooming and communication with stakeholders, that type of thing. Clayton: You’re saying actually be available…if the team needs something from me, I should be available almost immediate? Roy: I don’t know about should. If I was a team member, that’s what I would want. I don’t know if that’s realistic to set an expectation like that. I don’t know if I can say, “You need to be available within two minutes of me having a question”. That might be a bit excessive. Derek: I would say as close to immediate as possible, is desired. What is doable is an entirely different story, probably for every team, every organization. Roy: Every product owner. Derek: Every product owner. Part of availability is…we were talking about Jim McCarthy before we came in here, and the Core Protocols. One of them is presence. Physical presence of a product owner is key to availability because its not just about being able to ask questions, but there’s also a fear of how do we talk about product. There’re so many times as a developer where you’re working on something, and you’re really talking not about code, but you’re talking about experience or you’re talking about a functionality or interpretation of conditions of satisfaction or acceptance criteria, whatever you want to call them. Where if there is that kind of physical proximity or presence, it allows for a product owner to say, “Hey, that doesn’t really matter, don’t bother arguing about it. Just go ahead and implement it.” Or, it allows them to basically jump into the conversation almost immediately. One of the things that developers tend to do is not talk the product because they think they’re not allowed. When we come from this world of requirements, once a product owner tells us A or B, like we are incompetent if we have to go back for clarification. I think that availability to clarify is monumentally important. Product Owner Dysfunctions Clayton: What are some maybe dysfunctions? A lot of product owners probably are not that dedicated to the team and they probably spend a lot of time in meetings or on the phone or doing whatever. What are some problems you might encounter if you don’t have that presence of the product owner? Roy: What I usually see is it really screws up the planning meeting for multiple different reasons. The first being, is that because the product owner wasn’t available throughout the week, I’ve seen a lot of teams wait until the planning meeting to get acceptance. Clayton: Is that like wait until the retrospective to talk about things? Roy: Right, because it’s the last minute that you could technically get acceptance before the next thing. Obviously, you should be doing it as soon as you finish feature, like as close to that as possible. I’ve seen a lot of teams wait until they are in planning. The other thing that happens during planning is because the team is so fearful of needing to ask the product owner questions throughout the week and knowing that the product owner is going to be available, they’re going to want to like squeeze the product owner dry during the planning session which makes it really arduous. They try to think of everything that could possibly go wrong ever because when it does happen, if it does happen, they might not have that product owner there to ask. Derek: I definitely think that you get a sense of people get fearful when they’re making commitments, if they don’t think they have all the information, if they think they’re only getting one chance to get the information. If you have a lot of uncertainty in product ownership during a sprint, teams tend to be more fearful to actually committing to work. Where I think if you’ve got the higher certainty, teams tend to be a little more willing to commit to things knowing that they’re not going to be blocked by something out of their control, in essence. INVEST Stories Clayton: We have been talking about product ownership. Kind of related to that are stories. I was asking Derek today about that the new moniker for “INVEST” about stories. The V in there is for value. We talked a lot about delivering value to the customer. What do you guys think about stories that might deliver value in the future but if it were shipped tomorrow no one would use it. No one would get any value out of it. Is that even worth doing? Even if it’s maybe a building block to something? Roy: That sounds dangerous. Usually, when I hear of somebody think of a story as a building block, they’re slicing the cake the wrong way. You know what I mean? That would be my primary concern. If it’s not really adding value to the user now, then why are we building it now? Derek: For me, I hate this whole value discussion more than anything in so many ways, because nobody can really define value. I’ve gotten into Twitter arguments over this that made me want to pound my face into the concrete. For me the question becomes like, “What are the goals?” What are you trying to do with this product? Are you trying to make money with the product? Are you trying to influence people with the product? Are you trying to get more users with the product? Are you trying to not lose users with the product? What is it you’re trying to do? For me, where’s the data that backs up that this particular story helps you get closer to that goal? If it’s a building block, “Hey, we need to do this so that we can do that,” I’m OK with that. I get worried if it’s a technical building block like, “Hey, we need this technical building block in order to do this.” If it’s not really a technical building block but rather, “Hey, we need to implement this so that we can track this or so that we can add this additional feature, and that’s what we really want, and we believe that’s what we get there,” I’m OK with some of that. To me, most product owners can’t tell you shit. “We’re just doing this because it feels good or because the users are screaming about it or because it’s what we pulled out of our rear end before we came into this planning meeting,” which is probably not delivering value. If people came in and said, “We’re doing this because we’re losing users, and we really need this functionality in order to keep those users,” or “Hey, we’re trying to get into this new market or this new piece, and we need to add this functionality to compete with so and so, so we don’t lose market share of that,” then we’re having a different discussion. I’d say if product owners aren’t talking in that kind of language, they’re probably not doing due diligence around value delivery. Throwing Away The Backlog Clayton: Do you think there’s some amount of…maybe fear is not the right word, but if you got a bunch of stuff in your backlog, and maybe you’re not thinking on those terms about that way of thinking about value. If you were to actually do that, it might mean that you would have to throw away almost everything. You might have to get rid of a lot of stuff, which is scary. Is it better to keep prodding along and hopefully you can find a few things here and there that actually do deliver value, and then it’s OK that you did some stuff that maybe wasn’t so important? Roy: So you’re getting value out of having a large backlog? That’s what it sounds like to me. Clayton: It lets you fly under the radar to someplace… [crosstalk] Roy: Right, because you can say, “Hey, we need to extend the budget for this team because look how much work is left.” What Is Product Afraid Of Derek: Some of it is, a lot of teams or a lot of product owners get fearful of “if the backlog’s not really big, then the product’s not important.” There is something to say that there is value in being biased towards action. Sometimes maybe if you don’t know what’s valuable, not doing anything could be detrimental in the sense that you’re not moving forward at all. However, if you’re moving forward and saying, “Hey! Action, we’re delivering stories,” you fall in the potential of iterating to nowhere where the product is just spinning its wheels. It’s very similar to developers in the sense of, developers really get nervous about measurements. If you talk about velocity or estimating or anything, most developers freak out on that and want nothing to do with it because they think it’s going to be used against them or that they might be seen as failures. You name it. Product owners are the same way. If you start to say, “Hey, this feature should drive revenue by X,” and it doesn’t. “I was wrong. I failed.” Or, “Hey, this is going to land us a new customer,” and it doesn’t. “Shit! I failed.” There’s that same mental block of, “I don’t want to do the research and make predictions about what functionality is going to do for this product because what happens if I’m wrong?” Roy: Regarding the idea of having that big backlog just to keep the big backlog around, there can also be a difference between having a cluttered backlog and a large backlog because what I’ve seen is… and what you described, keeping a bunch of random stories thrown in there that may or may not actually add value. Derek: That would be moved to the bottom every week. Roy: Right, exactly. You can still have a large backlog and still say, “We have a year’s worth of work or whatever in the backlog,” but have really large epics. Let’s say you want to build out a whole new component. Instead of breaking that down early, don’t waste your time on that, just say, “We’re going to have this gigantic new component at some point or deliver that giant piece of value.” If you get to it and it becomes a priority, then you start to break it down as it gets closer and closer to when you actually work on it. That allows you to keep a really clean backlog because most of your really far out stuff are abstract ideas that haven’t been worked out. Break Things Down The Further Away They Are Clayton: If we agreed that things that are further out time‑wise are maybe not worth spending a lot of time breaking down, world changes kind of thing, do you think that the frequency of your delivery or your deployment makes a big difference? If I only deploy once every four months, does it even make sense for me to worry about defining things that I want to do in 9 months or 12 months because I’m only really ever going to deploy four times a year? Maybe… Derek: I could see that. Clayton: Does that make a difference at all? Roy: There are companies that do budgeting on an annual basis. You might need it for that, to be able to justify your budget for an entire year’s worth of work. I could see a product owner needing to do that. Its Not About The Release Its About The Release Plan Derek: For me, it’s probably less about when you release and more about what are release plans. There are a lot of people that do release plans, but don’t really release. When you start to do more continuous delivery, it starts to make your release plan, a hell of a lot more real. You are actually owning what you’re releasing because you’re releasing consistently. Where when you release infrequently or you deploy infrequently, you can constantly move your release date around. You can start to say, “Oh, it was supposed to be six weeks, but now, it’s going to be 8 weeks or it’s going to be 10 weeks or it’s going to be 12.” You can keep moving that stick and have that perpetual, “Let’s just add more shit into the product before the next release.” Where if you have that continuous deployment happening, you don’t get the ability to say, “Let’s keep dicking around with our release date. It’s going to our customers at the end of the week, at the end of the…,” whatever… [crosstalk] Roy: With or without this feature. Derek: No matter what. Continuous Integration vs Deployment Clayton: You mentioned continuous delivery or deployment, there was a good infographic that was going on that simplified those two terms. I believe that continuous delivery was, everything’s automated from my checking the code, and the tests run on the CI server and maybe it gets deployed to some staging place and acceptance tests run. The action of actually deploying that to the customer is a manual step. Whereas, continuous delivery was more of… Roy: Continuous deployment. Clayton: …the whole thing was all automated. Sorry, deployment, yeah. Derek: Integration versus deployment, right? Clayton: The idea, and you had mentioned maybe Twitter and Facebook have a model that’s like this, where I make some code changes and it goes out. It doesn’t necessarily go out to facebook.com, but maybe, it goes out to some subset of the server so that some part of the user base might get that, and that kind of thing. Roy: Roll that out to everybody outside, and know that it is completely automated. Clayton: No, I would guess most people, especially if you consider yourself an enterprise kind of company, the idea of pricing commit and your search control and having that go out.. Roy: So any developer could commit a code directly to our users? Clayton: Yeah, and the idea that everything is green, we ship, is probably pretty scary. Do you think a lot of people could gain from having a system like that? Roy: Man, talking about having to own your work. Talk about pride in the work. Clayton: That’s true. No More Feature Freeze Roy: I mean, seriously. One of the early stories that had came from Twitter and had impressed me is they had gone online live with Oprah. Biz, or one of them, was on…maybe with Ev was on Oprah and they were doing deploys during the airing of that show. That would be normally completely crazy if I’m some big company, if I’m Ford or something, and we have this big Super Bowl ad running, I probably am going to tell everybody, “No deployments for the next two weeks because we have to deal with all this traffic where…” Clayton: Feature freeze. Roy: With a company, like Twitter, the problem is they had to. They didn’t have a choice. Their system was growing so dynamically that adding an extra million users during an Oprah show had a real effect to the performance of their system to where, “OK, yeah, we could wait until the west coast showing views,” and then, start screwing around with things. But then, the experience is crappy for everybody. Or “We could go in and see this performance bottleneck that we see right this minute, make the change, deploy it to a small subset of users, make sure that nothing is coming back failing. Then, let it propagate into the entire base.” Which is a worse move? Looking bad performance‑wise or trying to fix those on the fly and then, if something goes wrong, having to recover. Part of it is when you got to continuous deployment, you are a whole lot less afraid of doing those things because you do it all the time. If you’re deploying every commit, your process is probably pretty damn solid if something goes wrong, being able to roll back. If you only release once a year, your process is probably so crappy, that if something goes wrong, it is like… Clayton: A week‑long thing. Roy: …catastrophe for months to clean it up. That plays a lot into it as well. Continuous Integration As The Buiding Block Clayton: One of the things I really like about continuous integration is the idea of having the code, basically, be able to compile and run all the tests. All the benefit you get from that is so far beyond the fact that you have a good CI server, but all the work that goes into making that actually happen, I think the same thing is true for continuous deployment. Although, at a much larger scale. If you only deliver once a year, it’s OK if everyone spends two weeks doing a bunch of manual stuff because it doesn’t seem that painful. If you’re doing it every two weeks or something, that subsequently going to get automated real quick and you’re going to fix a whole bunch of stuff. Especially, the roll back stuff, the fear just goes out the window at that point. Roy: If you’re doing continuous deployment where it’s going out as a constant stream, then it becomes even more so. Then, if you check‑in some bad code that breaks a build and I need my feature to go live now, we need to have that conversation now because it needs to be out by the end of the day, so none of that stuff gets postponed. Clayton: Probably, the chances of people breaking the build as casually as they would, otherwise, is probably much lower. I think that wraps it up. We’re at our 15 minutes here. Thanks you guys. Derek: Thanks. Roy: Bye‑bye.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich… Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy vandeWater. Sprint Zero Clayton: We’ve got a backlog of items today that we wanted to talk about. The first one is Sprint Zero. Derek: Sprint zero. Clayton: Derek, tell us your thoughts on Sprint Zero. Derek: One of our regular contributors to Agile weekly, Brainslink, had posted something about Sprint Zero and the value of Sprint Zero. That those in scrum or in Agile tend to devalue Scrum Zero. In an enterprise environment, it is really necessary oftentimes to have a Sprint Zero. Roy: Cowards, stop having enterprise environments. [laughs] No Architecture Is Irresponsible Derek: [laughter] My general response back was pretty similar to cowards and stop having enterprise environments. Which was that I think his argument and the article tended to go around, it is irresponsible to have no architecture, to have no kind of plan going in. Clayton: Right. Derek: What happens is if you just hit the ground running Sprint One and do the quickest thing to get working come sprint four, five, six, something down the road, you realize that you’ve made this really horrible choice because you didn’t really think out the bigger picture and how it interfaces with other things. You end up having to undo a bunch of work and so it actually causes more problems then if you just violated these Scrum principles and did a Scrum zero. My response back was I think that the danger in that is that it gives us false sense of security and that if we only spent an additional sprint before we did work to plan it then we won’t have any problems and everything’s going to be right. What I tend to find is when I’ve seen sprint zeros that all of the same problems happen in four or six weeks in, all of the decisions you made you… Clayton: That’s true. Derek: You found better decisions for them and you want to undo things so why bother with the first sprint zero to begin with. Roy: I think that the thing that unifies them that the thing you find out in week four that causes you to regret the decisions you’ve made in week one are things you don’t know in week one. Derek: Correct. Roy: If you spend a week in week zero trying to set stuff up, you still don’t know what’s in week four no matter how much time you spend on sprint zero. If you have five sprint zeros you are still not going to discover what’s in sprint four until sprint four. Clayton: There’s a concept in the book “Guided Object‑Oriented Software by Tests” that talks about having a walking skeleton which is kind of the idea of build something that you can deploy that actual exists. You can press deploy and it goes to production and it works. So, would you recommend that if a team wanted to avoid a sprint zero and they actually wanted to deliver a value in the first sprint, would it be OK if they started with maybe bigger sprint than ‑ ‑ maybe they thought they would do two week sprints, but if we look at the work to get this whole entire thing working it has to be three weeks. How should they handle that? Roy: It shouldn’t take you that long to deliver that sense of value. [crosstalk] Clayton: Say it does. Say it does. Not Being Able To Start Is Real Issue Roy: No, that’s bullshit. No, that’s your root problem. Assuming that you have one leg, how are you going to run this one meter sprint? I think that is the bigger issue at hand, is that I think when you believe that you couldn’t put a bare skeleton out in under ‑ ‑ and so, it brings links, kind of, comment his thing was, I would never advocate a thirty day sprint zero, but I think a week or two sprint zero makes sense. I think what they’re saying is, well we need this time to do this research. I don’t think they’re talking skeleton. I think they’re talking to do the research to even do the work. I would argue that if you can’t do a skeleton within a sprint, a two week sprint, you have something wrong with your tool set, or your skill set, that probably needs adjusting much more than a Sprint Zero is ever going to fix you. Derek: It’s going to hurt you in every single sprint. Not just the first sprint. Roy: That is correct. Performance Testing Is A Waste Of Time Clayton: Alright, so we gotta move on. The next topic that I want to talk about, is performance testing. I think you should also call this a waste of time, because pretty much everyone seems to waste time when they do this. Have you guys ever seen anyone do performance testing where it has been valuable? Derek: Yes and no. I’ve never seen anybody do performance testing beforehand be valuable. Meaning, usually when people do performance testing they don’t do it on their real environment. So, you know, all of these little things that are really the performance bottlenecks are never seen. It’s, you know, “We are worried about data reading rights so we are going to test the crap out of that.” But its late in the latency that really kicks their ass and so know that because their local network has no latency, but when they put it up in the cloud, the cloud has latency, or vice versa. You know, things like that. I think the Lean Startup methodology has really started to push towards ‑ get it in customer’s hands as soon as humanly possible. If you are worried about scaling limited number of users that are allowed to use it and open it up as you go until you hit a bottleneck, and then go in and start to test around some of that. I think you can do some things ahead of time to potentially give you some best practices, whether that’s tools like New Relic that or like Jamie standard things that you can run that will give you once of it. But I think going hog wild and creating all sorts of harnessing and everything else, is just a waste. Roy: If you are talking to your communicating effectively with your users, they are going to tell you really early on, two things you should be doing is talking to your users and be able to deploy really quickly, and so you get feedback really quick if your performance is going to be an issue. I’ve had a project I’ve worked on in the past where we had reports from users saying ‘When we perform this action it is taken unacceptable at that time and we are not going to be able to use this tool because of it.’ and what we are able to do is go run a performance test which is exercise a particular punctuality that wasn’t working right, and then had it hit it 5,000 times in a second and see how long the response was, and we’re able to do a binary search for the problem. It was based off of replicating actual production environment. We knew exactly what was going on. Non Functional Requirements Clayton: Is there a place for non‑functional requirements where if you were a product interviewer you could say that ‘These actions should support this much thru‑put and this much latency’ Derek: I think that it’s totally OK to do constraints like that. I think that you have to realize if that is not your current customer standard you run the risk of doing a lot of waste. If you say ‘I’ve got this app that’s got a thousand users’ I’m going to make the constraints, but say that it’s going to do with two million concurrent users or I’m not going to accept the story. The truth is, if you don’t really have two million concurrent users on a regular bases, you’re probably wasting your time trying to write stories that have that as a constraint. Clayton: Even if your constraint needs to be able to handle a thousand concurrent users and you’re a product owner, often times I’m hoping that most of the time the product owner is looking at the story before it goes into production. That means you have to write a performance test on every single feature that you write? Derek: My thing would be that if you really had two million concurrent users on a regular bases you probably have testing frameworks in place to test that stuff already. You’re not having to go build all this… [crosstalk] Derek: I think the problem is when you’re going to release a feature right away and you have no idea how many people are going to use it, you go and spend all of the time doing performance testing, I think that’s foolish. I think when you hit performance constraints you start to build those tools and then you can continue to use those tools as your software evolves and as your base evolves. Team Working Agreements Clayton: Moving on to working agreements. This is something that can be very powerful to teams, but we had a situation recently where a team made a working agreement around how other teams interacted with them. Is that really fair to call that a working agreement? Derek: I think it’s fair to make a working agreement on how that team reacts to other people interacting with them. For example, if I have a team that is constantly getting interrupted by… [crosstalk] …sure, and we had a problem where some of our team members will give in to it, and we’ll go and help them out, and hurt our sprint because of it, I could totally see us having a working agreement within the team saying ‘If we get interrupted, you need to bring it up with the entire team, you can’t just make the call on your own to go and spend the time helping that stake holder.’ The fact that it needs to be discussed with the entire team, I think that’s a totally fair working agreement. That would affect how you interact with outside people. Roy: To me this is largely about how things are communicated. If the three of us are all on a team and we agree that we all don’t like interruptions, we want to do xyz, do little flags, or do something that we’re busy, and if somebody comes in‑ If we’re going about our work, we put our flag up, and somebody comes in, and I say ‘I’m sorry, we’re going to have to tell you in 15 minutes that we will deal with your problem, but right now we need to stay focused on this.’ then we have a working agreement. What we’re doing is signaling to somebody else ‘ We can’t help you right now’ and if they question it ‘ We’ve got this internal working agreement that we’ve agreed up on this’ that would be really great when the three of us say ‘We’re going to have a working agreement that works like this.’ and we’re going to send it out to everyone in the company and say ‘By the way, when you work with us, this is exactly what you’re going to do, and you’re going to like it. This is our new working agreement.’ Us collectively, that’s bullshit. The reason it’s bullshit is because you didn’t ask of the other people that are coming to interrupt you to say that ‘When you interrupt us it really bothers us, and we would like to come up with a way to do that‑ how would it work best for you?’ I don’t think that the internal working agreement is a bad thing, but if you go out and you sell it as ‘This is how we’re now doing business, here’s the memo, read it, and abide by it by law.’ and then call it a shared working agreement among everybody, that’s bullshit. If you say ‘This is our working agreement that we’ve agreed upon, and we ask that you please respect that with us.’ I think that’s a little bit different. Backlog Grooming Clayton: Next up, back log gardening. Backlog grooming. Is this something that is avoided, or people don’t do enough and you do a certain workshop and generate a whole bunch of stories and you sit there and think you’re just going to work on them? Derek: Grooming on backlog is done in the middle of planning, right? While you’re trying to give your team stories. Clayton: Typically by the book, it’s more done before hand where you’re going through making sure things are prioritized, and… Derek: So you’re saying you shouldn’t spend the first hand on planning or reorganizing everything. Clayton: That’s probably a sign that you’re not doing any kind of gardening, right? Roy: That means you’re Advil, if you do that. Derek: That’s true. Clayton: That’s right. At the drop of a hat, you can reorganize everything. Roy: The reason I said gardening instead of grooming is, when I look at grooming, that’s cutting the hair, that’s picking the nits out of…the lice off of your head, et cetera. I think that that’s how most people view backlog grooming, which is most people have the problem of I’ve got an enormous amount of crap or features that I want to deliver, and most of my effort is trying to pull stuff out that they don’t really want to do or to get more details to clean up and prettify and get it ready. But I think that a lot of organizations on existing products, they have a much different problem. Their problem is one of we don’t know what features to actually be adding. We don’t know how to talk to our customers. We’re just adding crap that doesn’t matter, so what happens is this is like, “Oh, I’m not really sure,” it’s like, “Who called this last? What were they pissed off about? Let’s throw that into the product,” instead of actually saying, “Hmm, have we already plowed that field before, and is it going to fallow if we keep planting on it? What kind of vegetables do we think people are going to…” If you take more of the gardener’s approach of, “Hey, let’s be strategic about what we’re planting and the cycles of it,” I think it’s a little bit deeper than just saying, “Hey, we’ve got more stuff in the backlog than we can see. Let’s trim the fat.” I think it’s about really doing…it is about trimming the fat, but it is also about what you’re planting, what you’re putting in, all of that tending to it. It’s hard work. Clayton: Interesting. I think, from a perspective of…if it’s a new product, you obviously you’re going to have the problem of you buy up a bunch of stuff, and then you have to change things, like you said. I do like the idea of saying there are different cycles, different seasons. You might plant different things. Is it maybe that it takes too long to sow the seeds for things to sprout before you realize them, and those are the things that get crushed in the garden? Some new feature the next person yells a lot, so you say, “Oh, we need to dig that stuff up,” even though it’s barely even got started. Roy: I think some of it too is, if you look at maintenance, maintenance on existing products are like weeds. They start to choke out new growth. People get totally bogged down in the maintenance of things instead of being able to do things. But I think a lot of it is really hard work, and most product owners are not dedicated 100 percent, full‑time, to their project, or they’ve got other duties that they’ve got to do beyond that. It’s very difficult for them to work with the team as well as work with the customer to do demands, as well as work with the business to say, financially, how are these things working. So, usually, what we’ll see is somebody does one of those things really well ‑‑ either they work really fabulously with the teams, but they’re falling down on listening to customer demand or doing the business side, or they do really fabulously with the business, but the team hates their guts and they’re not listening to the customer, or they listen to the customer, but they don’t understand the financial decisions that they’re making, and they don’t get along with the team because they’re never present. I think it’s very difficult to manage all three of those hats as a product owner, so, usually, whatever is my strong suit, I’m going to gravitate to it, and I’m going to throw the other ones by the wayside unless somebody forces me to deal with them. Cross-functional Teams Clayton: All right. Next step: cross‑functional teams. It seems like something that people started saying a while ago and that’s stuck, but I don’t know that everyone really agrees on this or knows what it really means. Roy: I think that the question that most people have is, what does it mean? Some people, cross‑functional team means anybody on the team can do absolutely anything. Usually, the detractors that are against cross‑functional teams say, “Oh, that’s the fastest way to mediocrity. You can’t be a jack‑of‑all‑trades and master of none. “You get a bunch of people that know everything, but they only know that at surface level, so you never get the awesome gain of the super specialized stud muffin of a team member.” Derek: Those guys write the best code, by the way. Clayton: Yeah. Roy: I think more pragmatic viewpoints of what cross‑functional are, are the people are going to have things that they are better at than they’re not better at. If I’m on a team, it’s not seen as I can do absolutely everything at the same levels everybody else on the team. But, if push came to shove, if we said we had to push this feature, I wouldn’t throw my hands up in the air and go, “Not my job. I don’t know how to do it. We have to wait for Stevie to come back in order to do it.” I might say, “This is going to take me 100 times longer than Stevie, but I’m full‑bore willing to get in.” I think it’s a lot more about collective code ownership, and, if you took that beyond to product, its collective product ownership, is what I think you’re really saying when your cross‑functional team is we’re all contributors to this team, we all succeed or fail together. I don’t think it’s somebody can be better at database and somebody be better at design, or whatever. I think that that’s a trap that people fall into when they get too into cross‑functional. Clayton: Yeah. I guess you don’t want silos, but you wouldn’t want to stump out the specialization. You would benefit from having someone who knows a lot about SQL, maybe, or your team, but you wouldn’t necessarily structure the work or the product in “these are the SQL stories.” Roy: “I can’t do the work because I’m not the SQL guy.” I don’t think you’d want that. You’d say, “I’ll gladly take this story or this work, but I might go see Clayton, because he’s the SQL guy. This is really complex stuff, and I would really like to pair with him so that it’s faster and it’s done better and then we’re spreading the knowledge of how this stuff works.” Clayton: I think collective code ownership is a big part of that, everyone having to share responsibility for the entire thing. Derek: Right, and being able to deal with the full stack. You and I were talking about that yesterday. It was like debugging a problem that went all over to client to server to the database, involved everything. In the past, I don’t know how…because the team we were working with then used to be cross‑functional. You used to have segregated responsibilities, so you have a SQL guy, a front‑end guy, a back‑end guy, and all of that. I can’t imagine how you would have solved this problem. You would have had to have all three people working together, which I know they didn’t do, so how would that problem have ever gotten solved? And that happens all the time. Clayton: Very slowly. [laughs] Roy: Yeah. I think we see this a lot in silo teams, where it’s like a problem comes in, it looks like it’s a visual problem, so the front‑end guy gets it. He pushes the pixels around a little bit and goes, “This is not a front‑end problem. This is a back‑end problem. I’m making all the right calls, doing all the right everything. The back‑end’s got to be the problem.” When the back‑end guy gets it, he pushes some things around and says, “Oh yeah, they’re sending me the right thing, but then we’re sending it off to the database and the database thing.” So we call her up, and she says, “Nope. All the SQL things are handed back, but we handed to this other third‑party vendor, and they must be screwing up. “What happens is you get this chain, where this thing takes six weeks to deal with, because it’s going… Clayton: Right. And it’s going to cascade back and forth. “I’ll fix it.” “I’ll fix it.” “I’ll fix it.” and all the way back. Roy: Right. It ultimately goes to the whole cycle, and it’s really nobody’s fault. But, in reality, it’s a little bit of everybody’s fault, because… Clayton: No one cares whose fault it is, right? Roy: No, but it’s easy to bunch it up and say, “This isn’t my problem. Hand it to the next guy,” because it’s a really hard, complicated thing that’s hard to shoot, so it’s easier for me to go like, “Nope. I’m accepting the connections, so it’s not my fault. It’s somebody else’s fault.” Then that person gets it and goes, “Yeah, but you have given me the wrong thing,” so you play the hot‑potato game, whereas, if you are a cross‑functional team, it’s like, “Hey, I’ve got to deal with this no matter what. We’re going to deal with it.” Clayton: All right. That wraps it up for today. Thanks guys. Roy: Thanks. Derek: Bye‑bye.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Isaac: I’m Isaac. Deepa: I’m Deepa. Ryan: I’m Ryan. Roy vandeWater: I’m Roy van de Water. Moving Into A Shared Space (Bullpen) Clayton: Joining us today, we’ve got three people who actually work on two separate Scrum teams. You guys have recently, as of probably two months now maybe, three months, have moved into the bullpen, a shared team space. I was curious what you guys thought about going from working in cubicles to working in more of a team room environment. Isaac: I love it. I like the collaboration and working with other people, and being able to hear other conversations, and have quick meetings without having to go anywhere else. Is It Too Noisy Clayton: Do you ever think it’s too noisy? That’s always the complaint that we heard before. Before everyone moved in there, it was always, “It’ll be too loud, I won’t get any work done.” Have you had that experience at all? Isaac: I think maybe at first, just a little bit, but you quickly learn how to ignore that and work through it, so it’s not so bad. Deepa: I didn’t like the idea at first. I thought there would be no privacy, that I wouldn’t concentrate, and it would be too noisy. But I think I gelled into how the whole group works, and started to learn how to concentrate even with the noise around me. I think I like it. Enabling Self-Organization Clayton: One of the other things that has happened since you guys have moved into these team rooms is that you’ve become more self‑organizing in lots of different ways. Like the way you do the work, and all kinds of things. One example of that I thought of with Isaac and Deepa, in your team. You’re using a physical board, which is something that you guys hadn’t used in the past. What’s your experience been with trying to do something totally different? Moving To A Physical Board Isaac: Moving to the board, I thought it was actually kind of cool, because I think…Not just our team, but I think everybody hated Rally, which is the tool that we used online to track our task. We’ve never really kept it up to date, and for me at least, it felt like I never knew what people were working on. Moving to the board I thought was really cool, because you can actually see who has what task, and you can see where it’s at. I liked it a lot. Deepa: Yeah, it was more open to see who was working on what, and what the status was. Probably the morning and also check in the evening what was on it. That was very helpful. Clayton: Is there anything you’ve experienced, Roy, as far as things you’ve observed? The teams have been more self‑organizing, or doing more team activities that maybe we’re a little more used to? Roy: The team that I’ve been a part of recently switched to using a physical board as well. We’re only two days in, but to me it already feels like it’s making a huge difference from “What tasks people are working on” awareness, and actual looking at the tasks. You mentioned Rally’s a pain in the ass, so we threw all these tasks in there. In the past I’ve always worked on the environment where I grab a task off the board, and work on it in front of my desk, and I don’t work on anything without a task. It was such a pain to go in and find my tasks in Rally that I wouldn’t ever look. I started working the same way as everybody else, not looking at tasks at all. Which really made tasking during planning feel really irrelevant, other than as a way to get more accurate estimates. Ryan: It’s funny, because when we use electronic tools we think that’s for better communication. But we’ve found that the communication has actually been faster and better by having having the physical thing there. If we have a magical touch board with everything totally digitally up there all the time, maybe we would get a similar experience. Isaac: Until we have a power outage. [laughter] Ryan: The fact that it’s abstracted away on some web page that someone keeps on a tab that’s hidden behind other windows, and then you gotta go in there. Updating, we would always have problems with people updating their hours. “What did you work on?” “Is it in progress?” “Is it complete?” With a physical card it’s so fast and simple. Roy: I think the idea, too, that we’ve been doing, where we actually have the card hanging over our desks. Makes it really easy to point in the general direction of a task. Like if two of the guys were around one task and working another task, we can be like, “That task,” and wave at that side of the room. Which is a really general but quick way to reference something, that in a digital tool would be like “Just in task T‑436.” Color Coded Pens Isaac: I also liked that we used the color‑coded pens, too. It’s really easy to identify when things are in progress. Before, you’d have to go into Rally and actually make sure you double‑clicked the little “P,” or whatever, a lot of times. Roy: You guys have all the pen, so we just have random colored pens now. I’ll have to steal some. [crosstalk] Isaac: Yeah we have pens that we can block things, show them in progress, show the ones that are still available, and which ones are complete. Shared Space Enabled Working Differently Clayton: Do you guys think that way of organizing the work would have been possible, or easy to do, when you were still in cubicles? Do you think the team room has had a big impact on that? Isaac: I definitely think the team room made a big impact on that, it’s a lot easier. Deepa: It’s a lot easier, and I think we save a lot of time, just interacting with each other. Because we are all in the same room, checking on things. Ryan: How many times in a cubicle did you get up to go and talk to somebody and they weren’t there? Deepa: Well it’s [indecipherable 05:03] messenger first. Then the mail, and then… Isaac: Waiting for a response. Then you get up, then they’re not there. Customer Sitting With Team Roy: Something cool happened in our team a few weeks ago too. Which is that somebody from a non‑software engineering team, that generates content that we interfaced with a lot, or were supposed to interface with a lot, joined our team and sits with us as well. That’s been huge, because even though it’s really difficult for us to pair and help each other directly with the work that we do, the fact that we’re sitting in the same space, and overhear each other talking, and are just naturally communicating more, I feel has improved our ability to help each other by leaps and bounds. Ryan: He’s noticed a major difference. Roy: That too, yeah. Ryan: He loves sitting in there. Even when the dialogue isn’t directly related to what he is doing, he likes to be around to be involved in the discussion. Becoming A Team In Shared Space Clayton: One thing that a lot of things teams struggle with is, they’re trying to become a team, or have some feeling of a team. Generating working agreements always seems kind of difficult for a lot of teams. You guys seem like every retrospective you come up with some new goal and a new thing, a new working agreement, and it seems like everyone pretty much sticks to them. I’m curious why before, when you guys were sitting in cubicles, it didn’t really feel that way? It wasn’t so easy to make working agreements. Is it easier to hold people accountable, just because you are together all the time? It’s easier to notice when someone’s maybe going off‑track? Isaac: I think so, I think the visibility’s there. I think before, when you’re sitting in your cube, you’re so isolated sometimes you don’t even think about the team. When you are sitting there it kind of forces… Deepa: The smartboard was not that prominent sitting in your [indecipherable 06:42] queue. Now we have it on a common board, so everybody reads it and you see it all the time, so it’s always part of your [indecipherable 06:49] . Roy: The other thing too, is a [indecipherable 06:50] just isn’t that relevant when you’re working primarily by yourself. You’re working in isolation, it doesn’t really matter if you’re upholding the team, those issues don’t come up. You have your own issues, and someone else has their own issues, you’re not going to observe shared issues between everybody. Constant Interruptions Clayton: Has there been anything that you guys haven’t liked about the team room so far? Roy: Ryan and I had an argument earlier today, about an hour or two ago actually, that we haven’t resolved yet, about… Isaac: Another podcast. Ryan: I’m about to punch him right now. Roy: About the constant interrupting each other with questions. Ryan and I were pairing on something, and I felt like we were building up some steam, some inertia, doing test room development, switching back and forth a lot. Somebody came in and asked Ryan a question on something that he had expertise on, and he got pulled off into a discussion. Our working agreement is that you don’t do silent work, but I kept working anyways. Now all of a sudden it was either violate a work agreement or stop working, and it became kind of an issue. It almost feels like retrospectives aren’t frequent enough for us to deal with those type of issues, because they creep up too frequent. When stuff like that happens too quickly, I can’t afford to wait until Friday for us to deal with that. Ryan: I didn’t like the toe nails I found under my spot when I moved into the bullpen, but I think that’s been resolved for the most part. [laughter] Isaac: Personal hygiene’s kind of a big one with…That was a different team though. Isaac: Those were there before us. [laughter] Clayton: What about you, Deepa ? Anything that you haven’t liked? Deepa: I didn’t like that we didn’t have a common…What’s the presentation board? Isaac: Oh, the white board? Clayton: The white board. Deepa: Yeah, the white board. That was an issue [indecipherable 08:31] planning. What else did we have? [crosstalk] Deepa: But now we have it, so I feel comfortable. Planning In Shared Space Roy: It’s interesting too, you guys do planning in your team room, in your bullpen, but we choose to do it in a separate conference room. I’m wondering, why do you guys chose to do it in your team room? I guess we’re the ones that are doing it weirdly, so maybe we have to excuse our behavior. Deepa: You don’t have to move out? Isaac: Yeah, we don’t have to move. I think we like the fact that we have the team room, that we pretty much use it for everything. We do the retro, planning, everything in there. Clayton: I’d say everyone feels more comfortable in the team room, just in general. When we go into a conference room, that’s when it gets lifeless. There is usually just one person driving the computer that is showing stuff on the screen, and you can check out. In the team room it’s a little more intimate environment. Everyone’s usually sitting around the small little table, and people are having more fun. Deepa: It’s your own place, so you’re familiar with it. I was first against having demos in the bullpen, because I thought it would not be very serious, people wouldn’t be responsible. After the first demo in our bullpen, I think I was very comfortable in the same place that I work and do the demo. It didn’t feel odd to talk about [inaudible 09:46] . Planning Outside The Shared Space Roy: I feel like if I were to do planning inside of the bullpen, that it would be really hard for me to resist the temptation to turn to my computer and start working on something when the planning gets tedious. The other thing that I feel is, moving into a different room is, the room is associated with the planning mindset. When I’m in this room I’m in planning mode, and when I’m in this room I’m in developing mode. I feel like I make that mental switch when I walk through the doorway. Ryan: One thing I did like about watching them plan is how they gather around a center table. It does pull you away from the computer a little bit. It also gets you face to face with the people that you’re planning with, which I think we don’t still do very well on our stand‑ups. We all stand back against our machines. Getting closer, and getting interpersonal with people, I think generates a better feel as a team. Roy: Our planning, too, involves us looking in a “U” shape at a common screen. I wonder what it would be like if we got rid of the projector and didn’t have that at all, and instead just sat in a circle and talked? We probably don’t need to see that. Isaac: I’ve noticed that since we are gathered around that smaller table, it seems like everybody’s closer. When we used to be in a conference room, some people would sit way at one end, other people at the other end. Roy: Yeah, we have the same thing. Isaac: Breaking out tasks on index cards wasn’t very productive then, because it was too far away to see what was going on and the interaction just wasn’t there. Ryan: That’s the thing I like the most about sitting in the team room, if we’re talking about a story and Deepa starts talking about something, it’s so easy for someone to just grab a Sharpie and put it in front of her and basically say, “OK, start writing task.” In the conference room, when everyone’s so spread out, it’s like, “OK, who’s going to write this down” Then, it turns into, not an argument, but… [crosstalk] Roy: Usually there’s a dedicated… [crosstalk] Ryan: Hot potato. [laughs] Isaac: Yeah, hot potato. Deepa: You sit all across the room, and then you are not together when you do the tasks. All that is very… [crosstalk] Roy: Maybe we should seriously reconsider how we do our planning, because ours feel pretty lifeless, and energy‑less. Shared Space Advice Clayton: I always like to ask the practical questions. If you had a friend that was a software developer, who had a similar role that you have, working in another company, and maybe their boss was thinking about moving their team into a team room, what kind of advice would you give them? What kind of tips and tricks would you give them, now that you’ve done it for a while? Ryan: I would say, first off, that it requires a mind shift, that programming is a collaborative effort. I’ve been used to, in my career, it being a silent‑type thing. You get your little assignment, you go into your cave, and you come out of the cave every once in a while, and you slip your code under the door, kind of thing. The mindset has to change, where you’re working together as a group and it’s collective ownership of the code. That’s really, I think, a key shift in my mind, to accepting this style of interaction. Isaac: I’d say definitely be open to it, just go for it. Because I know some people really weren’t excited about it at all, but see a complete 360 when they just go for it and try it. Deepa: It’s more like teamwork that dominates, and that should dominate. That’s what I feel. The mutual thinking there, you should probably juggle with your group. Problems With Siloing Clayton: A flip side for you, Roy, since you have more experience working in a collaborative environment, when you first started, when we were doing more siloed stuff, what were the big downfalls that you saw, the problems that you saw with the old way of doing it? Roy: Back when we were siloing, back in Integrum? Clayton: No, no. I think when you started here we hadn’t really make that whole mindset change that Ryan had mentioned. Roy: What we had at first is, we had different types of developers. We had a flash developer, and a back end developer, and a whatever developer. We had all these specialized rules. Then, as we started pairing and working in a team room, it became impossible to maintain those roles. As a Flash developer, there may not necessarily be a Flash story. One of the things we were doing was randomized pairing, based off of names from a hat. It becomes impossible, because you’re pulled off of flash tasks as often as you’re pulled onto other stuff, so you don’t get to maintain your own fiefdom, and you don’t get to stick their own code. That was one of the negative things I saw in the past. If I’m a Flash developer, I would interact only with my Flash code, and then Ryan is a back‑end developer, and he’d only interact with the back‑end code, we never even saw each other’s codes. We never got to learn from each other. Ryan: I’ll add another one. Issac and I, in our roles, originally were kind of outside the team. I found that when I sat with the team and I was a participant in the tasks, that I had more influence with the team. I kind of had street cred, or I was in the trenches. When I had an opinion on something and wanted to influence the direction that the code was going…We make “Ivory tower” jokes, but it wasn’t like issuing edicts from some place in the distance. I was there every day, working on the same stuff they were working on, and so my opinion, I think, carried more validity just because of that, and not because of any title or position. Roy: Maybe it’s more of an “Ivory steeple” now, then. Ryan: Yeah. [laughter] Clayton: On that note, I think we’ll wrap it up. Thanks guys, for joining us today, and we appreciate it. Ryan: No problem. Deepa: Thank you.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Jade Meskill: I’m Jade Meskill. Clayton: Joining us today we’ve got Kevin Goldman from 29th Drive. Hi there, Kevin. Can you tell us a little bit about what 29th Drive does? Kevin Goldman: Sure. We design and sometimes develop software. Using Agile Frameworks With Design Teams Clayton: We’ve actually done a little bit of work with you in the past. We wanted to talk to you today about design, and you mentioned design a little bit of software, and the Agile framework. What’s your experience with that? Kevin: Jumping right into it. Clayton: Yes, right away. It’s a 15 minute podcast. We’ve got to get going. Kevin: Oh! Its 15 minutes. That’s good to keep in mind. [laughter] Kevin: Yeah, I was thinking about some things we could talk about today in terms of how we use some Agile processes in our design work. I think the thing that we’ve been using most, a process that we’ve been using most lately, is sketching. When people talk about Agile UX, oftentimes they’re talking about getting away from deliverables, from traditional deliverables based on predetermined milestone schedules in a waterfall process. What we’ve been doing more and more, is really embracing the idea of rapid ideation, and using pen sketches to replace a lot of what we used to do, around flushing out our ideas in digital form. Clayton: Like a Photoshop comp. kind of thing? Is that something that would maybe be the old way? Pen Sketches vs Wireframes Kevin: Yeah. Let me describe it that way. Old way might be having an idea, wire framing it, iterating on the wire frames. Then taking the wire frames into visual design, iterating on the visual design in Photoshop. Then taking those visual designs, and then throwing that over the wall to the development team, and them developing. Now what we’re doing is ‑‑ we have an idea. We’ll do a lot of pen sketches. We’ll bring in development right away, and actually do pen sketching with them, and start talking about the idea from end to end; talking about implementation, and all these development issues early in the process with design. Instead of moving from the pen sketches into Photoshop, or the pen sketches into digital wire frames like an omnigraffle, we’ll move right from the pen sketches into prototype. The prototype might be built in Twitter Bootstrap. It might be built if it’s IOS, a prototyping tool for IOS or it might even be prototype to nextcode. Clayton: Yeah one thing I’ve always, I have a background in doing what you described as the old way of the designer creates kind of stuff in Photoshop that’s very flushed out and very like final basically. Throwing it over the wall and then slicing it all up and turning it into a website and I’ve always thought it was interesting that when you got to that low fidelity like pin sketches kind of thing where you could really sketch something out and the crumple up the piece of paper and start all over again. That was so freeing and it made it so much easier to collaborate with the people that were editing, the traditional kind of design developer barrier like the mis‑communication that always happened, that seemed like it went away. Kevin: It’s so true so that idea of collaboration I think is a big part of what development teams think about when they think about agile development. And the same thing with UX so you don’t have to be an artist to pen sketch. Any of the stakeholders in the project can sketch an idea on paper. Customers, business, stakeholders, marketing analyst, anybody can sketch on a piece of paper. And so by making that the medium it allows the design process to be a little bit more inclusive. Clayton: Can’t lower the very so you don’t have to be a designer or artist or something. Kevin: Yeah and we’ve gone so far as to work with new customers or even existing customers and encourage them to bust out the pen and get their ideas out on paper and send them to us or a lot of times we work remotely with our customers so they’re not here in town so we don’t have the ability to just sit next to the person and flush out ideas but we’ll use sketch cameras. There’re these great little IP Vogue cameras that sit on your desk, they’re only $79 and if we’re using a Google hang out or a go to meeting it allows us to show what we’re sketching on the screen and through the go to meeting or Google hang out. So we’ll send those cameras o our customers so they can do those same things back and it creates the concept of having a white board, but doing it remotely. You Don’t Have To Be An Artist Clayton: That’s pretty neat. Have you found that your customers are embracing the idea, are they resistant to it? Do they not want to jump into what they consider your domain, the design territory? Kevin: Yeah, there’s a lot of, there is a. For people who aren’t designers, there’s a feeling that their sketches aren’t going to be pretty. There’re a lot of disclaimers. I’m not an artist, I’m not a designer. That’s OK. We’ve gotten some really great ideas and sketches from non‑visual people. Jade: What’s it been like working with the designers like the people that maybe used to do it a certain way and having to adapt into this, even like you said, using Twitter which drafted current prototype, I’ve worked with a lot of designers who were very comfortable creating things in Photoshop, but when you get more clear towards the front‑end, they’re actually writing something that actually works and you can look at, they didn’t want to do that necessarily. What’s your experience with that? Pairing Different Design Disciplines Kevin: I can only speak from my experience in the team, the people that I’ve worked with, and all of us have some degree of understanding the front‑end code, some more than others. In some cases, a designer of the team might be able to create an entire prototype by themselves and they’re very familiar with all the latest CSS3 and familiar enough with Java script to get some of the basic interactions working, and at other times, we just have to collaborate. If the designer on that particular project isn’t as comfortable, then we just pair them up with one of our front‑end developers so that they can really work day‑to‑day throughout the day on this task of creating the prototype. Jade: What’s like transition period been for you guys in making this change? Is it something that you were able to pick up pretty quickly or has it been a few months that you’ve been learning as you go or what’s that been like? Kevin: It’s been a constant evolution. In some ways, I want to say going back 15 years when I started doing design work because you’re always in the process of designing the design process, if that makes any sense. Jade: Sure, yeah. Pen Sketching Allows Collaboration Kevin: I say with pen sketching, we’ve really been getting back into it. It was really a part of my early training coming out of industrial design. There’s a culture of sketching in industrial design, and then of course, there’s whole lot of years where I used only digital tools and now with the team that we built at [indecipherable 07:47] drive, which is relatively new, we’re really looking for new ways to collaborate when we started to pen sketch more, it really gelled and it was very quick. Clayton: What do you think is the biggest contrast that you see between moving towards this new maybe more agile direction versus the old way that you did things, the more waterfall, lot more hand‑off, and more formality around that? Kevin: The contrast between them? Clayton: Yeah. Agile Design Allows Better Ideas More Quickly Kevin: Without sounding like a bunch of hype, I think the more agile processes in pen sketching in this collaboration that we’re talking about creates better ideas quicker. It really allows you to generate a lot more ideas, so therefore find the bad ideas more quickly and invest your time into the good ideas more quickly. Jade: Why do you think it allows you to do that? Kevin: The pen sketches, no matter what, specifically looks sketchy. It’s just so fast, you can’t get bogged down in pixel pushing, even if you’re doing what we call Greybox wireframes, which are very low fidelity wireframes. If you’re in OmniGraffle you inevitably just end up spending a lot of time trying to figure out how to invert an object, you have to search in through help and menus. If it’s a pen sketch, you’re going to just sketch that in a few seconds and be done with it. Clayton: You’re not as tied to the concreteness that a digital tool might give you. Kevin: Yeah. Clayton: Some of that formality of presenting it to your customer and having them review it, all that stuff tends to add overhead and really changes the interaction that you have. Kevin: Totally changes the interaction. With pen sketches, they never confuse the sketch with something that might be final and that happens a lot in design where if we present a wireframe, we know in the industry what a wireframe is and what to expect out of a wireframe, but sometimes a customer, they might just wonder why everything’s grey. We’ve actually heard that. Jade: I don’t actually like this color palate. Kevin: Why is every button grey or why is that font not consistent? They get caught up on those things. But a pen sketch is so far removed from the final that whole confusion or misinterpretation of what you’re trying to communicate is not an issue. Jade: I always try to ask like practical questions, maybe I’m a project manager or I’ve got a team that has some developers and some designers and we’re doing it the old way, what advice would you give to someone like that, who wanted to try and do something that was a little more collaborative? Is pen sketching the first steps? You just jump into doing that or what would you suggest that person do? How To Get Started Doing Agile Design Practices Kevin: Yeah, pen sketching is the first step. The sooner you can knock down that first hurdle of that first person drawing their first line and feel it, that they don’t have to be an artist, the better. It’s very quickly that people, I think, get over that. The other thing I would recommend is we do something called a design studio, which is an old concept that also comes out industrial design. The idea is that you get a bunch of stakeholders, designers, developers, whoever is on the team together for a half a day. Let’s say two to six hours and you have either a whole product concept or part of a product that you’re trying to develop and you work together collaboratively to flush out the idea for that section of the product. What we do, the way that we’ve structured a lot of the design studios is we’ll have an introduction and that’s lead by, usually it’s a lead designer on the project, who will give the context and constraints for what we’re trying to solve. Then, we’ll do, let’s say a half hour where everybody goes away and pen sketches their ideas for how to solve that problem. Then, you come back and each person gets five minutes to present their idea to the team. Then, you repeat that process sometimes two, three times and what happens in two or three hours, you get 40 ideas of how to solve a particular problem. Even more importantly, you get everybody on the team on the same page about what that process was. What worked, what didn’t and you get this building of ideas on top of each other. You have an idea, triggers an idea in my mind and then, we build on that. Jade: Agile talks a lot about continuous improvement, so I’m curious, what’s something that you think you might try in the future to improve on this process? Kevin: Oh, man. [laughter] Jade: I didn’t mean to put you on the spot. Kevin: Just about everything so down to how we can communicate better in the sketches with call‑outs and interactivity and how we can communicate those ideas, more of a how we can…Sometimes, we do need to have a snapshot of what happened in that design studio, so we can refer back to it. Often times in the design studio, there’s a lot of hand waving that goes along with the pen sketches, so we’re trying to figure out to capture that. I think there’s a lot of room for improvement there. Working remotely with customers is just how it’s done these days. I think there are just a lot of places where we can improve in our work with people remotely. Estimating projects is always very difficult, probably on the development side as much as it is on the design side. We can definitely try to improve how we set out expectations for how we bill something, how we structure timelines in advance of actually doing the work. That’s a big shift. One of the biggest, especially for service companies who are in‑house. If you’re basing your bids and your timelines off of waterfall deliverables, it’s very easy to say, “This milestone is this much and this much and this much. It happens on this day, this day and this day.” When you follow a more collaborative approach, it’s not as clear cut at the onset of a project. Jade: You have to go into more value based fees… Kevin: Exactly. Jade: …and it’s a lot more difficult to sell. Kevin: Exactly. Jade: Kevin, we really appreciate you coming down. To be fair, just so everyone knows, we asked Kevin yesterday if he could… If you’d like to record a podcast and you said, “Sure.” So we said, “Come tomorrow.” It was a little short notice, but we appreciate you making it out here. Kevin: Yeah, thanks for having me.

Clayton Lengel-Zigich, Jade Meskill, John Miller and Roy van de Water discuss: Agile in Education Scrum in the classroom How software developers are like pre-k children The post Episode #93 – Education and Agile with John Miller appeared first on Integrum.

Jade Meskill: Hello and welcome to another episode of the Agile Weekly Podcast. I’m Jade Meskill. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Roy vandeWater: And I’m Roy vandeWater. Adding People To An Existing Agile Team Jade: Guys, we wanted to talk about adding new people to an existing Agile team. I’m using air quotes here, so my quote unquote Agile team, if I hypothetically had one. Clayton: If that’s possible. Jade: If that’s possible, yes. Roy: How agile would you say they are? On a scale from zero to very agile? [laughter] Jade: Fourty‑two. Roy: That’s pretty agile. [laughter] Jade: Depends on what the scale is. [laughter] Jade: Let’s just say we have an existing team, they have some existing culture and ceremonies, and virtues, and vices, and all of those things. The organization believes it’s time to add new people to the team. Now what? Roy: Hire somebody and put them on the team. [laughter] Jade: That’s easy. Tuckman’s Stages Of Group Development Clayton: The first thing I think that comes to mind is the storming, forming, norming, performing stuff, right? So, maybe you get this Agile team that’s either in the maybe norming stage or performing stage and things are going smoothly, like you’ve mentioned. They have their set of working agreements or they’ve all agreed to certain things, and, there’s certain processes and they have this team culture. And, then you drop some new person on, and, you tip over the apple cart, they have to start all over again basically. Roy: So, maybe it’s ideal then, to do it as early as possible so you can start over as early as possible, and, get them performing again as quickly as possible? Jade: I don’t think any organization really optimizes for not disrupting the teams, right? Someone at some level decides that they need to hire new people, whether that’s, we need to get rid of this budget that we have, or, the team isn’t going fast enough. So, if we just had more people, they’ll go faster. That mapping makes sense in their mind. They’re never going to really…they don’t necessarily care about the teams, the gel of the team. Clayton: Let’s face it, there’s probably a problem, right? There’s a reason that’s driving the organization to want to hire people, and, it’s probably not because we have so much money that we just need to hire more people. [laughter] Jade: Sure. [jokingly] We just have to get rid of all these piles of cash. Roy: Problems I wish I had. Increased Pressure To Deliver When Adding Members Jade: I would assume that the team is not performing to somebody’s standard, right? Now, there’s going to be some subtle, or not, pressure to enhance the team’s performance by adding someone. Roy: I’ve seen this on a team where the team was consulted, so the management went to the team and said, “Hey, we want you to go faster. We want to get you another person and we’re willing to pay for this person. What do you think”? In our case, we had the team unanimously go, “No. We’ve got enough troubles as it is. We think that adding a new person to the mix right now isn’t going to really make us faster. It’s just going to make things more complicated and, actually, potentially slow us down, while costing you more money at the same time.” Clayton: I think, that was a sign of maturity on a team with a similar situation. They all realized that, if you add another person, that’s going to probably cause more problems. Even though, maybe, the team as it is now, from the skills perspective is lacking in certain skills and you could find someone that could fill that gap. I think the team realized that the overhead it would take and the time it would take to get that person up to speed, just from like a human cultural perspective, was a bigger deal than filling that skills gap in the short‑term. Jade: What about the team’s response to the assumed short‑fall in their performance? Did they think about it from that side as well? You Mean Adding People Means We Are Moving Too Slow Clayton: The one thing that’s interesting when you take the average corporate team, even if it’s an Agile team or Scrum team or whatever it is, if they have lived the traditional corporate life with the traditional corporate managers, then I don’t think they’d make that connection basically. I don’t think they realize that wanting to add a new person means that someone thinks they’re going slow. Roy: Even if they did, like the team I was on, when they said, “We don’t think that adding this person will make things go faster.” Even if somebody feels they’re under‑performing, “Yes, there’s now pressure to perform better.” But if the team being realistic about, “Even if we add this person, we won’t go faster.” It’s like it doesn’t matter, right? Clayton: Well, yeah, and the team in whether it’s performance or if it’s skills gap thing, if the team realizes, “Whatever you’re trying to solve, Mr. Manager, by adding this new person, based on what we think, it’s not going to solve the problem.” I don’t know really what the manager can say, other than, at some point, if they really have to do it, they’re just going to assert their authority and just put a person on the team.. Roy: If you need more people for whatever reason, the right thing at that point might be to form a new team. The only problem is, if you have teams working on different products, what do you do? Split off on the products, give to the new team and how do you deal with the main knowledge transfer? If you don’t have enough products, do you spin up a new product? That doesn’t make your old product go any faster, right? Jade: So what happens if I’m Mr. Manager and I decide that, you know what…You’re getting a new person. What’s going to happen to that team? Roy: I think part of what Clayton said about them going through the whole forming, storming thing is pretty accurate. It’s probably going to be even worsened by the fact that the team feels betrayed by management, because their opinion didn’t count and now they have this new person that was pushed onto the team that they’re already resentful about, right? Jade: But I’m doing it for their own good. Resentment Having a New Team Member Forced Upon You Roy: It’s like the control podcast that we talked about last week, right? Even if you tell people what to do for their own good, there’s an automatic resentment that happens, where if you let people discover that for themselves, they’re a lot more likely to buy in. Clayton: But I think that if you were to add that person to the team. If you take a team that is performing to some degree, or they’ve kind of gelled together, a lot of times, I think you’ll see that they all have some certain amount of respect for everyone. So if someone says “Hey we should start… we should pair on every task.” If it’s a reasonable team that has gelled to some degree, they’re not going to just throw that out of hand and think that this person’s crazy. It’s like, “OK, I’m going to take that as a valid point and we’re going to talk about it as a team and that’s totally acceptable.” Then you throw the new person on and they might have totally different opinions about all the working agreements and all the norms that this team has established already. In reality the team wants to treat them like a normal person, the same as everyone else, but they almost can’t because they’re a newbie right? So you can’t really treat them with the same amount of respect and you can’t really take their input at face value because they’re this new person, what do they know? They haven’t been around with us this whole time. They haven’t been in the trenches. Roy: But I think you have that problem regardless of whether or not the team chose to add that person, to bring on that person, right? I think you might have more resentment if they were forced that person by management. But if they chose to hire a new person, you’re still going to run into the same thing at first. I think that’s part of the forming and storming process. Choosing To Bring On New Team Members Jade: Yea, to some degree. So, let’s say that the team did choose to bring someone on. They went to the management and said “We want more people.” or “We need this thing.” I could see that even going wrong if the interview process was a traditional interview that had nothing to do with the culture and nothing to do with the team and it was all about technical aptitude and, “Do you answer these five…” Clayton: So they went through the HR process. Jade: Yea, they went through the HR process. I would imagine that the team, even though said we want someone, they’re going to get some crappy person they don’t actually want. Roy: I’ve had that personal experience where I was brought into a team with a fairly progressive interview process, not the centered HR thing and there was still that initial forming storming… Jade: Oh sure. Roy: …and all that stuff that was going on… Clayton: The Tuckman Model says that every time you change a team they will go through that. Roy: Right, right. Clayton: The difference is in a mature team. They might go through it quicker, and less painfully. But they will always go through that process. Every time you change that team dynamic. Jade: To get to maybe another part of this topic… [crosstalk] The Interview Process On An Agile Team Jade: If I wanted to hire someone else, if the team said that they wanted someone, the team was open to it. What would be a reasonable interviewing process to make sure the team could go through those stages as fast as possible? Roy: First, I think the team should be as heavily involved in the interview process as possible. I could see HR or management or whatever doing some high level filtering to get the obvious idiots out, but before anybody comes onto the team, every member of the team should have a say in it, I feel. Jade: In terms of, should it be like a unanimous decision basically? If someone comes in, the team should interview them and they only get hired if everybody says yes? Roy: Well I don’t even mean just a unanimous decision. I mean, it should be, everybody on the team should have interaction with the candidate too. You can have a unanimous decision where, “Clayton’s the only one that actually talked to this potential hire, but I trust Clayton’s judgment so I’m going to thumbs‑up it.” But I feel that if somebody’s going to get added to the team, everybody on the existing team should interact with that person and have an opportunity to assess them in their own way. Hiring Is Expensive, But Getting It Wrong Really Hurts Jade: So doesn’t that make hiring really expensive? [laughter] Roy: Well, how expensive is it when you hire the wrong person and you’ve got them on salary and you can’t fire them? That sounds way more expensive in the long run. Clayton: That’s a problem for future us though. [laughter] Roy: Yeah future us will… Clayton: For now us, that costs us a lot of money. Roy: And that’s totally discounting the idea of introducing this bad apple into the team and completely poisoning their chemistry and now you don’t just have the cost of the person you just hired that doesn’t fit, but also the cost of paying everybody on the team now that’s not performing because they all hate their lives. Jade: So what are you trying to say? Roy: I’m trying to say that one bad person can totally ruin everything on that team. Clayton: So hire slow? Roy: Yeah. Where To Look For The Right People Jade: Well, and I think what’s interesting though is if you take that as the perfect advice and say I going to hire slow. I would guess that most people that are development managers, probably the channels they’re using to find people are the wrong channels in the first place. So this is like a very painful lesson to learn of I want to hire people that are going to be a good fit for the team, that are going to fit culturally, that all these other things, all the check‑boxes that are not the traditional HR check‑boxes, but when I get the recruiter people, I get the wrong people every single time. Roy: So maybe you should start looking at the local bar. [laughter] Jade: Well, where would I go, right? How would I know a better place to find people? The only thing I have is, I submit something that goes through HR and they do something with it and I get people back. What am I supposed to do? Roy: Yeah. Jade: You would never hire anyone it seems, right? Clayton: What happens sometimes, if a team becomes self‑aware and empowered to make that decision and now they don’t ever want to hire anybody ever again. Jade: I can imagine that would happen, right? Clayton: Yeah, we’ve seen it happen in places that we’ve worked where it’s become almost impossible for them to hire people. Roy: I don’t know if that’s necessarily always a bad thing, though. It can be, because it reduces the potential for growth, but maybe… [crosstalk] Jade: We’re successful. Our product’s doing well and we need to grow. How do we do it well? Roy: Well, there’s… Clayton: I can tell you all the things not to do because I’ve done them all. Splitting Teams Roy: We’ve talked about the two pizza rule, right? A team of seven, plus or minus two, once you get beyond nine people becomes really hard for the people within that team to really know the other people they work with. So once you get to that point and you have to grow, I think that’s the time to spin up a new team. I think that’s difficult, especially from a domain knowledge perspective, but at a certain point, you have to split off into a new team. Jade: How does that fix the problem? Roy: Fix which problem? Which one are you… Jade: If we’re trying to add people to the company, right, even if we split into new teams… Roy: That’s tough. I would try to take the existing team, like if you have a team of nine, try to split that into a team of five and four or something like that. Jade: Now we need to hire four more people. Roy: If the team says that we don’t want to split, we like working with each other too much that we don’t want to split up, that’s really tough. I don’t have an answer for that. Jade: Well, and I think that’s just the reality of if you want good teams that are going to gel, then it’s going to take time for that to happen and if you need to change that, then there’s going to be a penalty. In your example if the product is growing and you need to hire more people and you need to expand and do more stuff, whatever that is, then that’s a price you have to pay, right? Changing Things Up Necessary For Growth Roy: I guess if you really have good people on the team that are high performers and want to learn and change and all that, at a certain point once they’ve been working with each other long enough, they are going to reach an equilibrium in which they stop gaining as much advantage from each other because they’ve already learned most of what they can from each other. If they’re really high performers, they’re going to want new blood into the system that they can learn from. They’re going to want to bring in people that are better than themselves so that they can gain new skills and gain new insights from. So if you have the right people, at a certain point, they will no longer be content with the people they currently work with and will insist on bringing in new people. Clayton: Yeah, I guess you could say that. It’d be a smell If you didn’t ever want to hire anyone else. Jade: So let’s take the other side of that coin and say that I’m a manager of some sort and I’ve realized that this is what’s going on. For the health of the organization, we need to grow but my team doesn’t want to do it. How do I help them understand the need and the appropriateness of this growth? Transparency Is Key In Dealing With Teams Clayton: So, part of it is being fully transparent. I think it sounds dead simple, but the idea of sitting down with the team and explaining to them, hey, this is where I see the company heading and I really feel like we need more people to solve this particular problem where I want to start up this product or I want to scale this or whatever, I think the first step is being totally transparent with the team about why you need to grow. Jade: Yeah and I think you could let the team be self‑organizing and then explain that you want this to happen and the company’s growing and we need to expand, so how would you guys like to address this? I think that’s probably the safest way. Obviously people are not going to like that to some degree, but that’s much better than just coming in and saying hey we’ve decided that we’re going to get bigger and we’re hiring two new people and you three are on this time and you four are on this other team and we’ll let you know how it goes, you know? Like that would be way worse than just saying we have this problem, we want you guys to solve it somehow by reorganizing yourselves. Clayton: So self‑organization. Jade: Yeah, why not live that up the chain, basically. Roy: You do run the risk of the team saying we don’t want to change and we don’t care, why do we even need to grow? But I think at a certain point if they are really a good team, they’re going to be respectful of the organization’s needs and find a good solution. Just like they did whenever you had some impossible story for them to do. Jade: Yeah, that’s good. On that note, we’ll wrap it up here. Thanks for listening. We’ll talk to you guys next week.

Clayton Lengel‑Zigich: Welcome to another episode of the “Agile Weekly Podcast”. I’m Clayton Lengel‑Zigich. Jade Meskill: I’m Jade Meskill. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: And I’m Roy vandeWater. Soul Crushing Technical Debt, Where To Start Clayton: And today we are talking about Soul‑Crushing Technical Debt. [groan of disgust] Clayton: [laughs] Yes. Times a thousand. [laughter] Clayton: Roy, you coined that phrase, moments ago. Can you explain that a little bit more? Roy: I’m just thinking of the technical debt where it feels like it’s so intimidating that you don’t even know where to begin. Every effort feels like you’re blowing into the wind, or trying to push a mountain with your pinky toe, or something. Clayton: Yes. I was looking at some code with someone today, pairing, and trying to work through some stuff. There was some code where no one really knew how this thing worked. If you changed the seventh constructor argument, there were 10 total, if you changed the seventh constructor argument from an empty string to null, then it did something totally different, and it blew up everywhere. I kind of was feeling the same way. There’s this core part of the application that nobody understands how to use it, and unless you’re sitting there with Eclipse open where you can actually look, and it will tell you all the different crazy details, you would have no idea how anything works. [laughter] Derek: That’s OK. I’m winning [inaudible 00:01:21] grudging technical [inaudible 00:01:23] GOTO statement in Java, so there. [laughter] Clayton: We didn’t see that. Makes You Want To Do The Re-Write Roy: That was pretty intense, but it makes you want to do the big rewrite, but some of these applications are so gigantic. First off, the big rewrite is always a mistake. I’ve never seen that go well. But, even a tiny, it feels so big that I don’t know where to start. I feel like anything I do just does nothing. Clayton: I think also this is when you get into the habit, or where people mistakenly call it refactoring. [laughter] Clayton: They say, “Oh, we just [crosstalk] need to refactor that,” which is “We need to rewrite that.” Especially even if they have a test suite, I don’t think you’re refactoring. Even if you have a test suite, if you just go through and just rewrite a big swath of the code. Derek: We’d have to rewrite every test. I refactored it and now it works better! Roy: Red, green, wait a decade, refactor. [laughter] Roy: Is that how it works? Reasonable Strategy Out Of Soul Crushing Technical Debt Clayton: I guess the thing I’m concerned, or I’m curious about, is it a reasonable strategy to say we don’t want to do the rewrite, but we know that there’s parts of this application that we don’t like. Can I take Boy Scout rule and when I’m in some part of the code just try and make it a little bit better? If, for instance I’m trying to use some PC application that doesn’t really work very well, can I just make some new endpoint or some new interface. And I can just use that thing and I can slowly piece it together. And if I do that over and over and at the end of the day, I would have this natural thing that one can use. But it doesn’t feel like a rewrite. Derek: No! Even that feel like is marginally better. I feel like it will take years and years before even, be able to notice the changes. Jade: Sometimes it does, right. Roy: That’s the author of a lot of technical debt. Derek: That is so crash‑y. Your Mindset Has To Change Roy: I can say that, we have to take that strategy before, or we make small incremental improvements as we go. What I tried to do in later days as I realized how bad things were is do the strategic rewrite. Rewrite small pieces at a time, try to make them a Modular. It still have to fit into the overall mess or nightmare. But those pieces will be nice and clean. It was really more of a mindset than necessarily a whole bunch of Codes that we had to rewrite. We have to start thinking about things in different ways in order to overcome not so crushing technical debt. We have to get a whole new religion to get over our depression from what we have before. Jade: Such really tough too. I can hear a whole bunch of people never seen any Code other than this, one project. They don’t any other way, they don’t even understand that there is a better way. Extracting The Monolith Derek: To me, is really most technical that people have created monsters. And they keep adding more, and adding more, and adding more. And I think what Jade might be talking a little bit more about is when you start to take a more unique approach instead of saying, let’s have a big monolithic Operating System that does just everything. We have this things that have series of tools that we can change the tools altogether. We can [inaudible 00:04:23] and we can do so really complicated things but by using some very really simple things. A lot of time, you have to take these big giant monolithic applications that nobody really understands from cradle of the grave and start to say, “Can we take a little bitty piece of it, this little component out of it?” And we pull that out and make it an API or a Library or something that is more independent and everybody can understand what that thing does. You kind of do that one at a time, one at time, until pretty soon, you’ve now got several smaller applications or some applications or some Libraries. So different things. But now it’s much more testable, much more readable, much less interdependent on everything. That’s where technical debt kills, where everybody is afraid to touch it because they have no idea what actually been impacted by. Fear Paralyzes And Creates Inaction Roy: Like we had that GOTO today that we were arguing about like why even sit and make fun of it, why don’t we just fix it. It’s like, everybody is too scare to touch because who knows what the hell they were thinking when they did that. Clayton: Well and that’s like the big thing that Bob Martin goes over is, you get code rot and you get all these bad practices because people are afraid. That’s like the fear of changing that code is probably the worst that you can have in your [inaudible 00:05:32] . Jade: I agree. Derek: Well and I think that is the smell of technical debt, right. Clayton: Right. Derek: The minute that you are afraid to change your code; you probably have some form of technical debt. The more afraid you are, the more soul sucking, soul crashing that, that has become. Self-Awareness About The Smells Of Technical Debt Clayton: How much technical debt or maybe how bad does it have to be or do you think before the average team is realizing that that’s inhibiting them from either being more successful or having more “progress” and how you will you measure that? Maybe shipping more features or being able to deploy more frequently or having a 10 minute [inaudible 00:06:07] or whatever it is? Roy: I don’t know but a month ago my opinion would have been way different than today. Clayton: I think it’s right about the time you got a business. [laughter] Clayton: That’s probably realistic. Roy: I’m willing the team whatever realize it on their own because they’ve been boiled into it slowly. Derek: The only time I ever see teams come to that realization is if they have somebody new added to the team that says, “Oh my goodness, what are you doing?” Or if they get to a point where they keep adding crap on and somebody asks…You think of a Christmas tree and it goes up to a point and then somebody says, “I’ve got a 7,000 pound star I want to put it on top of the tree,” and they go “Ugh! We need to rewrite this so that it can support a seven…” And that’s usually what it comes down to is, “Yes, we can do the 7000 pound star but we’re going to need three years to rewrite the application to accommodate that.” If it really is a 7000 pound star very often the business says, “It’s worth a whole lot of money, so I guess we’re going to give you three years to rewrite it.” Clayton: And then it doesn’t support the star and it takes six years. Derek: Right. Jade: [inaudible 00:07:13] deal with a 100 pound star. Clayton: Well and then we just build up a whole other set of technical debt, right. Derek: Correct, because we didn’t learn anything from [crosstalk] . We never had to deal with fixing the problem; we just got to start it from scratch. Achieving Technical Debt Englightenment Clayton: How do you get enlightenment? [silence] Jade: That’s a tough question. Clayton: I was just waiting for that to be totally silent there for a second. Jade: [laughs] Good thing we have all the answers on this podcast. Derek: I know. Clayton: I think some it… Roy: I needed the answer out. [laughter] Jade: It’s a secret. Derek: For a mere $3000 dollars for a minute we can tell you things… Jade: Get out of technical debt. Being Ready To Hear The Truth Clayton: I think there’s two kind of elements to it, one is I think that people have to be ready to hear it, have to be ready recognize it. Sometimes I think people are in kind of that mind set or that thing of, “Who are you to tell me that I’m potentially doing something wrong.” If I’m not ready to be there it doesn’t matter. Roy: It’s a 12 step program? Derek: You have to be able to make you have a problem. Roy: There’s a higher power and the higher power has control over the code. Derek: I think the other thing is until you kind of get a little promiscuous in other code bases, I don’t think you understand the deficiencies that you have. I know from myself the big thing we’re starting to participate in open source and free software, that really gave me an introduction to a whole bunch of developers working with them and hearing their opinions and hearing how they thought this was damn or that was great or this was… Clayton: They reject your patch? Derek: They reject your patch. I think that that opened up a whole new world outside of the limited scope. Even though I might have been in a company that had 100 other programmers, there’s a bunch of group think within that group of 100 programmers. The minute I started to step out and deal with different platforms and different countries and different ages and all sorts of different demographics about they viewed things, it started to open me up to like, “Wow, maybe I’m doing some things that are really stupid, maybe I’m doing some great things, maybe I’m doing some bad things.” It was the first time that I actually reflected and said, “Wow, maybe I should look at what I’m doing.” Jade: I had a similar more experience, I came mostly from a self taught, but a kind of isolated path right to development and once I really started getting into supporting free software and kind of drinking the kool aid there, that really opened my eyes to another whole other world of doing things and really an intolerance for crappy code. Roy: I think pairing helps a ton with that too, but even with pairing somebody in the group of people that are pairing need to know some different practices. Jade: If we both don’t care… Roy: Right, we both don’t care or we both…even if we care but we both only ever worked on the same code base and we don’t know any other way like, “We’re never going to be able to teach other good things.” Derek: I think a lot of it is getting out the same technology. If I program in .NET all the time and I have no concept of what UNIX is, there are some huge paradigm differences between those two operating systems and platforms. There are good things and bad things about both of them, but if I only know one of them, I am totally ignorant of the other. Same with languages. If I’ve never used a dynamic language or a statically typed language or a compiled language aversion, interpreted language, I have no idea how the other half lives. I think you can take so many things back, even if you just go play around with the project or with some code for a couple of days and figure out how some things work. You can take that experience back to what you’re currently doing and I think that is the thing that is really difficult. Until you’re doing that, I think you have no self‑awareness. I think you have to actively seek to be self‑aware about how you write software. How To Pay Down Technical Debt Clayton: So how do you go about paying off the debt? Is that something that you do? Derek: Add more people. [laughter] Clayton: Assuming you added infinity people… Roy: [laughs] Clayton: …and your project is good. Derek: I would rewrite it then, because now you’ve got lots of people to rewrite it. Jade: Skunk or a kitten? Incremental Approach Clayton: Do you try and just take the incremental approach and do it? Maybe you inflate everything, like every new feature you inflate because you’re going to try and tackle with the debt. You kind of, “Hush, hush.” You don’t tell anybody you’re doing it, but you do it anyway. Jade: How do you pay down normal debt? No, I’m really asking. I need to know. [laughter] On A Team, Your Debt Is My Debt Clayton: You don’t normally share a normal debt amongst a bunch of people, like you share it amongst your family. Roy: That’s why my wife [inaudible 00:11:46] . Clayton: But, with a team, many teams don’t even see themselves as that much of a team, so they don’t even think of the debt as a team ownership thing. They think of like their own specific screw‑ups a maybe a small part of their debt, but they don’t own the code base because, “I didn’t touch your part of it. That’s your problem.” Roy: I think that’s a good point. I don’t think you want to lie about it because what’s going to happen is I’m just going to end up trading all sorts of other problems and team dynamic issues and trust issues and everything else. But if you were to look at normal debt, you would say, “The first thing we have to know is, “How bad is it? How much do we owe?” Then, you have to know, “How much do we make?” Then, you have to know, “What’s an acceptable timeline to pay it back?” Based on that you’re going to have to make all sorts of decisions. So if you say, “I’m X‑thousands of dollars in debt. I make X‑amount and it needs to be paid in the next 12 months.” I know how much I need to cut my spending or increase my revenue in order to pay that in that time. Derek: What happens if you can’t? What happens if your income is not enough to cover the debt in that timeline? Clayton: If you’re listening to this podcast and you have a manager who treats it like, “Man, if you have technical debt, you screwed that up. That’s your bad. You’re going to have to figure that out on your own because you still need to make up. You need to deliver all these features. You need to have 20 velocity.” End Of Life The Product Derek: That’s what I put on my resume. At some point, you have to be realistic. There are some projects that are so far in the technical debt that it would probably be beneficial for people to say, “We’re going to ride this product out to its death and we’re not going to add more code to it.” Jade: Adjust the partner. Derek: We call it end‑of‑life in a product for a reason. There are times where a product has run its course. Meaning if the product is not able to boost revenue enough to pay to remove the technical debt, it’s probably not a product worth continuing to operate. Roy: That’s a good point. Jade: Sometimes the cost benefit ratio is so out‑sized because it takes so much effort to add the smallest feature because of all of this technical debt. Roy: Right. How Hard Is It To Add A Feature Jade: I think that becomes your compelling selling point. If you’re trying to maybe turn the corner before it’s too late. You really need to look at and measure, “How hard is it to add a feature? How many defects get generated every time we add a new feature because of intended consequences? How do we start to mitigate those things?” But you need some metrics around that. Clayton: I think it’s really difficult to measure how the technical debt and the coupling of the code and all that other stuff impacts the feature adding. I think that’s a difficult skill to acquire and a lot of teams really don’t have that. Derek: It’s not teams, it’s poor product ownership. This is a classic case of I’ve got a product that’s making $10 million a year and it’s been making the same $10 million a year for the last three years, i.e. it’s got no growth. But, I’ve got a team of 10 people that I’m paying to add new features to it. If I’m paying three teams worth of people to add features and I’m not getting any additional revenue, I have to ask myself, “Why am I not having two or three people maintain this program and let it ride itself out for the next two, three years making $10 million, take those other three teams and go build something new. Not rewrite this out again, but go build something new that could be a potential new revenue generator.” I think people are just afraid to admit those kinds of things. Clayton: I think we are out of time. I hope we have adequately addressed the soul crushing technical debt. Roy: My soul feels kind of crushed and under pressure. [background noise] Clayton: We’ll leave like 11 hours of silence on the podcast. [laughter] Clayton: Somewhere in there, we’ll answer the question about how you solve this problem. Roy: We’ll come back in with it. Clayton: So keep listening. [laughter] Derek: I’ll end at 17. Clayton: Thank you. [silence] [background noise] Clayton: My soul still feels kind of crushed. Recording: The answer is 42.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. Derek Neighbors: I’m Derek Neighbors. Clayton: Today, we’ve got a smattering of topics for you. Actually, I think we have three or four things. Derek: It’s like a turkey buffet, the day before turkey day. Clayton: Yeah, it’s like a podcast potluck sampler. Derek: In two weeks, which will be when you’re listening to this now. Right now, remember what Thanksgiving dinner was like two weeks ago, which is tomorrow. We Keep Failing One Week Sprints Clayton: We’ll see if this puts you to sleep more than the turkey. The first topic that we wanted to talk about was, oh, geez, I forgot. We have a team that we’ve been doing some work with that they were doing two week sprints, then they went down to doing one week sprints. They’re doing Monday to Friday. The topic came up of, it’s really hard for us to get all the work done in that one week, and we keep failing our sprints. Maybe we should shrink it down even more. Derek: Wait a minute. The first answer was maybe we should make them three‑week sprints. Clayton: Oh, that’s true. We shot that idea down. But we said, “Hey, maybe we should shrink it down and have an even smaller time box, and get feedback even faster, so let’s try and do one‑day sprints. Let’s meet in the morning, do a quick little planning thing to figure out what’s going on, organize the work, and then let’s do the work and let’s check…” Roy: …But we’ll spend all day planning. Clayton: What happened? Did we end up spending all day planning? Roy: I was not there. One Day Sprints Derek: No, I don’t think so. I think a number of people on the team, their biggest concern was it seems that we spend all day planning, regardless of what iteration size that we seem to have. If we went to one‑day planning, we would have to make planning happen a little quicker. Those of you that don’t know the Core Protocols, they use the Core Protocol Decider. The only way they could get the entire team to agree to a one‑day sprint was to time box planning to 30 minutes. Organizing The Work Clayton: When the team decided to do that, I think the very first planning meeting, they were still doing capacity planning where they would put their hours on the board, how much time they actually had during the day, and then they would commit to whatever work they could get done. I think for the week or so that we did that, it turned out to be that it wasn’t really like a one‑day sprint, because we weren’t doing a sprint demo necessarily at the end. It felt to me more like the team was really thinking about who was going to do the work. They were really organizing how the work was going to be done in the morning, which I feel like is something that is beyond what we were calling one‑day sprints. How did you think that went, Derek? Swarming And Pairing Derek: I think that the few fundamental differences that I saw were ‑ one, they were actually very concerned about how they were going to do the work, because they knew they only had a day to do it. When they were doing a longer sprint people would tend to kind of check out during planning and like, “Oh, Clayton’s got this, he knows what’s going on so I’m not paying any attention” to the tasking that’s kind of at hand, where I think they were much more focused. The other thing is they knew they really couldn’t take in more than a story or two, and because of that, you got a team of six or seven people, you got one or two stories by default there’s some swarming behavior, and there’s pairing opportunities that really came in. Two things that that team was not doing well at all before was swarming and pairing, and so they’d have seven stories, seven people, seven stories all happening in isolation. Everything looks great and they come to the last day of the one week sprint, and I’ll be darned that all seven stories are five percent of the way from being done. They’re a spectacular failure at the end of that. I think that it kind of reframed how they thought about breaking down work, and they realized I think for the first time that three or four people could all be in the same story, and it could still be effective, but it required them to talk multiple times throughout the day. Roy: Were you guys, actually, able to break the stories up small enough so they all fit within one iteration? Aggressively Negotiating Scope Clayton: I think in that case they didn’t have any stories that took longer. They actually were a little more aggressive about negotiating scope, which I think they normally wouldn’t have done. They would have been able to say, “Well we got a week to do all this stuff, so it will all fit.” But when they really got down to like, “Hey, let’s talk about what we have to do to get this done,” then I think they uncovered some of those unknowns they would have found out about on Thursday, otherwise. Roy: Did you find this made you really susceptible to people being late? If the first thing you’re doing every morning is planning, and do you want to figure out your capacity, and somebody shows up half an hour late, and they miss planning, how does that effect you? Replacing The Stand Up Derek: I think it actually had the opposite effect. I think people were, actually, more mindful of being on time because one of the problems before is they didn’t think the stand up was very valuable. There was no need to be on time to this stand up that you didn’t get any value of, where they knew if they missed a day of planning that they would be significantly out of touch with what was going on for the entire day. I think it actually made people value the start of the day much more than they did before. Product Was The Limiting Factor Roy: What point does it start breaking down, one day sprints sounds like you got some value out of it, like what if you did one hour sprints or one minute sprints or one second sprints? Like at where does it become unreasonable? Derek: I think the breakdown that I saw that was huge was ‑‑ it’s very difficult for the product owner who is in charge of multiple teams or not in charge of them, but has multiple teams on this particular product. It’s very hard for them to commit every single day with their workload at the same time. Since the team is totally dependent on having new work to start every day, if she was late or not able to be there, that could seriously impact the entire day for the team, so that was a major hurdle to overcome. Then, of course, the other one is if you start to get bigger stories that don’t decompose well to less than a day’s worth of time for the entire team, or if you got stories that rely on feedback from somebody else that might take a day or two for those to go, it becomes difficult for how do you deal with those. The Checkout Protocol Clayton: Just to shift gears a little bit, Roy, you recently have an experience using the Checkout Protocol during the retrospective. I was wondering if you could maybe share that story. Roy: Sure. We were having a retrospective. I think it had been going on for about an hour and a half, and I think a little bit in we decided to come up with a smart goal. The smart goal is actually suggested by the scrum master, so it’s a little odd from that perspective. In general, the retrospective was going around in circles, and we were lost to what was going on. It didn’t seem like it was moving forward at all, like it suddenly repeat back on itself, and it just go for some iterations. The rest of the team that I was working with was all familiar with the Decider Protocol. I ask them if they’re familiar with Core Protocols, and I ask them if they knew what the Checkout Protocol was, and they said, “No.” I explained to them how it works. If you feel that you are able to provide more value somewhere else or if you feel like you are ‑‑ I believe the word Jim uses is ‑‑ emitting random emotional signals, or something like that, the idea of you’re just firing off random emotional stuff and you can’t deal rationally with the situation. I explained to them that if that type of thing happens, you can say, “I check out,” and walk away. You are able to get out of whatever the thing that you are participating in. I explained to them how that protocol work, and then checked out, which I think shocked quite a few of them because they were not quite used to that type of thing. Clayton: The retrospective is like a meeting, and you can never really leave it. But in your case, maybe you felt like your time is better used elsewhere, or you couldn’t rationally participate at that point. Roy: For me, I definitely felt like my time could better be used elsewhere. I was probably misusing the Checkout Protocol in that I was trying to use it to send a message that I didn’t feel I could send in any other way, which is, “This is a waste of my time, and I should do something else.” It wasn’t so much that there was something more important for me to do as much as it was a, “This is something that’s not important at all.” Clayton: I was wondering when using the Core Protocols, if you have a team that is familiar with them, and especially if they’re familiar with the Core Commitments, I think using them can be the super powerful tool. If you get a group of people or team that is only tangentially familiar with them, and doesn’t really know the Core Protocols, I wonder if it’s like playing with fire. Roy: Yeah, I definitely stepped on a few toes, and I did that. I think some people were probably rightfully offended or at least hurt by it. Clayton: Do you think you’ll see someone use the Checkout Protocol in the future? Roy: I don’t know. I hope so. I think I talked to Derek about it afterwards, and he was present at the retrospective as well. He feels like if you were to ask anybody at the time if they want to leave, they probably would have said yes, because I don’t think it was a secret that the retrospective didn’t feel like it was adding value. I don’t think I was the only one who had that impression. Promiscuous Pair Programming Clayton: Speaking of adding value, you guys have been working with a team that has been trying to adopt pair programming or promiscuous pairing, and doing a lot of pairing with different people on the team. I think that you guys are facing that common criticism of pair programming that, “If I’m an expert or I think of myself as an expert, I can’t pair with novices because they’re too slow. They slow me down. I’ll be so much faster on my own.” Is that an [inaudible 09:43] ? Have you guys been seeing something like that? Roy: Mm‑hmm. Creating a Cross-Functional Team Derek: Yeah, I think it’s a little bit odd. It’s not probably different than you’d see in any other organization, but one of the things that this particular team has a little bit of a challenge with right now is they got a really significant skills gap between some of the people on the team. They were not a cross‑functional team before. They are now a cross‑functional team, and that has created a significance skills gap in both knowledge and domain as well as technical skills. Early on, the senior developers, for a lack of a better term, really didn’t want to pair with some of the people that had a skills gap, because they felt that it was really slowing them down. At some point, during retrospectives, the folks that feel like they’re slowing people down admit that they are slowing people down, but they came to the conclusion, “If you don’t pair with us, how are we ever going to close the skills gap?” They came up with one of the retrospectives goals that the senior people were not allowed to touch the keyboard at all. Their mindset there is if they are not allowed to drive, they are forced to teach us. Of course, this frustrates the developers to go a whole sprint without being able to touch a keyboard. Roy: That would frustrate me. Different Skill Level Pairs Derek: The retaliation back was that, “We need to have those with the lowest level of skill, pair a fair amount of time together, so that we don’t have to pair with them, and slow it down.” Some of that comes with, I do believe there is a matrix out there, where if you say, two people of a high skill level pair together they will probably go really fast, but they will not probably learn a ton from each other. They’ll learn something, but not a lot. If you have two low level people, or low skill people, pair together, they will go really, really slow, but they will learn a ton, because they’re both so out of water. They have no choice but to totally lean on each other to get anything done. Any combination outside of that, whether that is two medium skilled people or high skill and a low skilled, you’re going to get some variation of somewhat fast and some learning. What happens if you’ve got a high skill and a low skill? You’re probably going to have a fair amount of knowledge transfer, but you’re going to slow down significantly. Teams really struggle with what’s the balance, and they seem to shift from one polar to the other polar, to where it’s like, “No senior developers can drive. We have to go really slow so that we think we’re learning.” Then, it switches the other way, “No senior people develop with low skill people so that they have to learn more, and we can go fast.” What we’re seeing them start to understand a little bit more is that when they’re actually more promiscuous and switch up, at least once a day that they get both met. They feel like they’re able to go faster when they are with one person, and they feel like they’re learning more when they’re with another person. We’re finding that balance is striking pretty well for them. Roy: One important thing about that though is that you’re talking about this matrix as being applied to the same body of work ‑‑ two low knowledge people working on the same thing that two high knowledge people would. What we’ve started to see is it’s really uncomfortable for two low knowledge people to work on something that’s difficult or something that, maybe, requires a little bit more knowledge, because of the fact that they don’t have anything. That is exactly what is required in order for them to gain that knowledge. What we’ve started to see happen is that when two people with low knowledge start pairing, they would shy away from the difficult stuff, and grab the low hanging fruit that they already knew how to do. We ended up with these two, it was one pair which was essentially, idealistically high performing, but not really gaining much knowledge, and they were doing all the difficult stuff. Then you have one pair that would catch one of the lower hanging fruit and cleaning up after everybody else, but not really learning. Now you had, essentially, two silos, where it was a silo with two people that keep to themselves who, maybe, were moving fast, but the two low knowledge people weren’t actually learning anything. Clayton: I feel like from what I see more and more is when I’ve paired with people that are very novice or entry‑level, I try to make it very clear about asking questions. I think most people are open to that. They ask me all kinds of questions that I feel like when they’re pairing with the people that are “senior developers”, they ask some question about, “Why do we do it this way?” A lot of times, the senior developer person doesn’t really know, but that’s just the way it’s done. If they were pairing with another senior developer person, they have both already determined that this is the way we do things and there is no reason to ask that question. A lot of people, “experts”, get frustrated because it’s like, “I want to try and get this work done, but now you’re making me think about every little nuance, or whatever, every detail in this code base that I really don’t know myself.” It’s just aggravating. I keep seeing that more and more. Derek: For those listening at home or at work or in the car, the moral of this story… Roy: Or on a plane. Derek: …or the plane, or boat… Clayton: Hot air balloon. Pairing Is About Learning Derek: …the moral of this story, in my opinion, is that one of the key drivers and benefits of pairing is learning. If you are not learning when you’re pairing, you’re probably pairing wrong. The rate of learning is going to be dependent, but, I would say, even if you’re an expert with a novice, when that novice asks those questions that you don’t know, that’s an opportunity for you to know that you need to learn the material better. When they say, “Why do we use this plug‑in, or why do we accentuate the class this way?” When your gut reaction is, “Well, that’s just how we do it around here,” and you don’t really know, that’s a learning moment for you, that maybe you’re not as expert as you think you are. Roy: It’s really difficult for a lot of senior people to say that, or to even admit not knowing something. Derek: It’s hard to admit you suck for sure. Clayton: [laughs] Someone gave me this title and I’m not giving it away. You have to pry it from my cold dead hands. That wraps it up for our Thanksgiving edition of the Agile Weekly Podcast. Make sure to check us out on Facebook at facebook.com/agileweekly. You can talk about this episode and others. You can “Like” the page and get us some reach so other people can find out about us. Derek: Gobble. Gobble. Gobble. Clayton: Thanks. Bye‑bye. Roy: Bye.

Jade Meskill: Hello, and welcome to another episode of the Agile Weekly Podcast. I’m Jade Meskill. Drew LeSueur: I’m Drew LeSueur. Derek Neighbors: I’m Derek Neighbors. Roy vandeWater: I’m Roy van de Water. Team Has Lost It’s Motivation Jade: Guys, I wanted to talk about a hypothetical situation where what if the team that you’re working in has lost its motivation? You find yourself in a coaching role, a mentoring role, and the people that you’re working with just seem to have lost all their energy, really not making any forward progress. What would you do if faced with that situation? Drew: I’m thinking maybe something, an activity, or something to spark the joy that they maybe once had in that. I don’t know what that would be, but try to get them to remember the joy that they had at one time. Derek: To me, I think it depends. Do I know what’s causing it? Is it that they’re just working a ton of hours? Is it that they’re only working on defects? Is it that they don’t understand the product and the market? Is it that nobody is adopting the product? Roy: They hate the people they’re working with? Drew: They hate their coach? What Are The Symptoms Or Causes Derek: What are some of the symptoms or potential causes? Jade: Let’s say that they’re working at a sustainable pace. Nobody is burning the midnight oil, or anything like that. They have a reasonable idea of where they’re supposed to be going, they just don’t seem to be real excited about going there. Derek: I think motivation is this kind of tricky thing, that you have to really buy into it. If they’re not motivated in going there, I’m assuming that it’s one of two reasons. Either that where they’re being asked to go really doesn’t have a lot of meaning, and they actually know that, and their way of actualizing that is by disengagement. The other possibility is that where they’re going is meaningful, but whoever is asking them to go there hasn’t done a good job of providing that meaning in enough detail to get them excited about the journey. I think if people aren’t excited about the direction that something is going, or where it’s going, the barrier that it creates for them to actually be engaged can become to the point where it’s significant enough you can’t overcome it. Some of that depends on the people. Some people are fairly excitable. It doesn’t take a whole lot to get them excited about going somewhere. Some people are real sticks‑in‑the‑mud and you really have to fight, maybe even on a daily basis, to keep them going in a direction. I would probably say, if that was the case, I would start with asking myself, “Does this team really have a compelling vision and reason for going where they’re going?” If the answer is “Yes,” start doing something to get them down the path of realizing the impact of the work they’re doing. Until I could do that, there is probably not a lot of tricks I could do that would last more than a week or so. I might be able to temporarily engage them in something, but the truth is, “Let’s work on this fun new thing for a little bit!” As soon as the fun‑ness wears off then we’re right back to where we started. I think it’s always got to be the root of, they’ve got to believe where they are going. Roy: Now is it my turn? Is that why you guys are staring at me? Derek: [laughs] I don’t know. Roy: I don’t know. I don’t have any opinions, not in this case. All Out Of Tricks Jade: [laughs] That’s a lie! Let’s imagine that we’ve tried a few of the things to boost the energy, and like Derek said, it’s had a short‑term positive effect but its kind of worn down and now we’re out of tricks. This team still says that they still want to go in the direction that they’re heading, at least that’s what they say on the surface. Is it OK to have a season where you’re not making a whole lot of progress? Season Of No Motivation Derek: I would say that if the team was not making forward momentum, the answer is “No,” but I think it’s OK to say, maybe for this particular thing, “Hey, if we’re not making progress in this, we’re not moving forward with this particular thing, and none of us can be energized to get behind it, maybe we say, ‘For right now, yeah, we believe that’s a good direction to be going in, something that’s worth doing.’ “But if we can’t find the motivation to do it maybe we need to move into, ‘What does motivate us? Where is somewhere we want to go?’ Maybe we go through that until we get out of whatever that funk is.” Meaning, sometimes maybe you need a distraction. Maybe it’s a week, maybe it’s a day, maybe it’s a month, to basically be re‑energized back to level set. Jade: Do you run the risk of chasing the new shiny? Giving Up When It Gets Hard Derek: Yeah, I think that most teams, that’s their problem. that they don’t really understand where and why they’re going somewhere. They think they do, but they don’t actually know, so when the rubber hits the road, and you get to what I’d call “The grind,” or “The hard part,” or “The Dip,” as Seth Godin would say, I think it becomes like, “This isn’t so great. It’s not so shiny, it’s not so fun. I know I really want it, but I don’t really want it bad enough to push forward.” I think that, at that point, you either have to decide, “Hey, am I going to go a different direction?” but you run the risk of, do you constantly just run the other direction when you hit the dip? Or do you say, “I’m going to have to push through. I’m going to have to do that.” I think sometimes, to me I think maybe that’s where a coach…Maybe that’s where external factor, maybe it’s a jerk on the team, somebody who pushes that issue and says, “One or the other, go.” I can talk a little bit from an analogy perspective. I’ve got a daughter that plays pretty high‑level competitive soccer, and I think she lost, I won’t say “Her interest.” I think if I asked her, “Yeah, I still want to play in the US women’s national team, but you know what? It’s a lot of work. “I’m spending four hours a night, four nights a week doing this, playing on the weekends. I’m getting screamed at, and it’s emotionally difficult, and everything else.” I told her, “Why don’t you just quit? Why don’t you take a break for a while, you just play high school soccer, and don’t do that?” She was like, “No, I really don’t want to.” I’m like, “Well, you know you’re not performing, you’re not having this.” She got a new coach, and this particular coach is a role model for her, played on the US women’s national team. Can speak her language, and was really hard on her, and pulled her aside and said, “Look, if you really, truly, want this, what you’re currently putting in, you will never get there.”” “You’re telling me you want this. I’m going to sit you on the bench, and I will not play you until you show me that that’s what you really want.” It took her about two weeks of a lot of weeping and gnashing of teeth, and now she is more committed than ever. I think sometimes you have to look into the the fire and say, “Is this what I really want? If it is, how do I dig into that deeper level to get there?” The problem is that that’s deeply personal. It’s very difficult to do that at a team level. Avoiding Our Issues Jade: But is that part of the problem of a team who’s lost their motivation? That at a personal level, they haven’t dealt with those things? Especially if many of the people on the team are in that same situation, it’s a lot easier to just avoid it and focus on some of the surface level things that are going on. Instead of really, really digging down and saying, “OK, is this really what I want? Am I willing to cry about this, and get really upset, and finally work my way through it at a personal level, and now I can deal with it at a team level”? Making The Sacrifice, Delayed Gratification Derek: I think a lot of it too is, usually what I see happening in those aspects are there’s some level of sacrifice involved. In my daughter’s case, “I can’t spend a night in anybody’s house on Friday and Saturday, because I’ve got games all weekend. I get no sleep, because by the time I get home from soccer practice it’s eight or nine o’clock at night. By the time I eat and I do my homework, it’s 11 o’clock at night, and I have to be back up at 5 o’clock in the morning. All of these things are like, “Look, I’m missing all this other stuff, and so every day, it’s a decision, ‘Do I do this or do I do that?’ and the ‘This’ isn’t immediate. Spending the night with my friends is immediate satisfaction, and I had a great time spending that with my friends. Training and going to the game does not have immediate satisfaction. “Whether I win that game or I lose that game, I’m not going to try out for the women’s national team for four more years. I have to learn how to delay my gratification on what I’m putting a sacrifice for, for a significant amount of time.” I think as individuals and especially teams, that’s usually where it’s at. It’s like, “I have to make this decision of, ‘Do I piss this person off?’, or, ‘Do I miss out on this thing?’, or ‘Do I do this right now, today?’ for something that I don’t even know if it’s actually attainable. I don’t even know if I can actually get there.” I think that yeah, that’s deeply personal stuff. Then I think it cascades and complicates, because you can’t do any of those things by yourself. In my daughter’s case, it’s pretty much on her, probably, to be able to make the national team or not. But if you’re talking a company, you’re talking a team, or you’re talking a product, one person can’t deliver a product. One person can’t deliver whatever. Now you’re lying faith in other people to push through whatever they’re going through as well. How To Get Out Of A Motivation Crisis Jade: What could we recommend for a team that’s maybe facing this crisis of faith in wherever it is that they’re heading? What is it that we could encourage them to try to do to work through a lot of the personal issues before they can even bring it to the team? They’ll probably have to rework through the forming, storming, norming again after you’ve dealt with this internal issue. Derek: Just chase the new shiny. It’s a lot easier than when you go to work. Jade: [laughs] Derek: It’s more fun too. On a personal level, I think each person on a team has to take assessment of where they’re at, where they want to be. Do they really want to go whatever direction the team is looking to do with their product or whatnot, and say, “Is this something I can get in alignment on?” If the answer is “Yes”, then I think that they have to look back to everybody else on the team that is in the same boat and then say, “How do we help each other get there? How do we hold ourselves to be accountable?” I see this a lot of times. I like my sports analogies. You see this a lot of times on teams too. One of the premier teams that I coached for a long time, they really had this whole concept of “Be excellent.” What they would do is they would really hold each other to that standard. If somebody passed somebody a ball that wasn’t a great ball, they would say, “I demand excellence.” It wasn’t a rude thing, it was, “We’re all going to remind each other that if we really want to win a state championship, we’re only as good as our weakest pass. “It only takes one failure in defense to give up a goal. It only takes missing one shot to not score a goal. In this sport it’s a difference of one goal when you’re at that level, so we have to demand that of each other.” It’s making that internal commitment to each other. To say, “If we’re all making the personal commitment to this, now we need to make the team commitment to that same thing, whatever that level is.” Not only so you have accountability, but so that you have the ability to help each other to that level. Shared Alignment And Commitment Jade: If you’re not in alignment on those things, it’s going to be very difficult to do that. If a few people on the team are pushing in that direction, I think it’s going to be very abrasive to the rest of the people who aren’t on board with that. What happens if people don’t want to get on board or go through that trial? Derek: If nobody on the team wants to do that, then obviously the team needs to find what they do want, something that aligns to their personal piece. If you’ve got part of a team does, part of a team doesn’t, do you split into two teams? If it’s one or two people, does it make sense? I’ve seen this happen. Going back to the sports analogies, LeBron James would be a great example of this. “Cleveland Cavaliers, we’re not going to win a national championship. I want a national championship. I’m willing to take less money to go somewhere where I can win a national championship, because for me, that’s what’s the most important thing. “Being the superstar, or the highest paid or whatever, that’s not what I’m looking for. I’m looking for a ring, because that’s what I’m getting criticized for. That’s what I’m interested in, and I make that move.” That’s not saying that necessarily the other people on the Cavaliers didn’t want it, but their general office wasn’t willing… Jade: They weren’t willing to leave to do it? Getting Real Derek: Their general management wasn’t willing to spend the money to get the other supporting cast members to do it. I think that that’s part of it too, when you’re dealing with skills gaps or other things. Sometimes you have to say, “If we really want to get to here, we’re trying to achieve this, you have to be realistic.” What does that mean for each person on the team? What do they have to do to be able to help the team get there? At that point they might say, “I’m not good enough to be on this team. I need to be on another team and make do with that, or I need to step up my game, or I need to get a personal trainer.” Whatever that thing is. I want to be on a team that travels more. That’s what’s important to me. I don’t care if we win games. Maybe I’m just trying to get recruited for college, so I want to be on a team. I don’t care if they’re any good or not, from that standpoint. I don’t care if they win a state championship, I just want to be seen by college coaches. Whatever your goal is, if you don’t have personal alignment it’s impossible to be on a team that has team alignment. You Have To Know What You Want Jade: That’s the re‑occurring theme that I keep hearing through this whole discussion. If you don’t know what you want, it’s going to be impossible to work together as a collective to get what you want. You out there in listener land, if you’ve been through some of a similar journey please share with us on our Facebook page. We’d love to hear some of the experiences that you have, or techniques you used to work through an issue like this. Thanks for listening to the podcast. We’ll catch you next time.

Drew LeSueur: Hi! Welcome to another episode of the “Agile Weekly Podcast.” I’m Drew LeSueur. Roy vandeWater: I’m Roy vandeWater. Clayton Lengel‑Zigich: And I’m Clayton Lengel‑Zigich. Class Systems Within Organizations Drew: Today, we want to talk about Class Systems within Organizations. Clayton: Do you mean like Java classes? Roy: Yes. Clayton: Jars? Drew: Jars, class hierarchies, entity inheritance. What have you guys seen? How do class systems within organizations affect…? Roy: You mean classer developers, like second class citizens? Drew: Yes, like first class citizens and second class citizens, and it’s, “Oh, I’m better than you,” “Oh, they’re way better than me.” The Class Hierarchy Clayton: I think the most obvious one is usually the division between developers and QA. Roy: Developers and senior developers? Clayton: Yes, that’s another good one, too. Roy: Developers and architects? Clayton: Yes. I guess the hierarchy is usually architect, and then senior developer, and then regular developer, and then maybe junior developer, if they have that, then the QA people. Roy: Then manual regression. Clayton: Manual regression people. Yes, you are paid to click a mouse and smash on a keyboard thing. More Authority Drew: Have you seen it where the people who are maybe higher‑up looked down upon the people who are supposedly lower? Roy: There you have it. That’s how being higher up works. Clayton: Yes. I think that’s just inherent in the definition. When you get promoted to be senior developer, or whatever, can you have that job title? Then that somehow means that you have more authority, or better you have more experience. Roy: And a higher paycheck? Clayton: Meaning more pay, more benefits. Roy: It’s probably even at an expectation that you treat the people that are below you with at least a certain amount of disrespect, in order to make your position more substantial, and in order to fit in with other people that are at the same level as you. Manager Models and Creates the Culture Clayton: Other part, it depends on the on the manager. I don’t know anyone who would explicitly say that, but I could certainly see there’s management styles that are very hierarchical like that, that would really reinforce that thing. I could see a manager saying to someone like, “Hey, man, you’re a senior developer now. You can’t do XYZ, or whatever.” Roy: You can’t be hanging out with those lowly developer types. If they see you talking to those QA people, nobody’s going to take you seriously in this business. Clayton: I could see something like that. Do Classes Disempower People Drew: I really like the word “empower.” People should be empowered to do great things. If you have this system setup, it seems like it forwards that empowering of the people. What are some ways that you can go against that, this class system? Clayton: One thing that I think that you’re saying is that if you look at some people that are talking about agile stuff these days, they don’t like the word empower. They get like, maybe this is like second level thinking kind of stuff, super nuanced. But I think the gist of it is if you say that you’re going to empower people, it’s like you’re acknowledging that you work in a hierarchical structure, and so then people have to be empowered to do something. I think that one way you can kind of get away from some of the hierarchical stuff is like self‑organized teams that are cross functional, like some of the scrambling prescribe. Actions Speak Louder Than Words Roy: I think it’s easiest to come back from the higher up you are. If you are, let’s say, a senior level developer or an architect, and you have your own corner office, and perhaps your secretary and whatever it is that you got, because you got your fancy‑pants promotion. If you want to make a difference on the team, and you value the idea of everybody being equals, and being able to contribute equally into a project, then the best thing you can do is to give that up, and say, “OK, I’m just like you guys. I’m going to give these things up. I’m going to make my office available as a breakout room. My secretary if I have one can go work for somebody else.” You showed that you really mean it with your own actions. Drew: But you still make twice as much as they do. Roy: Come on. [laughter] Clayton: Like Robin Hood and [inaudible 04:03] . Roy: I don’t know, I think that’s a really good question. In an ideal world, it should. Promoting Based on Length of Service Clayton: I don’t think there’s anything wrong with people in organizations, necessarily, being compensated differently. There’s a whole bunch of factors that go into that. But one thing that I’ve seen a lot is people will get a senior developer title, because they worked at the same place for a really long time. Roy: That’s what you need to be a senior. You only have to turn 65, and then you get a discount. Clayton: I think it’s funny, though, because I can see that someone might say, “Hey, I’ve worked at three different companies in my career, and three totally different industries, and three different sized companies, and so I have a bunch of experience using a whole bunch of different things, in different teams, and all this other stuff.” Let’s say that it was over a fifteen‑year period. But if I worked for the same company for 15 years, doing the same job, every single day, am I really a senior developer, because I’ve just been there for a long time? That seems kind of silly. But that’s how most people are considered senior developers. Value Experience Over Loyalty Roy: In that context, senior implies loyalty more than it implies experience. Clayton: Yeah, I would think that’s probably a fair way to put that. Roy: There’s still something to be said about rewarding that type of loyalty. Clayton: Sure, but I think the one thing that always gets missed, though, that reinforces the class system stuff is you might have someone on the team that excels as a developer, and then they get this job as a senior developer. Then they get treated differently in the sense of, “You used to have to work on this crappy part of the system that no one really likes, and you used to just have to do the boring work. But now that you’re a senior developer, and you know all this stuff we’re going to let you go prototype this new thing that’s in a new cool technology, and you get to do new cool stuff.” I rarely see where the expectation of a senior developer is that they make the people that are below them better. I think everyone thinks “I am a total rock star,” “JAVA ninja,” “I’m so bad‑ass,” but then they can’t make the people that are the junior developers better. Roy: Just to clarify, I think I speak for all of us in that the idea of having different classes of developers on the team is a bad idea. Having everybody act as an entire team where there are certain people on the team who may have some weaknesses, and some people that have certain strengths, and the team values to bring out the strengths in everybody, and try to help each other better our weaknesses, and that that’s an idea situation. Clayton: I think if you think about it from a tribal aspect ‑‑ if I’m a member of the tribe, and I’m the one who’s trying new ways, new fishing techniques. I’m the one who gives you some of my food because your crops died, and I do all of those things, I’m going to gain your influence and you’re going to view me as a leader versus the chief just coming down and saying he’s the senior tribesman. That’s a totally different thing. Teams can be the same way. You have these cross‑functional teams, where everyone can do everything and there is no real distinction in the job title perspective. Some people are going to rise to the top, because they do certain things that the team buys into, and people on the team will follow them. Classes Can Become Self-Sustaining Roy: One of the huge problems I have with this type of class system, where there are multiple levels is that oftentimes it’s self‑sustaining in that the people that are at the bottom class are treated like crap, and given shitty assignments. They are given crappy, hard work and that type of thing. It’s almost like it’s really hard to overcome the handicaps forced down on you by the upper class developers. “We’re going have riots with the 99 percent…” [laughter] Roy: “…complaining about the one percent…” [crosstalk] Clayton: I think that’s totally fair. It’s a culture thing. If the organizational culture is that there are different levels of people, and if it just so happens ‑‑ which is probably the majority of the time ‑‑ that the different levels of people are picked improperly or poorly. Everything that happens to the people on the bottom of the totem pole reinforces the fact that they’re on the bottom of the totem pole, and every day you remind them they’re on the bottom of the totem pole. That’s where they’re going to be. You’re never giving them a pathway or any means to move up. They’re just going to leave. Roy: Even if the expectation is if you work here long enough, that’s how you move up, I think even that is a bad idea. Even the idea of a meritocracy where if you do really well you move up is kind of a bad idea, because it should be the entire team that’s moving themselves up. If it’s a meritocracy where my success is causing me to go up, that incentivizes me to sabotage everyone else on my level to make myself look better. Clayton: If you don’t buy into team‑based work, and you don’t buy into the value you get out of team‑based work, it becomes pretty obvious. People are very smart about cheating the system, knowing who they have to influence or be influenced by… Roy: Or sleep with. Clayton: …In extreme cases, I suppose, to move up in the organization. I still think it all goes back to a culture thing. I think if you take the traditional software development organization, where you’ve got developers who are treated in some degree badly, but they are treated better than QA people, because they just lob their code over the wall and the QA people have to test it. Roy: Is it that shit flows downhill syndrome a little bit too? I got crapped on by the senior developer so I’m going to take it out on the QA people? Immoral To Not Give People Opportunity For Growth Clayton: I think there’s something like that, too. I always remember that talk that Uncle Bob Martin gives about testing. He talks about how it’s basically immoral to have people do manual testing. The idea that someone would have a big binder and they go to some page in the application and they look at the binder and it says, “Step one ‑‑ enter x, y, z, colon, bracket, space and then click this button, then click this button. You do fourteen steps and then hit enter. Verify that the screen says this.” How does any organization think that’s OK? Roy: It’s totally demeaning to the people that work in those positions, too, especially if they are more qualified. Clayton: The people never give a pathway to become better. Roy: I’ve actually heard of organizations where they’re like, “Oh, we can’t have those people do that. They’re just testers. There’s no way they could ever be developers.” Clayton: Exactly. I think there’s a bunch of testers who probably think, “I’m not interested in being a programmer. I don’t want to learn engineering stuff. That’s not what I’m interested in.” There’s still a bunch of things that, if you take more of a test automation approach, there’s a lot of things that you could have a testing background or a testing mindset, and still contribute just as equally to the overall value of what’s being built. Roy: Those types of people could be invaluable in a planning meeting, and would be a very good compliment to a regular developer in a pairing environment. You would start to see the lines blur between the two, because I think, as with anything, the QA people that don’t like to learn coding is probably because it’s uncomfortable and new to them. Clayton: That’s true. To give an example I was giving a presentation at this QA conference, this local QA conference recently, and I was describing some scenario. One of the people in the room had talked about how they could have avoided this big problem that they had if they had done better planning. I asked them if they foresaw that before the event. They basically said, “Yeah, I saw that this was going to be a problem.” I asked them, “Why didn’t you say something?” The idea that the tester ‑‑ or the QA person ‑‑ would interject in planning and contradict the developer, or tell them that they were wrong was so unheard of that she looked at me like I was from outer space. “That’s just crazy. How could you even suggest that?” Roy: “You can’t do that. Those are developers. I want to be one of those one day.” Clayton: You have that scenario in your organization. Look at all the stuff you’re going to miss out on. All the resentment you create and all these other horrible things. Developers Are Not Special Snowflakes Drew: I’m thinking, sometimes you get these cowboy coders. It’s easy if you’re a good developer to have the mentality, “The work I do is so special. Nobody can do it. I am actually super gifted, super talented that I’ve been able to figure all this stuff out, and these people can’t learn it, or if they try they’ll screw it up.” I think that’s a very dangerous attitude to have. It helps reinforce the classes that you could have. The truth is anybody can do this stuff. Anybody who wants to, has a desire, they can do that. If the team adopts that mentality, I like that movie Ratatouille, “Anyone can cook.” It’s the same idea. Anyone can be a developer or can be whatever the job is. That mentality should be reinforced, so that we’re in the attitude of helping each other out. Get better as opposed to isolating ourselves, saying we’re the best. Roy: In that vein of, “Anybody can do it,” I totally agree in that anybody can be a developer as long as our heart is in it. I think we have worked with people where we see the potential, but they aren’t capable of reaching because they don’t want to work for it. Likewise, we have seen people that don’t know anything but were able to jump in it no problem, because they have the desire to learn. Which is why I think it is so important to hire for that quality over any technical experience. Becoming A Learning Organization Clayton: I think that gets into learning organizations. Rather than being, “Oh, we’re going to strive to be agile,” or whatever that means, strive to be a learning organization where you have that. You don’t have the fixed mindset of some people are good at this, and some people can never be good at this. Roy: You brought the concept of cowboy coders are like rock stars. I agree that’s a dangerous thing. There’s times when organizations revere that type of behavior. That’s highly encouraged. You even see that amongst the major organizations like Microsoft and Google, where they’re rock stars. They love the idea of having rock star developers. Clayton: I think that’s a tortoise and a hare kind of thing. A lot of times when the rock star people or the cowboy coders go off, especially when they do the hero coding thing at night, they will deliver some super sexy looking that’s so awesome. In that moment it seems like the best thing ever. No one takes the time to take a step back, and look at all the things that happened coming up to that. No one ever keeps that in their mind going forward, to think about what is the impact of this thing over time. Three months later, when there’s some bug that comes in, and the team can’t fix it because the super hero coder has pulled another all‑nighter and hasn’t come in, is not going to come in until 11:30, and there’s no one there to fix it. No one ever connects those two dots and says, “Hey, gee. We wouldn’t have this problem if the team had worked on it.” Maybe the team wouldn’t have been so sexy, but at least we wouldn’t be in this bind. Everyone just gets mad like, “You stupid non‑rock stars. Why can’t you fix this thing?” Roy: They’re like, “Look at this rock star. He was working until 3:00 in the morning. That’s why he’s not here until 11:00. Why aren’t you guys working until 3:00 in the morning?” Clayton: Very management 1.5 or 1.0. Roy: 1.23. Clayton: We were talking about Seinfeld earlier, it’s like George Costanza gets lock out of his car and his boss thinks he’s there before everyone, and he doesn’t leave until after everyone. If you can just trick your crappy development manager into thinking that you really work super hard then… Roy: Working hard is related to how many hours you put in. Clayton: Working hard outside the team makes you great. I think you can play the hierarchy system. You can gain that system. Drew: Thanks for joining us. To join in on the conversation please visit facebook.com/agileweekly. Thank you. Clayton: Thanks. Roy: Bye bye.