Drew LeSueur: Hi and welcome to another episode of the Agile Weekly podcast. I’m Drew LeSueur and with me today we have Jeff Patton. Jeff tell us a little bit about yourself and what you do. Where Did All Start Jeff Patton: Where do I start? I’ve been in Agile development since starting with Extreme Programming in 2000 and later in 2001 finding that was Agile. For the previous ten years I had been in software development in a huge variety of roles, but eventually ended up in product management. After 2000, I stayed in product management, then I worked as a product manager, and then as a consultant with a company called Thoughtworks. These days I’m independent. My focus is on software product companies, people that make software for commercial sale, although I still work with some companies that do IT. I like the challenge of working with companies where, if they make a product and it sucks, they’re in trouble. For better or worse, in an IT world, sometimes you can get away with making a product that people don’t like very much, because they have to use it. That’s a mouthful! Four Steps of Design Thinking Drew: No, it’s great! I watched a video of yours talking about design thinking, kind of labeled “Four Steps of Design Thinking.” Could you explain a little bit about that, just a rough overview, and how you incorporate that into your work? Working with companies that make software products. Jeff: Yes. Good question. The design thinking thing has become fashionable. You can go to amazon.com, type in design thinking and find a great number of books about it. It’s become popular at an executive level in a lot of larger organizations. The tenet of design thinking is, you start by understanding the problem you’re solving. You’ve got to do enough research or gather enough information about the problem before you stop and say, “This is a good idea,” or “This is a solution we should build.” In an Agile context, for instance, we build product back‑logs, but product back‑logs are filled with solutions and not problems. You know, in theory, if we were writing user stories. We’ll talk about who they’re for and why they want to use the stories. But, design thinking will ask you to go farther back. Stories contain solutions, most of the time. The next step in the design thinking process is an ideation step. When I’m teaching people design thinking, I’ll ask them, “Tell me about a typical meeting when someone comes in with a problem.” They’ll say, “Well, then somebody will propose a solution.” Then, I’ll ask, “Then, what happens?” People will usually say, “Well, then we start discussing that solution.” People usually joke and say, “Then we start tearing it down and then somebody will suggest something else or we’ll adjust the solution.” That’s exactly not ideation. If we were doing ideation, our goal is to come up with tons of solution, a great many solutions, and not stop and evaluate any of them before we’ve come up with a dozen or so. Does that make sense? Ideation vs Iteration Drew: Yeah, it does. When I watched your video, I wrote down the steps and you, to me, hit the first two at least. If you have a problem, you “ideate” ‑‑ is the verb you used, which I thought that was kind of a cool verb ‑‑ come up with a bunch of ideas and then, you had a step in there that’s “iterate”. Jeff: Iterate is a troublesome word. Drew: Right. Jeff: In Agile development, I started with extreme programming. These days, I teach Scrum because that’s the role that most person using Scrum as a starting part and Scrum uses the term “sprint”, but in extreme programming, they use the term “iteration”. Drew: I really like that word “iteration”, too, as far as software development goes. Jeff: But, iteration can mean repeat the same process over and over. But, when you’re talking about a product, a thing, iteration means, well, it means the same thing as rework. It means I build something and I look at it and say, “Well, that’s not very good.” I change it or I improve it. If you’re doing the design thinking thing. You ideate to come up with a lot of possible ideas and then, you have to start combining and refining. You start to take your best ideas and put them together. The only way you can tell if they’re actually good ideas is to prototype them or put them in a little bit higher fidelity and get them in front of people that might use them. They evaluate them and they say, “Well, no. Not quite.” Then, you make changes. That’s iteration. In a lot of companies, that’s rework. That’s not getting the requirements right, or all sorts of derogatory terms. But that’s iteration. And if you’re doing design thinking you want to iterate as fast as possible, so we’ll often iterate with simple prototypes. Drew, I steered you towards a client I’m really proud to work with and that’s the Nordstrom Innovation Lab. They’ve got a video on YouTube that’s worth watching. And one of the practices we’ve been putting in place is a lot more ideation and a lot more iteration, but oftentimes we’re working with solutions which are a combination of software and other things and they involve multiple people. So the way we’ve been iterating recently is by bodystorming. It’s kind of like using improvisational theater. We have to act out the way the solution goes, and you’d be surprised when you act out a whole buying process for someone in a retail store how you watch it and go “Oh, no it wouldn’t happen that way,” or “That looks kludgy,” or “That doesn’t work,” you don’t have to build any software to iterate. Drew: So you’re talking about acting out not only, I saw a video where on part of your video you had people with cut‑out pieces of paper and you would have people implement a website on cut‑out pieces of paper. And they’d have a user touch different pieces of paper, and the person behind who was controlling the thing would show different screens which were all implemented drawn on pieces of paper and to have a prototype of what the website might look like. What you’re talking about here, kind of going beyond that, and have people implementing a whole buying process or something, without actually implementing it, just acting it out. Jeff: That’s right. I’m trying to figure out what I can tell about you that I’m not under, that the non‑disclosure for, but oftentimes we’re looking at a buying experience where people in retail stores, they’re looking at things, they’re checking information on a mobile phone, they’re texting information to someone and they’re getting responses back. We’ll act out that whole experience with people pulling out mobile phones and pretending to type something in the phone and pretending to get the right information back. We haven’t implemented anything, there’s nothing on the phone. It’s just that by doing that we realize “Oh my gosh, I’m gonna need this information,” or, “The time it would take to get that is far longer than I wanna wait, so that’s not gonna work,” you know, things like that. Create A Plan Drew: And the last step that I saw on your video was of this design thinking kind of process is “create‑a‑plan,” so you identify the problem, you ideate, you iterate on that with prototypes, or whatever, and then you create a plan. Now, as far as where I come from with Scrum and Agile is there’s a big focus on the shippable product, or potentially shippable product, or releasing early, releasing often. How does this design thinking, this process of figuring out what the problem is first, how does that fit into that and how long should it last? Jeff: Good questions. Well first off on the plan part, so what I mean by plan and I would’ve talked through is in theory if we’re talking about Scrum process, the plan is a backlog, and I create a backlog. But, a good plan is a plan to learn. Drew, you’ve probably come across, the big buzz in the world today is the lean startup thinking, that you’ve come across? And a core tenet of this lean startup stuff is validated learning. They redefine the term MVP as ‘minimal viable product.’ The term MVP used to mean, and it still does mean, a product that is viable on the marketplace. A lean startup will say “Let’s not worry about viable in the marketplace, the first thing we have to do is prove that there is a market for what it is we’re trying to build.” So an MVP in lean startup terms is the smallest possible experiment. So a plan, at the end of a design thinking process might be a series of smallest possible experiments. In fact those smallest possible experiments might actually be part of iteration and the so your question there is “How long does it take to do this design thinking stuff”? I will refer to this as a discovery phase and this is the stuff that in Scrum would have called the sprint zero phase and how long that takes. I’m finding more and more that the design thinking part if we can join the design thinking part which is a core tenant of lean startup thinking. With Agile delivery mechanisms and if we talk about the iteration part as a validated learning phase so we don’t just build paper prototypes or do bodystorming like I was talking about where we mature that and actually build something working but it’s not potentially shippable. It’s not the code we want to keep it’s the code we built to learn something from then it starts to overlap with delivery and what I see in working with people like Nordstrom they will go all the way from the design thinking to implementing something they can learn from inside of five days, inside of a week, much faster than anybody’s typical sprint. And when I am talking with people about a discovery phase I’ll generally say a block off two weeks of discovery to drive two to three months worth of development for a smallish team of five to seven people. Drew: OK. And I’m curious, too. Part of my passion is, I love releasing software, I love being on teams that release software. With design thinking a lot of times we will release the wrong software, right? My understanding is with this process or with this in mind you will be able to focus on releasing the right software. When you are iterating on these ideas, is it always in house that you release them to or have you worked with companies or in your experience, do you iterate on these ideas and release them to other people, like beta users or alpha users or whatever? Jeff: Well, Yes, beta and alpha users. But like I mentioned I work with product companies and they are not willing to risk releasing something that won’t be successful to a large body of consumers. At least most of them aren’t. What they will do is a lot of split testing or AB testing. If you have heard that term, defining something that is a smaller experiment or a different way of doing things and releasing that to a subset of your audience and lately a subset of your audience for a limited amount of time. I have one group that I am working with that will come up with something that is a small experiment and release it to a small group of people for three hours on a Sunday and then measure the results and then use that to make a determination about where to go next, whether to iterate it, adjust it or go big. Drew: That sounds great. Jeff: You know, like you, design thing is just part of it and like you, what drives me, what I’m passionate about isn’t any of the building of the stuff but what happens after. I like, the pride I take in any of this stuff is knowing that there are people out there using products I built 10‑15 years ago now and they are still in use everyday. It’s about making things, and it’s about getting things out there so design thinking is just a step in a bigger thing. Drew: That’s a great perspective too. I share that. It’s so awesome when you are creating something that it actually gets used and adds value to people, they benefit from it and that’s one thing that you mentioned too we want to minimize the output but maximize the outcome. Jeff: Yeah. Drew: I think that’s a good way to look at it. Outcomes vs Output Jeff: That language comes from a lot of different places. The problem with outcome is you can’t measure it until after it comes out. So the outcome is what happens after you ship your product and for better or worse Agile development doesn’t talk very much about that. You don’t see it in a burn down chart whenever I go, whenever I read anything on Agile metrics, none of them are about outcomes they are all about output. How fast we’re building stuff or how good the quality of this stuff is but not how well it does in the world. Drew: That’s a great perspective. So we are about out of time. Do you have anything that you would like to promote or share with the listeners? Jeff: For the people out there that might know me they will have looked me up on the web you will find a stale old website that I haven’t updated and I won’t explain that. If you look me up at amazon.com you might find a couple book titles which aren’t coming out but I get known for a practice called story mapping and I promise there will be a story mapping book out before the end of the year. I’ve just launched a new company with a colleague of mine, Aaron Sanders, called Comakers. I’m going to take 30 seconds but there are the terms co‑making, and co‑creation and we are sort of championed the idea that the model we use a lot for software development is broken. When things work best there isn’t a client and a vendor. When things work best there is someone that has problems and someone that can build them and the person making things needs to go take several steps in to understand the problems and the person that has problems needs to take several steps towards the maker and understand what’s involved there. We’re shooting for co‑responsibility so sometimes being honest, I have a problem with the standard Scrum processes or Agile processes where I have got a product owner and a team. Yeah I guess someone needs to decide but I really want all of us to be responsible for those outcomes. I am promoting my company I guess but to me the concept is more important. It is that comaking concept. Drew: Great! Thanks a lot. We really appreciate your perspectives and for the listeners if you would like to join in on the conversation reach us at Agileweekly.com or at facebook.com/agileweekly. Thanks a lot Jeff . Jeff: Thank you, Drew.

