Podcast appearances and mentions of ken rubin

In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn reveal the keys to achieving lasting success with Agile methodologies. From embracing experimentation and fostering a culture of continuous improvement to improving communication with consistent vocabulary, they offer practical, relatable insights for Agile practitioners at all levels. Overview Brian and Mike discuss the essential ingredients to Agile success, touching on the power of experimentation, the need for flexible coaching, and building a culture of continuous improvement. The conversation dives deep into the importance of effective communication within teams, especially through user stories and consistent vocabulary, ensuring that Agile teams stay aligned. With personal anecdotes and actionable tips, this episode provides a roadmap for anyone looking to excel with Agile. References and resources mentioned in the show: Mike Cohn Essential Scrum by Ken Rubin Agile & Scrum Glossary #85: Effectively Managing Dependencies with Ken Rubin Dependencies Are Killing Your Agile Flow at Scale by Ken Rubin Creating a Software Engineering Culture by Karl Wiegers Private Scrum & Agile Training Agile For Leaders Working on a Scrum Team Classes Story Writing Workshop Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today we have our favorite back with us, Mike Cohn is here. Welcome back, Mike. Mike (00:12) Thanks, Brian. It's good to be here. Hi, everybody. Brian (00:15) So happy when Mike can make time and be with us here on the show. Obviously Mike has a lot of wisdom and experience to share with us. So we wanted to bring him in because we were talking about doing an episode titled The Secret Staggile Success. I remember back in the day in the 80s, was a movie called The Secret to My Success. There was a really obscure movie. was Michael J. Fox. Yes, it was Michael J. Fox. Mike (00:37) Michael J. Fox? Yeah, so it's not that obscure. Brian (00:41) But I still hear that theme song in my head. when we talked about this title, that's what I thought about. But we wanted to talk about maybe some hidden things or things that aren't as immediately apparent to people that are crucial to being successful when you go agile or if your teams are working in an agile way. So let's just open things up, Mike. What's one of the things you had thought about when we talked about this? Mike (01:10) think the number one secret to Agile success for me is being willing to experiment, to try new things. And if you think back, Agile itself, Scrum itself, began as experiments. They were probably teams going, know, this waterfall stuff we've been doing doesn't work. Let's try something different. Somebody else went, yeah, let's do something unusual, and let's try iterating or something. And so Agile itself began as experiments. And yet I see teams kind of get stuck in the mud and not willing to experiment. And I think that's to their detriment. We want to try things out. And silly, trivial examples, try different sprint links. Don't do a one -week sprint link and go, Agile doesn't work. It's not for us. No. Brian (01:52) Yeah. Mike (01:59) Maybe one week sprints are for you. Try a three week iteration or I try something different. And I think the the idea of experimentation is how we come up with new ideas. It's how we learn. It's how we get better. And so if you're going to succeed, you better have that that focus on experimentation. Brian (02:19) Yeah, there's a surprising number of Scrum Masters I've encountered that I'll hear stories about how they run the same exact retrospective, every single retrospective. And I just think, what are you doing? How can you be trying to communicate this and teach the team that this whole thing is based on doing little small experiments and seeing what the result is, when you're not willing to try something new in just how you run a retrospective? So yeah, I completely agree. I think the key there for me is demonstrate it. If you want them to pick up on that, then do it yourself. Mike (02:56) worked with a company years ago that fired their scrum master for basically for being too rigid. He had read something in Ken Schwaber's second book, and I don't want to pick on Ken's book, but he has this wacky sentence in there, and there are wacky sentences in my books, right? So somebody can go find those, and I mean, I get it. But anyway, Ken wrote that the daily scrum must be conducted left to right, starting with the person on the left of the scrum master. And it's like, what? Why is this mandatory? It must be left to right. Anyway, this guy read that in the book and insisted that the Daily Scrum be left to right, starting with the person on left of the Scrum Master. And his team knew that was insane, right? It's just nuts. And so they would mess with him. They would do things like he would call on the person to his left and the person on the right would start talking. he would point to the person on the left to start and they were standing in a semi -circle. They would move, right? So the person on the left was no longer on the left. And they were just messing with him over this. And he would just get mad and insisted it had to be left right because the book said so. And I don't know what it was with him, but he was just stuck on this. Ultimately ended up getting fired for it. Yeah, I heard this story because I ran into him at a conference and I saw him there and he Brian (04:14) Wow. Mike (04:20) looked a little down. It's like, you know, said his name and how are you doing? And he told me this story. And he said, you know, he'd gotten better since then. But, you know, don't get stuck on things. It's just not the it's just not a very agile mindset. Brian (04:34) Yeah. I mean, if you can't, no matter what it is too, I think that if you can't point to what you hope to achieve from doing it that way, or what's the purpose behind us doing it that way, that's questionable part of your process to just say, I can't point to any reason why this, any good that this thing does going left to right person by person, but. Ken said we should do it. I guess, no, I mean, if there's no reason, if you don't see the benefit in it, why would we do that? Mike (05:07) Knowing Ken, I think he was just trying to make it easier for people. Here's one less thing you got to think about. Start on your left and go around the room. But the way it's written and the way this guy interpreted it was like, shalt go left to right. It's like you've got to be willing to, I think, out the way that a known proven way start out that way. So yeah, go ahead and start left to right. It says so. I don't know any different. Might as well go this way. Brian (05:17) You Mike (05:35) But then experiment, learn, figure it out for yourselves. I I can't think of a successful company or team that I've worked with that ever quoted this Scrum Guide at me, right? You know, they may start out exactly the way a Scrum Guide says, or my favorite is Ken Rubin's Essential Scrum Book, start out in a known proven way, but then experiment, make agile your own. Don't throw away the important stuff, and that's why you have to start in a known proven way, but as you get experience, experiment, throw things out. Brian (05:46) Yeah. I love that. Yeah, I think that's a really good one. So a good one to start us off. Thanks for that. Mike (06:12) Yeah, that's, that's what I'm buying. Brian, can I ask you for one of your secrets to agile success? Brian (06:17) Sure. Well, and this one I know it's going to be a little, know, boy, it'd be nice if I could do that, but I, you know, we can't do that. And I understand that this is not going to be for everyone, but one of the things that I think is important is to have some kind of a coaching presence. Now, just to be clear about this, this doesn't mean that you have to, you know, fight tooth and nail to hire some outside consultant or anything like that. I understand budgets are tight and there may not be an ability to do that. But I think if I, you know, if you're a scrum master, then I think that having the ability to continue your learning journey and grow is really important and, and having someone you can go and bounce things off of. So if you can't have someone, if you, if you can't have someone on staff or someone there that's an outside consultant that can help you and coach you through the early stages, I think that could be really, really helpful. And to me, it's an accelerator. I think that kind of thing is something that can really, yes, we will go through training. We understand kind of the basics, but then the coach is sort of like pouring gasoline on that fire to say, now we're going to go from zero to 60 and I'm going to help you get there because I know the pitfalls to look out for and I know how to get you there. But if you don't have that ability, I think it's important to maintain some of those mentorship relationships that you can find through different community groups. Mike (07:18) Mm Brian (07:44) Maybe you'd find some kind of a weekly meetup or a monthly meetup or something that you could go to. Even if it's just a meetup of peers, right? There's not someone that you would say, that person's been in this for 10 years. No, we're all kind of in the same place. But if we can meet up in their network of my peers and let's talk about what's going on at your place, I'll talk about what's going on at my place, and we can share with each other and... help each other find the best solutions. Even that level, I think of coaching is really imperative and can really make an impact on how successful your implementation is. Mike (08:25) I think you're right. I think back to the earliest days of Agile, and at least of Agile training. And I'm thinking back to when I was teaching public courses on Agile in 2003, 2004, 2000, actually, the early days. One of the big benefits of the class, beyond whatever learning somebody had in the class, one of the big benefits was just feeling like you weren't alone in the world. And I remember people describing a problem, whatever it was. Like, my bosses aren't on board with this. and somebody would describe a problem and then somebody else in the class would just merely sympathize. Right. Yeah, mine too. I'm struggling with that too. That was like one level of support that was awesome. It was even better if there was somebody in the class who said something like, yeah, we had that problem and here's what we did. Right. But these were not people who were any smarter than each other. It wasn't like the person who'd worked through the problem was that much smarter. They probably just had a six month head start and Having that ability to go into a class and hear that you weren't alone and that your problems were not that unique was extremely valuable for people even way back then when there were not a lot of people doing this. Brian (09:32) Yeah, and I've said this before, and I probably said this to you, Mike, but one of the things I think people love the most when they come to the advanced classes that we offer is really being able to get sympathy from others, the camaraderie of talking to somebody else and saying, yeah, I've gone through that. It's not, I tell people at beginning of the class, it's Mike (09:48) Mm -hmm. Brian (09:59) likely not going to be a teaching point that sticks with you as much as it's going to be hearing from your peers and actually getting to learn from each other that's going to stick with you as much through those classes. to me, I think that's one of the reasons why those classes are so much fun is because I learned from the people who come to them. Mike (10:20) absolutely, absolutely. Some of what you're describing is why we set up our Agile mentors community years ago. Agile mentors community, not just the podcast, is a community we have where people who take one of our courses get a free membership. I hired a consultant to kind of give me advice on some business stuff years ago. he used the try. And I asked him, hey, we're thinking about starting this community. What do you think? I don't remember if he said do it or don't, but I do remember a term he used. He called it a continuity program. And it was a way to continue a relationship with people who taken our courses. And like I said, we give it away free to people who take classes because we know that a class isn't enough to get people successful, but it's a start. It gets people over some hurdles. It gives them the foundations of the education they need. But they're going to have ongoing questions. And our community has been wonderful because we have so many good people in there who helped each other out. And again, they're often somebody who's just six months ahead in their journey, helping somebody who's right behind them or, you know, there's somebody just in a similar industry and can sympathize or give advice on how they worked through a problem. Brian (11:29) Yeah, that's awesome. So we talked about experimentation, we talked about coaching. Mike, what was another one that was on your list? Mike (11:36) One for me is to focus more on practices than frameworks. The frameworks get all the attention. Should we do Scrum or should we do Kanban? Should we do extreme programming, going back a little bit more when that was extremely popular, still around, but not as popular? Should we do safe? And so people focus on their frameworks because they're these big, visible things. And I think what we want to do more is pick the right practices for us. Now, that's not to diminish frameworks. I think the frameworks are good. They're a good starting point. But I've said for years, if I have a team and they start with Scrum or if they start with Kanban, if they're doing the good old inspect and adapt thing, they're going to end up in the same place. They're going to invent the right Agile for them. And very likely, that's going to be some elements of Scrum, some elements of Kanban, perhaps some elements of Safe if it's big. I don't think it matters all that much where you start. I think it's worthy of some consideration. But if you're inspecting and adapting, you're going to end up in the same place. And that means that Agile needs to be thought of more as a set of practices rather than we do Scrum or we do Kanban. Brian (12:49) Yeah. Yeah, I love that. And, and, you know, we've talked about the kind of that concept before of, you know, trying to fit the right practices in place. I know when even on this podcast, when we talked about scaling and then couple of those episodes, we talked about how, you know, it may be better for you to, to, find the unique collection of practices that fits your situation. because, know, a lot of these frameworks, they're designed to handle everything. They're designed to handle any possible scenario and. Mike (13:14) Mm -hmm. Brian (13:18) You're not going to encounter every possible scenario. You're going to encounter the ones that are only particular to you. Yeah. Mike (13:24) Yeah, absolutely. Yeah, I've thought that there's I don't want to do this. I've never taken the time to really run this as an initiative. But I felt like there are a core set of practices that kind of everybody should do be iterative, right? know, inspect and adapt, right? Those type of things. But then there's a set of practices that are good for startups, let's say there's another set of practices that are good for people in the banking industry. Right. And that everybody in the banking industry should be doing a certain set of practices, and those will differ a little bit than perhaps every company in the game industry. And so there's these set of practices out there that can be grouped, but they do also need to be kind of tailored and hand -chosen for your particular organization. Brian (14:11) Yeah, yeah, I like that kind of the idea like a template, right? I mean, like when you use the template on a software program, that's a starting place, but you're expected to kind of customize it a little bit to your specific needs. Yeah, I like that. Mike (14:25) Yeah, wouldn't it be great if you're a startup and somebody said, here are the 20 practices you really got to do if you're to be successful as a startup. Here are the 10 you should think about, and then the rest, see if you like them. Same thing, bank. the bank, might have 30 practices you start with. Ivar Jakobson, who's the inventor of use cases, part of the unified method back with Bucin Rumba. He's had an initiative going on the last handful of years where he talks about method prisons and that the practices are all kind of locked up in these methodology prisons like Scrum and Kanban and everything else. And he talks about like free the practices, right? Let the practices loose of these method prisons and let people just more readily select the set of practices that are best for them. Brian (15:15) Love it. Yeah, I love it. That's a great concept. Mike (15:17) Yeah, I think it's a great, it's a great approach. It's got some traction, but it's something that more people need to hear and do. Brian (15:22) Yeah, I think that there's also maybe some stuff mixed in there with what you were saying that I've heard from the heart of Agile people. There's a lot of good stuff that's overlapped there as well. So that's awesome. Mike (15:32) Absolutely. What's another secret you can reveal Brian? Brian (15:37) Sure. Now, this is a big one, but what I would say is maybe moving in a different direction, the idea of how important the culture is and just setting the right culture even more so than trying to get things like time boxes correct. I was talking with a friend of mine at a conference recently and one of the things we kind of discussed was that whole inspect and adapt process, how important that just getting that ingrained into the DNA of what the team does. And Mike, like you said earlier, if they have that inspect and adapt built into who they are, then the practices come. The practices will actually kind of coincide with those because they'll find the right things to do. Like you said, they'll end up at the same place, right? They'll end up at the things that really are important to them. But I've seen lots of places where they go straight to the rule book and want to implement all the rules as quickly and possibly as they can. If the teams don't understand, when something goes wrong, when something does not happen the way that we thought it should, then that's a target to inspect. and dig in and find out why it happened that way, and then find a new way of doing it. I've told the story in classes before that I've encountered multiple situations, scenarios where I've worked with teams where they'll be doing something that they've identified as a problem. They've said, hey, yeah, this is wrong, this doesn't work. well, that's what I'm saying. Mike (17:26) Why are they doing it then? Brian (17:32) They'll identify something and say, yeah, that's not good. We need to do something else. But then they'll stop and say, all right, so let's really, we want to find the right thing to do to replace that with. So let's take the next two months and really investigate, find, and then we'll come back and we'll change in two months over this new thing. And my advice to them is always, so you're gonna just intentionally do the wrong thing for two months? Right. Mike (17:59) for two more months. Brian (18:01) You know, like you should try one of the other possibilities because you could get lucky and that could be the first thing you try. You know, and oftentimes it is something that is better because your gut instinct is usually pretty good about that kind of stuff. So yeah, try it. Something's not going well, all right? Then we're not doing that again, right? We're gonna try something new, whatever that is, and we're gonna try something new and then we'll do the same thing at the end of the next sprint. Mike (18:27) Mm -hmm. Yep. One of my favorite comedians, this guy named Bob Newhart died early, he was earlier this year. And he has this one comedy routine that he does where he's a psychiatrist and somebody walks into his office and she describes some problem he has. And he's like, okay, I'm going to give you the advice. It boils down to two words. And she goes like, should I take notes? Should I write the two words down? It's like, nope, you'll remember them. And he just looks her really like stern in the eye and says, stop it. Brian (18:54) you You Mike (18:59) She has a phone question. He's like, just stop it, right? Whatever you're doing, just stop it. And which is like just hilarious, right? Imagining, you know, some psychiatrist or therapist giving the advice of just stop doing whatever it is you're doing. But it's so reminiscent of what I've seen with agile teams, right? And with what you're describing here, you know, we're doing the wrong thing. We need to change, but we're going to stall looking for the perfect answer instead of just stopping and figuring out something, right? Just try something different. Brian (19:28) Yeah. And if our culture is a culture of always inspecting and adapting, then like you said, we'll end up at the right place because when something's wrong, we'll change it. And we won't just sit on something that we, I don't know how many times I've seen the organizations where you talk to people and take them out for a beer and they'll say, well, here's the real problems. everyone knows what the problems are. So why not fix it? Why not change it? Mike (19:41) Mm -hmm. Yeah. It's hard. It's hard in a lot of organizations. You and I both do sessions where we'll talk to executives, right? And to me, it's a really fun, like 90 minute training session that we have because the way we deliberately set that up was to talk about the benefits of agile. So we get people kind of interested, right? you know, those benefits. But then we tell them why it's going to be hard and what they're as executives, what was leaders, what they're going to have to change. And what I find is when we do that, if the leader starts arguing with me, because I tell them, look, here's going be hard. You're going to have to change this. You're going have to stop doing this. If they start arguing with me, we'll change that behavior if we get those benefits, then we know we've got them hooked and they want to be agile. But if I say agile's great, here are hard things you're going to have to change personally. And they're like, yeah, that'd be hard. We probably wouldn't make those changes. I don't want to go anywhere near working with that company. They're not going to succeed. They don't have a culture that's going to make those changes. And so I love doing those executive sessions because we hear it's just so instant, it's instant feedback on whether this company has a chance of being successful or not. Brian (21:06) Love him. Is there another one on from your list, Mike (21:10) One that I want to add is a little bit more about not just having one team be successful, but if you're working to get a set of teams, your department, your group, something like that. I think it's really important to have a consistent vocabulary across teams. Because we're talking about this idea of continuous improvement. And if your team and my team are using words differently, how do we share ideas back and forth? And that sharing of ideas is really important. if we don't have a consistent vocabulary, think it's hard to do. I worked with a team a couple years ago. I worked with this team, and I'm there for like two or three days. I think I'm there on the second day. And they've been using the words sprint and iteration interchangeably, just both words. And I'm sure you've encountered that. It's kind of normal. I think it kind of depends on if you grew up in the Scrum world, you call them sprints. If you grew up more generically agile, you call them iterations. They're using both words. And the second day I'm in a meeting and somebody says, well, yeah, that's how we do it in a sprint, but it's totally different when we're in an iteration. And I'm like, huh? What's the difference? And the guy had a really great answer. He said, a sprint is when we're working overtime and iteration is when we're going at a sustainable pace. That actually, there's a lot of logic to that. It's kind of a cool idea. I could see that. Brian (22:17) Ha ha ha. Mike (22:37) But I could tell by looking around the room that others were surprised as well. They'd been using the words interchangeably too. They didn't know there was this specific meaning that, I don't know, three Algel coaches had decided three years ago, this is how we use the words. But it wasn't part of, to your word, moment ago, culture. It wasn't part of their culture. And so some teams were calling them sprints, some teams were calling them iterations, and it was just creating a lot of confusion. when we found out that there were different meanings and different rules for whether you were in a sprint or iteration. So. Brian (23:08) Yeah. It reminds me of a Dilbert cartoon I saw a while ago, or it's been several years now, it was about, were talking to their big dumb boss, right? And they were saying, yeah, we're in the middle of a project and we're about halfway through, but we need, you know, six more months to complete this. All right. What's the project you're working on? We're taking all of our website addresses and we are transforming them into URLs. Right. Yeah. It's yeah. Okay. Yeah. Obviously, the boss didn't know the difference, right? Mike (23:37) That's a nice project, right? That's my assignment next month. Yeah, the vocabulary just creates confusion. like how Ken Rubin, I mentioned him earlier, the author of Essential Scrum, my favorite book on Scrum. You've had him as a guest before. I love how he writes his books. He starts out, I just start out, I just plunge in. just like, just start writing. And I have an outline, but I just start writing. Ken sits down for seriously months, I think it is. Brian (23:39) Right. Right. Mike (24:07) and defines a glossary, right? Here's how I'm gonna use certain words. then he, man, if he says a word means a certain thing, he uses it that way every single time. And he has a wonderful, agile glossary on his website, inolution .com. And so he's like defined every kind of agile word you could look for. He's got it defined there. But that's how he starts, right? So he defines all these words. And then if he writes a book and he... Brian (24:10) Wow. Mike (24:33) wants to use the term sprint, he knows exactly how he's going to use it. That's an easy one, but he will define all those words so they're clear up front. We do these working on a Scrum team classes for companies, which is a of a private whole team training class. And some of the feedback we get is that it really helped them get their vocabulary consistent. It allowed them to talk about ways to improve that were challenging until they had a common vocabulary. What is a Scrum master? What are the responsibilities of a Scrum Master? And that's not just defining the word sprint, but it's defining a more complex word and saying, what does it really mean? But if you don't have agreement on what a Scrum Master is or who is on the team or things like that, it's really hard to talk about that across a larger group. And so that, to me, is one of the secrets to Agile success is that consistent vocabulary. Brian (25:25) Yeah, I'm glad you mentioned that class because one of the things that that that we do periodically when we are not here every time. One of things that we do when we have one of those classes is I'll meet with their with a company in advance and have a conversation about what is it that you really want to get out of this. And one of the most consistent things that I hear over and over again from companies that come to us is we want consistent vocabulary. We want a consistent language that people use across this so that When we say something, means the same thing across all our teams. Mike (25:58) I think it's become more of an issue the last, I don't know, five, 10 years or whatever it is because we've got so many people that know Agile by now, right? But of course, they were trained by different people. They were trained in different ways. And so they'll be coming to it and using terms slightly differently. I'm going give a little example here. Velocity, right? Velocity can really mean two different things to people. Velocity can mean the amount of forward progress you made. in a sprint, right? How much forward progress did we get? Instead, velocity could mean capacity to do work. How much work did we get done in the last sprint? And forward progress, capacity to do work are slightly different things, right? And if we don't have agreement on that term, we're going to get into those fights about, bugs count towards velocity, right? Well, if you're using velocity to mean capacity to do work, yeah, bugs should count. If you're using velocity to mean forward progress, no. Bugs shouldn't count. And defining velocity, having that conversation with the team, once you get that figured out, a whole set of problems go away. All those discussions about what gets points, they all go away instantly. But most teams don't think to have that conversation. And they will have some team members using velocity one way, others another way. Important to get that defined. It's not hard, but it's important to get that consistency. Brian, do you have another secret, or have we revealed all the secrets? Brian (27:24) Yeah, I got one more. I got one more. you might, you know, if you're listening this far, you may notice that I have a sickness. I picked all C words. I don't know why, but that's just what I had to do. But my last C word was communicate. And really just the idea here was, you know, if you've ever gone to see a youth sports team, you know, a kid's soccer, kids basketball, whatever, right? If you ever go to see any of those things, one of the things that you will hear over and over screamed from the sideline from the coaches is, talk to each other. And it's a really important part of learning how to play that sport is, hey, I've got a call for the ball. I've got to let everyone else know, hey, here's what I need. And I think that's an important part of Scrum as well. Scrum is a team sport. It's a... Mike (28:02) Haha. Brian (28:19) You know, I apologize to people in classes and say, apologize for the sports analogy, but scrum is a sports analogy. You know, it comes from rugby and, it's, it's intentionally there as a team sports so that people can, can recognize and look at that and say, yeah, we're not, we're not playing golf, right? We're, we're, playing this as a team altogether at the same time with the same goal. And so you got to talk to each other. You got to have communication. I know, you know, Mike (28:24) Yeah, itself, Brian (28:47) One of the main ways that we try to help that here at Mountain Goat is when we talk about things like user stories. That's a main tool that the teams will use in their communication back and forth between the business and the developers. And I know in your Better User Stories course, we go in detail about that. And we also have this thing that we do occasionally called a story writing workshop that's kind of more coaching, where we'll sit down with people and kind of Mike (29:01) Mm -hmm. Brian (29:17) actually work through stories that they're writing to help them effectively communicate what they're trying to get across to the developers. Any communication takes practice. Any relationship, the communication grows and gets better the more you do it. Mike (29:36) I think it's a good point about using user stories as an example, because one of the user story mistakes people make is to think that user stories exist to document an agreement. They don't. They exist to facilitate a conversation. And then the conversation is where we're going to figure out the specific needs and things like that. Yeah, maybe we could document that. It's got to be documented for various reasons. in many organizations, but the story itself is there's a reminder to have a conversation, right? It's not there to document an agreement, which is different from things that came before, like a use case or IEEE 830 document, right? Those did document agreements. User stories, they're there to make sure we talk. Brian (30:13) Right, right. Those were in essence contracts, right? I mean, they were, you shall do this, the system shall and whatever. But yeah, user stories, not that. I love the way that you put that and I've said that for years as well. It's a placeholder for the conversation. Mike (30:28) Well, let's add one more C then. didn't realize you were on a C theme here. So let's add one more secret to Agile success with a C. Crack the whip, right? Yell at your team, make them work harder, right? That's the secret to Agile success. I shouldn't say that because you'll pull that out as a little clip. crack the whip on your Agile team. That's how you get them successful, right? Brian (30:30) Hahaha! Hahaha. I can guarantee you that's gonna be the cold open here for our show. It's Mike Cone saying, the secret is cracking the whip. I love it. Well. Mike (30:59) So there was a great book by a guy named Carl Weigers on culture. is like creating a software engineering culture. And he has these little gray boxes in there. There are things not to do, right? Don't do this. But the boxes don't say don't do this, right? You have to have read like the intro to like, hey, don't do the things in the gray boxes. But he also has like anti -patterns in there. And I just remember being a, a, I think it was a director, VP at the company. And I showed it to one of the directors. I'm like, man, look at this. He's got guys highlighted all the things to do in the boxes here. And he was like, really? We should do that? Okay. And he was like, ready to go do these things. I was like, no, no, no, these are the things not to do. So you gotta be careful with things like crack the whip, right? It's, you know, a direct quote. It sounds pretty horrible. It's a joke. It's like, hopefully people understand. So. Brian (31:42) That's hilarious. Yeah, yeah, I think everyone who's, you know, listening to this would understand that, right? Would understand that that's a joke, but and just in case. Mike (31:56) As a guy who had the whip cracked on me as a young developer, I've always been a very much do not crack the whip. I'd rather I'm always after people's energy rather than their time. Right. It's kind of like we do four day work weeks, right? I'd rather have energy than time. And so, don't think cracking the whip is the way to succeed. Brian (32:15) Yeah, I'm in the same boat. remember having a boss once that used to take me into the server room to yell at me because he could raise his voice in there and nobody would hear it. So, that was fun. Right, right. Well, this has been great, Mike. I really appreciate you making time for this. And I think everyone's going to get a of good tips out of this. Mike (32:23) You I gotta remember that. Great, thanks for having me, Brian. Bye.