Drew LeSueur: Hi and welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur, and with me is Alex Sloley, who works for a company called Deloitte. Alex, what kind of work do you do for Deloitte? Deloitte Digital Alex Sloley: Deloitte is a global company. I work in the consulting functional area for Deloitte. I’m in a service line called Deloitte Digital. We’re a brand new service line. I am a senior engagement manager. On a tactical basis, effectively, I’m a scrum master or an agile coach here within this service line. Drew:: Is that what it means by senior engagement manager is scrum master or agile coach, or is it more to it? Alex: Yeah, senior engagement manager, also for consulting company. We deal with external clients, so from the senior engagement manager side, managing the relationships with the clients, but internally and tactically, I’m running multiple Scrum teams for the clients as we work on their projects. Drew:: You’re helping your clients implement Scrum, and run Scrum, and you have been coaching them through that. Alex: Actually, we develop mobile applications and mobile optimized web sites. We’re building internal product here using Scrum, and delivering it for our clients. Favorite Flavor Of Agile Drew:: A lot of people have different takes on Agile and what it means to them. How is your flavor of Agile different from what you might read in a book? Alex: I think I came from a product of Scrum background personally before I came to Deloitte Digital. I think the big difference here is that you’re working in a consulting model. There are several key differences between what I would call traditional Scrum, and the Scrum we execute here. The biggest being that the product owner is typically not co‑located with the team. For example, if we’re working with Alaska Airlines on an iPhone application, the product owner is on the client side, but is located at Alaska Airlines corporate headquarters and not with the team here. We work out of Seattle at Remind Studios. The development team is all here at Remind Studio. Part owners remotely located next ‑‑ that’s the biggest difference. The other big difference I see in the consulting world of Scrum is that there’s some level of upfront estimation that needs to be done on a project for contractual reasons, so that you can provide a general level of effort, estimate to the client and in general, how much the project is going to cost in the long term. Upfront Estimates And Sprint Zero Drew:: You’re confronted with having to provide kind of a little more hardened estimates than, maybe, traditionally people in Agile projects do. In my mindset, you try to focus on the iteration, every sprint having a potentially deliverable product. The plans in the future are fairly fuzzy, and you kind of focus on the iterate of development. Because of the contracts you have to do, you’re not able to do that as much. How have you handled that? Has it been very hard or how do you do that? Alex: I definitely think it is a challenge. In general, I think it leads to certain practices here that we need to do to fulfill those contractual requirements. Number one, I think we probably do more road‑mapping than is usual, because we’re trying to forecast ahead of time. The other thing I would say slightly different is that we try to get a general feel of the entire backlog in a Sprint Zero. Sprint Zero is critical here in the consulting world, because we have to get a general overview of the entire backlog, a general estimate of total story points, so we can come up with a long‑term vision of how long the project is going to take at a standard velocity. We also have to phrase our contracts in such a way that it’s clear to the client that this is ongoing work. I think because we’re in the consulting world, we do have to do more evangelizing, and socializing, and educating of Scrum and Agile methodologies to the client. Drew:: A lot of times, when I try to estimate things in big projects early on, I fall short a lot or it just turns out way different than what you imagined. In your practice, is there a negotiation phase where it looks like we’re not going to make it? Or maybe the product owner says, “You know what? I kind of want to shift paths on this, which will kind of invalidate some of this other stuff.” Do you do that much, or not much? Alex: The thing is, because we’re in the mobile application world, the actual life‑cycles, the products themselves, are extremely rapid. We can produce a mobile application for a client in three to four months. Drew:: You’re still on a short time span in general. One Week Iterations Alex: Yeah. I prefer to run one‑week iterations at this point. Some teams still run two‑week iterations, but we’re moving pretty much, as a service‑line, towards one‑week iterations exclusively. That means changes are extremely rapid. But we don’t have the kind of impact from a dependency that would affect an 18 month long project. Since the scope is really refined, and somewhat narrow, I think it makes it a little easier to do that upfront estimation. But I think we do place a lot of emphasis on sprint zero, simply because working with a client is much different than working on an internal product for say, an enterprise company. Remote Product Owner Drew:: When you talk about the product owner not being close with the team as far as proximity, do you still get daily stand‑ups? Do you still get those sprint reviews and demonstrations, that kind of thing? Alex: I think that’s one of our efforts when we go into that sprint zero with the client, is we have to set these expectations. “Hey, look, you’re signing up to provide a product owner.” We clearly lay out what the product owner role entails, how much time and work is involved. Yes, on a project I expect the client, product owner, to be available for all stand‑ups, plannings, reviews, retrospectives, meetings on architecture, anything that you would expect from our PO in a co‑located team. Commitment Driven Planning Drew:: Now I also saw on your LinkedIn profile that you had experience at Microsoft. How has that helped you, your mindset, where you are now? Alex: Microsoft in general uses a flavor of scrum that I call a “capacity scrum,” similar to Amazon, in that you use ideal hours and capacity, and you plan for load of individuals on the team. I think that I made a conscious decision to actively move away from that model, while transforming the organization here into the use of scrum. But I think Microsoft is great place to start, and to hone your enterprise‑level skills. Drew:: Can you explain a little more “capacity‑based” scrum, and hours? I didn’t really get that. Alex: At Microsoft, a typical scrum practice is you establish an individual team member’s load, which is just how many hours per day they can do actual work. A typical percentage at Microsoft is 50 percent. If you have one dev on a scrum team, he can provide four hours a day of actual work. Drew:: Because the rest is taken up by meetings or interruptions? Alex: Yeah, exactly. Then you calculate capacity based on the number of people, the person in each day, what they can work, called “load.” Based on your iteration length, you calculate how many hours are available per sprint. Then, when you’re doing your estimations for stories, you break them down into tasks and assign hours to those tasks, and tally them up, and subtract them from the capacity until you reach zero. That’s how you determine how much work you can do in a sprint. They do the exact same thing at Amazon, except they just call it “ideal hours.” Drew:: I do something similar, at least I have. We call it commitment‑driven planning where we’ve got our sprint velocity, and we can get an idea based off our previous velocities or the average of how many stories we can take in. But we won’t necessarily commit to all those stories until we break it up into tasks and figure out, based off the hours, “Do we have enough time?” Is that different than what you use at Deloitte? Alex: Absolutely. Within the group of my studio here at Deloitte Digital, I advocate strictly story point estimation and no hour estimation whatsoever. Drew:: Does that causes you to focus on something else? Or why the shift? Increased Planning Time Alex: The shift, I think, is through my experience. There were several reasons I discontinued the use of that practice. Number one being that it just takes more time to break stories down into those granular tasks and assign hours to them. I’d say probably it increases your planning time by 400 percent, somewhere around there. Number two, it gets the team away from thinking about tasks or stories in a relative fashion. They’re not thinking about, “Is this bigger than that, or is this smaller than that?” They’re thinking in hours. The other thing I think is that it’s great for senior executives or managers who often focus on, “Is the team working to their capacity?” They’re looking at that burn down chart, and all they really care about is, “Is that trend reaching zero, zero, zero?” I actually prefer burn up and looking at how much value is added over time. Incorporating Fun Drew:: I can see that shift. Also, I read on your LinkedIn profile that you mentioned your job should be fun. How do you try to incorporate that in the work that you do? Alex: I do fun little things. During estimation for example, if I get bored, rather than estimating on zero, I’ll say something like, “We’re estimating on banana.” Then I’ll say, “Pomegranate, peach, pear, banana,” and little silly things like that. I’ve also used retrospectives of fortune cookies. Those are pretty cool. Those sparks some interesting conversations. I’m a big believer in holding retrospectives, if not at a local bar, then getting a couple of six‑packs, and bringing it into the team. I’m also a big believer in doing some very basic exercises every now and then, like tribes and constellation. You’ll see a lot of people use those kinds of things at open spaces. I also like to do regularly planned morale events, take the team out to the shooting range, take the team out and go to whirly ball, stuff like that. That’s important. Transitioning To Agile Consultant Drew:: That’s all good stuff. To close here, we talked a lot about different flavors of agile and different ways to implement it. For you, what is your passion with this stuff? Why did you gravitate your career towards helping other people implement agile and running agile software projects? Alex: That’s a great question. I think, for me, it was spending a long time delivering in the waterfall model, and seeing it fail again, and again, and again. Then, going into agile where really the focus is on the team and the people. I do like process, and I’ve heard people talk about it. “Is agile or scrum a process or not?” I think it’s a framework that allows you to operate in an agile fashion. Yeah, I guess I would call it a process, but it’s a very clean and streamlined process that puts the emphasis on the team and the individuals. I think it just leads to better work‑life balance. I’ve seen it lead to more successful projects in terms of actually delivering on time. The thing I’ve seen happen more than once, which is probably the ultimate validation of this methodology, is spinning up an agile team, bringing in a product owner from a client who doesn’t really know much about agile or specifically scrum in our case. Then, through the process, they learned to love it, and go back to their company and implement scrum or agile within their company based on the success that they saw working with us. I think that speaks volumes. Drew:: That’s all good stuff. Thanks so much for joining us, Alex. Do you have anything to promote or share as a final word? Alex: I welcome everybody to go to DeloitteDigital.com and check out some of the clients we worked with like Alaska Airlines and Target and REI. We will be hosting a mobile, agile, QA conference in Fremont, Seattle, October 19th, called the MAQcon. You’ll be able to find more information online by googling, soon. Drew:: Sounds fun. Thanks a lot. For the listeners, if you want to join in on the conversation, find us at Facebook.com/AgileWeekly. Thanks a lot, Alex. Alex: Thank you.

Drew LeSueur: Hi and welcome to another episode of the Agile weekly podcast. I’m Drew LeSueur. Roy van de Water: I’m Roy van de Water. Drew: With us we have Mark Levison. Mark, tell us a little bit about yourself. Mark Levison: I’m one of Canada’s two certified Scrum trainers. I’m based in a part of Canada called Ottawa where it’s already dark outside, even though the rest of you are still looking at sunlight. I have been in the Agile business one way or another for about 12 years now. I do a lot of writing on a blog, and these days I’m spending a lot of time writing about a Scrum Master named John, and all the problems I throw him as he and his team try to win their way through the Agile world. Adding A New Person To The Team Drew: The article that we read that caught our interest was “Scrum Master Tales ‑ New People on the Team” and you talk about John and he’s struggling with a new person who’s on a team. Can you talk a little bit about that? Mark: Like any organization, John’s team grows and at the critical moment they decide they need a bit more senior technical help. They hire in a character named Kirby, and Kirby has over 20 years experience developing software. He thinks he’s seen and done it all. It turns out that Kirby is very, very loosely modeled on me. Kirby strolls into the team and starts throwing his elbows around, he’s extremely knowledgeable and very skilled, but he’s not very human‑skilled. He’s thinking a lot about what’s wrong with their code and very little about their personal needs and understanding how they came to that position. Roy: I agree. One thing I liked about this article is we through around the concept of forming, norming, storming, and performing as phases of a team (Tuckman Stages Group Development). You mentioned that when some person gets added onto the team, that process starts all over again. Roy: For the entire team, not just for that individual right? Mark: Yes. The way I illustrate this when I’m running a CSM course, I have a group of people sitting at a table, and by the time we’ve talked about this in the course they’ve already formed a fairly tight team. They’re often sitting a lot closer together. I simply walk over as the instructor, pull up an empty chair, and jam myself in the middle of the table and start pushing people to one side. Of course, what happens is ‑‑ I don’t do it too rudely ‑‑ but that ripples around the table. People start to realize, that even though they weren’t sitting next to me, when moved in next to one of their colleagues, their position on the team got affected. My claim is that you’ll have the same outcome when you introduce a new person to a technical team. Even the people who hop away, wind up finding their role changed as the new person comes in. Fastest Way To Onboard People Roy: What’s the fastest way to on‑board somebody if you’ve got a new person coming in? How do you just rush through the forming, norming, and storming stages and get to performing as quickly as possible? Is there a quick path or is that something that needs to take its time? Mark: I wish there was. It’s funny. It comes up in nearly every one of my courses and with nearly everybody. I have a little test at the end ‑‑ not the scrum lines test ‑‑ but my own personal test to make sure we understand what people have really understood. In every course, I can guarantee you at least two people will answer the question about conflict ‑‑ to which the answer is conflict is natural and cannot be avoided. They will answer that conflict can be avoided with skillful scrum mastering. Roy: Ooh… Mark: Sadly, no. I’ve not found any skills yet which allow us to avoid conflict. There’s no better way to deal with it than to simply allow it to happen and to get through it. Roy: I’ve been on a few teams that wanted to jump the idea of conflict through a form of hazing, where they wanted to have a gauntlet for new team members to run through. What kind of impact would something like that have on the team? Mark: Wow! That does not sound like a great idea. [laughter] Hazing Rituals Mark: My first thought is it puts the new person in position of weakness and possibly fear, depending upon how bad your hazing rituals are. I went to a university where the hazing rituals were fairly unpleasant. It puts the existing people in a position of power. If anybody really wants to think about just how dangerous that can be and how far it can go, they should read some of the original prisoner experiments from the mid ’60s. I can’t remember the author’s name. Roy: Were those ones in response to the Nuremberg Trials? Mark: I’m thinking of one called “Prisons We Choose to Live In”, I think. It’s a series of psychological experiments where people were recruited. Some people were made guards and other people were made prisoners and very quickly, evil and not good behavior started to evolve. The gist of is that sounds really quite dangerous. That sounds like it sets up power relationships which are not very good. Roy: Sure. Mark: I’ve not encountered that before. I’d have to go give that a lot more thought. Roy: Luckily, the team that I was on, or one of the team members that were pushing for that, ended up rejecting it. We didn’t actually go through with it. I agree with you, it would have been a dangerous idea. I think it stems from the idea that a team seems to form quickest when they have to rally together around some kind of crisis, right? When there’s a need for the team to form or, even if there’s ‑‑ in lack of a crisis ‑‑ a strong vision. That might have been the driving force behind it. A Crisis Forms A Team Mark: A crisis is exactly what it takes for team formation. Luckily, in Scrum, we usually get the crisis fairly quickly. It’s one of the joys of Scrum, I might point out. In my course, I simulate this. I actually use Scrum to run my course, so I have a burn‑down, I have a back‑log. The course is a product back‑log, there isn’t printed agenda. We have our first crisis at the end of sprint one, when it becomes clear we cannot achieve all of the material that we’ve set out. Then, we have to do some radical reprioritization. That usually has them desirable effect of throwing the team into crisis, in the sense of a real Scrum team ‑‑ maybe not on my CSM course. I don’t need to create artificial crises. They usually take care of themselves quite nicely. Roy: That’s a good point. Mark: Honestly, I’ve never seen a team that didn’t, after the first few sprints, quite naturally start trending into storming. My favorite analogy is, “If you interrupt me and I’m in the IDE, your interruption had better be damn good. Actually, it better be a serious reason.” If on the other hand, I’m browsing cnn.com, “Hey, any old interruption is good”! That’s the beginnings of storming there. I’ll yell at you if it’s not ‑‑ I won’t really ‑‑ I might pretend to yell at you if it’s not a very good interruption and I’m in the IDE, and I’m doing something I think is valuable. I might be more open to it when it’s just cnn.com. Trying To Prevent Conflict Roy: Earlier, you mentioned about people entering that scope of Scrum Mastering that will allow them to avoid conflict. I’ve seen that in the past where there are individuals that are so against the idea of conflict that they’ll do anything to prevent it from happening, even when they wouldn’t even be involved. For example, Scrum Master just hates conflict so much that they will try to prevent it. You had mentioned that it doesn’t really seem possible to avoid the conflict, but is it healthy to even try? Mark: In fact it’s even worse. If you try you’ll probably set the team back. I try it all too often myself and what I find happening is…I can’t remember, I think, it’s Kirby and Markman…I’m pretty sure are in conflict. Let’s say we go to Kirby, “Kirby, would you please stay clear of Markman’s tasks for, at least, the next two weeks”? “Mark, would you please stay clear of Kirby for the next two weeks”? I haven’t really resolved the problem. All I’ve done is taken two warring parties and told them to back off. A much better solution to this problem requires getting them to talk. I might take them individually out for coffee just so you can hear each of their sides. [jokingly] A great Scrum Master spends 20 to 30 bucks a month on coffee or tea, if that’s your preferred beverage. Roy: I like that. Mark: Take them out each individually for coffee, hear their respective sides and then, if this is an on‑going issue and it isn’t just the first time, maybe bring them together and see if they can create working agreements, but the point is you don’t ever actually do anything on their behalf. You simply help them come to the conclusions that they need to come to. Scrum Master Must Be Unbiased Roy: In your article, you mention a lot about that ‑‑ where it’s very important for the Scrum Master not to take a side, to remain unbiased. That’s got to be hard for a lot of people. Can you elaborate a little more on that? How is that possible? Mark: It’s hard for a number of reasons. A lot of organizations have part‑time Scrum Masters, who is usually a Developer. At the moment, we have Kirby come in. Kirby is going to see John as the Scrum Master/Developer in that case, and he’s going to assume John is primarily friends with all of the existing people. Instead of seeing John as someone who is playing the role of neutrality and balance, he sees John as another friend of those developers who aren’t churning out very good code ‑‑ someone else to do battle with. There is no great solution except that you have to win people over a little bit at a time, and you have to be seen as being neutral. You have to make it clear that there are no sides ‑‑ that your job is the care and feeding of the entire team, and not just any one individual. That can be really difficult. Frankly, I suspect that will be just as much a problem in the Kanbanny world as it is in the Scrummy world. Process Highlights Problems Roy: We just published or are about to publish a podcast in which Derek talks about most of these problems that we’re seeing in teams having nothing to do with the process. The process just seems to highlight them, and almost exacerbate them. The point of the process seems to be that we need to highlight these problems, so that we can attack them. Scrums aren’t going to solve your problems anymore than Kanban, or any other processes. The important part is to cycle as often as possible, get some feedback and get better. Mark: Exactly. I shock people in my course on a regular basis by making the rather bold statement, “Scrum has never solved a single problem.” Scrum merely helps you see what problems you have already. People are shocked. They think they’d spend a lot of money to get their problems solved, and they’re very surprised when I explain that no problem will be solved. Include The Team In The Hiring Process Roy: I like also in your article, you talk about if the team had been more involved in the hiring process from the beginning, it would avoid some of these problems, or maybe avoid bringing a member on who wasn’t a great fit. I’ve been in a setting where we did do that, and it was great. The whole team got to pair with the potential hire and they got to decide as a team, “Is this a good fit for us”? How about you? Can you share an experience? Mark: I have seen a few examples of that, but sadly I never got the chance to do that when I was employed working for real companies before I moved into the consulting world. My favorite example of that recently goes one further. The folk at Menlo Innovations in Detroit go one further ‑‑ they get the candidates to pair with each other, the thinking being, “If you can make the person you’re supposedly competing for job with look good, you will make every one of your peers look good.” Roy: That is an awesome idea. Mark: Yes, I’m looking for someone who’d like to have me run that as an experiment with them. [jokingly] By the way, please don’t take the forgoing as legal advice in the United States of America. [laughter] Roy: That sounds like a really neat idea to try. I can’t imagine as an interviewee though getting paired up with another interviewee that I’m competing with and trying to make them look good like that. That’s going to be tough, but I really like the idea of trying to see what comes out of that. Mark: I suspect if I tell too many people about it, the secret will get out and maybe the secret sauce will be lost. [laughter] Roy: That’s true. Thanks a lot for joining us on the Agile Weekly podcast. For those of you listening, feel free to participate in the conversation at facebook.com/agileweekly. Mark, did you have any last words, anything to share with the listeners? Mark: Don’t stress. When you see your team going through forming and storming, don’t stress over it. Let it happen ‑‑ it’s going to happen at the pace it happens. There’s nothing you can do except watch, and think of yourself as a sheepdog and not a leader. Roy: If you get a chance, Mark’s blog can be found in the description of this podcast. All right, thank you very much. Thank you Mark.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly podcast. I’m Clayton Lengel‑Zigich. Joining me today we’ve got a special group here, and I’ll let them go round and introduce themselves real quick. Laura: I’m Laura. Nancy: I’m Nancy. Catherine: I’m Catherine. Mary: I’m Mary. Starting With Scrum Clayton: Laura, Nancy, Catherine and Mary are a Scrum team. The first question I have is, what’s your experience with Scrum? I think you guys were all working here before they adopted Scrum, with the exception of maybe Catherine. What’s the background? How did you guys get into Scrum? Is it something that the company decided to do, and you went along with it? Mary: The company decided to do it, but it wasn’t implemented evenly. Some groups were doing it, and some were doing it half‑heartedly. I took part in two different groups and had two different experiences, but most recently I found it to be very rewarding. Clayton: What about you Catherine? I think you’re relatively new compared to the group. Is this your first experience working with something like this? Catherine: Yes, first experience working with Scrum. I really like it, I think there are so many benefits to working as a team using Scrum. Working as a team is hard, and I think it helps solve a lot of team issues and team problems. Scrum Outside Software Clayton: One that’s unique about your group is you guys obviously aren’t…Not obvious to the listeners, but to me obviously, you’re not doing software. One of the big questions in the Scrum community over the last few years is, does Scrum work outside of software? It sounds like from what you’re saying maybe it does, is that right? [pause] Clayton: Lots of nodding of heads. Nancy: Yes it does, in that it gets us out of our own little silos that we’ve been in previously. We’re able to communicate to other groups, which contributes greatly to how we function as a group. Mary: There are times, I think, when we need to adapt it somewhat for our content development. For instance, in one of my projects we use the Kanban board, and that was helpful there. Clayton: You thought that worked better than what you were trying to do with Scrum before? Mary: For the tasks we needed for that particular thing, they were very sequential and it involved different teams. It’s nice to still have the Agile process and the Scrum meetings, but the Kanban board allowed us to proceed on something a little more scheduled. Scrum Ceremonies Clayton: You had mentioned the Agile meetings, or the Scrum ceremonies. Do you guys think that the stand‑up and retrospective and planning meeting, are those generally helpful or are those some kind of pain points? [laughter] Catherine: For me, I think they are what your team makes them. I think if your team really buys into it and it is more like a ceremony, then it’s much more meaningful, and important, and useful. If you’re just going through the motions, I don’t think it is very helpful. It’s that buy‑in that makes it work for the team, makes it useful. Clayton: You get out what you put in? Catherine: Yeah. Physical Vs Digital Board Clayton: A change that we had made, based on most of the team’s feedback, was going to using a physical board instead of a digital tool to manage your work. That seems like you guys are pretty happy with that, but can you describe that experience? There’s a lot of teams out there that probably use digital tools that might not like them, and would want to use the physical board. What would you say to someone on a team like that? Mary: You feel more ownership when you’re able to go up and grab a piece of paper and take it back to your cube, which I really like about it. Clayton: Compared to clicking around in the software somewhere? Mary: Exactly. Clayton: What else other than ownership is it? Do you guys feel like it’s more visible to what’s happening? Mary: Absolutely. I think you get credit for the work you do. People look up there and see all those tasks that you’ve performed, and it can be very impressive. It gives you a feeling of accomplishment. Hourly Burndown Chart Clayton: One thing that I was doing with the hourly burn‑down chart was taking the capacity of the team on a daily basis. Then stair‑stepping down where the commitment should have been burned down. The joke became that you don’t want to see any red on that chart. What is it about the red when you guys get behind? Maybe there is an unexpected meeting, and it takes up a few hours. You don’t burn down all the hours that you technically should have, and then the red comes up on the board. Is that stressful, or do you just brush it off? Mary: It just reminds me back in school, when you get back the papers and they have red all over it. [laughs] Maybe if it was just a different color it wouldn’t be so horrible. [laughter] Nancy: We’re in the blue zone! [laughter] Clayton: That’s interesting, I guess I had never really thought about that. That’s a good one though. Collaborating With Other Teams Mary, you had mentioned collaborating with other teams. Does it seem like the process that you guys are using is helpful to collaborate with other teams? Or is it in the way? How would you describe that? Mary: If you’re still talking about the physical board, I think that’s opened up some conversations we didn’t expect. Sometimes a manager or someone else will be passing by as we have our stand‑up, and they might have a question for us or a comment. It’s been really good for dialogue. Clayton: In terms of the work that you’re doing, you have to interact with some software developers. The ceremonies that you’re using, the stand‑up and those kinds of things, have they made it easier to interact with those people, or harder? How do you feel about those? Nancy: It’s much easier, because when you see people on a more regular basis, it’s easier to work with them [inaudible 06:27] problems as they arise, or build each other up. The demos I find very interesting too, because that gives us the big picture. I think it’s important to stay focused on the big picture too, so the overall product, not just our own little part of it. Mary: We’ve learned a lot by working with the other teams. Clayton: Nancy, right up to the sprint review or the demo, there seems to be some kind of trouble with integrating the work that you’re doing, since it’s not software‑based, into the demo. Have you guys found that to be difficult, or is that more of an external thing? Nancy: It’s external, but I’ve always held that without content, no matter what technology does, if the content isn’t good, the technology doesn’t matter. [laughter] Mary: Content rules. Nancy: Really the content is the meat of everything. Sometimes people get so wrapped up in the technology, they forget about the content. By having the demos, Curriculum is able to show things from a content point of view, which is a little different than the technical point of view. It’s important for the technical people to remember that they are delivering content. Demos Help Show The Whole Picture Clayton: That’s a good point. In the situation where the organization has some teams that are doing Scrum for software, and some that are doing Scrum for content, to keep that big picture in mind, you really need to have both of those groups involved in the demo, right? Mary: Mm‑hmm. Nancy: Mm‑hmm. Self-Organizing Teams Clayton: If someone’s listening and they’re part of a Scrum team that maybe they’re in the similar situation. Their company adopted Agile, and they were told to use Scrum, meaning they want to use a physical board, or they maybe want to make changes to the stand‑up. You guys have done a pretty good job of embracing the idea of self‑organizing teams and trying to guide your own future. What are some roadblocks that you’ve run into in that regard? Nancy: Lack of technical support when we need it. Clayton: Maybe you want to go down a certain path, but you need some collaboration from the technical side of things? Nancy: Yes. Clayton: Have you had any trouble in terms of wanting to do something, but maybe it was off‑limits to a manager, or because other teams weren’t doing it, you couldn’t do it? Have you seen anything like that? Nancy: I haven’t particularly. I don’t think there’s anything that’s come up that has been an important issue that hasn’t met with some resolution. Sometimes we get told “No,” but that’s different from not being able to meet and told “No.” Women Under Represented Clayton: One of the things that popped into this podcast, Laura, was you had mentioned that a lot of the other podcasts that you listened to have…I’m sure you went back and listened to all of them… Laura: I did. Clayton: …the Agile Weekly Podcasts. Laura: All 60 of them. [laughs] Clayton: You had mentioned that there weren’t too many women on the podcasts. As far as this organization is concerned, it seems like there is a fair mix of men and women in whatever roles, but from an IT perspective there aren’t too many women. Is that something that you’ve experienced in other jobs that you’ve had? Do you think that’s an issue contributing to how the teams interact, the difference between men and women on certain teams? Laura: Definitely. Yeah. [laughs] Clayton: How does that manifest itself? Laura: I don’t know. I don’t think it’s something you can quantify so easily. It’s more just a feeling that I’ve gotten. I don’t know. What about you guys? Mary: Well sometimes we have to translate between the technical teams and our team. Nancy is sort of our intermediary there, she understands a lot of their terms. But it can be challenging. Clayton: Do you think the difference in gender has anything to do with that, or is it a generational thing? What are some things that make that collaboration have some more friction than maybe it should? Or that you’d like it to? Different Perspectives Require Translation and Empathy Nancy: I just think there’s different perspectives from the different groups, and how they view what’s happening. Sometimes Curriculum has a particular way they want something delivered, and the technical folks will say “Why can’t you do it this way?” and the reason you can’t is because educationally you would do it this way. The programming sometimes has to bend more I think, because of the Curriculum need. Or they would rather do it a different way, because it’s more expedient perhaps. Clayton: Do you think those problems are easy to solve using a Scrum framework, or some Agile method where there’s more smaller cycles? More feedback, that kind of thing? You think it’s easier that way? Nancy: I do think it’s easier. It’s easier than to really discuss the issues that come up as you’re doing the process. Because there’s always those variables, those unseens. You don’t when you dig in, and suddenly you’re faced with something that has to be a certain way, and we have to compromise. Clayton: Is there anything that each of you can share with us that you would change about the process that you have now, or maybe change about the Scrum framework in general? That you think you would be better off if you did something differently, or didn’t do something at all? Or added something? Effective Process Requires Buy In From Everyone Laura: I think, just to piggyback on what Catherine said at the very beginning, is you have to have buy‑in from everybody. Being able to at least trust your team. I don’t know how you can implement that, but I feel that way with this team. We all are in it in the same way, 100 percent. Clayton: You feel committed? Laura: Yeah, and I think that’s made us a really solid, good team. Catherine: I think that the expectation has to be set from the company itself, that “This is the way we want to run our company,” and they expect success. I think if, “Oh, we’re just going to give this a try and see how it goes. Maybe it won’t work for our company,” then people don’t have that buy‑in. It’s not important to them. If the company is leading it and directing it, and they expect it to be successful, they see it as part of their future, then it’s a different kind of feeling for the people that work for that company. It’s easier for them to transition from the way they’ve always done things into something new. Clayton: Nancy, Mary, anything that you would change or add to the process? Nancy: I just keep thinking that it’s a work in progress. We’re still refining the process. The company, in some ways, does back it very well. For instance, we’re doing our performance reviews and setting goals and things for the year, and they’ve mentioned they’d like us to include our Agile efforts in continuing to improve the process. Agile Transitioning Tips Clayton: If you guys had a tip to give somebody that’s on a Scrum team that you think would help them out, and they could be more successful, what would that be? Catherine: Don’t be afraid to take a risk. Clayton: Take some chances, and see what happens? Nancy: Be ready to be flexible. Clayton: Embrace change? Mary: Yes. Nancy: Communicate openly. Mary: Have fun. Nancy: Yes. [laughter] Clayton: That’s a good one. Having fun, be flexible, and enjoy your work, those kind of things. I think we’re about out of time, so I’d like to say thanks for joining us today, and I really appreciate you taking the time to do this. Group: Thank you.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich… Derek Neighbors: I am Derek Neighbors… Pavel Brodzinski: And I am Pavel Brodzinski. Myth of 100% Utilization Clayton: Welcome, Pavel. We’ve found an article that you wrote, it’s entitled “The Myth of 100 Percent Utilization”. I was curious if you could explain a little bit about the motivations for writing this one and kind of what you mean in terms of what is the myth of 100 percent utilization. If you could just introduce the topic a little bit, that would be great. Pavel: The motivation to write the piece was that what I see over and over again in different organizations is that the organizations or managers are trying to optimize the way people work, the way companies work in a way that everyone has something to do all the time. We basically are trying to utilize people for the whole time. We aim for 100 percent utilization. If you learn a bit more about the subject, you start thinking it is not the best way of organizing work. By implementing Kanban, we implement WIP limits, work in progress limits. If WIP limits are set correct, it usually means that people will have some idol time, which is called slack time. It actually is a mechanism that the team makes the organization improved. My main motivation was sharing the idea and spreading the word. What I tried to do was to explain why thinking of utilization in the first place is the wrong idea to have. Appropriate Amount of Slack Time Clayton: Is there a good level of slack time or amount of slack time, that you think on average a team should spend with no assigned task, so to speak? Is that going to vary from team to team and situation to situation? Pavel: When I think about utilization in terms of different contexts, for example, traffic on a highway. There is, I don’t remember the numbers, but something around, I believe, 70 percent, which is the optimum, the point where most cars are going through the highway. However, I would say that in terms of teams, it’s not that simple. You can say that teams should have around 20 or 30 percent of slack time. What I believe in is experimenting. You should try to tweak WIP limits, tweak the way you organize work in your team, and measure what the optimal way of working is, in your case. In terms of knowledge work, we deal with high variability of tasks we work on. It’s not that one car passes through the highway in pretty much the same time as another, as our tasks differ. It can be said that there is some kind of ideal number. I believe every team needs to find their own sweet spot. It will be floating, by the way, it’s not something that is set for a longer time. Clayton: In terms of the time that…let’s say that a team has some slack time. What do they do with that time? Is that time that they burn down technical debt, fix defects, or experiment with new things…If I’m a manager and I’m willing to accept that the team should have some slack time to do other things, this will not be a hundred percent utilized. What are they doing with that time? Are they doing nothing, what exactly would that look like? Pavel: It would depend on policies you have in your team. Because you can have some guidelines, what kind of tasks people should choose first, during slack time, but…most teams I know have freedom, in terms of they use their slack time. In an ideal world, by the way this is something I teach in Kanban, the first task to be taken, would be either swarming on tasks that are already now a bottleneck. Let’s consider the situation that we have, say, too many developers and too few testers or quality engineers. We have this bottleneck in testing. Basically, after some time one of our developers would have this slack time. In an ideal world, he would either take one task and test it or maybe swarm with one of the quality engineers, to deal with the other task faster. However, we don’t live in an ideal world. Most of the time, when a developer faces the opportunity to test [sarcastically] , he will do anything to avoid using this opportunity. [crosstalk, laughter] Clayton: Yes. Right. Optimizing For The Whole Pavel: In the long run, that’s even better, because usually they would spend time working on things that optimize the whole process, for example, automating some testing. Because this is fun, this is still development, and yet it helps quality engineers to shorten the time they spend on their regular tasks. This is the story of one of my teams that are actually working on this kind of tasks, automating tests, improving code quality, simplifying configuration. We were able to remove this bottleneck in testing because we improved the way we build the code, the way we build up. Developers had fun, working during their slack time, and still we improved the whole process, the whole end to end process. I would say that it’s pretty safe to leave much freedom to team members to choose what they’re doing during slack time. A Contradiction In Terms Derek: I follow that you’ve been bantering back and forth on this a few months back where, maybe it’s optional task stuff, maybe it’s important task, maybe it’s my inability, from the English language perspective, but I’m feeling a very strong disconnect to the logic. What I’m hearing is that people should not be a hundred percent utilized, yet they should have slack time. In the slack time they should be doing things that propel the company, the sprint, or the team forward. To me, that’s a total disconnect. If we say, “You should be doing something for the company a hundred percent of the time that you’re at work,” and then we go, “Oh, no. We don’t really believe that, what we really believe is that you should only plan 80 percent of your work, but the other 20 percent that’s not planned, you should still be doing something that moves the team forward.” I’m having a disconnect there, in the sense of…I guess I’m more of a believer that in creative work you need to allow your brain time to process things. If you’re doing, I don’t want to say slack time because I just think it’s a horrible terminology, a horrible expression, because it has so many meanings within the English language that are bad, [?] got baggage with it. May be the Pomodoro method’s an easier way to articulate it. You’re doing some volume of work, whether it be 60, 80, 90 percent, some planned form of work, and then the remainder is really more of a state of play, where you allow your mind to process…whether it be play video game, table tennis, or take a walk around the campus, whatever. I was thinking that the concept of not being a hundred percent utilized is that we’re not being fully utilized, that there’re some cycles outside…so maybe, if you could help clarify some of that…it would help me. Pavel: The first perspective is that we look at a hundred percent utilization from the perspective of building new theories of doing our regular work. When we introduce WIP limits, we try to avoid starting too many things at once before finishing some of them. This is the first thing. However, you aren’t actually forced to do this improvement work during slack time. You can perfectly do nothing. You can take a walk. You can take a break and do nothing in terms of building any value, and it would still result in better effectiveness of the team as a whole. However, what I find typical is that people actually do find time to think, do find time to have a break and play foosball or whatever. They don’t have problems like this. They still are starting too much, too many concurrent tasks. They still build those huge, huge queues in the process which make all the work of the whole team ineffective. I don’t really see introducing WIP limits, introducing slack time as a way of building this spare time to think because from what I witness in many organizations is that people, whenever they need, they actually take this time to think, to take a break, to refresh themselves but still do have problems with effectiveness in this other area. This is my view on this subject. Derek: I don’t think there’s any easy answer because I think that we can all agree that you end up with queuing problems if you have a hundred percent working on feature mentality and don’t have any slack to deal with the world around you. I think we can probably all agree that creative people need some time to process things. It’s just a matter of what we call it and how it’s planned for and how it’s probably communicated to managers or people paying the bills in a way that that they can understand that they don’t feel like people not working on whatever, to them, feels like the most pressing thing, right? Pavel: Yeah, exactly. Commitment Driven Planning Clayton: Let’s say for instance a scrum team, and they’re using a commitment‑driven approach or capacity planning where they say, “We have a hundred hours of available capacity for this sprint.” They pull in stories. They pull them in, and they task them out and everything, and they try and build up until they get to the hundred hours. Let’s say they’ve been doing that for a while where they try to pull in as many tasks as they can, I think, that they can commit based on their capacity. Would you recommend that they lower their capacity a little bit so that they do have some of that slack time? Do you think that would be beneficial to that team? Pavel: I would definitely try this kind of experiment because what you end up when you try to pull as much as possible, you end up doing features, doing tasks ‑‑ those regular tasks ‑‑ all the time. Basically, what you don’t have time for is this kind of improvement work. When you’re thinking about a classic scrum team…In sprints, we limit our work in progress in pretty different way than we do in Kanban. We don’t try to limit the number of tasks which are on this stage or the other stage, but we just have time boxing which is just the other idea of how we can limit work in progress because we can only have that many features that’s queued into our sprints and not anything more. I would definitely advise trying to introduce some time for improvement. Maybe to commit to one feature less or one story less and see what happens. If nothing changes, in scrum it’s not a problem to pull one more story out at a later time during sprint. We usually have this bunch of stories that might be in sprint, but we don’t commit to them, right? Clayton: Right. I think we’re actually about out of time here, but if listeners want to find you maybe a blog or on Twitter or if there’s anything you’ve been interested lately and a community that you’d like to share with the audience, if you can just let them know where they could check you out and see some more of your articles. Pavel: A basic, basic place where people can find me is the blog which is blog.brodzinski.com, B‑R‑O‑D‑Z‑I‑N‑S‑K‑I. My Twitter handle is @PavelBrodzinski, which is my first name and surname. Clayton: We’ll put those in the show notes for you. Pavel: Yeah, but basically if you Google my surname, all of the results somehow connects with me as that name isn’t that popular, I guess. Clayton: [laughs] That’s a good one to have. Pavel: Yeah, that’s true. Derek: Well, thanks a lot for joining us today. We really appreciate it, and we look forward having you on again. Pavel: Thanks for having me.