In this week’s episode, Brian is joined by the legendary Ken Rubin, the author of Essential Scrum. Together, they dive deep into the world of dependencies in larger organizations and scaling, drawing from Ken's extensive experience since the early days of Scrum. If you're navigating the complexities of dependencies and looking to optimize your team's flow, this episode is a must-listen. Overview In this episode of the Agile Mentors Podcast, Brian welcomes the iconic Ken Rubin to explore the intricate realm of dependencies at scale. They dive into the impact of dependencies on flow, the challenges of scaling, and the effectiveness of feature teams in managing structural dependencies. Ken shares valuable insights into the myths surrounding dependencies and practical strategies for minimizing their impact, whether they involve external partners, scarce specialized roles, or deliberate component teams. As a bonus, Ken announces his upcoming one-day live online course where you’ll dive deeper into effective dependency management strategies, Dependencies are Killing Your Agility: Learn to Fight Back! Tune in as Ken and Brian provide practical wisdom, actionable strategies, and a wealth of knowledge. Listen Now to Discover: [01:16] - In today’s episode, Brian sits down with the first director of the Scrum Alliance and author of Essential Scrum, Ken Rubin. [03:03] - Ken defines dependencies as a relationship between two or more entities that requires collaboration or coordination. [04:31] - Ken distinguishes two dependency types: structural and instantiated. [06:48] - Brian emphasizes addressing the root cause of dependencies, comparing it to optimizing water flow in plumbing systems. [08:06] - Ken stresses the importance of addressing structural dependencies to prevent them from becoming blockers and impeding flow. [10:18] - Brian highlights an upcoming one-day live online course with Ken titled Dependencies are Killing Your Agility: Learn to Fight Back! on March 14th, emphasizing its relevance for Scrum Masters and product owners. [11:10] - Ken defines the concept of flow and compares it to the concept of utilization. [13:04] - Leaders listening should prioritize optimizing flow over squeezing individuals for efficiency. [14:23] - Ken underscores the importance of managing structural dependencies by balancing system-level WIP. [16:28] - Ken debunks the myth that 100% feature teams can eliminate all dependency issues. [19:14] - Ken shares how feature teams are compelling but face exponential challenges. [21:45] - Ken explores the need for specialized roles in scaling feature teams, proposing a threshold approach. [24:57] - Discover why Ken advocates for a combined feature and component team model, suggesting systemic swarming for specialized roles. [26:55] - Today's episode of the Agile Mentors Podcast is brought to you by Mountain Goat Software's Private Training for Agile transformations. Get your team on the same page through subject-specific training, coaching, and mentoring. For more information, visit the Mountain Goat Software’s Private Training page. [28:06] - Ken challenges the idea of a one-size-fits-all solution for dependency problems, cautioning about tool limitations. [30:25] - Ken proposes expanding the concept of working agreements to include inter-team arrangements. [33:55] - Ken highlights the misconception of solving external dependencies through internal escalation, stressing the limitations and challenges. [35:40] - Ken dispels the myth that identifying dependencies means solving the problem, emphasizing the need for control. [38:35] - Brian highlights the significant impact of waiting time, using the example of ordering a t-shirt online. [39:36] - Addressing flow problems in scaling challenges is crucial. [42:35] - Brian underscores the impact of addressing flow issues and promotes Ken's upcoming one-day live online course, Dependencies are Killing Your Agility: Learn to Fight Back! on March 14th [43:24] - Brian highlights the value of Ken's insights on dependencies and provides helpful resources and links. [43:50] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts. [47:26] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We also have Advanced Certified ScrumMaster® and Advanced Certified Scrum Product Owner®. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. [48:12] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Dependencies are Killing Your Agility: Learn to Fight Back! Essential Scrum by Kenneth Rubin Innolution Dependencies Are Killing Your Agile Flow at Scale by Ken Rubin #47 Exploring Lean Thinking In Agile Development with Bob Payne Subscribe to the Agile Mentors Podcast on Apple Podcasts Mountain Goat Software’s Private Training Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Ken Rubin is the #1 best-selling author of Essential Scrum and world-renowned Agile trainer and coach. Ken focuses on full end-to-end business agility, applying agile ways of working with your development teams, technical and business leaders, executives, as well as the important non-development groups that are critical to providing your whole product solutions.

Ken Rubin, information access researcher Learn more about your ad choices. Visit megaphone.fm/adchoices