Derek Neighbors: Welcome to another episode of the Agile Weekly podcast. I’m Derek Neighbors. Drew LeSueur: I’m Drew LeSueur. Roy vandeWater: I’m Roy vandeWater. Johanna Rothman: I’m Johanna Rothman. Thanks guys, for having me. Derek: Oh, thank you. Johanna, I know that you’re working on a new book that is about how to maybe go about using some agile practices to change your outlook on getting hired. Why don’t you tell us a little about the work you’re doing? Manage Your Job Search Johanna: I have a new book in beta called “Manage Your Job Search” with a totally ridiculous subtitle, which is, right now, “Reduce your overwhelm, focus your search, and get your next job.” I’m going to change the subtitle. But I think the title is “Manage Your Job Search.” It’s on Leanpub, which is the way I’m writing my next couple of books. It’s Leanpub/get your next job, and I have a new version of the hiring book also on Leanpub right now. As soon as I have the title for that and a cover, I’m going to hit the publish button for that, too. The idea with “Manage Your job Search” is, if you use Personal Kanban and work in one week Editor Relations you actually can stay focused and work on your task in really small chunks and figure out “How do I’ll do a little experiment, and get my next job”? One of the problems with a job search is you say, “I have to write a resume,” but writing a resume can take you a week, and you have to say, “No no no, I can do the first draft of the resume. I can get it reviewed by a few people,” And maybe you can say, “Well I don’t know. Should I be a Product Owner? Should I be an Agile Project Manager”? I actually am one of the few people that says, “Yes, we do need Agile Project Managers, not everyone can be a Scrum Master.” Because, if you read my stuff on geographically distributed teams, I actually think you need Agile Project Managers. I don’t think you can just do everything with Scrum Masters. I think there is a role for people such as Agile Project Managers. You don’t know what you might want to be, and you might want to be one thing in this company, and one thing in another organization. You might want different kinds of resumes for different kinds of organizations. You can’t just say, “Write the resume to end all resumes.” You might want to have a focused resume for this kind of company and a focused resume for that kind of company. You have to figure out what you want to do for this week [laughs] and what you want to do next week. And maybe based on the interviewing that you do, or the phone screens that you do, or even the talking to people that you do. That you want to experiment, this is the idea behind the Lean start‑up. You do a little something, get a little feedback, and pivot. If you’ve used Personal Kanban, you can do this. The idea behind “Manage Your Job Search,” which I do think is the [laughs] main title of the book. Although the subtitle, no, no, no, we’re not going to keep the subtitle. But I’m going to keep the main title of the book. That’s the book I’m working on in beta. I was so hung up on trying to say, “Should I publish? Should I get feedback? How do I get feedback? It’s on LeanPub.” I don’t have a developmental editor guiding me. And I finally said, “I know how I can do this. I can do a beta book”! I have 53 people who are reading this book and using it. Some of them have given me feedback ‑ not all of them, of course ‑‑ which is what happens with a beta book. But a couple of them have given me feedback. The ones who have given me feedback say, “When they do this, when they actually use Kanban, it really works.” What a surprise. Using Agile For A Job Search Derek: What kind of response are you getting from people when you tell them that they might want to use a Agile practice like Kanban to do something like a job search? Do you get kind of crazy looks that you might use what people think of as a manufacturing process or a software development process as a way to look for your next career or your next path in your career? Johanna: The technical people who already know about this say it’s a sort of dope‑slap on their heads, “Oh yeah! That’s a good idea.” And the non‑technical people…I’m working with a couple of people whose parents I know, and their kids are just graduating from college. Their kids ‑‑ they know me as Johanna, the friend of their parents. They say, “What is this with the stickies? Why does Johanna want me to do this”? And I say, “Just trust me. Just try this.” They say, “You know, I’ve looked at your office, Johanna, and you have stickies all over the place.” And I say, “Yes. That’s because it works and I get all the stuff done.” They say, “Why do I have to use stickies? I don’t know about this business.” I say, “Well, it’s pretty cheap as a way to organize your to‑dos.” And they say, “Well, OK.” Then they try it and say, “Well, this is a weird thing, but I’m getting stuff done.” They don’t know that it’s from manufacturing because a lot of these people have BAs in Philosophy. I mean, they are liberal arts majors, who don’t know anything about manufacturing, and they are taught to be critical thinkers. Incoporating Feedback Derek: How are you incorporating some of the concepts from feedback? I loved how you started off with, that it’s really a hypothesis, that you’re trying to prove that hypothesis. If I go in and say, “I really want this job,” and I look at the particular employer, I think that they’re really wanting to potentially hire for this. Maybe I’m going to change my title a little bit to be more appealing, and I’m going to do these things. I get a call back, I go through the screening process, and ultimately I end up not getting the job. How are you trying to incorporate feedback back into that process? Roy: Especially when a lot of employers have a very hard time with giving you honest criticism about why they didn’t hire you, or aren’t very timely at all about it. If you’re trying to improve on one‑week sprints, and it takes some three weeks to get back to you, how do you deal with that? Johanna: A lot of it is if you’re looking for a job and have enough leads, which is a piece of the job‑finding puzzle. If you only have one lead, then you’re just holding on by your fingernails to that one lead. That’s one of the reasons you have to have really small tasks, and really small to‑dos so that you are not hanging on by your fingertips to that one thing. You have to be looking for multiple jobs, at all times. That’s one of the things that I’m really hoping that people get from this book because if you’re only looking in one place, you’re not going to find a job. You have to be looking in multiple places. I have a whole thing on how to use LinkedIn and how to use Twitter because you have to be expanding your network. I have a session at the AYE conference about how to be a social butterfly, for people who are not social butterflies. I met Derek at, what was it, a Better Software Conference a number of years ago? Being A Social Butterfly Derek: Yes. I think so. Do you sometimes say that you want to be more of a social butterfly? Johanna, are you encouraging people to potentially do some of this, well before they’re actually looking for a job? Maybe, in a current career are there some practices that you can pull through that position you, should you decide to change careers or decide to change employers that maybe you’ve already done some of the groundwork, or is it something that really only applies when you’re in the thick of trying to find new work? Johanna: I started writing this book, before I realized I was writing this book, when I was coaching a bunch of my management coachees…I do a lot of management and executive coaching. What I was realizing is, a lot of my manager colleagues had not been building their networks. I was coaching all these managers and some executives, who had a 150 people in their LinkedIn networks. I said, “This is crazy. You, guys, need to expand your networks because how are you going to hire people”? I was looking at this from the hiring perspective. When I was redoing the hiring book, I was saying to people, “Part of what you need to do ‑‑ especially if you’re hiring for an agile team ‑‑ is you need to be building your LinkedIn network so you can look at the people in your groups and look at the people that you have a relationship with so you have a shot of knowing who are the passive candidates. If you don’t have a good personal network, how are you going to reach out to people who might be really good people for you to hire? And that’s assuming you don’t want to relocation and assuming you just want people who are good people. I cannot tell you the number of people in my local network in the Boston area who every so often send me an email saying, “Do you know of a good project manager? Do you know of a good tester? Do you know of a good developer”? I have these serendipitous emails from someone who says, “I’m just starting to look around and if you know of anyone looking for somebody” and I happen to be able to put them together. Not because I’m trying recruiting as a second career because I don’t want to. But got this email and then I get this other email and I can say, “I know this person, I haven’t worked with him or her and I know this manager I haven’t worked with him or her but based on my little relationship with both of you, I think you guys might have something in common.” Power of Serendipity Derek: Yeah I see that a lot in the work that we’re doing with Gangplank, especially is that…you said serendipity and I think people do not take nearly enough advantage of serendipity. But one thing serendipity requires is that people signal. I heard you say two things, somebody signaled that they were looking for a particular type of person to hire and somebody else signaled that they were looking for a particular type of work. Because both of those people were signaling, you were able to basically cross those signals and then probably put them into touch and maybe good things happen. Maybe good things didn’t but there was an opportunity to potentially have there and maybe something like Personal Kanban for looking for next job. One of the things it does, it forces you to look at things at a granular level that allows you to signal in multiple ways which just increases the opportunity for good things to happen. So it’s just a really interesting approach. The last question I really have is, one of the things that is difficult with any kind of process is discipline. When you’re in the self‑mode, I’m not on a team, an agile team, I can have other people help enable me to accountability but in a Personal Kanban or personal agile space of some kind, how are you coaching people to be disciplined in the work they are doing? Johanna: I have people start and end their week on a Tuesday or a Wednesday, that’s the first thing. I don’t know if you’ve read “Manage It!” Or any of my project management stuff that says, “Don’t ever start or end a week on a Monday.” I wrote an article a long time ago called “What’s Wrong with Wednesdays?” And in “Manage It!” I actually say unless there’s a really good reason, never start your week on a Monday and iteration on a Monday either. Because that just begs for people to slide into the weekend then you don’t really know when your iterations start. I strongly suggest that people start their week on a Wednesday. I say to them, “You have to take time off. You absolutely not work on your job search at some point during the week. You have to take time off from it. And I don’t know which days you’re not going to work on your job search but some of those days you’re not going to. Because it’s a job like any other job. You cannot work on it seven days a week, that’s craziness.” Then I have retrospective, I tell them to count up their tasks. I tell them to make sure that their to‑dos are small chunks. I explain that they should try and make their to‑dos a couple hours in duration. I explain that this is how I work actually. None of my to‑dos in my work are longer than a couple of hours. This is literally how I work. I do a chunk of work in the morning, I do a couple of chunks in the afternoon. This is how I keep the ball rolling in my work. This is how I get books written, this is how I write articles. I explain all of that in this book because this is how I keep the flow of work going. I explain that in the book and then I say that count up all the tasks you got done and it doesn’t matter how many you got done. It’s just a number. That’s how you can predict which you might be able to get done. And I say it’s just a number, it doesn’t matter what the number is. For those of you who are…I don’t actually say the word anal, but for those of you who are worried that it’s not a normalized number, it’s not a normalized number, don’t worry about it, live with it and use that number to predict what you might be able to get done next week. If you always have really small chunks it doesn’t matter but you’ll be able to do approximately this number next week. And then I walk them through three different kinds of retrospectives. I offer them three different kinds of retrospectives and tell them to mix it up. One Person Agile Team Derek: You’re creating an independent one‑person agile team, that’s awesome. What… [crosstalk] Roy: …be beneficial in that type of case if you have somebody you can trust like a spouse or a good friend to help hold you accountable to that type of stuff. I know that, personally, I don’t have the willpower to keep myself to an iteration like that. I’d probably have to have some kind of external force holding me accountable. Is that something you’ve seen have good success or does it not really make a difference? Johanna: I don’t know. I mean, this is what I do. Am I so weird that I’m the only one that does this? Maybe. When the book is actually out, I was going to offer some webinars based on the book and see what happens. Maybe I should offer webinars before the book is out of beta. [crosstalk] Derek: That sounds like the lean thing to do to me. Johanna: Yeah. I’m having knee surgery this summer. Maybe that’s what I’ll do when I can’t travel. I actually thought for sure that people would maintain focus but you guys are giving me feedback, that maybe people are not able to maintain focus. Maybe that’s a question I’ll ask in this version of the beta and maybe people will give me feedback that they’re having trouble maintaining their focus and see if they are or not. And maybe that’s something I’ll offer as another offering. Are you having trouble maintaining the focus of the Kanban? Derek: Sounds great. I think we’re at the end of our time box. Is there anything that you want to promote or share with us before we head out? Johanna: Go see if this is interesting for the book. I will have a new version of the hiring book with a lot more about cultural fit, also on Leanpub. Look for “Agile Program Management” at some point this summer. Probably also I will first release it in beta. That’s my next writing project. Derek: You’re looking to do that on Leanpub as well? Johanna: Also on Leanpub, yes. Derek: All right, so it sounds like [inaudible 18:23] it on Leanpub. Lots of good stuff coming out. Thank you so much for your time and thank you for participating. Johanna: Well thank you so much for asking. I really enjoyed it.

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Roy vandeWater: I’m Roy vandeWater. Drew LeSueur: I’m Drew LeSueur. Derek Neighbors: I’m Derek Neighbors. But Are They Working Hard Clayton: Today, we’re going to talk about an article that we found from Esther Derby. It’s titled, “But are they working hard?” It’s a story about some managers in an organization that’s adopting Agile and they’re wondering to themselves, “OK, everything seems like it’s going well, but there’s this guy over here and he’s got that “senior” word in front of his title. He’s a senior developer. I’m wondering, is that guy really doing senior level work? His team is this cross‑functional thing. Everyone’s doing a bunch of stuff all together.” How do I know that this guy is really pulling his weight? Drew: Why do you care? Clayton: As the host of the podcast, I’m not sure. Roy: Maybe you care because you’re paying him a lot more than everyone else. Drew: That’s a good example. Clayton: Maybe I’m paying this guy more or he’s got more seniority or he’s my buddy and when special assignments come up, in the past, I’ve always picked him. But now, I’m just kind of wondering, is he kind of just goofing off now because he doesn’t really have to work as hard? I don’t know. Drew: Is that a legitimate concern of mine? Roy: I think that’s true. I didn’t think about like that, but yeah, if this guy is not pulling his weight, then maybe you can cut his pay, right? How Do You Know Hard to Push Derek: I think the other way we see this manifest is, you know, good people have to be pushed really hard. If I can’t tell if that individual is really working hard or not, how do I know to whip him harder? In the old school management style, if somebody is not working, you whip them and you continue to whip them until they are performing to their “stretch goal”. But if you don’t know if the person is being stretched or not, how do you know to whip them? Can a team only reach its maximum potential if every individual on the team is reaching their individual maximum potential and are putting in the maximum amount of effort? Drew: I think, that’s what Management 1.0 believes. How Do You Measure Effort Derek: How do measure effort, too? If you’re talking about laying bricks or shoveling something, yeah, sure you can be maxed out and shovel as fast as your physical body can shovel. But if you’re on something that’s creative like software or something else, how do you physically think harder or think faster? How do you judge that even? Drew: I think it goes back to the “work smarter not harder”. Derek: Right. Work Smarter Not Harder Drew: So if you go to your snow shovel example, if I give you a tablespoon and I go ask you to shovel snow and you are putting every ounce of your body into it and working so hard that there is no question that you are ready to be on the brink of death you are shoveling snow so hard. Then I turn around and give you a two foot by one foot snow shovel and you are working half as hard but you’re getting twice as much snow shoveled, should I be pissed that you are not working hard enough? Derek: Let’s say, I am on a senior development product team and I see that this team is not going to hit their commitment. Let’s say, it’s a longer term commitment. They’re missing their release. I could see that in an organization, especially one that even has the concept of senior developers like me, right? Roy: You’re not that old. Derek: Well, I am a senior developer. Drew: Do you get the discount at Denny’s? Super Hero Creation Derek: Yeah, the over 65’s discount? I think, I might still qualify for the student discount. I could see what I would so as a senior developer is not help my team out. Let them fail so it look’s like shit is going to hit the fan and I am not helping them. I knew from the beginning that they weren’t going to make it without my help. Then what I do, is at the last moment, when it looks like all is lost, I work my ass off for two days straight. I just kick ass and, now, I’m the star. I mean, that’s how I got the senior title in the first place. Why wouldn’t I keep doing that? What Makes A Senior Developer Senior Clayton: I was going to ask, what is it about the senior developer that makes them the senior developer? I think, in this example in the article, a lot of it comes down to you have been there longer or, maybe, you have exhibited some hero coding specialties where you burned the midnight oil a few times. Then, all of a sudden, you are loved by the manager. What is it really? I think that’s the question. Why is this person the senior developer and how do I really know that they are the senior developer, especially if they’re working in this environment where everyone is supposed to be equal? Derek: I think this is kind of a mind set shift that management has not gone through. Today, the mindset is the person that works the hardest is the leader, right? If you come in early and you stay late, you write more code and you’re more knowledgeable about the code, then, clearly, you are the code leader. You’re the senior developer. That becomes what they look for, so who is going to burn the most midnight oil for me? When that person steps up they will become the leader. I think that on Agile teams, specifically, or self organizing teams, it really is all about continuous learning. It’s about learning how to adapt to situations and learning new things. I think, the concept of leadership fundamentally changes. It’s not the person who works the hardest. It’s the person who gets the most out of the people or makes the people around them the best. That’s who the real leader is on an Agile team, it’s the person that people say, “This person makes me better at what I do.” Drew: Is it really the person who works the hardest or is it perhaps the person who sacrifices the most because I think we’ve seen even internally where we have issues with team members that have a martyr complex and they seem to rise to the position of leader because they earn respect through sacrifice. Derek: I definitely think, that’s just a form of working harder, right? Drew: Sure. Derek: I think, when you say, “Woe is me. Look at what I had to give up to get this.” That largely becomes a, “Wow, you know that person’s really taken one for the team. They’re really working out,” you know what I mean? I don’t want to say those are interchangeable pieces, but yeah, I definitely would say that sacrifice, commitment, working hard, you name it, like all of the kind of Management 1.0 or 2.0 concepts. “I don’t have to crack the whip hard on that guy. I know he’s going to work hard. I know he’s going to sacrifice for me.” What Makes a Leader Roy: Some of the things that were mentioned in the article, that senior level things “are like pairing and mentoring”, code kata, examining the team’s practices, looking for ways to improve, those are all things I think that speak to Derek’s point of helping the people that are around you improve. I think, the real sticky situation that comes up a lot especially in an organization that’s transforming itself, from an HR perspective, if you have people on the payroll or that they’re in this position in the pecking order as a senior person, but these attributes aren’t things that only they can do. They might be doing something like this in some aspect of the team for some period of time and then someone else might get jazzed up about it and they start doing it. You have this floating role in leadership position where everybody can be some leader in some aspect and now that senior thing kind of disappears, right? Derek: Right, I think you start to have senior people with different things. It kind of becomes who’s initiating that particular thing and that person might rise to the leader of the team or the senior person on the team for that particular type of thing. Whether it’d be a technology or whether it be a process or whether it’d be whatever, the teams start to say like, “So‑and‑so is kind of our go to person. They’re the champion for whatever that is.” They’re the database champion or they’re the Javascript champion or they’re the Agile champion or they’re the Kanban champion or they’re the training or teacher champion. Social Loafing Drew: What if the entire team is kind of slacking off? I remember we were reading about the article and briefly talking about it. It mentions the concept of something called social loafing. I think, Derek, your eyes lit up when that was mentioned. I’m not really familiar with it. Can you explain what it is? Derek: I’m not too familiar with it. I talked about it a bit this last week with a number of other coaches. I think, the term goes something to the fact of this concept of when you get in groups, people start to defer responsibility and it becomes somebody else will pick up that slack. There’s this loafing around concept the more social something gets. I think, there were some studies done by some people doing a tug‑of‑war (Ringlemann Effect) type of thing that if you measured people’s exertion of force when it’s one person’s tug of war against another person, they give a much higher effort than when it’s 10 people tugging war against 10 other people. I think, there’s some kind of concepts out there around. Can that be contagious as well, where you start to see one person kind of loafing? Does that start to get contagious within a group? I think, that this is something that managers fear. Providing Right Level of Challenge/Motiviation Drew: Is it something that we can prevent? It seems to me like if we are being accountable to our effort and somehow broadcasting that to our team members, we can hold each other accountable. Is that something we even want to do or is maybe that measuring something we want to do not that we ensure that everybody is spending maximum effort? But if we notice that everybody is spending maximum effort, it means we’re doing something wrong and we need to change the way that we’re doing something. Derek: Yeah. I think maybe the way that I look at it is if you’re looking at the tug of war sample, maybe I’m not pulling my absolute hardest, but if my team starts to lose, I do pull harder. If you’re setting clear vision for people and you’re putting goals out there for them to hit, can you put motivations out there? I’m not talking about more money, more whatever. But can you put some intrinsic motivations out there that get them to want to pull harder because you’re challenging them? I think that, to me, human beings have an innate desire to learn and grow. I think, sometimes people get a beat out of them or they got out of touch with it. But I think ultimately, if you’re challenging people to go deeper and harder than they’re used to, they tend to engage more. When I’ve sees social loafing, it’s usually when the team or the organization is not providing much of a challenge for somebody. They go like, “Well, I don’t have to pull that hard because we’re OK,” with regards to the power of the pull. Drew: I don’t know if this is where the metaphor is breaking down, but it seems to me like, if the goal is to win in tug of war, then it sounds to me that the minimum amount of effort required in order to win is the best strategy and the most sustainable strategy for a team to take. Is that true in all cases? Derek: I think that sounds fairly true to me. Clayton: One of the examples that she mentions in the article, the question she asked is, “Let’s say, we’ve got a few teams, and we’ve got them formed. They got a foundation. They start going. They’re producing software, delivering results, and things are going well. As a manager, do you care if they’re giving a hundred percent of the work all the time?” I think that’s the core question. Are they working hard? Is that even a valid question? Should I even be worrying about that if they’re still producing results? Am I just measuring the results? Am I only measuring effort? Then you get back to that concept that Derek has mentioned of, “Do I get mad at Drew for exerting less physical effort to shovel that snow because he’s got a better tool for the job?” Am I supposed to be mad at him about that? But if he’s delivering results, I don’t care if he’s working half as hard because it’s still working, right? Always Looking To Improve Derek: You’re right. I think, that teams should get to the point where they’re only exerting as much effort as it takes to basically pull past the goal. But the second thing, I would clarify, is that if you win, you should constantly be looking for better competition. If I’m playing tug‑of‑war and if everybody on the team only has to give 10 percent to beat an opponent, we should be looking for a tougher opponent next time, until we get to the point where we are having to put more and more effort into making that victory. If we get to the challenge where we can’t win, then we need to start looking at, “What do we need to do? Do we need to go lift some weights so that we don’t have to pull as hard to win the next time?” I think that that’s, to me, the whole concept of a healthy team. Challenge yourself just enough that you’re in a sustainable effort level because I think a hundred percent effort all the time is not sustainable, so whatever that level is. It’s probably different for everybody on the team. Get them to that point. See what victories you can have. Then challenge yourself, “What do we need to do independently and as a team to grow so that we can go against harder and harder competition while still being sustainable?” Drew: It is still a smell if the team is exerting almost no effort and not because you aren’t getting any results you want, but because it might be reasonable to be concerned that your team is going to lose motivation if they continue to have to put almost no effort into their job on a daily basis. Derek: Absolutely. Do You Have To Have A Title To Behave Differently Clayton: I guess as a manager, if I am committed to the idea that I don’t really care if my team’s working hard so much as I hope they’re delivering results and improving, like you’re mentioning Derek, should I be responsible for trying to find or uncover ways that they could be improving? Or should I just focus on enabling them and giving them some culture or some guidelines for that kind of continuous improvement mentality? Roy: The same as inside the team, I think, as I mentioned in this bullet points, the leader or the senior person, as Derek said, is the person who is going to spread his knowledge or empower or enable the rest of the people on the team. I think, maybe, somebody outside looking in can do the same thing. They’re a senior, or whatever, for whatever reason. Hopefully, it’s because of one of the bullet points on this list. How can they use their mentoring skills, or their coaching skills, or whatever skills they have, to empower the team to be better? Because we can all be better. You just have to balance that sustainability versus effort. Drew: So do you need to be a senior developer in order to practice the things on this list? Roy: I don’t think so. A senior developer, no. Drew: Do we even have a need for senior developers or that title? Derek: Probably not. Maybe hitting your question a little too, Clayton, I think, that it is valid for leadership or managers to understand how hard a team is challenging themselves. Not necessarily working hard, but are they going up against tough opponents or not? I think, if they’re going up against opponents that are complete softballs, I think, that it’s OK for management to say, “I think, we should be trying to solve harder problems, or basically push harder.” But that’s not necessarily work harder. The team needs a tougher challenge. In the same way that, I think, if they’re being over challenged, the management needs to be able to pull back and say, “Hey, we need some potentially easier opponents to go against.” To me, the difference is you’re measuring or you’re looking at the team not the individual, and let the team decide what to do with the individuals. If it’s, “Hey, this is too hard,” let the team figure out who needs to improve on the team and how they’re going to improve. Don’t dictate that to them. Don’t say, “Well, if Roy would just work harder, then we would be able to beat this guy.” Giving Up Senior Title Clayton: One last question, I’ll ask around, and you can give me a yes or no answer. If you were on an Agile team as a senior developer, do you think it would be meaningful for the progress and improvement of the team for you to publicly rescind or give up your senior developer title? Roy: That sounds cool. Drew: Yes, without being a martyr. Clayton: OK. Derek: It doesn’t really matter. Clayton: I’m no longer a senior developer. I’m a developer committed to the team. Derek: I don’t think that matters. Roy: I feel your pain. Clayton: Just symbolic, OK. Derek? Derek: In principle, I absolutely love it. I actually saw a team the other day where somebody pretty much did that and said, “We’re all developers here. There is no better or no worse.” Because somebody was talking about a better developer or worse developer, and their response was pretty much like, “We’re all developers here. There’s not better and worse.” This was somebody who’s seen as the senior person. But I don’t know if that necessarily change things either. While, I think, it’s noble and the right thing to do, I’m not sure that it necessarily helps. Drew: Do I lose my paycheck when I give up? Because I want to keep that. Clayton: All right. If you are a senior developer and you would like to come yell at us, we invite you to the Agile Weekly Facebook fan page at facebook.com/agileweekly. You can give us an earful about why we’re wrong about your senior developer title. Or if you’d like to just join the conversation in any other aspect, we’d love to have you, too. Thanks!