Join Chef Ken Rubin in his virtual office as he welcomes all of your questions. From cooking techniques to course-specific questions, to how to turn your cooking passion into profit or simply hearing the perspective of a professional chef, Chef Ken tackled all variety of questions! Ken Rubin is a nationally recognized chef, educator, food anthropologist and with over 25 years of broad culinary industry experience. He currently serves as the Chief Culinary Officer at Rouxbe, the world's leading online culinary school that has helped over 600,000 people learn to cook better. Rouxbe delivers technique focused culinary instruction to home cooks, professional cooks and healthcare professionals around the world through leading edge partnerships with organizations such as Marriott International, Compass USA, The James Beard Foundation, Hyatt Hotels, Trilogy Health Services, Wegmans, The American College of Lifestyle Medicine and many others. Ken has also held top-level teaching and executive leadership positions at well-respected culinary academies and training organizations including Le Cordon Bleu Schools North America, Chefs.com, the Art Institute of Portland, and the Natural Epicurean Academy.  Ken currently serves as the Chair of the James Beard Foundation's Broadcast Media Awards Committee which oversees the national recognition for television, film, radio, and online food media content. Ken previously served as a Board Director for the International Association Culinary Professionals (IACP) before joining as Trustee and Chair of The Culinary Trust, IACP's philanthropic foundation founded by Julia Child. Ken is a regular speaker and presenter at culinary and medical conferences. He received his BA from Colorado College and an MA in anthropology from the University of Texas at Austin. He and his family enjoy cooking and eating in Portland, Oregon. You can watch the original video version of this episode on ⁠⁠⁠⁠Rouxbe⁠⁠⁠⁠.

Join Chef Ken Rubin in his virtual office as he welcomes all of your questions. From cooking techniques to course-specific questions, to how to turn your cooking passion into profit or simply hearing the perspective of a professional chef, Chef Ken tackled all variety of questions! Ken Rubin is a nationally recognized chef, educator, food anthropologist and with over 25 years of broad culinary industry experience. He currently serves as the Chief Culinary Officer at Rouxbe, the world's leading online culinary school that has helped over 600,000 people learn to cook better. Rouxbe delivers technique focused culinary instruction to home cooks, professional cooks and healthcare professionals around the world through leading edge partnerships with organizations such as Marriott International, Compass USA, The James Beard Foundation, Hyatt Hotels, Trilogy Health Services, Wegmans, The American College of Lifestyle Medicine and many others. Ken has also held top-level teaching and executive leadership positions at well-respected culinary academies and training organizations including Le Cordon Bleu Schools North America, Chefs.com, the Art Institute of Portland, and the Natural Epicurean Academy. Ken currently serves as the Chair of the James Beard Foundation's Broadcast Media Awards Committee which oversees the national recognition for television, film, radio, and online food media content. Ken previously served as a Board Director for the International Association Culinary Professionals (IACP) before joining as Trustee and Chair of The Culinary Trust, IACP's philanthropic foundation founded by Julia Child. Ken is a regular speaker and presenter at culinary and medical conferences. He received his BA from Colorado College and an MA in anthropology from the University of Texas at Austin. He and his family enjoy cooking and eating in Portland, Oregon.Join Chef Ken Rubin in his virtual office as he welcomes all of your questions. This event was created for you and we encourage you to Ask Anything – from cooking techniques to course-specific questions, to how to turn your cooking passion into profit or simply hearing the perspective of a professional chef, Chef Ken is ready to answer them all. You can watch the original video version of this episode on Rouxbe.

Ken Rubin is an Ottawa-based public-interest researcher, freedom-of-information user and critic, author and organic farmer Learn more about your ad choices. Visit megaphone.fm/adchoices

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. When Catherine joined this team, she was told by the previous Scrum Master that she should not bother with the “fluffy stuff”, as the team only wanted to “get on with the work”. As soon as she heard that, Catherine was alarmed, but also curious. A few weeks later, she knew what was going on. The team was a group of specialists, that had very deep, but narrow experience in the area they were working. This specialty-focus affected everything in the team, from the PO who had to choose work that fit the available specialist, to the motivation of the team, who felt bored and de-motivated when they did not have work for their specialty. In this segment, we talk about how Catherine approached the elephant in the room: the silos that were not allowing the team to perform! Featured Book of the Week: The Happiness Advantage by Shawn Achor In The Happiness Advantage: How a Positive Brain Fuels Success in Work and Life by Shawn Achor, Catherine found research that helped her understand the impact of a positive outlook can have on her work, and the teams she works with.  In this segment, we also refer to Essential Scrum by Ken Rubin, a book that presents Scrum for those wanting to go beyond what they can learn in their first Scrum training course. How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta!   About Catherine Kraus As a Scrum Master & Team Coach, Catherine Kraus inspires and galvanizes others into action with her playful and pragmatic approach. She works with organizations to build happier, healthier teams with purpose. She has over 15 years experience leading various transformation and change management projects in IT, Finance, HR & Marketing. You can link with Catherine Kraus on LinkedIn. 

In this classic New Years episode, join chef Chad Sarno and Chef Ken Rubin for some great advice on how to make your New Years resolutions stick! Chad Sarno is co-founder of Wicked Healthy and VP of Culinary at Good Catch Foods. Chad also is the plant-based ambassador for Rouxbe, the world's largest online cooking school, where he has launched multiple courses including the Professional Plant-Based Certification course. He spent several years at Whole Foods Market as Senior Culinary Educator, and media spokesperson for the Global Healthy Eating program. Prior to this, Chad launched a line of boutique restaurants throughout Europe, in Istanbul, Munich and London. Through the intersection of culinary innovation and healthy eating Chad continues to share his passion as a speaker, activist and RnD chef at events and with projects globally. @wickedhealthy on Instagram Ken Rubin is a nationally recognized chef, educator, food anthropologist and with over 25 years of broad culinary industry experience. He currently serves as the Chief Culinary Officer at Rouxbe, the world's leading online culinary school that has helped over 600,000 people learn to cook better. Rouxbe delivers technique focused culinary instruction to home cooks, professional cooks and healthcare professionals around the world through leading edge partnerships with organizations such as Marriott International, Compass USA, The James Beard Foundation, Hyatt Hotels, Trilogy Health Services, Wegmans, The American College of Lifestyle Medicine and many others. Ken has also held top-level teaching and executive leadership positions at well-respected culinary academies and training organizations including Le Cordon Bleu Schools North America, Chefs.com, the Art Institute of Portland, and the Natural Epicurean Academy. Ken previously served as the Chair of the James Beard Foundation's Broadcast Media Awards Committee which oversees the national recognition for television, film, radio, and online food media content, and as a Board Director for the International Association Culinary Professionals (IACP) before joining as Trustee and Chair of The Culinary Trust, IACP's philanthropic foundation founded by Julia Child. Ken is a regular speaker and presenter at culinary and medical conferences. He received his BA from Colorado College and an MA in anthropology from the University of Texas at Austin. He and his family enjoying cooking and eating in Portland, Oregon.

In this classic Holiday Episode, join chef Ken Rubin for some seasonal holiday cooking tips! Ken Rubin is a nationally recognized chef, educator, food anthropologist and with over 25 years of broad culinary industry experience. He currently serves as the Chief Culinary Officer at Rouxbe, the world's leading online culinary school that has helped over 600,000 people learn to cook better. Rouxbe delivers technique focused culinary instruction to home cooks, professional cooks and healthcare professionals around the world through leading edge partnerships with organizations such as Marriott International, Compass USA, The James Beard Foundation, Hyatt Hotels, Trilogy Health Services, Wegmans, The American College of Lifestyle Medicine and many others. Ken has also held top-level teaching and executive leadership positions at well-respected culinary academies and training organizations including Le Cordon Bleu Schools North America, Chefs.com, the Art Institute of Portland, and the Natural Epicurean Academy. Ken previously served as the Chair of the James Beard Foundation's Broadcast Media Awards Committee which oversees the national recognition for television, film, radio, and online food media content, and as a Board Director for the International Association Culinary Professionals (IACP) before joining as Trustee and Chair of The Culinary Trust, IACP's philanthropic foundation founded by Julia Child. Ken is a regular speaker and presenter at culinary and medical conferences. He received his BA from Colorado College and an MA in anthropology from the University of Texas at Austin. He and his family enjoying cooking and eating in Portland, Oregon.

Ken Rubin, Ottawa researcher

It is time for the next installment of our Agile Expert Series where we are joined by the author of Amazon Best Selling book Essential Scrum, Ken Rubin. Ken is the Principal of Innolution and has been part of the Agile movement from the very onset of Agile. Join us for a discussion around how dependencies are killing your agility! Join A VERY Special 8-hour course (two ½-day sessions) on October 27-28, 2021 Dependencies Are Killing Your Agility: Learn to Fight BackListeners of the Agile Dad podcast can get a 15% discount on the class if they use the code agiledad15 during checkout!https://innolution.com/

Join the Traveling Chef Steven Petusevsky and Ken Rubin for a discussion of world cuisine and unique flavours! Chef Steven Petusevsky is a pioneer in healthy and creative cuisine, in fact, he is the author of The Whole Foods Market Cookbook (Clarkson Potter; 2002). His most powerful tool is traveling throughout the world and integrating cuisines in areas where there are no labels, only incredibly delicious dishes with bold flavors and the value-added bonus of health and wellness. Join Steve on a virtual culinary tour where healthy cuisine is at the root of the daily diet. Ken Rubin is a nationally recognized chef, educator, food anthropologist and with over 25 years of broad culinary industry experience. He currently serves as the Chief Culinary Officer at Rouxbe, the world's leading online culinary school that has helped over 600,000 people learn to cook better. Rouxbe delivers technique focused culinary instruction to home cooks, professional cooks and healthcare professionals around the world through leading edge partnerships with organizations such as Marriott International, Compass USA, The James Beard Foundation, Hyatt Hotels, Trilogy Health Services, Wegmans, The American College of Lifestyle Medicine and many others. Ken has also held top-level teaching and executive leadership positions at well-respected culinary academies and training organizations including Le Cordon Bleu Schools North America, Chefs.com, the Art Institute of Portland, and the Natural Epicurean Academy. Ken previously served as the Chair of the James Beard Foundation's Broadcast Media Awards Committee which oversees the national recognition for television, film, radio, and online food media content, and as a Board Director for the International Association Culinary Professionals (IACP) before joining as Trustee and Chair of The Culinary Trust, IACP's philanthropic foundation founded by Julia Child. Ken is a regular speaker and presenter at culinary and medical conferences. He received his BA from Colorado College and an MA in anthropology from the University of Texas at Austin. He and his family enjoying cooking and eating in Portland, Oregon. You can watch the original video version of this episode on Rouxbe.

Raghavan Iyer and Ken Rubin held this Live Event to learn about culinary career paths, leveraging your skill set and 21st century skills for culinary and food professionals. Chef Iyer shared his personal and professional path and answered questions about how to build a career as a culinary professional. Bombay-born Raghavan Iyer, CCP, is a cookbook author, culinary educator, product development expert, and consultant for numerous national and international clients. He has authored 4 award-winning cookbooks and has contributed to the top food and culinary publications. Raghavan served as President of the International Association of Culinary Professionals (IACP) – a leading organization for culinary professionals in a wide variety of disciplines from around the world. Raghavan won the 2004 IACP Cooking Teacher of the Year and was a Finalist for a 2005 James Beard Journalism Award. Ken Rubin is a nationally recognized chef, educator, food anthropologist and with over 25 years of broad culinary industry experience. He currently serves as the Chief Culinary Officer at Rouxbe, the world's leading online culinary school that has helped over 600,000 people learn to cook better. Rouxbe delivers technique focused culinary instruction to home cooks, professional cooks and healthcare professionals around the world through leading edge partnerships with organizations such as Marriott International, Compass USA, The James Beard Foundation, Hyatt Hotels, Trilogy Health Services, Wegmans, The American College of Lifestyle Medicine and many others. Ken has also held top-level teaching and executive leadership positions at well-respected culinary academies and training organizations including Le Cordon Bleu Schools North America, Chefs.com, the Art Institute of Portland, and the Natural Epicurean Academy. Ken previously served as the Chair of the James Beard Foundation's Broadcast Media Awards Committee which oversees the national recognition for television, film, radio, and online food media content, and as a Board Director for the International Association Culinary Professionals (IACP) before joining as Trustee and Chair of The Culinary Trust, IACP's philanthropic foundation founded by Julia Child. Ken is a regular speaker and presenter at culinary and medical conferences. He received his BA from Colorado College and an MA in anthropology from the University of Texas at Austin. He and his family enjoying cooking and eating in Portland, Oregon. You can watch the original video version of this episode on Rouxbe.

In this classic episode, join Rouxbe's Chief Culinary Officer Ken Rubin and Rouxbe Wellness Advisory Board member Dr. Julie Briley, ND, as she shared a naturopathic physician's perspective on food and cooking. She spoke about her experience using food to support overall health as well as to help support treatment of specific chronic conditions. Dr. Julie Briley is a licensed naturopathic primary care physician and co-founder of the Food As Medicine Institute (FAMI) at the National College of Natural Medicine (NCNM) in Portland, Oregon. Founded in 1956, NCNM is the oldest accredited naturopathic medical college in North America and an educational leader in naturopathic and classical Chinese medicine, and integrative medical research. NCNM’s FAMI is dedicated to helping individuals, families and organizations develop healthy relationships with whole foods. FAMI provides curriculum-driven, bilingual nutrition/cooking workshops, classes, webinars and corporate wellness programs. FAMI also produces symposia and webinars for healthcare professionals to deepen their understanding about food as medicine and to assist in the prevention and management of disease in their patients. FAMI’s community-based nutrition and hands-on cooking programs for children, teens and adults of various cultures and socioeconomic levels reflect Dr. Briley’s longstanding interest in community health education. Her commitment to underserved communities was first sparked when she served in the Peace Corps in Paraguay and other Latin American countries. In teaching villagers how to plant and cook nourishing foods, she gained a profound understanding about the link between nutrition and disease prevention. Dr. Briley is a faculty member for NCNM’s Master of Science in Nutrition program, and maintains a private practice in Portland where she addresses the underlying cause of disease in patients with acute or chronic health conditions. Ken Rubin is a nationally recognized chef, educator, food anthropologist and with over 25 years of broad culinary industry experience. He currently serves as the Chief Culinary Officer at Rouxbe, the world’s leading online culinary school that has helped over 600,000 people learn to cook better. Rouxbe delivers technique focused culinary instruction to home cooks, professional cooks and healthcare professionals around the world through leading edge partnerships with organizations such as Marriott International, Compass USA, The James Beard Foundation, Hyatt Hotels, Trilogy Health Services, Wegmans, The American College of Lifestyle Medicine and many others. Ken has also held top-level teaching and executive leadership positions at well-respected culinary academies and training organizations including Le Cordon Bleu Schools North America, Chefs.com, the Art Institute of Portland, and the Natural Epicurean Academy. Ken previously served as the Chair of the James Beard Foundation’s Broadcast Media Awards Committee which oversees the national recognition for television, film, radio, and online food media content, and as a Board Director for the International Association Culinary Professionals (IACP) before joining as Trustee and Chair of The Culinary Trust, IACP’s philanthropic foundation founded by Julia Child. Ken is a regular speaker and presenter at culinary and medical conferences. He received his BA from Colorado College and an MA in anthropology from the University of Texas at Austin. He and his family enjoying cooking and eating in Portland, Oregon. You can watch the original video version of this episode on Rouxbe.