Drew LeSueur: Hi. Welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur. Derek Neighbors: I’m Derek Neighbors. Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich. Roy vandeWater: And I’m Roy vandeWater. Don’t Change Process Because People Aren’t Following It Drew: Today we’re going to be talking about an article by Jamie Flinchbaugh titled “Don’t just change the process if people aren’t following the existing one.” The article talks about how people focus on the process and following it to the tee, as opposed to questioning whether that’s a correct process. What are you guys’ thoughts? Roy: I don’t know. It sounds like it could be very easy to abuse. It sounds like an invitation for scrumbutts, or any other process butts, “Well, it’s a problem with the process.” I guess this is, actually, saying don’t change the process. Actually, I like that. I guess maybe it’s not a scrum‑but right. It’s saying, just because it doesn’t work for you, maybe it’s not the processes fault. I completely turned around right there. [laughs] Process Doesn’t Fix Problems, It Highlights Problems Derek: What I see a lot of times are people get so hung up on their process as the problem. I think what he might be saying is, if you’ve got a process, and people aren’t following it well, what makes you think they’re going to follow some new process? Even if they are following the process, is how do you know the process is really the problem? Meaning, if you’ve got deep culture issues, or you’ve got leadership problems, or you’ve got visioning problems, process does not solve those. All process does, especially if you’re talking Scrum or Agile, Kanban, all it does is highlight problems. It doesn’t actually solve them. If you just say, “Here’s process A,” and we run through it, and it highlights all these problems, and we go, “Hmm, yeah, let’s not do anything about these problems, let’s just switch to another process, and maybe if we have to have that process those problems won’t exist.” Then that process highlights the same exact problems, at some point you have to deal with the problems. Drew: Derek, how often have you found that it actually is the process that is the problem within a company? Has that ever happened to you? Or is that something that happens generally speaking and this is an exception where it is? Derek: I’ve never seen the process be a solution. I have seen a lack of process, or no process, make it so that a company or a team does not know what the problem is. I think sometimes you have to jump into a process to help highlight what the problems are. But, ultimately, the process never solves the problems, it just highlights them. If you’ve already got a process that’s highlighted a bunch of the problems for you, I wouldn’t advocate going and switching to another process. I would deal with the problems that your current process is highlighting. If you have no clue what problems you need to tackle, then maybe you need some process to help highlight the problems for you. Not Enough Time For Planning Clayton: Yeah, I think that one example that comes to mind is you might find a team that is doing Scrum, and they never have enough time for planning. Like, every time they say, “Scrum, the process says we have to do this thing called a planning meeting,” and it has these certain things we have to do, and there’s this artifact or whatever that falls out of it. But we just can’t just do it. Either the work we’re doing is too complex and we don’t have the time to break down all the work that we’re doing in this planning meeting, or there’s just not that much time in a day. They told us we have to do this two week sprint thing, so we can’t spend two days. That’s too big of a percentage of our Sprint just doing planning and thing that’s one of those situations that Derek’s getting into is, “OK, well, maybe there is a problem. Why does it take so long to plan?” Or maybe that’s not even a problem. Maybe that’s OK. But I think that’s the kind of thing that people will dive in and say. “This process is broken, it doesn’t work!” Roy: Does that mean that maybe processes like Scrum, and like some of the other ones out there are really just a way to normalize your team, so that you can talk in the same language as all the other teams? For example, having the issue of not being able to spend the time for planning, you might be able to go to another team that is practicing Scrum, and say, “Hey, we’re having this problem, and because you guys are using the same terminology, and you are trying to implement the same process, maybe all it is, is a framework to make it easier to communicate your problems to other teams, so that they are able to help you out.” Clayton: Yeah, that probably would make it easier, but I don’t think that’s really the goal so much as the teams have probably going to all have some different kinds of problems. They are all going to be exposed in some different way. I think it’s kind of, you get to that fork in the road, where either you decide to, “OK, well, here’s this problem we have. We’re going to resolve it somehow.” I think what the gist of article is, “We have this process problem. It must mean that we’re not doing something about the process right so let’s stop doing this and find a new process.” That’s the real issue. A lot of times, the stuff that something like Scrum or any agile methodology will uncover are difficult things that you would rather not have to solve. It’s a lot easier to blame it on the process, do some new thing, “Here, look, look, a pony.” You get some new thing in there, and you can kind of start the cycle over again. Negative Processes Drew: We have some processes out there that I feel like most of us consider negative processes. I think, in most circumstances, for example, waterfall is pretty much frowned upon in the agile community. There probably is a time and a place for it, but how do you make that determination? I suggest if the entire agile community shuns it, then we can’t consider it a valid process. It might be the process that is a problem. How do we know that it is my process that is a problem, or how do I know it is my team that is a problem? Do you know what I mean? Derek: I think a process lets you know what challenges you face within a team or an organization. I think the reason that waterfall has been universally shunned over or shown to be not so effective is it’s feedback cycle is way too short. It does have the ability to tell you that things are wrong, and to deal with them. However, the time frames that that are in are generally in months or years as opposed to days or weeks. I think when I look at why most agile processes do fairly well is because they’re very iterative, which means they’ve got much, much smaller feedback loops. I would almost argue that a lot of teams I see doing scrum are really doing mini‑waterfall. Their teams are still very siloed. They’re doing two or four‑week sprints. In whole, they have iteration zero, and they have a hardening sprint. They have all these smells, but they are getting feedback in a much tighter loop than if they said, “Hey, we’re going to do this 12‑month project, and we’re not really going to do a postmortem until month 12.” Clayton: Just to clarify, I think you meant to say that they have a longer feedback cycle? Derek: Yes, longer feedback cycle. I’m sorry. Resistance To Process Drew: When people have resistance to part of the process ‑‑ like, “Oh, we can’t spend all this time planning” or “This standup is just getting in our way. Why don’t I just get my work done?” ‑‑ part of a lot of agile processes are ceremonies that may be uncomfortable for people who are trying them to start. What are ways you guys think to overcome those type of awkwardness of starting a new ceremony that, by their culture, they’ve never done before? Roy: I think a lot of it is providing value in those ceremonies. I see way too many organizations institute a standup or a planning meeting. They are pretty much dog and pony shows in the sense of, they are there only because some scrum book or some scrum master or some coach told the team they need to do that, but the teams get no inherent value out of them. I think the key is getting the information out in the ceremony, dealing with it, reflecting on it, and improving the ceremony every time. Otherwise, what’s the point? There’s been several times I’ve told teams, “Why do you even bother having a stand up, because what you’re doing is not valuable to yourselves or anyone around you?” When Should You Change The Process Clayton: Going back to the article about, “Don’t just change the process,” when do you guys think it’s OK to change a process? How far does it matter to team maturity? Or if you get to try it for a certain period of time, how would you know now is the right time to change things and do something different even just as an experiment? How would you know how far to go with that? If you keep that for a longer period of time, is it OK to change process? How would you know that? Drew: One example that I have ‑‑ it’s just maybe a change of not necessarily a process but a practice ‑‑ is we were trying to get our stories smaller. We had a problem of having stories that were too big. I remember during planning once, we argued forever or discussed for a long time, “Should the stories be broken up or not?” At that point, we decided, “OK. Let’s just put it into this sprint. Let’s not talk about it more. We can move on and figure out if it was too big or not.” But I think sometimes, because of a time constraint, you can just move on, and, maybe, just skip some of those things that, maybe, you know you should do, but as a team, you don’t have consensus. Derek: I think it’s all about data. I would ask, “Why did the team think they needed to break the story down to a smaller story?” What behavior or what symptom or what data made you think, “Hey, we should potentially break this down”? Drew: In that experience, I think it was more of just people saying, “Hey, we should break this story” or people saying, “Big stories are bad, and smaller stories are good.” That was all the data that we were going off of. Later on, we actually learned that ourselves when we learn that, “Hey, it’s getting near the end of the sprint, and we have no story signed off. How can we fix that problem?” Using Data To Better Guide Change Derek: To me, it’s all about data. If you say, “Hey the problem is the data that’s coming up is that we’re not getting stories into pending until the end of the sprint, we should change something.” Once you change something, you should then be able to measure, “Once we did that change did the problem of not getting stories into pending until the end of the sprint go away?” If the answer’s yes, then that was probably a good process change, or a potentially good process change. If the answer’s no, then you say, “Hey, that’s not had anything to do with it, let’s either go back to what we were doing before or let’s find what the real problem is.” Roy: It sounds like in that type of situation you’d want to be very careful to make only one change so that you know which change caused your measurable effect. Doing a process swap, like you had asked when is it appropriate. It sounds like doing a whole process swap is very difficult, because sure you can measure whether or not there was a successful change, but you don’t know which aspects of your new process made that change. Chances are, if it did improve, then your ideal process as a team lies somewhere between the old process and the new process. In some cases, not all cases, obviously. I kind of feel like instead of approaching a new process, what I would do is try to get the existing process working, so that you know that you are following all of the ceremonies. Deal with those problems that arise. If you still are noticing problems within the organization, or within the team, I would start pulling in one aspect at a time of the other process and trying them out. Trying to see if, just swap it in place, and see if that works for your team or not. I can’t really think of too many cases in which different best practices from multiple processes are mutually exclusive. Clayton: I was going to say, what if the different aspects that you might be pulling in are conflicting? Roy: Since you’re only pulling in one aspect my assumption, and it could be a wrong assumption, is that it should really only affect one aspect of your existing process. I still feel like that’s a one change that you’re making. Derek: Maybe the way I would say it is if your current process is not highlighting problems for you, by all means, change your process. If your current process is highlighting problems for you, until you’ve dealt with those problems, changing your process will not help you. Roy: If you think you kick ass, you’re using the wrong process and you need to switch immediately. Derek: Maybe. Roy: I wasn’t being totally facetious. Let’s face it, no team is perfect. Everybody needs some proof. If your process is telling you that you are perfect, something’s wrong. Clayton: Yeah, I guess that’s a matter of does your process support something like continuous improvement, and those kind of things, right? Derek: Correct. Getting Process Dumped On You Clayton: I guess I have one last question. If I’m in a situation where maybe I’m part of a team, and all of a sudden some ‑‑ let’s say scrum ‑‑ scrum‑thing gets dumped on me, and I’m told now you do this process. We used to do this thing over here, that’s the old and busted, now we’re going to do the new hotness. Do it. Is that kind of culture, and that kind of thing even conducive to having that process be successful in the first place, or is that the kind of culture where people are going to blame the process for problems? Roy: That’s a good point. When something like that is mandated from on high it makes it very difficult. I think we’ve had some good arguments in the past about the power of self‑organizing teams, and I think if you start organizing the team for them, it’s going to be difficult to get buy‑in. Self-Direction vs Self-Organization Derek: I mean, I think it’s the difference between self‑direction and self‑organization. I think that you can still have a large amount of self‑organization and be put in a container. You could be put on a team and say, “Hey you have to ship product x.” Technically, that’s not self‑direction, but you can be pretty self‑organizing within that. I would say that, if you’ve got leadership, or you’ve got somebody who understands self‑organization, who really wants the team to quickly adopt, or quickly accelerate through a new process that is highly self‑organizing, I think you’d probably want to go through some form of a process, where you start to talk about the old process, or lack of a process, and say, “Hey, doesn’t it bother anybody else that we can’t do A, or we can’t do B, or that this is a problem, like our quality sucks, or we don’t have predictability,” or these kind of things. Start with isn’t this a problem. If the team starts to identify it’s a problem, then you can kind of say, “Well, what if we use this thing,” whatever the process is to try to help solve some of those problems. Then, now it’s kind of the team is kind of pulling it along. It’s not you will use this. It’s rather, “Hey, here are the problems we’re trying to solve. Does anybody know how to solve them?” I’ve heard these particular processes might be good for it. Now you’re kind of letting them be part of that process of choosing the process. Roy: The best part is they might actually have better ideas than ones you’re already aware of to deal with some of those issues. They may be able to point out that what you think are the issues are not the real issues. Drew: They can adopt the changes, as you talked about, Derek, if they show the problems or if they share with the problems, then they can choose some change that they can make to solve those problems, and make it more of a gradual thing. Roy: It’s their victory if they succeed. Derek: I think it falls in line with, if we’re talking at least scrum. It falls in line with you can tell the team this is the story that needs to be done, but you’re not telling them how to implement that story. In the same way, you can say, these are the problems I need as a product owner, or these are the problems I need as a CEO, but you’re not telling them this is the process you have to use to give me that information or to fix those problems. Drew: Thank you. That concludes our episode. We’d love for you guys to join the conversation at facebook.com/agileweekly. Thanks a lot. Clayton: Thank you. Derek: Bye‑bye.