In this HCI Podcast episode, Dr. Jonathan H. Westover (https://www.linkedin.com/in/jonathanhwestover/) talks with Ken Rubin about hospitality hiring and how offering training can help you recruit and retain employees. See the video here: https://youtu.be/9VvjQ3ORoYw. Ken Rubin - Chief Culinary Officer (https://www.linkedin.com/in/ken-rubin-2a95ba1/) is a chef educator and food anthropologist with 18 years of broad industry experience, oversees Rouxbe's cooking course curriculum development and recruitment. Recognized for his expertise in education and training, food culture research, health and wellness and product development, Ken nevertheless considers himself a lifelong student of every aspect of food.  Ken has held top-level management positions at well-respected culinary academies including Le Cordon Bleu Schools North America, Chefs.com, the International Culinary School at the Art Institute of Portland and the Natural Epicurean Academy. As a volunteer, he served as board director of the International Association of Culinary Professionals (IACP) and is currently a trustee and chair of The Culinary Trust, IACP's philanthropic partner. Ken is also the Chair of the James Beard Foundation's Broadcast Media Awards Committee.  Ken studied the anthropology of food and developed ethnographic research methods to understand how people learn to cook. He received his BA from Colorado College and an MA in anthropology from the University of Texas at Austin. Check out Dr. Westover's new book, The Alchemy of Truly Remarkable Leadership, here: https://www.innovativehumancapital.com/leadershipalchemy. Check out the latest issue of the Human Capital Leadership magazine, here: https://www.innovativehumancapital.com/hci-magazine. Ranked in the Top 10 Performance Management Podcasts: https://blog.feedspot.com/performance_management_podcasts/ ; Ranked in the Top 10 Workplace Podcasts: https://blog.feedspot.com/workplace_podcasts/ ; Ranked in the Top 15 HR Podcasts: https://blog.feedspot.com/hr_podcasts/ ; Ranked in the Top 15 Talent Management Podcasts: https://blog.feedspot.com/talent_management_podcasts/ ; Ranked in the Top 15 Personal Development and Self-Improvement Podcasts: https://blog.feedspot.com/personal_development_podcasts/ ; Ranked in the Top 30 Leadership Podcasts: https://blog.feedspot.com/leadership_podcasts/

Whether you’re a restaurant owner, chef or line cook, now may be the time to uplevel your kitchen talent. This pandemic keeps on keeping on, but you’re future in this business depends on your creativity, skillset and value to your employer. So why not consider taking cooking classes online? In this episode of the Restaurant RockStars Podcast, I’m speaking with Ken Rubin, Chief Culinary Officer of Rouxbe, the world’s leading online culinary school. Ken’s experience comes from top level management at Le Cordon Bleu, as well as the Natural Epicurian Academy of Culinary Arts. You’ll hear all about Rouxbe’s world-class instructors, the extensive range of online culinary classes to take at your convenience, and even eLearning these skills in multiple languages. Check out www.rouxbe.com and get inspired. Now go out there and Rock Your Restaurant! Roger More Restaurant Resources: https://restaurantrockstars.com/

Ken, a chef educator and food anthropologist with 18 years of broad industry experience, oversees Rouxbe’s cooking course curriculum development and recruitment. Recognized for his expertise in education and training, food culture research, health and wellness and product development, Ken nevertheless considers himself a lifelong student of every aspect of food.Ken has held top-level management positions at well-respected culinary academies including Le Cordon Bleu Schools North America, Chefs.com, the International Culinary School at the Art Institute of Portland and the Natural Epicurean Academy. As a volunteer, he served as board director of the International Association of Culinary Professionals (IACP) and is currently a trustee and chair of The Culinary Trust, IACP’s philanthropic partner. Ken is also the Chair of the James Beard Foundation’s Broadcast Media Awards Committee.

Ken, a chef educator and food anthropologist with 18 years of broad industry experience, oversees Rouxbe’s cooking course curriculum development and recruitment. Recognized for his expertise in education and training, food culture research, health and wellness and product development, Ken nevertheless considers himself a lifelong student of every aspect of food. Ken has held top-level management positions at well-respected culinary academies including Le Cordon Bleu Schools North America, Chefs.com, the International Culinary School at the Art Institute of Portland and the Natural Epicurean Academy. As a volunteer, he served as board director of the International Association of Culinary Professionals (IACP) and is currently a trustee and chair of The Culinary Trust, IACP’s philanthropic partner. Ken is also the Chair of the James Beard Foundation’s Broadcast Media Awards Committee.

There were some connection issues that affected the quality of the recording but in typical Corporate Thought fashion, the episode is presented here with all the flaws so please bear with it as you learn about the impressive Jessica Katz Jessica coaches businesses in Agile. She also talks about the subset Scrum. Here is an overview. Jessica spoke about Gravity Payments and their CEO Dan Price and his decision to make a minimum salary of $70,000. Here is the full story. I asked Jessica about the book Team of Teams which she knew well. It caused her to mention a company called Buurtzorgout of the Netherlands which is disrupting the nursing care industry by creating a teaming approach. I told Jessica about Atomic Habits by James Clear which we featured on our social media posts recently. For learning more about Agile and Scrum Jessica recommended Scrum Essentials by Ken Rubin. I think she meant Essential Scrum by the same author. Jessica is currently reading (actually listening) to Paths of Alir by Melissa McPhail and next she is reading So You’ve Been Publicly Shamed by Jon Ronson Jessica recommends that people really start with understanding their why and to state the culture of their company right at the beginning. Jessica can be found at liberatedelephant.com

Please join us as we sit with a Culinary Mastermind, Ken Rubin from Rouxbe online training. An amazing NEW Partner with Sysco Canada. rouxbe.com --- Send in a voice message: https://anchor.fm/syscocanadafoodiepodcast/message

We were overwhelmed with the positive response of last week’s episode with Chef Ken Rubin, so we decided to keep that momentum going this week with Chef Del Sroufe. If his name isn’t familiar, his work will be. He authored, “Forks Over Knives: the Cookbook,” “The China Study Quick and Easy Cookbook,” and “Better than Vegan,” the story of his struggle with weight loss and gain, and how he managed to lose over 200 pounds on a low fat, plant-based diet.  Not only does he share some of his favorite practical cooking tips for common staples in your home - beans, potatoes, veggie stock, and even low-fat recipes for delicious cheese substitute sand guacamole (that you won’t want to miss), BUT - he also talks openly about his own struggles with health and weight. Like many of us, Del has fallen victim to overstress, overeating, and finding comfort in the wrong foods. Sound familiar? He’s in the middle of his own personal reset just like many of you, so let’s do it together with love and empathy. His transparency may just be what you need to help you right now.  Episode Resources: Chef Del Sroufe Website Tips and Recipes from the Episode Support for this week's episode comes from Wild Earth Dog Food - use promo code: PLANTSTRONG for 40% order Seeking a solution for making the plant-strong lifestyle convenient and inspiring? The Plant-Strong Meal Planner offers 1000s of recipes customized to your preferences, an integrated shopping list and grocery delivery! Our Engine 2 Coaches are on hand to offer support and answer any questions. Visit our Plant-Strong Meal Planner today and use promo code: HEALTHNOW to save $20 off an annual plan. Theme music for episode

Ken Rubin is the Chief Culinary Officer of Rouxbe Online Culinary School, training people to become more creative, confident, and HEALTHY in kitchens around the world. A silver lining of the Covid-19 quarantine has been a trend back to rediscovering the joy of a home-cooked meal with the family. Cooking doesn’t have to be complicated and, in fact, it can be fun! Rip and Ken introduce simple ways to level up your cooking with tips on roasting, sauteing, and boosting the flavor of pastas, sauces, soups, and more. If you’re on a quest to do more cooking at home, or if you want to increase the depth of flavor in the meals you’re already cooking, this episode will definitely wet your appetite! Episode Resources: Rouxbe Online Culinary School Support for this week's episode comes from Wild Earth Dog Food - use promo code: PLANTSTRONG for 40% order Seeking a solution for making the plant-strong lifestyle convenient and inspiring? The Plant-Strong Meal Planner offers 1000s of recipes customized to your preferences, an integrated shopping list and grocery delivery! Our Engine 2 Coaches are on hand to offer support and answer any questions. Visit our Plant-Strong Meal Planner today and use promo code: HEALTHNOW to save $20 off an annual plan. Theme music for episode

Employment issues as we reopen the dental offices. 

Ken Rubin - Dental CPA and Dental Practice brokerJonathan Ingalls - Dental Practice Broker (questions? jonathan@tdibroker.com)David Barnier - Dental AttorneyA presentation and round table discussion about the about selling a dental practice and any impact these events have brought to this process. An attorney's explanation of the legal terms within a practice sale agreement and how Covid-19 is affecting the content of the legal documents associated with a dental practice sale. How can I protect myself if I make an offer on a practice during these unstable times?How does this compare to the 2008 recession and its impact?How is this issue impacting dental transitions? How might these transitions be different going forward?Are sellers still selling? Are banks still lending? and more...

Logan chats with Dr. Joel Diamond about the value of using genetic and genomic testing to make real-time diagnoses and treatment decisions and how these tests can positively affect the outcomes and treatment paths for a variety of medical conditions.  Logan also talks with Ken Rubin of BPM + Health about how building a community comprised of different levels of patient providers can help deliver a better standard of care.  The following companies, all of whom are exhibiting at  HIMSS 2020 sponsored this episode: Ōmcare (omcare.com), changing the way the world cares with its Ōmcare Home Health Hub™; Fujitsu Computer Products of America (fcpa.com/us) the leader in document imaging and scanning, offering a full range of scanning technologies and solutions; 2bPrecises (2bprecisehealth.com) helping healthcare organizations leverage the full value of genetic and genomic testing;  BPM+ Health (bpm-plus.org), a community that brings together CMIOs from hospitals and healthcare systems, industry and physician associations, vendors, and consultants to create machine-readable clinical pathways that can be shared across healthcare systems; TouchPoint Medical (touchpointmed.com), which designs, manufactures, and sells medical equipment around the world that mobilizes medical technology and manages medication dispensing; and Bridge Patient Portal (bridgepatientportal.com), a company that revolutionizes the patient experience by giving users access to an unprecedented set of tools and services to manage their care through a “single pane of glass.”

On this episode of if/else, host Mayuko Inoue explores a choice faced by many software development teams: which agile methodology should they use?There are several different agile frameworks, including Lean, Crystal Clear, Extreme Programming, and Feature Driven Development, but we'll focus on two of the more popular approaches: Scrum and Kanban.You'll learn about the history and philosophy behind these two methodologies, and you'll hear some perspectives from several developers about their experiences–good and bad–working with these processes.You'll also meet Grant Ammons. Grant is a development team leader at an online marketing tools company. Grant and his colleagues have been working in the Scrum framework, and it has dramatically improved communication with their stakeholders. But they're running into problems with certain aspects of the process, and are beginning to think about giving Kanban a try. To help Grant decide whether to tweak his teams current process or jump into a completely new one, we've enlisted the help of two industry veterans.Eric Brechner is a Principal Software Engineering Manager for Azure at Microsoft. He is also author of Agile Project Management with Kanban.Ken Rubin is the founder of Innolution, an Agile and Scrum coaching and consulting firm, and he's the author of Essential Scrum: A Practical Guide to the Most Popular Agile Process.Ken and Eric join Mayuko to discuss the guiding principles of each methodology, and to debate the strengths and weaknesses of each system. You'll also hear about the types of teams that each approach best suits. The idea is to give Grant, or anyone else facing a similar decision, the information needed to make a solid choice.if/else is an original podcast by CTO.ai, makers of The Ops Platform. The Ops Platform makes it easy for development teams to create and share workflow automations without leaving the command line. Visit cto.ai/platform to join the beta.If you enjoy the show, please leave a ⭐⭐⭐⭐⭐ rating or review on Apple Podcasts.

What was the first thing you learned how to cook? For me, it was scrambled eggs and ever since I’ve been fascinated by food. Cooking has a reputation for being scary and expensive, but it is anything but that.As Ken Rubin, who is an accomplished chef from Rouxbe and our podcast guest says, "Start with one dish, one little thing…master that, and then build out your toolkit of food." Great advice whether you want to turn your love of food into a business or just want to learn how to make a few killer dishes. Learning how to cook is probably one of the smartest money moves you can make – and you can bank on that!What You'll LearnHow can learning how to cook really save you moneyWhat are some staple dishes that everyone should know how to makeBreaking down some of the biggest myths around cooking, including Ken's answer to "I can't cook"How you can turn your love of cooking into a full-time careerSome of the most inexpensive but awe-inspiring ingredients that you might have in your pantry right nowLinksRouxbeSUBSCRIBE & SHAREWant to be the first to know when new episodes are released? Click here to subscribe in iTunes! IT’S FREE!Want to have a cup of coffee this week on us? Leave a review in iTunes and email a copy of your review to info@mmoneypodcast.com. Ask ShannahHave an Ask Shannah question, submit it hereGet SocialShannah on TwitterShannah on Instagram

Orchids tricking Bumblebees Wandering trails around the Bow River valley, it seems like every day there are new and exciting changes taking place. The leaves have begun to emerge and the early season blooms are adding a splash of colour to the meadows and forest leaf litter. Today I saw my first Calypso orchids of the season. These tiny, delicate orchids are one of the first forest flowers to emerge in the spring. The forest floor is still a tangle of pine needles with nary a hint of colour, other than the few green leaves and similarly coloured buffaloberry blooms, willow bushes, and bilberry. Calypso, or Fairy Slipper orchids as they are also known, are one of the most beautiful of the mountain orchids. More intricately coloured than the showier Yellow Ladyslipper Orchid, it takes a keen eye to see the amazing detail in the bloom. Each plant produces a single basal leaf close to the ground. In the spring, not long after the snows have melted, a single stem will emerge to produce a single, tiny flower. They rarely reach higher than 20 cm above the ground and the flowers are only around 3 cm across. In some regions, it's nicknamed "Hider-of-the-north" because it's so easy to miss. While there are 4 species globally, there are only two found in the mountain west, Calypso bulbosa var. americana and Calypso bulbosa var. occidentalis. On the eastern side of the great divide, you'll only see the americana variety while British Columbia, Washington, Oregon, California, Idaho, Montana and Alaska have both. All of the flowers are similar in appearance. The first thing you'll notice on close examination is the typical ladyslipper appearance. Usually, 3 sepals and 3 identical petals rise vertically and to the side of the flower. The actual slipper has a pinkish cover and the pouch is intricately coloured with dark purple streaks. It sports a yellow beard which holds pollen, and a lower lip. In the eastern slopes, the americana variety has a white to pinkish lip while the western occidentalis variety has a lip covered with darker purple spots. Perhaps one of the most remarkable features of the Calypso orchid is that it doesn't provide nectar to the bumblebee queens that seek it out looking for a sugary reward. Instead, they get large amounts of pollen deposited on their body with no actual nectar for their effort. This is not very common in nature. As you can imagine, providing a sugary treat is a huge motivator for bumblebees to come visit. Instead, the Calypso provides bright colouration that says, come over and say hi, and then provides little in return to the bumblebee. Food deception, as this behaviour is known, has seen more intense study during the past few decades. Biologists have come up with a number of theories as to why it occurs. Food-deceptive orchids usually see fewer visits by bees for obvious reasons, but it can also help to ensure cross-pollination by making bees less likely to visit the same plant twice. Two competing theories try to explain how food-deceptive orchids are able to attract pollinators even though they don't offer nectar. The first focuses on the fact that they are often one of only a few bright flowers at this time of year, and this may increase their chances of being visited, despite the lack of nectar. Alternatively, they may still benefit from other nectar-producing flowers nearby. Their blooming period overlaps with a few other pollen producers like willows and some bilberry plants. A 2015 study published in Scientific World Journal found Calypso pollen on 7% of bumblebee queens captured on willow plants, and 18.2% of those visited more than one flower. Since flowering willows make an area attractive to bumblebee queens, the Calypso likely benefits from their proximity. On a smaller scale, the lack of a diversity of other flowering plants helps the Calypso to attract queens that may have been attracted to the area for willow or bilberry nectar. Why not just provide nectar like other flowering plants? Quite simply, it's expensive. Calypso orchids save resources by not producing nectar. A single visit by a queen can take a lot of pollen and so they don't need too many repeat visits. They still need to attract the queen though. Their bright yellow pollen beard and purple streaked pouch provide a visual attraction. They also have a strong smell similar to the smell of vanilla. Essentially, while the flower doesn't offer a reward, it still takes advantage of bright colours and a strong scent to attract a hungry bumblebee queen. In the end, these tricky flowers are able to attract enough queens to ensure reliable pollination. That brings up another question: why just bumblebees queens. The simple answer is that the queens are the only bumblebees around when the Calypso blooms. As summer begins to draw to a close, a bumblebee colony begins to prepare for the following year by producing a final brood of larvae that will contain several queens along with some males. It's those queens that will find a safe place to hibernate for the winter, usually around 20 cm below the surface. They produce glycol in their blood to keep them from freezing to death. Other than these few queens, the rest of the colony dies at the end of every season. After a 6-month sleep, these groggy queens emerge to look for the very earliest spring flowers. In this area, Calypso are one of these wildflowers, along with willow, buffaloberry, and bilberry that greet their arrival. It's this grogginess and the naivete of these newly emerged queens that is likely why the Calypso is able to fool them into pollinating them. As she gathers strength and experience, she'll get to recognize Calypso and avoid them in the future. The next year, it'll be another naïve new queen and the process begins anew. Her next order of business is to find a den. They're fond of mouse, ground squirrel, or weasel burrows. They'll even take advantage of an empty nest box as well. Once she finds a den, she begins the real job of preparing for a new brood of worker bees. Unlike honeybees that can have thousands of individuals, a bumblebee colony will only have a few hundred. She starts by building a wax honeypot that she fills with nectar. This will offer her a food supply when the weather doesn't cooperate. They don't make hexagonal honeycomb-like honey bees, but instead, she makes waxy cups. Into these, she'll lay 5-15 eggs. These will pupate in about 20 days and emerge as adults after 4-5 weeks. From this point on her foraging days are over. These solely female workers will take over those duties and she'll spend the rest of her life in the den laying and tending to eggs. At the end of summer, the colony begins to produce additional queens along with some males. They leave the nest and look for suitable mates. Once mated, the queens will try to feed on as much pollen as possible in order to store up reserves for the winter. She'll then look for a den to hibernate, waking up just in time for a new crop of Calypso to bloom. Let's Talk Parks Canada Way back in episode 26, I dedicated the entire episode to slamming some of the decisions that Parks Canada had made in the previous years that were putting the important ecological integrity of parks at risk. At that time, Parks Canada released the results of an intergovernmental panel that had listened to stakeholders looking into Canadians views on Parks Canada's management of the nation's parks. Simultaneously, they were trying to force feed an $86.4 million dollar bike path from Jasper to the Columbia Icefields - while trails with decades of history were falling into disrepair. To their chagrin, a master of the Freedom of Information Act, Ken Rubin, managed to get all of the original internal documents from Parks Canada's own scientists that reflected the same concerns that many of us had - along with some that I hadn't even considered. To the agencies credit, they didn't deflect the results of the report. They owned. It. Also in their defence, some of the decisions were a reflection of a decade of the Harper government's anti-science, anti-conservation policies. It was a decade of open the floodgates, spend money where it will return the most short-term returns and let the ecology be damned. The Liberals have taken the time to listen to a decade of frustration on how Parks Canada has lost its way. I first came to the Canadian Rockies in 1980 along with my best friend, to hike the 176 km South Boundary Trail running from Nigel Creek in Banff all the way to Medicine Lake in Jasper National Park. Today, routes like the north and south boundary trails are no longer viable backpacking routes. An April 16, 2018 document released by Parks Canada titled Backcountry Fact Sheet for Operators describes the routes as such: "Users of the North and South Boundary trails should consider these more like wilderness routes and expect trees down, with a variety of un-bridged stream and river crossings. Campgrounds are primitive with little if any infrastructure apart from designated areas for cooking, camping and open pits for human waste." When I visited in the 80's, Parks Canada was expanding the facilities at these backcountry sites by providing good toilets, trees for hanging food, and well-designated campsites. It was still a wilderness trail, simply due to the fact that it traversed long distances with little proximity to highways. At the same time, these were also the days of backcountry wardens and we regularly encountered them in the backcountry. In 2018, once you leave the highway, fuggedabout seeing any representative of the Parks Canada Agency. The days of backcountry patrols are long gone. Even the warden cabins are falling into disrepair. Now while the South and North Boundary Trails have always been considered wilderness trails, other trails like the Tonquin Valley Trail in Jasper National Park are not. Back in Episode 10, I talked about growing complaints about Jasper's most popular backcountry trails becoming virtually impassable due to decades of neglect. Jasper's Fitzhugh Newspaper profiled the neglect. It quoted one particular example: "When B.C. resident Philip McDouall set out with three friends to hike the Tonquin Valley Sept. 16, he expected to encounter challenging conditions typical of a backcountry trail. What he didn’t expect to find was appalling trail conditions, dilapidated infrastructure and facilities overflowing with excrement". Of all the trails in Jasper, the Tonquin is one of the most iconic. The article continued: "On top of the appalling trail conditions, he also said many of the campsites are in a state of disrepair with dilapidated cooking areas, broken bear poles and outhouses that were nearly overflowing. At the Clithroe Campsite, in particular, he said the outhouse was so full there was evidence people had been defecating in other areas of the site. 'It was horrible,' said McDouall, 'The way the one chap described it, when you lifted the lid up and sat down you were literally sitting on the last person’s turd'." Why do I dredge up these old stories again? Because this past week the Minister of the Environment and Climate Change, Catherine McKenna published the government's response to the 2017 "Let's Talk Parks Canada" nationwide consultation. The early results of the consultation, which I talk about in Episode 26 was just the first response from the government on the many challenges facing our parks and protected areas, as well as cultural, and aboriginal sites. McKenna, in the government's official response to the consultations published just last week, has reaffirmed Parks Canada's commitment to making the protection of ecological integrity job one. The government has taken a beating over the past few years over the increased development within the parks and the endless focus on bringing more and more cars through the park gates. Most of this was the legacy of the Harper years, but the Liberals are trying to chart a new course. While the words are comforting, we'll need to see whether the words result in action. (I'll add a link to the report in the show notes for this episode). The report puts forward three priorities for Parks Canada going forward: To protect and Restore our national parks and historic sites through focussed investments, working with Indigenous peoples, working with provinces and territories, and ensuring ecological integrity is the first priority in decision making. Enable people to further discover and connect with our parks and heritage through innovative ideas that help share these special places with Canadians. Sustain for generations to come the incredible value—both ecological and economic—that our parks and historic sites provide for communities. The value they bring to fighting climate change, protecting species at risk, and shaping our Canadian identity and jobs and economic opportunity for local communities. These are all things that we have been fighting for for the past decade in the mountain west. During the engagement process, the number one concern voiced was simply that the parks were not being protected and that ecological integrity was NOT the first priority. Respondents also voiced concerns over the reduced role of science and scientific funding in the decision-making process. Parks Canada has historically produced some of the most compelling wildlife research in the country and many of the respondents, myself included, reflected this disillusionment. Along with reductions in scientific funding, rigor, and the freedom to publish, respondents lamented the lack of maintenance of existing facilities. I've covered this in the preamble to this story but the challenge remains. Decades of decline leave long lists for renewal. In defence of Parks Canada though, many good things have begun to happen on this front. There have been huge investments in trailhead facilities in Jasper, along with dramatic investments into the Mount Edith Cavell day-use area. While the focus currently seems to be on repairing long-neglected front-country facilities, it's also important that funds are equally invested in even more decrepit backcountry campsites, trails, bridges, and signage. The more backcountry facilities deteriorate, the more damage the use of backcountry trails generate. If trails are experiencing deep rutting or flooding, hikers will bypass these areas leading to widening or braiding of trails. If outhouses are not maintained than hikers will bypass them and backcountry sanitation is also compromised. Parks has also realized that decisions have not been made transparently in the past. Decisions allowing the Glacier Skywalk, and tentatively an $86.4 million dollar bike trail from Jasper to the Columbia Icefields are only two examples. Other decisions allowing expansions to the Lake Louise Ski areas should also be coming into question. The Icefields bike trail should be immediately cancelled and reviews into the Lake Louise Ski Hill Expansion properly assessed. Participants in the study displayed a lack of trust in the transparency of decisions along with the ability of Parks Canada to really put ecological integrity on the top of their priorities. When stated goals simply don't match management decisions, trust gets eroded. Minister McKenna also vowed to focus on both ecological integrity AND to "restore funding to research, ecological monitoring, and public reporting." The past decade has not been easy on Parks Canada and the nation's parks and reserves desperately need stable funding to ensure important research is ongoing. The 30-year study of wildlife movement corridors and highway crossing structures is a great example. The global value of this study is largely based on its long years of study. Good science takes time, and this study shows dramatic changes in wildlife adaptation to crossing structures over time. Without stable funding, science like this would be lost. We need the federal government to be a leader in research, ecosystem and facility restoration, and environmental assessments. These pillars can help to reduce some of the damage caused by a decade of neglect. Traffic management in busy parks was also a key point in the feedback received by Parks Canada. Over the past decade or so, with deteriorating backcountry conditions and increased frontcountry development, some 95% of the traffic visits the same 2% of the park - the paved corridors. As an example, traffic on Banff Townsite roads increased 17% between 2014 and 2017, increasing from 22,600 to 27,500 per day during July and August. This weekend's Victoria Day holiday could see a repeat of last year. On the Sunday of the long weekend, Banff saw 31,600 cars moving in and out of the townsite. The roads are only designed to accommodate 24,000 cars per day. The cars backed up at both entrances to town with delays in some cases stretching as much as 30 minutes. This doesn't even take into account the increased transit service in the mountain parks. Local Roam Transit saw an increase of 25 percent during July and August. While the final numbers are not in, it's expected that some 700,000 riders will have taken advantage of the service. In addition to this, vast numbers used shuttles from Calgary to Banff, Banff to Lake Louise and Moraine Lake, and from the Lake Louise overflow campground to Moraine Lake and Lake Louise. Last summer, ATS Traffic performed magic in terms of keeping vehicles moving, reducing traffic jams, and keeping people from parking for kilometres along busy roadways. While this is laudable, we need to ask ourselves an important question: how many visitors are simply too many? If our focus is on bringing more and more and more people to the shore of Lake Louise, we may reduce traffic snafus, but we are also negatively impacting the visitor experience. Ten years of the Harper government trying to push as many cars as possible through the gates to cash in on the rush didn't factor in the importance of the experience. Tourism is fickle. The experience is critical. Last summer, I was on a multi-day trip and was finishing my day at a hotel in the Village of Lake Louise. My most beautiful lady, Jules was coming to meet me to stay the night and have a nice dinner at the Station Restaurant. She drove from Canmore to the Lake Louise exit. To meet me, she needed to take a left turn off of the exit, but the ATS Traffic staff forced all cars to turn right towards the ski hill. She complied, even though it was the wrong direction. When she had an opportunity, she did a u-turn to head back towards the village. When she got to the village, no vehicles were allowed up the road towards the Chateau. Instead, they were all required to turn right to go towards the Station. She was becoming increasingly frustrated and was on the verge of heading home when she was finally allowed the right of way. Essentially, they were stacking cars off of the highway. The roads don't have the capacity to accommodate so many vehicles trying to go up the hill to the Chateau, so the ATS staff were simply stacking the cars along any road that was available. This prevented cars from backing up into the busy traffic lanes of the Trans-Canada Highway. It was one of the most painful tourism experiences I've witnessed, but safety was the primary concern. When we walked to the restaurant, we chatted with drivers stuck in the various stacking lanes and they expressed major frustration. Many had travelled long distances to see Lake Louise but instead were stuck in Toronto-style traffic. Even if they eventually made it to the lake, along with the thousands of other visitors in their convoy, the experience was not a positive one. As a destination, we can't afford large groups of visitors flocking to sites like Trip Advisor and saying: "don't go to Banff…they've ruined it!". We need to look at hard limits to the number of people that can visit sites like Moraine Lake and Lake Louise. As much as we need to appreciate the revenue that each additional car brings, we also need to think of the future. If tourists of today slam the experience, then how many visitors will come tomorrow? This doesn’t even consider the impacts to wildlife and ecological integrity that comes about as a result of high-intensity, volume tourism. Since park fees stay in the park they're collected, it forces the park to rely on those dollars for their operating costs. When parks depend on gate fees, it's hard to imagine they can focus on improving visitor experiences and ecological integrity when doing so requires them to give up large amounts of important operating income. The funding of the park should NOT require the park to compromise its mandate in order to have the cash to keep the lights on. One of the final topics covered by Minister McKenna has to deal with expanding opportunities for new people to experience Canada's Parks. She repeatedly mentions "new Canadians" as a group that, as the future of Canada, need expanded opportunities to explore and learn from our natural landscapes. I totally agree that new Canadians can play a huge role in the future of our parks but we need to facilitate the experiences in a way that will help them understand the ecology, sensitivity, and uniqueness of the parks. When literature is only available in two arbitrary languages, we're not facilitating the experiences of visitors whose first language is not English or French.  Canada has huge numbers of tourists arriving from countries like Germany, Japan, India, Taiwan, Korea, and increasingly, China. Many of these visitors don't come from places with intact wilderness or truly WILD life. We read about wildlife habituation and other park management challenges, and often the names in the articles reflect the potential for language barriers. We need to make sure that the literature we provide to visitors is in a language they can understand. If we want visitors to the National Parks to respect and appreciate nature, we have to help them understand just how delicate wilderness really is. That is best done without artificial barriers. All literature should be available at least in English, French, German, Japanese, Mandarin, Spanish, Hindi, and Arabic. I would also argue that Parks Canada should reach out to diverse communities through outreach as a way to help bring the messages of conservation to these same communities in their native language. Let's make sure our visitors have all the tools they need to have the best, and safest, visit possible. The landscape will thank us for it. And with that, it's time to wrap this episode up. Don't forget that Ward Cameron Enterprises is your source for step-on, hiking, and photography guides in the Canadian Rockies. You can find us online at www.WardCameron.com or visit our Facebook page at www.Facebook.com/WardCameronEnterprises. If you'd like to reach out to me on Twitter, you can hit me up @wardcameron. Don't forget to visit the show notes at www.MountainNaturePodcast.com/ep060 for links to additional information as well as an easy subscribe button so you'll never miss an episode…and with that, the sun's out and it's time to go hiking. I'll talk to you next week.

Joe Krebs speaks with Ken Rubin about agile budgeting and planning. Ken was the first Managing Director of the Scrum Alliance back in 2006, is the author of the book "Essential Scrum" and he became an Angel Investor in recent years.

Jochen (Joe) Krebs speaks with Ken Rubin about agile budgeting and planning. Ken was the first Managing Director of the Scrum Alliance back in 2006, is the author of the book "Essential Scrum" and he became an Angel Investor in recent years.

Have you heard part one of the podcast yet? bit.ly/2vBBImV In this second half of my interview with Ken Rubin, we talk about common leadership mistakes, the importance of the Economic Framework, and the benefits of limiting WiP. Be sure to check out my blog for all the questions asked, timestamps, and links to everything mentioned: http://bit.ly/2vY0k80 Thanks for listening! I'd love your feedback.

Story 1 - First Bison Born in Banff Well, today, I'm able to share several good news stories that makes all the work worth it. While we are constantly being bombarded with bad news, it's always exciting when the hard work of thousands of people has a tangible impact on decisions taking place in the places we love. So let's take a look at the great announcements filling the newswires this week. First on the list has to do with the cutest thing on earth – baby animals. Spring is the time of new life in the mountains. Over the next month we'll begin to see mule and white-tail deer fawns, elk calves, and those oh so cute black and grizzly bear cubs. So what makes this year so special? How about the first bison calf in 140 years to be born in Banff National Park? Now if that's not cool enough, not only is it the first bison in more than a century, but it was born on Earth Day, April 22, 2017. Story 2 - Icefields Trail Stalled Parks Canada has been planning a paved bike path running all the way from Jasper to the Columbia Icefields, and eventually all the way to Lake Louise and possibly Banff. This 86.4 million dollar trail has been hugely unpopular by conservationists, researchers, and as was revealed recently, Parks Canada's own scientists. Freedom of Information crusader, Ken Rubin peeled back the curtain of secrecy and has been revealing the long trail of public documents and emails that led up to the decision to build this trail. One of the most telling signs was the fact that Parks Canada actually posted a tender for engineering firms to begin the design of the actual trail. This is especially troubling since the trail is not even through the public consultation phase and has not been given any official go-ahead from the powers that be. Well it seems that the overwhelmingly negative response to this tender has finally caused Parks Canada to pay attention. This week, the tender was withdrawn. According to a story in the Fitzhugh Newspaper, Minister McKenna's press secretary, Marie-Pascale Des Rosiers said: "This was determined to be premature given that the agency is currently focused on the consultation process and the environmental assessment for the proposed project". Story 3 - Big Wins in Canmore's Wildlife Corridor Battle This has been a week of very good news in Canmore particularly in terms of the struggle to designate the last critical wildlife corridor on the south side of the Bow River valley. On April 26th, Alberta Environment and Parks announced that they will not be making a decision on the Three Sisters Mountain Village and Smith Creek Wildlife Corridors for at least another four to eight weeks. The very next day, Three Sisters withdrew from consideration, its area structure plan for its Smith Creek Development until the provincial government renders it's decision on the corridors. They did move forward with their submission for first reading of the Stewart Creek Village Centre area structure plan. But in a third blow to the developer, on May 2nd Canmore Town Council unanimously rejected Three Sisters asp for its village Centre development. Story 4 - Anglers Beware If you're one of the many anglers that love to cast a fly in the Bow River to test your luck against the prevalent trout population, you'll want to pay attention to this story. Beginning on April 1, the entire stretch of the Bow River from its headwaters at Bow Lake in Banff National Park to the Bassano Reservoir is now catch and release only. And speaking of Whirling Disease, it has now been confirmed in the entire Oldman River watershed as well. The disease now affects rivers throughout the western boundary of Alberta from Bow Lake south to the Montana Border and Waterton Lakes National Park. Despite this recent report, the Oldman River system will not see any changes to fish regulations at this time. Story 5 - Updates on Transportation and Parking for Banff In the past, it has been difficult to get to and from the mountains without a vehicle. There are a number of airport shuttle companies and a few regularly scheduled buses, but not really a proper transit system connecting Calgary with Canmore, Banff and Lake Louise. This summer, it looks like a number of players are combining to help solve this problem. One of the first stories was a new transit service between Calgary, Cochrane, Canmore and Banff. The service will run on weekends and holidays, beginning in mid-June and ending on Labour Day. The buses will be run by the Calgary Regional Partnership and will also allow valley residents to use the buses to travel to Calgary for the day. The cost of the buses will be $10 each way per person. The program would dedicate 3 buses to do approximately 13 round trips per day. The first bus will arrive in Banff around 8:30 am and the last one would leave Banff approximately 10:30 pm. The buses will pick-up and drop-off at the Crowfoot LRT Station in Calgary. A few morning and evening trips will pick-up and drop-off in Okotoks, Somerset-Bridlewood in South Calgary. There will also be additional bus service this summer between Banff and Lake Louise, as well as the Lake Minnewanka Loop. Both of these buses are also intended to encourage people to park their cars and reduce some of the strain on the busy road systems. On sunny summer days, the highway interchange at Lake Louise is completely closed as the roads become overwhelmed by the number of cars that want to visit. And finally some great news for traffic in and around Banff Townsite. On April 25th, Karen Sorensen, Mayor of Banff announce a new transportation hub and 900 stall parking area to be developed adjacent to the Banff train station.

Ken Rubin, VP of Culinary Training at Rouxbe online cooking school and a food anthropologist. Learn what food anthropology is, about the food culture in America, what the Rouxbe school is, and along the way learn some helpful cooking tips which I used the same day. I hope you enjoy listening as much as I loved talking to Ken. Enjoy!

The Agile Mindset.  We've all heard that term, but what does it mean? What effects can it have on an organization if they are just adopting the frameworks without the mindsets? Ken Rubin and I spend this episode discussing the Agile Mindset. He shares how it effects delivering working software in companies, how he uses it in his family, and even as an angel investor in how it helps him make decisions on who ( and who not) to fund.  Ken also shares  his unique “Colonel Klink” test (from Hogan’s Heroes)  to help determine if someone has and agile mindset or not.   About Agile Amped: The Agile Amped podcast series connects the community through compelling stories, passionate people, shared knowledge, and innovative ideas. Fueled by inspiring conversations with industry thought leaders, Agile Amped offers valuable content – anytime, anywhere. To receive real-time updates, subscribe at YouTube, iTunes or SolutionsIQ.com. Subscribe: http://bit.ly/SIQYouTube, http://bit.ly/SIQiTunes, http://www.solutionsiq.com/agile-amped/ Follow: http://bit.ly/SIQTwitter  Like: http://bit.ly/SIQFacebook

Do you work in an organization that expects development to be agile but doesn’t see any advantage of changing the way the rest of the organization operates? Do your colleagues in sales, marketing, finance, legal, HR, governance, etc., unintentionally make your job more difficult just by doing things they way they’ve always done them? Do you try to explain that agile requires changes across the organization, only to hear, “But agile is all about development, right?”The reality is that if we want to be successful with agile, I mean truly reap the benefits of what we expect to get from agility, then we need to embrace agile throughout the full value chain. In other words, the non-development parts of the organization have to embrace agile and align their efforts with those of development.

Please checkout out this exciting interview with author of Essential Scrum, Ken Rubin. Ken is a distinguished author, speaker, and Agile instructor. He has worked with many of the nation's top companies, and he joins us in this episode to tackle some of the tough questions facing teams as they adopt Agile.If you haven't already read Ken's great book, please pick up a copy of Essential Scrum on Amazon today!  You can also read Ken's blog and learn more about his services through his website innolution.com.I hope you enjoy this episode and please remember to subscribe in iTunes. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: coach@agileinstructor.com.All Things Agile - Episode 011 - Ken Rubin InterviewTranscript:Welcome to the All Things Agile Podcast – your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast in iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.Ronnie: Hello everyone and welcome to All Things Agile. I’m very excited to announce that Ken Rubin is our guest today on the show. Ken is a noted author of Essential Scrum as well as being a public speaker and Agile instructor. Before we begin, a quick reminder that this podcast is for informational purposes only and we accept no legal liability. So let’s get started! First off, Ken, thank you so much for joining us on this episode.  I am really glad to have you on this show. I’ve given the audience just a quick introduction, but can you please take a few minutes and explain a little bit more about yourself, both personally and professionally? We really want to get a chance to know you.Ken: Sure! So my background is software engineering. My degrees are all in computer science and I’ve had a typical path through most software companies. I’ve been a developer, project manager, VP of Engineering at a number of companies both large and small. I’ve done 10 startup companies in my career, and I’ve taken two of those public on the NASDAQ. I did my 2 year stint with IBM in the mid-1990s. I’ve helped companies and I worked with 130 people; we ran around North America building large distributed object systems and if anybody’s old enough to remember, I came out of the Small Talk world. Back in the late-1980s, I helped bring Small Talk out of the research labs at Xerox PARC, and I worked with a startup company that was a spin-off of Xerox PARC called Barclay System. We were the early market object technology folks.  So we brought Small Talk and object technology to the market.I’ve been doing Agile since the early-1990s. Scrum, formally, since 2000. In those days, I worked for a startup company in Colorado called Genomica. It was a 90 person engineering team, and they let the VP of engineering go. I ended up inheriting the engineering team which wasn’t functioning all that well and we transitioned everybody over to Scrum. And that ended up working out much better for us. And I’ve been using Scrum ever since, about 14 years. These days, I spend my time out either doing Scrum training classes and Kanban training classes or doing coaching. And, I hope that in our discussion today I can go over a number of examples that I had the benefit of seeing a lot of different companies and what’s working and what isn’t working.Ronnie: Thank you for the introduction Ken. I’m really looking forward to the insights you can provide us based on your considerable experience. The first question I’d liked to ask you, regarding your book Essential Scrum, is in regards to the dedication and introduction. It really got me thinking about the importance of relationships and software. I also started thinking about how relationships or soft-skills play into the success of Scrum. What is your insight or your advice on how relationships affect Agile teams?Ken: It’s a good question to start with. To me, the unit of capacity in Agile is the team. Even the Agile Manifesto calls that out – individuals and interactions over processes and tools. It really is about the team. So how they interact with each other, how they perform is of outmost importance. The relationships among the members of the teams is critical. If you’re going to have self-organizing teams, they have to have trust in one another. That’s one of the characteristics that, for me, distinguishes a group from a team. Group, simply being a bunch of people that I threw together with a common label. And honestly, the only thing they have in common are the T-shirts they printed out that have the name of the group on it.A team is a group that’s gone through the stages. Sort of the top most stages: forming, storming, norming and performing. And if you can make a real investment to turn a group into a team, first, they had to figure out these soft skills issues: how to work well together? Otherwise, they would never become a high performing team, and they would constantly be at odds with one another. So one of management’s responsibility is to help put the right people on the team, but once they’re there, it’s the soft skills that help bring these members together, that help them work well and function well. In most Scrum classes, there’s an exercise: the Yes – And, vs the Yes – But exercise. And the intent behind that – it’s actually an exercise that borrowed from improvisational comedy training and the idea is to try and help teams understand how to work well together, how to form those relationships, how to take one person’s idea, build on top of it and not be in a Yes – But style passive-aggressive cutting things down: ‘Yeah, I heard what you said; it seems like a good idea but let me now tell you why it sucks.’ That’s not a foundation for building a high performance team. If the soft skills are not addressed, then likely you won’t have a style of organizing teams which are the unit of capacity in doing Agile and for that reason, you’ll likely fail.Ronnie: I definitely agree. What came to my mind is the book ‘Speed of Trust’ by Stephen Covey. It describes how trust is a major factor and how people fill in the gaps in communication and that with a high trust environment, the team is able to move more quickly.Ken: I think it’s really important. How we disagree is as important as how we do agree. At no point would I ever suggest that team members shouldn’t disagree, or shouldn’t have a vigorous debate. They should do it though in a very proactive way; in a way that’s reinforcing their ability to come up with an innovative solution, not inhibiting that ability. So if they don’t have the skills to work with each other and challenge each other, then very likely that the best achieved is mediocrity.Ronnie: Excellent point! And I think that leads into our next question: There is a quote in your book that I love, which is that one of the benefits of Scrum is that it really exposes existing issues. I couldn’t agree more. It’s been my experience that Scrum really sheds light on underlying problems or processes that are actually bottlenecks. One of the challenges that I’ve seen is that sometimes the personalities and procedures that were in place before adopting Agile may be discovered to be part of the concerns. Some of the potential personalities involved may even be in leadership roles. So one question I would like to ask you is, how does an organization work on improving their adoption of Agile when much of the legacy culture, leadership style and procedures are still in place?Ken: This is actually a critical question and how people respond in this situation, to me is one of the tell-tell signs as to whether they’ll be successful – let me give you a specific example. Some years ago, I was giving a management presentation during lunchtime in front of my boss. So we budgeted 90 minutes, brought in food, the management team. So senior management and director level people and some VPs are in the room and I made the following comment; I said – by the end of your Sprint, you should get the work done and you should have zero known defects on what you just built. And I also mentioned that people that have historically been members of the testing team should be fully integrated in with developers in a single team. They should work together collaboratively with zero defects to get things done.Immediately this lady in the back of the room raised her hand. She said ‘This won’t work here’. I said ‘Why not? What part of that?’ She said ‘I manage the QA team’. She goes ‘You just told me that I should assign my people on to the Scrum team.’ Yes, right – we work collaboratively that way. She said ‘Yeah, well here’s the problem. You also said that at the end of every Scrum we should have zero known defects and the reason that won’t work is because we compensate our testers based on the number of defects they find.’ So she’s saying basically that’s not very motivating if you’re one of my testers because you’re going to make less money if you do that.Now, what she says next is the tell-tell sign for me as to whether a company has a hope of being successful with Agile. Here’s what she didn’t say. She did not say ‘Well, in that case, I’m just not going to assign my people out on to the Scrum teams. I’m not going to do that, I’ll just keep them together’. Meaning, I see the impediment. Agile has shone a bright light on where we have an impediment. And rather than address the impediment head on, instead what I’ll do is I’ll alter the definition of Agile so that that impediment doesn’t exist. Now, companies that are bolted to that approach will probably fail and fail quickly with Agile. Instead, what she actually said was ‘I think I’m going to have a conversation with the VP of HR and the VP of Engineering so that we can discuss how we’re going to change the compensation plan for our testers’. Now, we have in place people that understand that the current process, the current compensation system is at odds with them being successful with Agile. And rather than run away from the problem, hide when the impediment gets exposed, we’re willing to address it head on. So my advice – if you don’t have the executives trained or understanding these key points, you’re likely to have a problem. By the way, her next comment – I mentioned other things; I don’t pull people off of Scrum teams to work on your pet projects. Another person raised her hand and said ‘I do that all the time – what else shouldn’t I do?’At least in an environment like that, they’re willing to entertain it. So my approach to trying to address the problem is the leadership requires the proper kind of training and coaching principally on core Agile principles. That’s where I try to focus with them. So if I can get 60-90 minutes with them over lunchtime, that’s a good start. Not as good as having them in a multi-day class, but they’re not willing to make that commitment usually. So get 60-90 minutes, help them to understand that core Agile principles and hopefully they can align their behavior with how we’re going to do agility downstream, cause if they don’t, we will have a serious disconnect and companies with a better experience at that will likely fail in their attempt to use Agile, because of that disconnect. It’s a critical question and either they’re going to understand what we’re trying to do and embrace it, or they’re not and these companies are going to have a hard time. Ronnie: I love that example! One of the approaches that I’ve seen previously is that the director VPs and executive teams actually complete certified Scrum Master training. I believe that really helped them understand the vision and what Agile teams actually need.Ken: I find it beneficial when people like that, people with high level titles actually attend the classes. Part of the benefit is not just their understanding, which is profound, but a second benefit as well. You know, for example – in one class, I was talking about how teams should give range answers to questions as a way of communicating uncertainty. Range answers to planning questions, like ‘When will you be done?’ Give a range answer: between X number of sprints and Y number of sprints. And in this one class, an engineer stood up and said ‘Yeah, but my management is never going to accept a range answer’. And there’s only one person in this class – it was a large class – and the only person in this class wearing a suit was the general manager of the whole division. He then stood up, turned around and said ‘Well, I’m the guy asking the questions and I’m telling you I’m willing to accept a range answer and I’d like to talk to you about how we can keep range answers within one calendar quarter – but yes, a range answer will be acceptable’.That pretty much addresses the whole point right there. People are looking at each other, are like ‘Okay – he is the guy who’s asking questions and he just said he’s willing to do it and I guess we can actually move on here under the assumption we can provide range answers’. So getting the senior execs in a classroom, I think it’s a high priority – but it doesn’t happen nearly as frequently as it should. Occasionally, I’ll get the luxury of having a one day – and rarely, but it does happen – a two day class with leadership. I would say one of every four classes I do, we have that hour to 90 minutes lunchtime conversation. Which is precisely an hour to 90 minutes good, not as good as a half a day or a day or two would. Ronnie: Great answer! Leading to my third question which is adaptive vs. predictive, which is referenced in your book. One of the examples that came to my mind was release planning. Could you please take a moment to explain to our listeners adaptive vs. predictive and perhaps how it might apply to release planning?Ken: Be happy to. A lot of folks, when they think of Waterfall, they think predictive. Predictive up front water. In Waterfall, we have to put together the full requirements document on the first day, when we have the worst possible knowledge we’ll ever have about that project. So to a certain stage, you have to predict. If you’re being rude, you’d say you’d have to guess what all the requirements are. A lot of people didn’t think of Agile as adaptive – more just in time. So if you imagine like these two being on either sides of a teeter totter or a see-saw, what I’d like to suggest is that if you’re overly aggressive in either dimension, overly predictive or overly adaptive, you’re probably going to be unhappy.If you’re overly predictive, you’re probably just going to dip down into the guessing pool. There’s a part of you who might say ‘You couldn’t possible know that – not on the first day, not when you have the worst possible knowledge you’ll ever have!’ At this point, you’re just guessing, and that seems dangerous. On the other hand, if you’re fully adapted and you’ll do everything just in time, which in the context of release planning would mean no upfront planning whatsoever, my guess is that’s going to feel chaotic. Agile isn’t about everything done and adapted just in time. It’s about finding balance; balance between up-front work, predictive work and downstream adaptive work. And where you set that balance point will be different for different types of projects or products, different companies.So let’s buy into the fact that it’s a misperception to believe that Agile is anti-upfront planning. Because, of course, that’s simply not true. Agile is anti-waste. And if you do too much planning upfront, then you’re going to inject too much unnecessary planning inventory into the system that’ll have to be reworked or thrown out when something goes wrong. So the principle here is upfront planning should be helpful, just not excessive. In the spirit of just enough, just in time. But there’s nothing in there that says ‘avoid upfront planning’ so release planning – if you very specifically look at that, if you define what it means, in today’s world release planning is becoming a harder term to use because in the past, a release typically was performed after multiple sprints of work were completed. So in that scenario, a release was larger than a sprint. But what about the teams that release every sprint?You can argue ‘Well, isn’t sprint planning the same as release planning?’ Or what about teams that do continuous delivery or continuous deployment. They can release every feature as it become available during this sprint. You can even argue that in that context, a release smaller than the sprint. So let’s change the term just for a moment. Let’s call it longer term planning. And people might say ‘Well, longer than what?’ Well, longer than a sprint. Even if you release every sprint, or even if you release multiple times during the sprint, there’s still a benefit to looking out at a horizon that’s larger than a single sprint. We might be using milestone releases along the path to a bigger goal. And so release planning, is really trying to plan to that large goal.Okay, that presents certain issues. Here you are at on the first day of the project – what if that longer goal is 6 months out? Or even longer? Can you actually give any kind of accurate answer that early on? And the answer is that you’re going to get asked the questions. And we all know what the questions are. Questions like ‘When will you be done?’ or ‘How many of those features do you think will be available 6 months or 9 months from now?’ And ‘What’s all this going to cost?’Now, these seem like fair questions to ask. And for us, trying to be in a position to answer them, we need to figure out what realistically we can do. And the good news is we can do some things. And the way we’ll address it is, much like I was suggesting earlier, we give range answers. In release planning, the smart approach is always give a range answer to questions. If they ask, ‘When will you be done?’ – stating a specific date is likely going to be overly precise. On the first day of the project you cannot be that precise, you don’t have good enough information. But I can always be accurate by giving a range. You just have to give a sensible range. If I tell you it’s going to take 4-7 sprints to get this done; that expresses one level of uncertainty. If I said it’s going to take 4-29 sprints; that would express a completely different level of uncertainty.At a certain point, I know I can always be accurate, but it could be ridiculous. Yeah, it’s going to take between now and 3 years from now – yeah, but that’s not very helpful. So we try to give range answers that are accurate, that are reasonably actionable by the people who hear them. They can make a business decision – ‘Should I do this, should I not do it?’ So we have to do some amount of upfront planning to be in a position to answer those questions. Typically, at the release planning level, we try to work with medium-sized stories. Not epics that tend to be too big, but use more portfolio level planning, but with some people might call features or even themes so we try to generate a first pass at those, input high level size estimates on them and then based on a team’s history velocity, or a forecasted velocity, we try to give a rough estimate. And we try to simplify the problem. If someone says ‘Well, my release is going to be 2 years out’, I don’t think that’s a reasonable timeframe to be planning. Especially because there’s likely very important increments along that path that we can plan first. Rule number one is always try to turn a big problem into a small one in planning. And always give range answers. So I do think by balancing upfront, predictive work, sort of adjusted time adaptive work, we can do reasonable release planning. With a very important caveat. We update the release plan every sprint. Release planning is not a one time at the very beginning activity. Yes, I did do it early on because I probably got asked some questions I had to address. But I update my release with every single sprint as I acquire better knowledge. That’s how I tend to approach it.Ronnie: Perfect answer. Our next question is also from Essential Scrum which is in regards to idle work vs. idle workers. I’ve seen this come up countless times and it can be very frustrating on me. I often see management focused on idle workers. For example ‘Why is this person only at X percentage of utilization and rather than a team mindset of why is there work being idle?’ Could you please take a few minutes and explain idle work vs. idle workers for the audience? Ken: I will. To me, this is a critical topic, and I cover it in all of my classes because it lays a foundational principle that I need. The way I try to explain it to folks is this way: the largest cost in software product development is the people. Once we buy hardware and whatever software people need to do their job, the real cost of any software organization is the cost of the people that are hired, which is why budget almost always equals headcount. Everybody is interested in eliminating waste, but the issue of course, is that within organizations there are multiple forms of waste. And these types of waste typically trade off, meaning it’s usually impossible to simultaneously eliminate all forms of waste. So what people tend to do is they go after the waste they can see. And since we said the largest cost in software product development is people, then a visible obvious form of waste would be underutilization of people. Meaning, if I hire someone to do testing and I pay them 100% salary, there’s an expectation that that person is going to test 100% of the time. And by the way, my management probably measures me on how busy I keep that tester, so they assume that the tester reports to me. If I hire that individual in, pay them 100% salary and assign them to a project, and that project requires 60% of their time, if I were to stop there, it would give the appearance of a 40% underutilization of my tester. And I’ll look bad to my management because I’m paying this person 100% salary, but the individual’s only working 60% of the time. Okay, that won’t do.So to solve the problem, I’m going to do the obvious. I’m probably going to assign that person to a second project, which will lead them up 30%. Okay, I now have them at 90% utilization – but there’s still a 10% underutilization – well, it worked so well for 2 projects, let’s try 3. Okay, clever me. I’ve now eliminated idle tester waste. I’ve driven underutilization of my tester to 0. They’re 100% utilized. So I have eliminated that form of waste. The question, of course, is what just went the other way? Meaning, we said sometimes waste trades off – as one goes down, the other goes up. Well, here’s the problem. The idle workers weren’t waste that was causing the most economic advantage. Here’s the problem: as we keep people that busy, chances are they’re going to need to start blocking work. As an obvious example, I’ve assigned that person to work on 3 separate teams. It’s very likely, at any point in time, that person’s blocking two teams. They’re working on one of the projects and the other two are waiting. That means, the work is now idle.So what you end up seeing is this inventory that’s building up all over product development. Inventory being blocked work sitting in queues, waiting to get done. And the problem is that blocked work, that inventory, is causing huge economic damage. And people don’t focus on it because that’s an invisible form of waste, hard to see in our inventory and product development because typically, it’s bits out on the disk, code out on a server in best cases. Whereas inventory in other cases tends to be more visible. So they go after the visible ways which is idle workers and they ignore the kind of invisible ways. The people are still 100% busy, so it looks like the system is working at capacity. The problem is that if you examine what happens in large companies, at scale, if you look at how work flows across their organization, across the system, the collection of teams they put together to get the job done, what you often find is up to 90% of the time, the work is blocked.Imagine you took a stopwatch out of your pocket when a customer asks you to work on a feature and you agree to do it. If you click the stopwatch at that point and time starts running, you don’t get to click the stopwatch again until you’ve actually delivered the features to the customer. And so, what I’m saying, from click to click on that stopwatch, in a lot of organizations that I visit, up to 90% of the time or more the work isn’t moving. And that’s causing severe economic damage and the reason I say that is it’s injecting a cost of delay. The work could have been done faster and delivered to customers faster and delivering work faster generates revenue today; revenue today is worth more than revenue tomorrow because revenue today generates money and money is a time battle. When you compare the cost of delay, of idle work, against maybe a little bit of underutilization of the workers you realize that you’re working on the wrong thing.In organization, it’s all about the idle work, but that’s exactly the opposite of what most companies do. Most organizations attempt to optimize the utilization of their people, and by doing so, they inject a lot of delay into how long it takes to get the work done and that delay has a real cost. And they don’t quantify it, so they don’t really see the impact of that. So you focus on the idle work, you don’t worry about the idle workers. You’re trying to achieve what I call ‘fast, flexible flow’. To very quickly flow the work across to your teams in a fast and flexible way. You subordinate other decisions to that, which means ‘I don’t really care how idle or how occupied or how utilized your workers are, but I do care about is how quickly you can pull the work across your organization in a high quality way.’ Though in a sense, most organizations are focused in the wrong place. They’re watching the workers when they should be watching the work. That’s the concept here.Ronnie: Well, unfortunately I’ve seen that happen many times, and especially with the example regarding QA. It is such a common practice to do just what you described – when one person is placed on multiple teams to boost utilization numbers. That practice actually injects more project risk because if the person is working on team A, B and C – if team A hits a major bump in the road, there’s no margin to absorb it. Work simply becomes blocked in the other teams, it can really cause havoc. I love your answer which forces the organization to ask better questions.Ken: It’s a good example. I’ll leave you with one analogy for the listeners. And I know it’s the extreme analogy, so don’t get upset because it’s just extreme, but it’ll illustrate the point. Isn’t it true we pay firefighters to be idle most of the time? If you think about it, you really don’t want to keep your firefighters 100% utilized, because if you do, then the next fire that breaks out, very likely structures will burn and people might die. And as citizens, we deem that to be unacceptable. So we actually pay firefighters to be idle most of the time. Why? Because when you need them, you need them. And you need them now and any cost of delay associated with that work is unacceptable because the ramifications are too great. But I’m not saying you should pay people to sit around and be idle on your software project. But I’m suggesting the fallout – if there’s a certain skillset that when you need it, you need it; and any delay in it becoming available blocks your work and there is significant cost of delay in the blockage, you might want to seriously rethink the strategy of trying to keep everybody at 100%. Ronnie: Very true, I love that example. There are tons of questions that I would love to ask you, but I definitely want to respect your time. With that said, my final question is in reference to Validated Learning, which is mentioned in your book, Essential Scrum. I’m a huge fan of Validated Learning and the Lean Startup by Eric Ries, which I highly recommend. We may have some audience members that are not yet familiar with the concept and how it might apply to their team. Can you please take a few minutes and explain to our listeners Validated Learning? Ken: Sure. Lean Startup is a very good book and does leverage core Agile principles and a lot of the terminology, which is why I’ve used it in the Essential Scrum book, because it very nicely captures a category of principles that are fundamental to Agile. And the way to think about Validated Learning is you should validate important assumptions fast. It’s dangerous to make an important assumption and have it live long in an invalidated state. Because if I make an assumption and I don’t go out and get it validated, I start building things or making other decisions on top of that assumption and if a long time later I finally validate or attempt to validate the original assumption, what if I determine the original assumption was wrong? Now, I’m likely sitting on a problem that is much, much larger than it needs to be. So most people are familiar with the techniques of performing validated learning, prototype, concept study, experiment – meaning that validated learning is the act of buying information when you’re presented with a high degree of uncertainty, and therefore you made an assumption, if you were certain about something – you wouldn’t have to make an assumption, you’d just make the correct decision. But in the presence of a high degree of uncertainty, you have to make these assumptions and then what you have to do is go buy knowledge, buy information to validate your learning, meaning to be able to confirm or refute the hypothesis that you stated, the assumption that you made is correct or it isn’t.You just have to do that fast. So, in Agile, if you think about a learning block – you make an assumption, then we build something, then we get feedback on what we built, then we inspect and adapt, the goal is to go through that loop very very quickly. So in Agile the third part of this Validate Learning is that you have to organize the flow of your work to get fast feedback. In a sense, you say ‘What is the next most important thing I can learn?’ and then go learn it. And then validate your learning. And if you learn that you’re going the wrong way, take what you learn, plant your foot and alter your direction. Take the learning that you have and maybe go to a better place based on that. So Validated Learning has two superior economic characteristics. One – it prunes a bad path quickly. If you’re going down the wrong path, which you don’t want to do, is keep running down that path very fast. You’d like to determine you’re on the wrong path quicker so that you can then pivot over to a new path. That’s economically valuable. The second economic characteristic – it helps your exploit an emergent opportunity faster. What you don’t want to do is learn late in a project: ‘Wow – there’s a much better way we could’ve done this’. When it’s likely to do anything about it in this release and maybe in the future. Maybe we’re so far down committed on the path we’re on that even though we all now agree there’s a much better way of doing it, we actually can’t exploit it. By validating your learning sooner, you’re able to them exploit those opportunities sooner and end up in a much better place.So this is a critical concept. It applies in startup companies, it applies in well-established companies; they’re building the next generation product that’s been there for 10 years. You have to validate your learning, validate the important assumptions fast and you organize the flow of your work to get that fast effect.Ronnie: Thank you so much, Ken, for being such a great guest on our show. I’d love to give the listeners an opportunity to learn more about your services and how they may be able to contact you. Can you please take a few minutes to expound upon that?Ken: I appreciate that. I have a website, it’s innolution.com and on there I have a blog that I talk about a lot of these topics and I also have a lot of my presentations that I give at conferences so, if anybody’s interested feel free – you can go down and look at presentations on portfolio management, on what I call Essential Scrum and a variety of other topics, the most recent being risk management. So by all means, feel free to have a look at that. Mike Cohen and I also have developed a tool called Comparative Agility. It’s a free survey that you can take which at the end tells you how Agile your team is by comparing you with close to 13,000 other people who have already taken the survey – so there’s a number of resources out there. Also, I do offer training and coaching, so if your company might have an interest, feel free to contact me. All my information is on my website.Ronnie: Thank you so much for joining us today Ken and for your great insight and advice.Ken: I appreciate you hosting me and I wish everybody the best of luck with their application of Agile! Thank you for listening to All Things Agile! We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!

Welcome to another episode of All Things Agile. In this episode, we discuss the tough subject of team conflict. Whether your Agile or not, every organization is bound to encounter team conflict. We'll discuss how to resolve existing conflict as well as preventing it from even occurring.I am also very excited to announce that the next episode will feature an interview with notable Agile author, Ken Rubin.  Ken is the great mind behind Essential Scrum. I hope you enjoy this episode and make sure you subscribe to catch the upcoming interview using this link: iTunes. Reviews on iTunes are also always appreciated. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: coach@agileinstructor.com.All Things Agile - Episode 010 - Resolving Team ConflictTranscript:Welcome to the All Things Agile Podcast! Your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.Hello everyone and welcome to the All Things Agile Podcast! First off, I want to get started by issuing an apology for the delay in getting a new episode out. The reason why is because I have an upcoming guest and unfortunately, we are not able to get the scheduling worked out in time for this episode. But, I am pleased to announce that Ken Ruben, author of Essential Scrum, will be the honored guest in our next episode.That said, I want to go ahead and issue another episode. I don’t want to keep you waiting too long – and with that, I hope you accept my apologies for the delay in getting this episode out to you. Now, before we begin, a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So the topic for today will be ‘Resolving Team Conflict’. Virtually any team you will be working on is going to have some degree of conflict. It’s just part of human nature. You can’t all agree 100% of the time, even though Agile encourages more of a democratic approach to what the team is working on and the approaches that they use, there’s bound to be some degree of conflict on any team that you work on.Now, before we dive into solutions to resolving team conflict, let’s first identify the different types of conflict. One type I think is just general healthy conflict and what really we’re referring to is debate. Using the word ‘conflict’ is probably inappropriate in this particular case. An example of debate, you may have people that share different ideas and solutions and what type of technologies should be used, or different coding practices, whatever. That’s fine. Having those healthy debates, discussing ideas, is actually a good thing. In this case, it allows you to have differing points of opinion which can be discussed, evaluated and reach an ultimate decision on. And that’s fine. That’s a healthy form of debate or conflict, if you will. And, if you have a little bit of that on your team, that’s fine and I wouldn’t worry about it.What we’re really going to be focusing on in this particular episode, is unhealthy debate. And I would describe unhealthy conflict or debate as a case where it’s really impacting the team. Where it’s creating what I like to call a toxic environment. You can definitely tell it when you’re part of a team that’s having this because it just brings everybody down. It brings the morale down, and it just feels like the team has been poisoned, if you will. And you’re going to see evidence of that not only in the morale, but the conversation, the level of communication and collaboration are going to go down. You are going to see people that are going to be engaging in using a lot of inappropriate language. You’re going to have a lot of people getting into some sort of personal battles with each other or one-upmanship, and it just really destroys the overall team morale and ultimately, the productivity. And you’ll actually begin to see this long-term in the metrics where you’ll start to see a team that was doing really well, and then they start to perhaps have their velocity dip down and more and more of their stories are being accepted late, etc. So that definitely has an impact. I would definitely classify unhealthy conflict as conflict which is really bringing down the team. It may be disrespectful, and it’s simply just not in the long-term viability of the team. So that’s kind of how I would probably classify the two main types of conflict that I see, either healthy, just discussion of topics and technologies versus some things more personal and toxic. And so we’re going to talk about the latter and how do you resolve it?Now, I have personally seen these cases come up numerous times in my career, and if you are particularly in a situation – your team or teams that you’re coaching or another team in your company that you’ve seen this kind of just not quite right environment, just a little bit toxic, that’s not uncommon. First off, it’s bound to occur on average. So that said, even though it’s a common experience within a company, you certainly don’t want to maintain that toxic environment. Because here is an interesting point that I have seen personally which is if one team is currently experiencing a level of poison, if you will – not only does that team’s morale drop and their productivity drop – it can spread to the other teams. It’s true. You can have a team that is doing really well, but if their neighboring team is engaging in disrespectful behavior and yelling at each other, cursing at each other, it’s going to impact the neighboring team. They are not going to want to come in to work that day. Their morale starts to drop and then their performance starts to drop. So another reason why you want to deal with unhealthy teams head-on is because not only do you want to help that team, but you also want to ensure that the degree of poison really doesn’t spread to the other teams and disrupt them as well.Alright, so let’s talk about some practical tips that I’ve personally implemented in the past and found beneficial. Again, every company’s unique, every team’s unique – you’re responsible for your own actions, but something that has worked well for me is to focus on the present and the future. Often times when you’re trying to resolve team conflict or coaching the teams through conflict situations, the team members may get too focused on the past and the things that happened. And, what I mean by this is that I’ve certainly seen cases where people get into paper trail battles. You know what I’m talking about? Where you have someone who has an email that they sent 6 months ago, and they bring it out. ‘Six months ago you said blah blah and now you’re saying this!’So you have these people that hold on to every little piece of communication, every little email and their real honest reason why they do so is so that they can spit it back out later. And candidly, that’s not healthy. And when you really analyze it, those persons, those individuals are focusing their attention on things that occurred in the past, right? ‘Two weeks ago you said this; last year you did that’ and so they can get into a lot of negative debate, a lot of disrespectful behavior sometimes because they’re so focused on past hurt. And they’re not really learning to forgive and let it be water under the bridge. And they’re just holding on to that pain, and they’re then letting that disagreement, anger, and pain, poison the waters in the present and then going forward towards the future. And you don’t want that.One of the first things I like to focus on when trying to coach a team is to – sort of phrase of the idea is: keep the water under the bridge and keep it there. Okay? Don’t say ‘Oh well, yeah, okay we can move forward’ and then the next week later ‘Again, I told you 4 months ago that this is the way we’re supposed to do it’, etc. And again, that leads to that negative behavior if you’re always bringing up the past. And so whenever I’m sort of involved in trying to coach a team, I try to think about staying present, right? Think about: never mind the past, whatever happened in the past has already happened – we can’t get back into the DeLorean and go back in time and try to fix it. So in that case, what can we do right here, right now? Stay focused and present. And if you’re speaking with them and they start going ‘Well, what about that 3 months…?’ just say Stop! Stop. That was in the past, we can’t change it – what we can change is the present, let’s focus on that. And it’s not easy to do, but try to hold a hard line on that. Just say ‘That’s in the past, let’s learn to forgive and put that behind us and carry on for the present and the future.’Now, if you can work on that and allow the team to avoid getting into those negative conversations about the past, then I’d say the next step is to focus on what actions or changes they can make here in the present to avoid future pains. So, for example, if part of the past pain was say, for example, some of the defect procedures were not being followed, as an example, and people were complaining about it with each other about whose fault it was – this person didn’t follow procedure and they should have, and someone has a paper trail from 6 months ago. To avoid that situation, I would say: Identify what changes could prevent that problem from happening again. So, for example, you might do six sigma root cause analysis, if you will and say ‘Okay, what really happened? Why was the process really not being followed?’ Well, maybe one reason is because the tool being involved wasn’t adequate enough. Maybe you just need to upgrade your toolset, maybe there’s some other procedures that can be added. Maybe someone needs to go through some additional training or maybe involvement with another team can be changed or improved. Or another team member’s schedules can be altered to allow them greater flexibility in the work schedule. Whatever the case may be, but the point is this: don’t dwell in the past, it’s already happened, okay? And then, for being able to resolve the team conflict, identify actions or steps that can be processed right here, right now and able to prevent that future pain.In terms of where it’s a little bit more personal – that does happen sometimes, where you have teams that for whatever reason, people harbor personal grudges towards each other, and even if all of your policies and tools and procedures are all well and good, some people may, simply put, just not like each other. It certainly can happen. Again, most of the time, teams will be okay with just changes in their practices. But, there will be cases where people just simply have personality clashes and where I’ve seen that in the past – if it’s really that strong, I would say it can be sometimes worthwhile to go ahead and switch some team members around. There can be cases where, for whatever reason, those overlapping personalities just bump up against each other just a little too strong, but you can take that individual and perhaps shift him to another team, and he’ll work perfectly well there! Because at the end of the day, all team members are not equal. We each bring our own level of skill and personality and really, you don’t want everybody on the team to have an exact mirror copy of each other, in terms of skillset and personality. You need that diversity because it helps produce a more well-rounded and ultimately balanced team.If one person, for example, is a little bit more thorough and another person is a little bit more sort of quick to act, actually having them on a team together can sometimes help because the person who’s more thorough will help balance the other individual out and ultimately, you can end up with a sort of a middle ground which is actually pretty well and functional. However, if you have those personality clashes where perhaps you have two individuals that are for example overly thorough and they may be bumping heads with each other, maybe that person belongs on another team and maybe there’s another team out there who needs that type of personality and skillset and they may actually be a welcome addition.Now, it is kind of like a last resort to implement team member changes to shift the morale, but it is certainly better to do that than to let the team continue in unresolved conflict. And I know it takes a little bit of guts to go ahead and to talk to people and say ‘You know, I think we need to move you to another team' but you got to think about the overall team and the overall organization with the other teams. And again, if you let this team remain unhealthy or toxic, it’s going to spread to the other teams and you certainly don’t want to do that and that’s not fair to the other teams, to have that happen. So, again – I always start first by avoiding getting into the past trauma state, focus on the present, evaluate what options can occur in the present, changes and practices, etc; they can be implemented to prevent future pain and if it is a situation where it’s kind of a deep personality clash more so than the practices, there need to be team member changes. And that’s okay, and that does happen – I have certainly seen it happen in other teams as well as my own teams before. And that’s okay – in a larger organization, it’s bound to happen sometime.I would say, kind of like an ultra-last resort, I really hate to see situations where a team member is removed from the company. That has happened, I have seen it happen, but that is such a last resort action and I would certainly encourage any Agile professional that’s trying to help a team experiencing conflict, that they truly keep that as an absolute last effort action. And the reason why it’s because it’s my belief that it’s easier to coach and maintain than it is to replace. Whenever you replace a person in your organization, you’re incurring cost not only with recruitment, but also with the interview process – people have to take time out of their days just to interview the guy or girl – but you also have to consume time with training and getting them up to speed and having them learn the culture and the ins and outs of the team, team practices or they may be new to Agile and you have to train them with that. So all that process can easily take a couple of months. And in doing so, the team’s velocity is already impacted. So I personally recommend, whenever possible, try to coach through the situation and reach a solution, rather than simply just throwing in new bodies. That’s my experience and that’s my belief. So, again – this is sort of a fourth option there, kind of last resort.But those are the strategies that I’ve employed to try and resolve team conflict and that’s a conflict once it’s already occurred. And I’d actually like to take a moment and cover a different topic which I honestly think many Agile professionals don't even consider, and I haven’t seen it mentioned too much in articles or books, and that is preventing team conflicts. The material I just covered a second ago is in relation to resolving team conflict once it’s already occurred. But, the old adage is that an ounce prevention is worth a pound of cure. So you might ask yourself: how can we prevent team conflict from ever even occurring?I’ll offer, I’d say about 4 suggestions that I believe, if you can implement them, they may help you. I’ve certainly seen them help teams in the past. The first is co-location. When you’re able to bring the team together physically, like they’re actually physically sitting next to each other, it often times helps prevent team conflict. If you have teams that are composed of a lot of full-time remote members, it can be difficult to maintain a healthy team. And the reason why is because of the bandwidth of communication. And the highest bandwidth of communication is face to face, where the person can see the other person’s gestures, the tone of voice, etc. And if they’re remote too much, then you’re doing a lot of email, a lot of IM chats, etc. and it’s so easy for the words to get misinterpreted, to get lost in translation. And so, in that case, it’s just bound to result in team conflict eventually. So if you can co-locate the teams, and I mean physically co-locate, like in the same office area, that really helps with being able to reduce the chances of team conflict ever occurring.Second way I’d highly suggest is in how you treat the team members. And what I mean by that is this: if you have a team of let’s say 7 members or whatever, and one or two of those members are always favored upon by management or leadership and always listens to those individuals and nobody else, or those individuals get included in all the important discussions and meetings and nobody else does; they’re the ones that always get promoted, that receive a healthy salary and everyone else doesn't– that’s bound to create team conflict, right? But if you can really look at the team as a team, and comprised of many different people, each bringing their own value and contribution to the team, that will significantly reduce the chances of team conflict from ever occurring. Because you’re reducing the likelihood of people feeling disenfranchised or left out. Or disrespected. So if you can prevent that – again, it’s a lot easier to prevent team conflict than it is to fix it once it’s occurred, right?I would say that another way to help resolve team conflict is through training. I’ve seen so many times where Agile teams are just thrown together and the training aspects is never really fully delivered on. Even though it costs a couple of thousand dollars, it’s far worth it to ensure that your team gets off to the right start. You want to ensure that, for example, all the Scrum Masters become, in my opinion, Certified Scrum Masters, Product Owners become Certified Product Owners – again, these are my experiences; your actions are your actions. But that’s my personal opinion – when you’re able to have those individuals be formally trained, it really does help because they learn the right practices, not just the way that the companies or organizations are currently operating. And that’s important!I also recommend having all of the team members receive some sort of Agile training. Again, it enables them to have buy-in, and enables them to better understand the changes being implemented and why, for them to really see the benefits. If you simply throw people on an Agile team without adequate training, I think you’re setting yourself and the team up for failure. Don’t do it. Even though there may be some costs involved in training, it is absolutely worth it to do so because the longer term cost of not giving them adequate training and education will be ten times worse or even more than the cost that could’ve just been handled up front through adequate training. So I definitely recommend doing that. Don’t skimp on training and coaching and that’s not some ad or something for my own benefit. I mean this sincerely that I have seen teams and organizations that did not train adequately and I’ve seen others that did. And it’s a night and day difference. And again, by doing that, you’ll help prevent the team conflict from ever even occurring, and that’s certainly something you want to do.The fourth thing that I would like to throw out there, a suggestion again to prevent the team conflict in the beginning, is how you form the teams. Who’s on the teams and in what roles or capacity? So many times I have seen team conflict occur because the team members are just thrown together. Look at a spreadsheet, get some names, throw them on a team. That’s simply just not wise. You need to really examine the skillsets and the personalities. Who’s got a strong personality? Who’s going to be the person who’s going to challenge the status quo? Who’s the person who’s going to be a negotiator? Who’s the person who’s going to help bridge different people together and help people come to a consensus?Finding out those personalities and the skillsets, including development and maybe testing skillsets, finding out those individuals and then seeing how to craft them into a functional and balanced team really pays dividends because they are far less likely to have conflict. They are going to be able to work with each other and compliment each other. If you just simply throw people together in a team, you’re just asking for conflict. And not only that – but if they’re not balanced properly, if you look at for example the work each member’s contributing during a particular sprint or iteration, you’re more likely to find that the workload isn’t very balanced and that’s usually because the team’s not balanced. They’re not properly structured. So prevent the conflict in the first place by investing time to ensure that from all the people you have across the organization, that you’re really analyzing their skillset and personalities and putting them together and positioning them to win, right? If you’re just throwing the bodies together into a team, you’re just asking for failure and conflict. If you invest the time – and really, how much time does it take, folks? A couple of days, maybe, to really take a deep look at the team members and really consider who would be great to partner up with who and if you can spend that time to partner the team members up correctly, it really will pay dividends. If you can do that, you’ll prevent a ton of team conflict down the road. So that’s four suggestions for you, in relation to preventing team conflict, on top of the other suggestions on resolving if it’s already occurred.Alright, well I think that wraps it up, regarding for how I have personally tried to resolve and prevent team conflict. I certainly am open to hearing your suggestions. If you have any, feel free to send me an email at coach@agileinstructor.com. And don’t forget to check out the AgileInstructor.com website and TeamXcelerator.com website. And as mentioned earlier, I do have a special guest coming up in the next show, which is Ken Ruben, author of Essential Scrum and I’m really looking forward to asking him some really great questions I think you’ll enjoy and find insightful. Well, I think that wraps it up for this show – thank you so much for your patience in waiting for a new episode, I apologize for the delay and looking forward to releasing a new episode with that great interview with Ken Ruben. Thank you very much! Goodbye! Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!