Clayton: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Roy: I’m Roy van de Water. Clayton: Joining us today, we have Deb Spicer. You can say hi, Deb. Deb: Hi. How are you? Destructive Team Behaviors Clayton: Good. We actually found an article you had written. The title is “10 Destructive Behaviors That Can Bring Down a Team’s Success” and that’s we wanted to talk to you about. A lot of the work that we do involves working with teams and taking teams from maybe being some dysfunctional team and trying to get them toward high performing and those things. We were really interested in that topic. First off, I was just curious. Where was it you came up with this list of 10 ideas? Is that something you’ve observed or a list you’ve compiled with people in the industry? Where’d you come up with that? Deb: Actually, I came up with it after 25 years of working in global matrix teams or organizations and it is part of the book that I wrote, “Power Teams.” We can talk about that later, but actually I wrote the whole book about high‑performing teams, what makes them high performing and also when you do have destructive behaviors, how do you deal with that. Lip Service Clayton: We’re look at a few of the behaviors that were identified on that list and we had some questions about some of those. The first one that jumped out at us was the one about lip service. We feel like whenever we identify this where there’s somebody that is in the organization that’s like this, it seems like everybody know that that person is full of it but nobody seems to say anything about it. Why do you think that is? Deb: It’s very common. There are a couple of reasons that people behave that way. One is in all these behaviors, people behave the way that they do because leading to this point, it has worked for them in some form or another. When you have someone that promises everything but doesn’t really deliver on that, then it’s likely that that person has gotten away without being accountable for the things that they claim. By instilling some accountability for that person by breaking it down, holding their feet to the fire, that helps change that behavior and it just shows them, “hey, it’s a new day and you can say whatever you want but the rewards will come from the delivery, not from the words.” Inacting Counters To Bad Team Behaviors Clayton: Another thing we were wondering about is…we’re trying, whenever we have guests on the show, to take a viewpoint of maybe one of the listeners…so, if I’m a manager listening to this podcast and I think, “OK. I’ve identified these 10 behaviors, and I understand they’re wrong. If I want to make my team better and promote the good things, how do I keep my team intact, because if people get better, aren’t they just going to leave and get a better job, or something”? Deb: That’s a great question. In fact, when teams come together and achieve for something being themselves, they tend to stay, because that is a reward that is so rarely seen in organizations. It’s like when you get in the trenches with a group of people, but yet you achieve, you come out, you succeed, and you’re rewarded. Those teams tend to be the ones that stay together in a very tight cluster, move on, and take on even bigger challenges and bigger jobs together. They’ve gelled, they trust each other, they know how to deal with conflict, they feel safe to just push back on each other, and challenge each other’s ideas. Always on the other side of that, something bigger and better comes out of it, so, in fact, organizations don’t have to worry. The organizations that promote that kind of team cohesiveness, with many different teams in the organizations, are the ones who have the most innovation, are the strongest, and tend to be the leaders in the forefront of whatever dynamic is happening in the marketplace. Merging Cultures Clayton: One thing that you’ve mentioned also is the idea about the old culture. There’re some people who maybe have been there for a long time and have a way of doing things. Something that we’ve been seeing a lot…it looks like a lot of chatter is, especially in the software industry where you have people that are the new Millennial Generation. These 20‑somethings maybe out of college… Roy: I guess me. Clayton: Yes. That might describe Roy, actually. How do you integrate that? They got these old culture people that have a certain way of doing things, and then you got these Millennials. Would you have any insight on treating this kind of generational gap? Deb: I can, and in fact that chapter in my book talks about a computer company that was number two in the marketplace. Overtime, the focus was on one of the divisions in the company that was not performing, and that was to the detriment of what were the high‑performing divisions. There was enough complacency to go around that really brought the company down and it slipped down to number three. Important in dealing with this is to just shake that culture up. How do you do that? First of all, as the leader, what you do is you start setting very tight timelines on deliverables. You start speeding things up. You start the focus on what those measurable outcomes are going to be. You add things like higher level team reports so that those people that are complacent on a team, psychologically they know they better step up or they risk looking bad in front of the higher management folks. You keep the pressure, you set the deliverables, you set the timelines short, you know, “By Thursday this is what is due.” You hold people’s feet to the fire and what you see happening then is it’s not the leader holding people accountable, it’s the rest of the team that starts holding them accountable. That style supports the new millennial styles of work that haven’t been built in to some of the older cultures. Then the pressure starts coming from within the team and not just a top‑down kind of pressure. Clayton: Just to clarify, you’re suggesting applying these pressures to the entire team, right? Not to individuals or is it… Deb: Correct. Clayton: …or is it doing it to the individual? Applying Pressure To Teams Deb: No. In fact, that’s a good point because whenever we talk about these behaviors, that is what we’re talking about. The people themselves are not bad people, it’s just that they have gotten used to using behaviors that don’t necessarily fit with the kind of culture organizations need today when those organizations want to succeed. We address the behavior by putting things in place that will shake it up. That’s a particular one, you haven’t mentioned the piranha factor, but that’s actually one of the hardest ones to deal with for this reason. It doesn’t matter as a leader how charismatic you are, it doesn’t matter how great of a negotiator you are or a communicator. This behavior is very difficult. Just close your eyes for a minute and think about this scene. You’re in Brazil, you’re on a bridge looking over the river down into the water, and you take a piece of raw meat and you throw it down into the water. What happens? All of a sudden, you see backs of fish. It starts looking like a washing machine is just churning up the water and you see tails and fins and pieces of scales and stuff floating in the water. What that is, it’s the piranhas. They’re coming after that raw piece of meat. In the piranha mentality, it doesn’t matter…what people don’t understand is they are eating each other to get to that prize. It doesn’t matter who’s in the way. They just go after them and they’ll take them out to get the prize. Picture that in a team setting. The same destructive things happen. The piranha personality can leave a whole team in shreds. It doesn’t matter who they take out because for whatever their motivation or agenda is, they’re going to take out anybody who gets in their way. That’s an important one that if you inherit that person who has that personality or if you’re taking over a new team and you see that coercive, manipulative, sabotaging, demeaning kind of personality, what you have is a piranha, what I call the piranha factor. One of the most difficult and destructive team behaviors is that and it’s manifested by deliberate manipulation, deliberate coercion. They will sabotage individuals and the team as a whole for whatever their personal gain is. That behavior of all of them needs to be dealt with immediately and it needs to be dealt with very firmly. How do you do that? One of the ways is that, while you’re in the team setting, you still handle everyone very professionally, because the other team leaders, who are very aware, just like the ingrained old culture, everybody sees it. Everybody knows. But it’s your leadership that’s important in this scenario, to not that person out, if you will, in front of everyone. It’s you address it professionally, firmly… Deb: Then what you do is, besides talking to that particular person outside of that team setting, what you want to do is find a way to remove them from their comfort zone. What that means is, and what I’ve used in the past is, I then moved the entire team outside of the role that they bring to that team. IT, example, if you’re an IT programmer, then I might move you to the finance role, so you have to put on the thinking cap as if you were the finance person for that organization. If you’re a quality assurance person on the IT team, I might move you to the market role. As the piranha is the director of IT programming, like I said, I wouldn’t move that person to a finance role. Everybody figuratively moves outside of their own comfort zone, so what you get is the information, experience, enthusiasm that people bring to their regular job, plus you’re making them stretch themselves into what if I were the finance person, how would I deal with this team challenge or this team initiative that we need to solve. Roy: I guess the moving people around works but what if you have somebody on your team that is irredeemable, or he doesn’t seem to be willing to take on any of the positive traits that your team requires, and they just keep exhibiting his negative ones? Do you find that that even happens? Is nobody irredeemable? Or, if somebody is irredeemable, how do you deal with that? Deb: The easy way is to [laughs] remove them from the team, if you can. In my circumstance, that I write about in the book, it was people higher up than me required that this person stay on, because they found that person brought something in a niche way that was important. Because this initiative was at such a high level, and the outcome of this initiative was so critical to changing some of the direction for the company, the other team members, who were also decision makers, actually took on the role policing this person, and it didn’t have to be me to get them in the right vein. They did it themselves. But there are some people who, no matter what, will make sure that they don’t have any personal loyalty that they will not allow the team to collaborate, they’ll keep blinders on, they’ll stay single‑focused, and, at the end of the day, they have to be removed, or else it destroys your entire team. How Can Team Members Deal With Problems Within The Team Roy: One last question for you here. Let’s say that I’m just a member of the team, and I come across this article, or maybe I listen to this podcast, and I’m witnessing some of these behaviors on my team. What can I do? What to do for a step for me? Maybe I’m not ready to stick my neck out and make a big deal out of it, but I want to make some change. Deb: Very good question. The most important thing that you can do is be an example. You heard of the 80/20 role in business and in sales. There’s a different role. It’s called the 10/80/10 role. What happens is 10 percent of any team, of an organization, of a homeowners association, whatever dynamic that you have, 10 percent of the people will be wonderful cheerleaders, they’ll buy in immediately, they’ll rah‑rah, they’ll be supportive. On the opposite end of the spectrum, you have 10 percent, no matter what, that will serve their destructive behaviors. They’re against things because that’s just who they are. If everybody else wants it, they don’t want it. Then there’s this 80 percent in the middle, we call them the mushy middle. This is in politics, this is in lobbying, in can be in churches. 80 percent of the people are the followers. They’re going to look, they’re going to watch, they’re going to observe, and then, eventually, they’re going to choose aside the 10 percent positive, the 10 percent negative. You, as a person who wants to see the success of this, modeling successful behavior will start to bring more and more of that 80 percent over to that dynamic. You’ll see more and more people come to that. What, ultimately, does that do? It marginalizes and makes the 10 percent who are negative very insignificant. Even as a younger manager, new in your growth professionally, you can still model the behaviors as if you’re at a higher level, and you’ll find that more and more of the mushy middle will start to also model those behaviors, again making the negative, stubborn, procrastinating type of people, or the outright saboteurs, be very insignificant, because they won’t be able to sway the team. Clayton: It’s a good answer. I’m a big fan of modeling good behavior, so that’s a great way to think about it. We’re about out of time here, but you’ve mentioned a book. I was curious if there is anything else relating to the book or anything like that you’d like to share with the listeners. Deb: Sure. Actually, the book is called “Power Teams: The New SQUARE ROOT MODEL That Changes Everything!” It’s on Amazon, by Deb Spicer. If you’d like to look up on my website, it’s quantumlevelsuccess.com. Also, I do have some additional materials. I have a quick reference guide that goes with the book that I give for free. I have some chapters that are available for free. If you have any questions that are bothering you with any of your team members, and you’d just like to drop me a line, I’m very happy. I talk through ID as an issues with people all the time. It’s no charge. I really enjoy hearing the good and successful team stories as well as the challenges, and I think talking through those makes us all stronger, so I encourage you. It’s deb@quantumlevelsuccess.com. Please reach out. I’d love to hear from you. Clayton: Great. That sounds great. We really appreciate you taking the time to speak with us today, and we loved having you. Deb: Thank you, and thank you for inviting me, to your success, to your team success. I wish you the best. Take care. Clayton: Thanks.

Roy vandeWater: Hello, and welcome to another episode of the Agile Weekly podcast. I’m Roy vandeWater. Drew LeSueur: I’m Drew LeSueur. Running A Transparent Consultancy Roy: And joining us today is Chris Sims to talk about running a transparent consultancy. Chris Sims: Greetings. Roy: Chris, your company is a little different. You guys value having a high amount of transparency within your organization. You guys work in a fairly communal way. Can you tell us how your culture evolved to that point? Chris: Yeah, absolutely. Part of it was by intention. I started Agile Learning Labs about five years ago. We just do agile training in coaching and transformation work. It was my intention to create a company that was first and foremost for the benefit of the people who work there. I want it to be a great place to work. I figure well then you’ll get great people and then you’ll be able to deliver great value to the clients. That was the general attention when we started and then some of these evolved basically using agile principles of inspect and adapt and all of that. For example, one of the things that have got a lot of attention recently is the way we pay ourselves. Everybody in the company makes the same money. Everybody. Me, the person who does the billing, our creative director, our sales people, everybody makes exactly the same and it’s based on how successful the company is. That evolved over time. We started out with more traditional approach and we found that it wasn’t working for us right. We wanted to create a team and we wanted to create a team that would work towards a common goal. We found that one of the things that helped create that alignment was having everybody’s compensation package be aligned. Equal Pay Distribution Roy: How does that work from an investment perspective? I assume that you starting the company put forth quite a bit of investment capital to try to get things rolling. Is that something that just went away in the wash? How are you handling that? Chris: [laughs] I love that question. It’s one of the things we’re actually working on together. One of our progression of goals is to first make sure that we’re all making enough money that we’re living comfortably and we’re happy with that. Then interestingly enough, the whole team is actually really committed to making sure that I ultimately end up getting a good return on my initial investment. It’s kind of an exciting time because we’re actually at that point where that’s going to start happening. So, there is going to start to be a little bit of a return on owners equity you can think of and basically a little bit that’s coming off the top that’s going to come my way as a representation of “Hey, you currently own the whole company.” Over time, my intention is for that to change ‑‑ for it not to be necessarily entirely owned by me. I think it’s probably healthier when a company is owned by the people who actually operate it. For the moment, having me own the whole thing is working, but I think long term, it will actually be healthier if I’m not the only person owning it. How Do New Hires Work Roy: That sounds interesting. It sounds like you might run into some future bumps down the road bringing new hires. Would new employees have to buy into the company? Chris: Yeah, boy, we haven’t figured that one out yet. We definitely do expect bumps down the road. We’re really committed to basically working in a very inspective and [indecipherable 0:04:18] way working very collaboratively to make these decision about how we’re running the company and adjusting to the issues that present themselves. I think none of us think that what we have is like the ultimate perfect arrangement. It’s just the best one we can come up with so far. I think we all expect it’s going to change and evolve as we go. How Do Performance Reviews Work Roy: In a really transparent company, how do you handle the traditional concept of performance reviews, or more importantly the value that I think most developers want out of those? How do you handle people getting feedback on their performance so that they can target how to improve? Chris: Well, I love this. This has been one of my pet peeves for ages, which is that I think the goals of performance reviews and what actually comes out of performance reviews like what you actually get out of them, in most instances most common thing are not actually aligned. Most companies have performance reviews because they think, “Hey wow, this’ll really help people improve and grow,” and they usually have some notion of, “We should identify the people who are the high contributors, and pay them more.” Because maybe that’ll keep them around, or maybe it’s just because somehow that’s good, that our high‑performers make more money. What actually happens on the ground is ‑‑ especially if you do a traditional approach to performance reviews, where it’s an annual thing, and you do the traditional thing of tying it to compensation ‑‑ people get really wrapped up in making sure their performance review makes them look good. They want to argue about things that don’t sound good, and it really gets all wrapped up in, “Hey, I want a bigger raise,” and all of that sort of thing. If you’re trying to work in a team environment, very often this sets up a “Zero Sum” game mentality, like, “I have to look better than my co‑workers, so that I get the lion’s share of the raise money,” and all of that. What we’re doing instead is we’re choosing to go without that. We’re choosing to develop a culture, where team members give each other feedback all the time. Our goals are, on the individual level, people want to grow professionally, they want to grow their capabilities, they want to grow their skills, they want to become ever more valuable members of the team, and at the financial level, we’re all just lying around, “What can we all do, to make Agile Learning Labs even more successful?” Then that will directly translate into more money. It’s not about, “How do I look better than the other guy,” it’s like, “What does my team need right now to help us actually create more value, and I’ll just jump in and do that.” That’s what we’re doing. For bigger companies, that can be a struggle, especially if they have an entrenched HR performance review kind of situation, but some of our clients are actually moving in directions where they are changing their performance review systems to make them more aligned with their actual goals, which is to have higher performing teams. It really changes things. If you’re managing for, “We want high performing teams,” you actually do very different things as opposed to saying, “We want high performing individuals.” It turns out that a high performing team can deliver way more than even a group of high performing individuals. It’s a case of, I think, managing for what you actually want. Continuous Feedback Roy: As far as the continuous feedback part of it, where it sounds to me like your company culture is that, if somebody see a team mate underperforming, then they’ll bring it up with that person, or if they see someone succeeding really well, they would compliment them, and let them know that they appreciate however they are performing well. How does that work in practice? Because at Integrum, we’ve tried something similar, where we initially started with anonymous feedback, which we felt we got pretty much no value out of it. Perhaps we even got negative value out of it, because we felt like we wasted our time. We tried doing completely transparent feedback, where all of us sat around a table and went one by one, and gave each other feedback. I think Drew will agree that we got a lot more value out of that. We have talked, in the past, about having a culture of continuous feedback, but in practice, it doesn’t seem to work out that way. We’re not always as quick to criticize or compliment as we should be when we see things happen. Anonymous Feedback Pitfalls Chris: I’m not surprised to hear that didn’t get much value out of the anonymous feedback. In part, I think for feedback to be meaningful, it has to be a conversation. By its nature, it ends up needing to be personal. We would like to say, “Oh, no, no, it’s got to be very objective,” and in some theoretical perfect world, maybe that is even possible, but we all live here in the real world, where we’re actually working with people. In order to get a common understanding about, for example, what behavior somebody may have engaged in, that wasn’t as useful and as helpful as we would like it to be. We need to engage with them, have a conversation, and say things like, “Hey, wow, just now, when you said such and such, it lead to this reaction, which wasn’t helpful. Boy, it would be better if, next time, we could find a different way to navigate that.” It invites a conversation, and we start to understand more of the subtlety of what’s going on. The last, with people, with human beings, I think all the value is in all of that subtlety, so you have to go there. In terms of building the culture of continuous feedback, I think it’s one of those things that take practice. It takes a framework and structure to get in going. For example, we run the whole company using Scrum. We run a two‑week sprint cycle, and we plan what are the major objectives we want to achieve with this sprint. All the classic Scrum meetings, daily Scrum, a strict review at the end to see how did we do, and, very importantly, a retrospective at the end. So, at the core sprint, that becomes a place where, very exclusively, we’re looking for what can we do better as a team, which often involves how can we communicate better or how can we do a particular thing better, which might mean “Chris did something this sprint that didn’t work out as well as we liked, and we want to look at how could he do it better next sprint.” Then, building off of that, working on it and trying to be conscious about giving people feedback regularly, both positive and negative, because, if it’s just one or the other, it’s way less powerful, and people end up valuing it less and being less open to it. We’re actively trying, succeeding better on some days than others, but actively trying to create a culture where we regularly give kudos and we regularly give, “Hey, here’s an idea, Bob, how we might do it even better next time.” Who Is The Product Owner Drew: That’s great. You mentioned how you guys run your agile coaches or Scrum coaches and trainers, and you preach Scrum to other places, but you also use it internally as well. That’s one thing I have a question for you, is in your open, transparent team, where everybody is probably a lot more equal in your company than in other companies, how do you handle not having a specific product owner? Or do you consider yourself the product owner? I think of a traditional software development project. The product owner always has the final say. The team can help out, negotiate, and talk, but part of it is the product owner has the final say. How do you handle that while trying to run Scrum internally? Chris: Yeah. You nailed it right on the head. I am the product owner for Agile Learning Labs. We have a backlog. Anyone in the company can suggest items for the backlog. We talk about them, we refine them, we have identified acceptance criteria. Then, in sprint planning, I walk in with the backlog that I’ve set out ahead of time, saying, “Here’s the top of the backlog. These are the things that are likely to be offered in this sprint planning.” I offer them to the team in order to decide the order that I’m interested in, and they get to vote to accept or reject, like, do we feel like we can commit to this or not. Sometimes, there’s some negotiation around that. Sometimes, they feel like, “Well, our capacity is going to be a little lower in that area, so we can commit to a slightly less ambitious goal than that, but not the one you want.” We go back and forth all the usual sprint planning, Scrum team stuff. Roy: I think that’s something that we’ve been experimenting with. We have taken a rather different approach to running a Scrum within our organization, and we don’t really have a specific product owner. I think that sometimes hurts us more than it helps us. Chris: Yeah. We initially didn’t have a product owner. We tried to collectively groom in order to backlog, and we had a similar experience. It really didn’t work well. Everybody has an opinion, but then you come down to how do we arbitrate between all these different opinions. Finally, we realized, “Well, somebody’s got to be the product owner.” Everybody looked at me and said, “Well, you started the company. You’ve set our big‑picture direction. I guess you’re the product owner.” One of the things that have come out of that is me going, “Great! Except that means I really can’t be the Scrum Master. Darn it! Darn it!” [laughs] I like that job better, but it’s one of the things that have fallen out of that. Using Scrum To Write A Book Roy: You’ve actually used the Scrum process to write a book, recently, haven’t you? Chris: We did. Actually, two books. About a year ago, we released a book called “The Elements of Scrum,” and I have been just honestly amazed at how well it’s done. It is regularly the number one best seller on Amazon in the software project management category. That just blows me away, because, when I saw our book up above books by people like Mike Cohn, Jeff Sutherland, Ken Schwaber, and people like that, I was like, “Wow! How did that happen?” Then, about a week ago, we released a book that…it’s actually a bit of an excerpt from “The Elements of Scrum” that has been revised, updated, and polished, but it’s called “Scrum: A Breathtakingly Brief and Agile Introduction.” We intentionally targeted this one to people who really just need a brief overview, like, “What is this Scrum stuff, anyway?” Paperback is priced $9.99, which is about as cheap as you can get it, but the Kindle, since there’s actually no production cost, we priced it 99 cents, and the darn thing is already flying off the virtual shelves, which we’re really excited about. But yeah, the big book, “The Elements of Scrum,” we used Scrum to write it, and, in particular, the final big push was a writing retreat in Chicago in December, which, by the way, if you ever want to be able to focus on writing, go to Chicago in December. Roy: Nothing to do? Chris: Yeah, you don’t want to outside. [laughs] It’s below zero out there and it’s windy. So we just hold up, and we used all the classic Scrum tools. We had a story map that we used to lay out the book in the way we thought it should be. We estimated all the pieces that we had to write. We were actually running one‑day sprints. We had a burndown chart for every day and a bigger release burndown chart for the whole book. It worked like a charm. Roy: That sounds awesome. Chris: Yeah, it was fantastic. Releasing Early and Often When Writing a Book Drew: I have a question. When you were writing this book, a part of Scrum is to deliver early enough. How did you do that with your book? Did you focus on the potentially deliverable product or did you have any deliverable while you were not quite done with the whole book? Chris: It’s interesting. During that final phase, we were basically working with the potentially shippable concept, like building up and flushing and all of that, but the overall process of writing, it was much longer. It took a couple of years. What we were doing was, on a regular basis, we were actually going off to the copy shop, printing the whole book, spiral bound, and we were using it in our workshops. For two years, this was the ever‑improving, ever‑growing book that we used to take away from our scrum workshops. Each workshop, that was kind of a release, so we were motivated to get one more chapter in, or get one more concept in, or clean up a section that we weren’t real happy with. We did have lots of incremental releases. Right lying around the office, I could probably pick up maybe 10 different versions of the book before it got to the point where we actually published it properly. Drew: Awesome. Roy: Great. Drew: It’s been great having you on. Is there anything that you’d like to promote or anything that you’re working on that you’d like to tell us about? Chris: You already gave me this great opportunity to talk about the book, “The Elements of Scrum” and “Scrum: a Breathtakingly Brief and Agile Introduction.” Agile Learning Labs, we do training and coaching and love to hear from people who are adopting scrum or evolving their scrum practices. You can find us on the Web, agilelearninglabs.com. Boy, this was a lot of fun. I really appreciate the opportunity to talk with you guys again. Roy: Awesome. It was great. Drew: Yeah… Roy: We’ll definitely have to have you on again.