Transcript:Joe Krebs 00:20Welcome to another episode of agile FM. Today is back to Agile FM show just as we spoke in, I looked it up may 2020. Already on this podcast. And last time this was interesting. We talked about wikispeed a lot cars. And you were sitting, I remember that vividly you were sitting in a Tesla, we were doing the recording straight from a Tesla. And today we're going to talk about Tesla. What's the irony of that after two years later? This is awesome. Welcome back.Joe Justice 00:53What an amazing full circle. Joe, it's my honor and privilege to be collaborating with you and your entire audience again, today. Thank you so much. In the meantime, I did work at Tesla and operate the Agile program at Tesla. And I learned a lot. And I'd be happy to update the community on what I learned while working in the company.Joe Krebs 01:16Yeah, so I just recently traveled to to Austin for for business reasons and took a cab back to the airport. And I kept traveling and traveling and traveling on that highway. I don't know what number that was. But I was still passing this new headquarter of Tesla just buildings in under construction right now. But I believe somebody said it's the biggest building in the country or something like that, and in square footage or something. And it's obviously under construction. But it is massive. And it's impressive. And it shows something about growth of this company. And I want to talk a little bit about what supports that growth, I want to talk a little bit about what's the agile mindset of of Tesla, this company is so on fire that sometimes it feels like it's not transparent and what's going on. At least that's my perception, right? And you're gonna debunk this because it is actually very transparent.Joe Justice 02:10Bizarrely about transparency, I have not ever worked in a company as transparent as Tesla, except when I ran my own company, wikispeed, wikispeed was the accounting was public, anyone could join anywhere in the world, they could simply join the company, and they were as inside as anyone else. Tesla is the closest to that I've ever seen. And that from a company with 110,000 employees and 500,000 suppliers is shocking. Most people think by the time you have more than seven employees, you probably can't afford to be transparent anymore. And Tesla has destroyed that. For example, when Elon gives what do I want to call it? I guess marching orders. When Elon says this is important. He does it through Twitter. That's how the employees see it, too. That's why it's so important that Twitter be a public record where you'll be able to say what you believe is important whether or not everyone agrees, which is Elon stance, Elon stances, Twitter should be the global Town Square where anyone can say what they think is important and not be censored. The reason why well, well, one of them is that's how Elon uses it for the business. When Elon wants to say, here's the update of the master plan, He does it through Twitter, like employees don't get it sooner than that. They look at Twitter, too. So the company is truly led in the open.Joe Krebs 03:42It's very different to other companies out there, right where you have to get a legal approval for going on Twitter first.Joe Justice 03:48Yes, yeah. Where it's you get tweets, where where other CEOs, for example, try to sound hip and cool. But it's gone through a PR department. It's gone through marketing. It was part of a quarterly release plan that was planned six months ago. And it's completely different in Elon's case. Truly, that's when the employees get the information as well.Joe Krebs 04:16Unbelievable, that is fantastic. So what he was or what Tesla is in the news very lately is working from home for working from home being you know, being removed, or at least like trying to be reduced to coming back to the site. Does that impact you being in Hawaii at all?Unknown Speaker 04:34Well, I'm no longer an employee at Tesla Oh, yeah. The mechanics under Elon statement of you need to be back in the office work from home will no longer be accepted. except in exceptional cases and you need to make the case to Elon. There are maybe two interesting topics here for for this audience. Joe Krebs 04:58Yes. Joe Justice 04:59One is order, so I'll get it out of the way first. And that is Elon saying except in exceptional circumstances, and you need to make that case to Elon. Elon has a very effective business strategy, in my opinion, called, he calls it doing your chores. And what this means is their chores, a business leader, especially the CEO, but anyone in the business has to do every day where the company suffers or even fails. And that is, for example, you yourself, viewing what are the exceptional circumstances to work from home, not delegating that to someone who might not have your same point of view right now. Elon is so deeply involved in the company that Elon does Elon's chores every day. It's these types of conversations. Okay, talk to me to Elon, why do you think you need to work from home and no one else should? Do you understand why I believe it's important to not work from home. So that's the simpler concept. Do your chores phenomenally effective? Most leaders delegate that stuff? Elon doesn't. And many, many years in this has made Elon, the very effective manager. by some measures, Elon is the most effective manager, leader, executive of all time, by some measures. Objectively, I mean, CEO of five companies simultaneously, they're all top profit, all top impact in their fields globally. This is a new phenomenon. Nonsense, possibly the Yellow Emperor of China has this occurred. So the do your chores, ethos is part of it, then the larger issue is, why not work from home? What's the issue there? Or what's the advantage to not working from home? Why is this? Why is this so important that in Elon is limited? Right? seconds on planet Earth? Elon is investing many of those seconds convincing, people are demanding that they cannot work from home. Why is this essential to the success of these Musk companies. And the core of it is Tesla makes physical products. If you're developing software for Tesla, if you're doing procurement for Tesla, if you're doing any resources for Tesla. The goal is to be within touching distance of the machines and the materials that you're supporting. Will wait what does that mean, if you're a software developer, if you're developing autopilot, the assisted driving functionality for Tesla cars. And it's also used all across the other Musk companies for other areas, right and it has artificial intelligence stacks is part of it, etc. Like auto labeler. Your goal is to be within touching distance of the machines that are etching the circuit boards for the autopilot computer, or the machines that put the autopilot computer into the cars when they're sold. Why the feedback loop of being directly in the point of production accelerates the creative process. Yeah, it also lets you physically mob if you were writing only a virtual product. If your product were virtual, like let's say you make an app for cooking recipes, yeah. And it's completely virtual. You could be remote. No, Tesla does not actually have very many really virtual products. Even the Tesla app, which I have on my phone now has a feature called Summon, where you can call the car to you physically, it will attempt to come pick you up if it needs to leak do so. And you can open the trunk honk the horn, vent the windows, you can make the car dance, plays music and wiggles the windows up and down like an ocean wave. It's actually very entertaining in my opinion. And developers are making changes to robots to factory floor automation, to procurement automation, and to the cars automation and car sensor suites. And the cars are getting 60 new parts a day. That includes electronics and circuits. So if you're writing something for the Tesla app, you think of course I could do that remote. Well, it also controls talks to the cars. And if the cars are getting 60 new parts a day, every day you are updating your code to be working well with the cars are checking at least making sure your known stable interfaces are still valid and your test cases are still valid. And you're checking information security going back and forth to the car in the app. That is way faster if you are within touching distance of the car's manufacturer. Now there's a last part of this. I've been working with them the mob mentality who advocates mob in primarily software development, but I've been using mob for hardware development and hardware engineering, okay and bringing peace to them. And they propose and have some very intriguing data to back it up. That if you have five people 4, 3, 2 people, and you have a choice, they can work alone on different pieces of work, or they can work together on one piece of work. The quality is so much higher that the overall speed is far higher, because of the reduced time in bug tracking, bug finding and bug fixing and bug deployment. And the data appears completely sound. It appears mob is dramatically faster when you accommodate time to find, fix and deploy bugs. And people report higher job satisfaction and higher pace of skills improvement. Yeah, so if you could work remote, even in a remote mob that would be next best. In person mob has an even higher rate of learning is what they're tracking. Yeah. But it isn't. Really virtual product in person mob has advantages, but virtual mob wouldn't be next best. And of course, never work alone if you truly want to be innovative quickly.Joe Krebs 11:18Yeah. While this is. So I had like, a few years ago, actually, it just reminded me I had Woody Zuill on my podcast, to go into the, you know, like, I don't know if he wants to be called creative, but definitely one of the leading causes of mob programming. So that's very interesting. So that is an aspect that is also happening at Tesla and is obviously in person. And that's one of the reasons why Elon Musk is promoting in person because of mob. And then the next one would be virtual mob. And that's I think I, you know, using a lot of these tools, like zoom and etc. You know, they're great for some meetings and training, etc. Right. But I, I don't know, just by evaluating this, how effective it would be for mob programming, right. Other tools come into the mix.Unknown Speaker 12:08Any desk seems to help a lot, any desk through any video chat system or service? Yeah, Zoom allows breakout rooms, you can dynamically re partition sub mobs. So if you are in a larger group, like I was at Tesla, often Around 50 people, sub mobs can use Breakout Room functionality at will to form task specific mobs from larger group. And that works well. It is even easier in person, you're never waiting for a tool. No one's screen isn't sharing. I mean, if you listen to an audio recording of virtual development, remote development, there is so much waiting. Yeah, of my microphones not working? Oh, you're muted. Sorry, my headset battery died. We missed the last 20 minutes. And you just don't have those issues. You have different issues, but not those issues. Yeah, and you're in person. If pace of innovation is the only thing that matters in the long run in-person mob is the only way you would choose to work currently.Joe Krebs 13:18So and this comes from somebody you know, who's obviously promoting in person work, who is for many, many people on this planet on the most beautiful spot on earth in Hawaii. So you know what the chances are, if you're promoting this means you're leaving the island at some point.Joe Justice 13:36Here is the challenge. It is easy to talk about work. And you can talk about work remotely, that's fine. You're not actually doing work. And if what I'm doing is reflecting on what I learned at Tesla and writing books, creating podcasts, delivering keynotes remote trainings, that's fine. But I'm freaking out. I guess this is a version of what people would call Island fever. Maybe this is entrepreneurial Island fever, because I haven't built anything. Yeah. And if you actually want to create something new, create something innovative, not just talk about work. You've got to be there. You've got to physically be there. So I remodeled my condo, so I can build something,. But I'm currently shopping for factory land all around the world. I was looking in Japan yesterday, I was looking in Germany the day before. I have a small piece of factory land on the mainland United States. And absolutely my goal is to get back into product development and product production. And for that you have to be co located. And in fact, if you want to be very fast, you need to live there. You need to actually sleep there. So you have to think Where's someplace that I can go not have much overhead not have much slow down and living here,Joe Krebs 15:04right. But it makes total sense from a. And obviously, we can only speculate what you would you would be doing with all the land, you know. And obviously land is not something you could easily get in our way so I can see why you're exploring other territories. Tesla just won't come back to that one time because what's also fascinating is to hear that you talk a lot about agile you are a certified scrum trainer, right? Is scrum a thing? Or is it more like agile a thing is, I would my guess is correct me if I'm wrong, they would be agile, but and that the organization is thinking about change and innovation rather than a specific process. But what's what's uh, what are we did the teams look like is there like a variety of things is, you know, Spotify is very transparent also how they work. And these things, just curious. Scrum is way too slow for what Tesla is doing. But scrum has a beautiful place in the world of business. So most companies around the world have annual or yearly or longer budgets. And they allocate the majority of the finances at least at a coarse level, sometimes even at a fine detailed level for a year or longer. That's normal. That's how most companies around the world allocate budgets. That means if you're going to respond to change, like a chip shortage, or a supplier change, where a new product in production, responding to customer feedback, you would need to politically advocate for re allocating capital inside the budget cycle, which is costly. You have to make presentations, you have to make reports, you have to make friends, you have to be congenial. It helps if you're handsome, you start to get politicking, which is a massive overhead most companies have about 60% of all headcount dedicated to that, yeah, to allocating politicking and shaking hands appropriately and respectfully making reports and not actually building the product. Well, it'd be phenomenally more capital efficient. If you had near 100% of staff directly improving the product like sweating, welding, programming, nearly 100% of staff, which is Tesla's goal, because of the capital efficiency involved. That means you can't take these people's time to be negotiating for budget change. So you need another mechanism for budget to change. That's very fast. That's very nimble, right? Okay. So Scrum is a awesome step towards that, what what scrum does, from my perspective, as a certified scrum trainer, is it introduces 30 day or less budgets, we call those sprints. It's a funded release, including testing, including design, a lot of companies don't do this, even though it's part they say they're doing Scrum, and don't actually have 30 day or less budget cadences, because that means disrupting their current budgeting cycle, I get that step by step, please get there. But part of the goal of Scrum is to do that, and you won't be able to move past scrum until you do. So that is the hard work some companies still have to do. It's an interesting thing. Once you've achieved 30 day or less budget allocation, and Scrum has an accountability just for that called the product owner and maximizing the value of those iterations and a list of what those are called a product backlog. And as long as the product backlog can change with feedback at any time, you have increased your agility. I'm actually predates agile in my definition, it's actually not an agile method, but it moves you towards agility. If you actually do 30 day or less budget cycles, and have a mechanism to change what the next budget cycle is at any time called the product backlog and some coalition to do it in scrum it's accountability called the product owner. Let Scrum. If you're already at 30 day or less budgets, and you're already able to produce product within 30 days, test it certified, give it to customers. That's huge. Most companies are not there. Most companies need Scrum. If you're already there, you're 30 days or less. Now the five events of Scrum, the three accountabilities of Scrum, the three outputs are artifacts of Scrum. Those are overhead now, those are now slowing you down. And that is where Tesla is. Tesla is at 60 new part introductions a day and 61 or more part deletions a day so the total part count is going down to keep serviceability becoming simpler and warehousing becoming simpler, continuous aggressive simplification that you there is no time to do so. sprint planning, much less Scaled Agile Framework which is even slower than pure Scrum, iteration planning, big room planning, there's no room for that in any of the Musk companies. Now there's room for that in a lot of companies. Yeah, if a company has an annual longer budget, I will recommend Scaled Agile Framework to help them get to quarterly releases through the train system and bigger and planning. Once they've accomplished that I'll recommend cross functional Scrum teams that manage their own dependencies inside to get to 30 day or less budgets and releases. Once we're less than 30 days, you get, you're attempting to do what the Musk companies are doing, especially if you've gotten under a week. You can sort of keep scrum useful down to a week. Less than that, it's actually just silly, you can make it work, but it's not adding value. That is where you do what the Musk companies are doing. And you actually shouldn't call it agile anymore. Because the Agile Manifesto says we're going to allocate budget, we're going to release product with customer feedback from a couple of weeks to a couple of months with a preference to the shorter timescale. So if you're past a couple of weeks, you're past agility, but I don't know what to call it. So I still call it agile at Tesla. In Tesla, there was not a name for it. There was not Yeah, so what what would it look like? Is it like Kanban-esque? Or is it like, with like, teams that just like totally self manage? building their own way of working? Is it something that results out of the mob? What is what would you see there on the ground?Joe Justice 21:37It is not exactly Kanban. It's like combine if you had just one column just doing column, so like a focus. But someone who is familiar with Kanban, and WIP reduction and flow theories would be feel very at home. Yeah, and so but it's simpler than Kanban. It's like combined with one column. And it's a lot like open space. So for those of us who attended the global scrum gathering Denver, which was just last week, I don't mean to make this recording sound so old three years now. But I was I actually it ended yesterday, closed yesterday. Much of that conference, as are many agile conferences was run with a technology called open space, where people propose agenda items self allocate to which agenda they want to go to. And they use the law of two feet to change sessions at any time. They can also be a butterfly or a bumblebee. And these are actually very valuable roles. As silly as they may sound, depending on what is useful to you. Tesla does not call it open space, they actually don't name it. It looks a lot like open space. Okay. So whether you're a software developer, or a product designer, or a manufacturing engineer, or a manufacturing line worker, which by the way, you are all of those things. I mean, everyone does everything. I don't know if I can really explain that without people doing it. But it's, it's true, no matter what you were hired to do, you are going to be lifting 20 kilograms every day, putting metal into robots mixing paint, you are going to be working with CAD, you're going to be working with procurement software, you're going to be working with a lot of AI software, no matter what you were hired to do. So you walk into the company, and you are in the factory, no matter what you were hired to do, you enter the factory, and it's 12 hour shifts. So in my case, I would come in at 5am. Actually, I'd often come in at 4am. But that's another part of the story. For now, let's say your shift starts at five. So you're already there. You're at 5am. And you walk up to well, everywhere in the factory are these monitors, they're usually suspended from the ceiling, but they could be coming off pylons. They're all around. But most of the time they're above you just above head height. So you almost hit your head on them. And that's important. You can see them easily. It's also available on your phone. But you don't want to have to get your phone out to check these things. You look at them all the time. And these boards did not have a name. I have since named them. And I talked about these and I teach them. I call them justice boards. I've named them after me. So they are justice boards. What these boards show you is what are all the funded projects like what is Tesla spending money on or SpaceX? When I visited SpaceX, it was the same what is this company funding money on right now this second, these are real time they're driven by Tesla's vision. So Tesla vision is an AI stack it is not going to solve all your problems for you. But what it's very good at doing is auto labeling. looking at pictures or now video multi channel 8k video now but looking at vision and labeling what's there who Is there this employee? Okay, what robots are there? How much does it probably cost to run those robots? About how many cubic meters of the factory? Does it look like they're using? Okay, well, what's the cost to Tesla to consume about that many cubic meters of factory, and they automatically gas and the gas isn't perfect, but the value is no engineer has to think about it. It's automatic. They guessed the cost of whatever group is working. And then that group has to say, through an app on their phone, what am I doing? And how do I think we could measure the value, so they could say, We're re-programming three of the paint robots, we think we can reduce the time a car spends in paint by 11 seconds, what we're really they don't take time guessing a number, they just say we think we could reduce the time a car spends in paint, which happens to measured in seconds. Well, what the AI then does, is it calculates the value to the company, if the cars spent any less time in paint, without defect rate going up with quality increasing, and without consuming more cubic meters of the factory or more robots, or if you do, it's offset by the time reduced in pain. And that becomes a row on the Justice board. Now what I added, since leaving, I've had a chance to reflect right, so what you can do remote well is reflect you can sit and think is these boards were unique per area, and you could toggle through them on your phone. What I added is to the justice board, is there's a row for each of these. And they dynamically sort up and down based on value ratio, which is more valuable versus expense that's at the top, which is lower value versus expense. Now, when I was in Tesla, we were encouraged to guess at that, and use the law of two feet to go to the highest value product that we thought we could meaningfully add value to or we were really passionate to learn. And we thought it was worth the investment in our learning. And we were asked to make that call, there was no manager allocating yourself allocate like attending an open space conference. And you can use the law of two feet to go to a different work group anytime. And what these work groups are changes in real time because people can propose them from their phones, they can just go to a new area and start working on a new idea and propose it with their phone. Well, now the Justice board dynamically ranks highest value top lowest value bottom. And if what you propose is the bottom, and it doesn't look and you don't have a great idea of how to dramatically increase its value, you should probably use the love to feet and abandon it immediately.Right? You're just managing money. Joe Krebs 27:44What a great concept is like, you know, like open space. I've used it, you know, obviously in a lot of conferences and I had Harrison on here one time on on agile FM to speak what an interesting concept, right? But now to use it actually, it turns out so if I would I'm in the development stages, right? So what's super fascinating is like you're talking about about group work, you're talking about crowdsourcing of ideas. I heard recently, I forgot the reference I have to look it up with that is obviously when I heard the sentence somebody saying the next 10 years, we see more innovation that in the last 100 years combined. And, and companies obviously need to be prepared for that. Do you see that as a recipe for it? Is this because you said 110,000 employees, the company obviously grew very, very fast to that number you guys are doing or have been doing things in during your employment, you observe things of crowdsourcing? Do you think that's scalable bigger, if that company is growing? Like what's what's your advice for companies that are possibly looking at that stat saying like in the next 10 years, there's so much innovation, I'll be ready for this. What should we do?Joe Justice 28:57There are two enablers that I'm aware of now, one is Musk's philosophy of do your chores. And you have to do those every day. That's what prevents the company from becoming siloed. Hierarchical. Like when you join Tesla. You're given the anti handbook handbook. It's four pages long, and it's been leaked online. And it looked exactly like the one I was given. So I believe that page is completely correct. It's four pages, that is your training. And then safety training and you're in Tesla. It takes four hours total you're in, you get your work shoes, you get two pairs of safety shoes, and you get the AI apps downloaded on your phone which replaced management. So there's effectively no managers in the Musk companies. AI has replaced that which is the idea of digital self management, which moves towards the goal of 100% of staff directly improving the product, which is higher financial efficiency, higher capital efficiency, part of the anti handbook handbook, and it's very few words for agents who will be part of it. So As you can talk to anyone, you can go anywhere, you can do anything. And in fact, if you see a bottleneck, if you see a problem, and you don't go work it, we will hold you accountable for that. So it is your job no matter where you saw it. And it says you can talk to anyone, anywhere, you can talk to Elon, if talking to Elon is the fastest way to resolve this bottleneck, you must do that. And if anyone tries to stop you, they will be fired immediately. This is what prevents the hierarchy. Now, what that means, conversely, is if someone prevents you from talking to Elon, for example, about removing a bottleneck, not because you're like, hey, what kind of pizza do you like, but because you you want to I mean, you could do that, too, he lines up pretty friendly person, but especially about a bottleneck to the organization. Someone actually has to fire them immediately. And so Elon actually has to check. Is that happening? Are these words still what is running the company? So that's part of the do your chores, if you are in the position of deciding who gets paid, who doesn't who's on staff who's not who has access inside the company, who doesn't what we usually call employment. But now in the Wikipedia global contribution model, it's more like who has author access, right? But whatever, if you're in the position of determining that you have to do your chores every day. Now, the second part of that is you can automate a lot of those chores I just mentioned, digital self management, right? This is truly, in my opinion, the musk company's superpower. What Elon is doing is intensely funding, and joining the mobs to automate away wait states. If someone is waiting to ask a manager or an expert Did I do a good job? If we can, that should be an app on your phone and running on the monitors above you. So you never have to wait to talk to another human. The idea of Elon's chores are being automated to the extent they can be. And that is part of the goal is that is what x.com is supposed to be supposed to become eventually, which is a domain of just a Url domain on the internet that Elon owns an aspiration for x.com, which was tweeted to Elon, a couple of years ago, and Elon replied, Yes, that's exactly what I should do. You're right, is for it to become the parent organization that keeps the other companies lean and valuable, and radically innovating. So you don't have the founders departure complex, where when the founder when the founder departs the company dramatically slows down, it falls into corruption falls into debacle and decay. Well, the attempt to solve for the founders dilemma because Elon says, Look, by the time someone is 70, they probably shouldn't have a job, their brain is corroded, biologically, that Intel neural link does what neural link supposed to do. You should not be running a company and Elon says no one should be CEO forever. So you can count that down. That's 20 something else? Yeah, 21 years from now. Until Musk says, you know, I would be incompetent it'd be criminal derived from Elon to have Elon having financial authority of the companies on a day to day basis. So that's the timeline where x.com needs to have replaced most of Elon's chores, if not all with automation. Then you have a rules engine, like playing a video game to keep the rate of innovation high to keep the politics out to keep silos out to keep a flat nimble organization at any size. Elon, because of an aggressive workday, is able to do that across five companies simultaneously, all around the world. So you can a human can you just have to make it your passion. Just like if you love to watch sports every day. And you watched two full sports games everyday if you were deeply passionate, and on the weekends, maybe watch four. Well, if your business is that level of passion, even doing your chores, the unfun part of it, then you can scale this you can keep this innovation high so we can continue to have founders and even not founders, even board members who are at this level of performance. However, what Musk is not currently selling, not now, is any of the digital self management. So if you want to compete you better be building your ownJoe Krebs 34:50This is awesome. Yeah. Joe this is maybe there's somebody listening right now as it's like wow, this is a very open and transparent conversation where and you know in And I want to say thank you for being so transparent. What's interesting is, I have seen some, I think it was somewhere on social media, I have seen you post something, and Elon Musk actually liked it, right? So you got a like, so I hope that people when they find this episode that they also gonna like it right? And possibly vote, vote this episode up. And because they enjoyed the conversation, for the parents out there listening to this, I decided to get my kids prepared for the workforce, and the workplace in the future. What I'm learning is do your chores and work in groups, right, and be able to work in groups? I think that's what I'm hearing when that should be promoted. What you don't want to tell your kids is that hierarchies don't matter. At least until the 18th. Right. Joe Justice 35:51Joe uour was hilarious. Joe Krebs 35:54Yeah, this was an awesome conversation, right? I love it. And looking back two years ago, coming back to where we started. Two years ago, you did not work for Tesla at that point, and what kind of vision and everything now we talked about Tesla tremendous amount of information, and that is fantastic to digest and getting some insights. Now with your little cliffhanger on I'm trying to buy land, we can only assume what's going to happen in two years from now. When we speak again. I hope it's not going to take two years to talk about again, but hey, let's see what's what's in the making always curious.Joe Justice 36:33Joe, it's my honor and privilege to be part of Agile FM, Agile.FM to the moon.Joe Krebs 36:39Thank you. Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www agile.fm. Talk to you soon.

Transcript:Joe Krebs 0:20Welcome to another episode of Agile FM today I'm here with Tracy Defoe from the learning factor, I believe in Canada because your domain name is the learning factor.ca. Tracy Defoe 0:35that's right. I'm in Vancouver, Canada on the Pacific coast.Joe Krebs 0:39Fantastic. Tracy, we want to talk a little bit about a lot of things here today, we want to talk about Kata. We want to talk about maybe bring a little bit order into the various kinds of terms that are floating around and getting possibly the Agile community a little bit, you know, warmed up to Kata thinking, and most importantly, where they can go and you know what's out there because you are not only a community builder, you are buildingcommunity builders, right. So there is a lot going on in your in your work before we get started though, because I myself have been working a lot lately. In recent, let's say 12-24 months on something that's called the Agile Kata that is not the topic necessarily of today, even though we could explore that, right? We're really talking about the core of the Agile Kata, which is the improvement kata, the coaching kata things that were published a while back by Mike Rother. So just to give it a little orientation here now first Tracy, the learning factor. Just curious, your company name what is the learning factor is somehow related to Kata and Kata thinking Lean thinking.Tracy Defoe 1:57No, the learning factor greatly predates when even my learning about Canada but my background is in education. So I have a master's degree in adult education, curriculum actually an instruction. And so I was doing I've been for a long time been doing consulting in adult learning and I'm actually a specialist in what people learn at work. So most of the time, if you once you've left school 75% of new things you learn, you'll learn at work and I'm a specialist in workplace learning. Particularly I'm interested actually in what you might think of as frontline learning so blue collar learning, literacy, numeracy, technology advancements. All of that took me into of course, then helping supervisors and managers and they're the people who introduced me to Lean and through that. I was in a good position when Mike Rother was first publishing his first book, to get involved in the Kata community here in the Pacific Northwest where there was actually Mike did some of his research here inthe West Coast. So I got to meet some people about 2010. Who helped me get passionate about the Kata.Joe Krebs 3:08Yeah, that was the Toyota kata by Mike Rother.Tracy Defoe 3:10Toyota Kata Yeah, the original Toyota kata research book was in 2009, I think.Joe Krebs 3:15Right? So, and since then you have obviously stepped into this. In the Kata world, you did a lot of coaching. That's my understanding, you have worked with some companies out there also, although on the software side, we might have some listeners right now, on this on this podcast, you might be thinking, Lean and Toyota factoring. There are companies out there that are using this for for other means to produce something different than a car.Tracy Defoe 3:44Well, the cool thing for me about the improvement kata and coaching Kata is they're just a really excellent model for continuous learning, and learning together and having a non hierarchical relationship between managers and workers or between the coach and the learner. Basically, we teach coaches to listen and ask questions, and not to tell people what they think the answers are. And that's really great training for anybody who's in a management position or a coaching position,Joe Krebs 4:18right. And those two cutters, they really belong to each other. So the improvement kata, the coaching kata, I mean that we're using the word kata a lot, right? It doesn't exist in plural. It's my understanding. It's just kata. But it's these two things that really go hand in hand.Tracy Defoe 4:35Yeah, the word Kata is a Japanese word that comes mostly you would hear it from martial arts, but it's used in other things and it has two meanings. The I guess nobody's gonna see this but the I have it on a pin. The Japanese characters mean both the method and a way so it's, it's a way to be but also the way to learn to be and we If we save, you know, everybody always talks about the Karate Kid movie where the guys teaching him wax on wax off. And then that turns out to be the move that helps him win his match or something like that. But also, if you practice the improvement kata, it's a method to learn more scientific thinking patterns, right? So what leaves behind is a mindset. And on the coaching side, if you practice the coaching kata, it leaves behind a kind of curiosity and discipline around not talent. So turning from a command and control kind of coach are telling you no, do this do that to the kind of person who's invested in developing people and seeing other people do stuff. So I think the the Mike Rother, the author of the Toyota kata books always says, It's not about the Coaching Questions. It's not about the improvement kind of steps. It's the mindset and the skills that they leave behind.Joe Krebs 6:02Right, this is fascinating. They did improvement Kata is something that reminded me when I started way, way back with something called Scrum in the Agile community. And we often hear in the community. And sometimes I say that to is that Scrum is easy to teach, you know, but hard to do. The first time when I came across the Kata, it felt very similar to that. So it's like that is is it's very simple steps. We don't have to go into the details. It's a great improvement kata, it's four, or sometimes five steps, depending on how you see it right. But what are your What is Your Experience? Why is it that some companies, what are they struggling with when they are trying to use the product the first time,Tracy Defoe 6:46the first step of the improvement Kata is to understand the direction or the challenge that you need to go. And an enormous number of companies don't have a clear strategic direction, or a clear business strategy that people know. So that already says, you know, you have the benefit of everybody understanding where they go is that they can align their actions and move together like towards it, and I do my part of that job, and you do yours and we end up somewhere better. So the first step sounds easy. Oh, you know, your your your executive suite people will give you your strategic direction very clearly, and you will understand what to do. That doesn't happen very much. So that first one already, people end up having to craft their own challenge. Or guess what they think based on maybe a statement or a five year KPI or something a ey performance indicator, you know where they're supposed to go. So that's step one. But imagining now we have that, then the second step, which is to grasp your current condition, is to get a good look at where are we now? So it's like, where do we want to be in six months? Or whatever? a month? Where are we now? And that takes process analysis skills, or some way of asking, answering the questions. How is how am I performing over time? What are the steps in our process? How are we measuring it, etc. So there are sort of skills built in to each step. So that's where we going that's the challenge. Where are we now? How are we doing that's during condition, target condition? Where do we want to be in a little while, so usually a week or two. And that, again, there's a bit of skill around having a good look at where we are now and saying apples to apples, like direct comparison, what we want to change how we're doing, that we hypothesize will give us a different result. And it is, I think it is the structures, all of that is before you start experimenting. So you know, you know where you are, and you know where you want to be in 10 days or two weeks, then the next coaching question. And the next step really is to say, what do we believe is in our way, what do we perceive is in the way, and it's very important that they don't have to be factually or data proven to be in your way at first when you list them all down? Because confronting your perceptions is really, really cool. Yeah, you know, like, it's really often people will write down all these things that they think are in their way. And then as you say, Okay, pick one. And then let's work on that one. What do you want to learn about it? What what test or change do you want to run? After you've tried to run the way you think you can run you're gonna see all these obstacles we call them obstacles are things in your way. And mostly, we want to learn about them. So people sort of that part always make sense to people pick something, kick it, see what happened and make a change, run it. And then of course, the last step of that fourth stage is to reflect on what you learned. Right? And this is what Mike always says the writing it down and reflecting is what makes it scientific, because we use that to inform our next step. Step or next kicker, the obstacle. But I find many, many people are not very comfortable with reflection. Like they're, they're literally not used to it. And they'd rather take a swing, you know, just try again, without literally saying what is the data show us is happening? What do our observations show us is happening and what our learning show us is happening? And that's where I think the Yeah, can you talked about them being a pair, I always think of them as a duo, the improvement kata and coaching kata, but it's kind of like a food term for me, you know, they like they go together. And I think that the powerfulness of the structure is partly that it's, it gives you a lot of structure. So you don't there's a lot of room for creativity there. Because a lot of things are held in place. Right? The questions are known, you know, what questions you will be asked, the steps aren't known. And so in between those things, there's time to listen and learn. But also, I think people don't know how to reflect they literally are perplexed that you're asking them, Did you learn anything else? What did you learn about what you thought was going to happen? What did you learn about your process? What you learned about your team? What did you learn about your assumptions? And people are like, Oh, my gosh, she's just keeps asking me this stuff. But in about two weeks, or three weeks, people are like, piling on what they learned, like, they're really understanding that you want to see what they learned.Joe Krebs 11:33What I think one point you just mentioned, was like data too. Sometimes some answers to those questions you just said, right, before a newcomer to kata, maybe something like I don't have any answers for those questions, right? Because I haven't collected the data points before. I have no reference point. But I think that's what the kata also takes care of right? It's, over time people want because they know the questions as you said, right, and they will be preparing for those things in a different way. So the kata has a behavioral change.Tracy Defoe 12:06Yeah, in a mindset change, but also we It comes with what we call starter kata, or prescriptive tools to use in the beginning. So that you, you are like not leaving anything out. And also the starter kata will tell you like, what is what do we expect to see? We use a storyboard which is like a giant A3. I don't know if you use A3, but it's a giant A3. And is there was derived during my process research from the A3 that he saw at Toyota, and the conversations around the A3 that became the coaching kata. But the, you know, what do I expect as a coach to see in current condition, I expect to see a run chart, a process diagram, some process metrics, how do we know how this is working? When it's working? How do we know outcome? How did it what happened when it was over? And some description of the conditions that this was happening under which we call process characteristics, but the people I have coached who came from agile and I don't know if this is common, or if it was idiosyncratic, had never done a run chart?Joe Krebs 13:07Yes, that's right. Tracy Defoe 13:08But to teach her how to do the run chart the first week, and at first, she didn't see any value in having each time what was the what was the number and making a little chart, I'm making W's in the air with my hands down, up and down. But in fact, the pattern like once you have some data points, we start to look at the pattern, and what can you learn from the pattern. And making it visual means we all agree, this is what it looks like. And it's it's a simple visual tool, pen and pencil, you can do it in software, but you can also just do it with a pencil and a piece of paper.Joe Krebs 13:47Yeah. So that's very interesting. So you have applied this agile kata, we have probably a lot of listeners here from agile, coming from IT groups, not exclusively, there is a lot of business agility. But you have applied these kind of concepts in the context of software engineering.Tracy Defoe 14:06I've coached people who worked in software a couple times, actually. And there's their starting positions and their strengths and their habits. Were kind of expanded by learning the kata that gave them a bigger look. But like I said, never seen a run chart before. And it's not unusual in manufacturing to sometimes run into people who have never kept track of how this is performing over each trial in a chart, but that's basically what a run chart is.Joe Krebs 14:40Yeah. Very interesting, right. So just come back to my in-coming kind point about the Agile Kata, right? So this is being utilized. And there's like an agile culture, as you know, and it's it's all around and surrounding this. So this is a very interesting thing, and I'm pretty sure the listeners were now make connections between those four steps. You just write to the Agile world because that is really what we're dealing with in Agile transformations, or what people are talking about in business agility. When I , many, many years ago, is probably 20 years ago, when I getting more and more involved in the Agile community. It was a grassroots movement. It agile, right? So everything was like bottom some people did it. And there was like, a lot of polished kinds of things. It was a lot of sharing of experiences, but it has like to have this energy. I'm sensing this in the Kata community too.Tracy Defoe 15:39Yes, we always say the Kata community is a sharing community. And lots and lots of people will share their stuff with you or present or help you. The reason I got so much help because I'm remember, I'm just an adult education teacher from Vancouver, British Columbia, Canada, but the people across the American state line in Washington State House ROIC and Mark Rosenthal for two. They were people who were practicing before way before I was for sure. And they just opened their doors to me and how let me hang around his factory and see how he was using it every day with 13 Different storyboards on the go. And Mark taught me what I a lot of what I know about process analysis and how to how to manage the started was up. And board and things like that. And I didn't pay them. They were just community members who said you want to learn come and learn. And I think the Kata has a pretty because we're enthusiastic. And because we see that it's, we say it's a meta skill, that scientific thinking part you can apply to lots of places in your life. And so we're happy to share that with people.Joe Krebs 16:53Yeah. And you in particular, right. So I just want to ask, because you're very humble here right now in all the work you do. And in the in the community space, there is even a club. There is a I call it a club, but I'm not invited to. It's the KataTracy Defoe 17:09Girl Geeks, yes, yes, no, unless you identify as female. We don't ask any questions on screening, okay, but I in 2020, m plus C. So early COVID days, I was contacted by a young woman in the UK, well, younger than me, sorry, Gemma. And she had was trying to learn the Kata and was really confused. And she reached out somebody on LinkedIn said, You should talk to Tracy Defoe. And so she called me and I said I would coach her. So I coached her remotely. And at the end of she wanted to be a coach. But firstly, we really do say in the Kata community, be a learner before your coach. So getting some experience as the person answering the questions, reading the storyboard, studying your own process, studying your thinking and stuff. So we do that first. So I coached her through I'm gonna say maybe it was May, June, July, August, or something like that. And she said, Okay, now I'm a coach. And I said, No. Now you need more practice.And so we decided to invite some more women into our group, and that group grew up to be Kata Girl geeks, we have a website and a home we meet every Monday, we have members from, oh, I'm gonna say Eastern Europe, Africa, the Middle East, the UK, Canada, the United States, all the way through, like, as many time zones as we can think. And we actually match up people. In addition to teaching people, we match them up for free coaching. So we've had many, many, many coaches and second coaches go through and and we're think we're pretty good at turning new learners into coaches fairly quickly. One month or six months or so for mostJoe Krebs 18:53people, I'll definitely put the link into the Show page so that people can click on it and, you know, possibly read more about this. AndTracy Defoe 19:01I'm not gender centric. So I also have a group for men and women. That which is actually older than kata girl geeks. So it's called Kata school Cascadia. There are Kata schools all over the world. They're regionally based. Cascadia is a term for the west coast of North America. It is an earthquake zone and a biological song. And it includes Canada and the US. And since since we were a group of people in Canada in the US before we became a kata school, that's why we took that name. And we meet every Friday for free with a drop-in zoom. There's two there's one for beginners and one for coaches and we just try to bring the community together. And then we also offer some trainings or conference. We have a conference in July 2022. And we have online training where people can sign up inand learn We also do some free training. And I will occasionally match people up with a coach if they can't find a coach. So we're just out there trying to build the community. And our mission is to rock people's worlds.Joe Krebs 20:12That was the intriguing part. For me when I first really came across the car several years ago as like, I write about it, I found it intriguing, interesting. And then I went on websites, and I learn more, etc. And what's very interesting, is it is this helping to bring people into this topic. And as you said, I made It's the passion I make since then, have been very much here we are. Oh, here we are. Exactly.Tracy Defoe 20:41Oh, well, I think that actually started with Mike Rother, he made although he sells a couple of books, he made a lot of material available under Creative Commons. And so following that lots of people who have subsequently created new material or new downloadable things, we offer them under Creative Comments. So they're usable. You can use them for non commercial use. Yeah.Joe Krebs 21:05You just use the word online and online help and bringing people together in different time zones. When I looked at some videos on YouTube, about cycle, coaching cycles, etc, etc. A lot of these things were in person in these videos, because they were pre pandemic, what do you think has changed with a Kata? If so, anything with a workplace, the coaching relationship, the Kata itself? Do you see anything in the last few years on the improvement Kata?Tracy Defoe 21:35I had? I had the opportunity to remotely coach somebody in 2017, I think. And we were using WebEx. And I'm only laughing because yeah, it was funny. It was terrible. And I actually didn't think it would work to remotely coach because I thought, the body language and the together at the board that this really meant something. But to my surprise, it did actually work. And so we were using, I started remote coaching people then after that, if they asked, there's a lot of advantages to the remote coaching, if you're, if you're paying for coaching, no travel time. Yeah, so you're paying for 20 minutes instead of a half a day, right? Yeah, the other thing is, I think you can have a wide variety of experiences as a coach. So a lot of the time, as you said, within a company, it's your leader, who's your coach. But if you're going remote, you have the opportunity as a coach to coach people where you do not understand their process. And this makes you a better coach. Because you don't give it you can't give advice because you literally don't know enough about it to give advice, you can't give direction, all you can do is follow that one of our categories calls it the golden thread, you can follow the golden thread of logic, across the actions and the things that the person says the improver says that they want to do. And this is like a really great liberation for a coach to not even think about the process. Just think about the learning. Think about the person and how they're doing. So I think we've seen a lot more remote coaching, yeah, for sure, during the pandemic, andwe've also expanded our community. So I wasn't in daily contact with people in the UK, or Sweden or Germany, before the pandemic. But now, some of my favorite co workers are in Ireland, or they're, you know, someplace like South America, someplace where I would not normally think of connecting with people around the Kata.Joe Krebs 23:46That is really fascinating. And I feel like everybody can hear you and what you're saying and the passion you have for this topic, from early stages of business education, in our being in the Kata world, and obviously that drives you in all aspects. For everybody out there. I wanted to bring you the topic I wanted to bring Tracy in into agile FM, that everybody can see, even though it's called Toyota kata, this is not only for car makers.Tracy Defoe 24:18No, actually the Toyota came for the publisher. Right? Exactly. Mike wanted to call the first book beyond what we can see. Because it's about that on the invisible routines, the managers running in their head and it's about the invisible thinking that the learner is doing. Yeah, but I think his publisher said there's pretty big money in anything we slap Toyota on so they call it Toyota kataJoe Krebs 24:43but might be misleading for somebody says, Oh, that is for car manufacturer.Tracy Defoe 24:48We're not making cars. I knowWe are not making cars right. Joe Krebs 24:52So maybe maybe that podcast helped a little bit for people to see you can improve possibly anything with this Kata.Tracy Defoe 24:59Yeah, and And we know a lot of people use the kata pattern for their personal improvement too. So, we often encourage people as they're learning to take their first project or their first thing, something that they personally can 100% We always say put their arms around, but something they can't control of. And for that reason, people often do something, not necessarily in their work life as their very first project. And I know that it is you can do it for any any issue or problem or thing you want to improve parenting your relationship with somebody your finances, you want to lose weight, you want to get more active, more creative, you want to get more sleep, we can Kata that stuff.Joe Krebs 25:42So yeah, it has, it's great. And for all of those things you just mentioned, the Toyota kata, or, as we just said, improvement, kata does coaching kata together, would make great sense. If somebody is really interested here on Agile transformations, you can certainly try that too. Or just look at the Agile Kata agilekata.org, which is an extension of what we just talked about. And it's very specific to Agile, and we are on agile FM. So I thought it would mention this.Tracy Defoe 26:10Yes, yeah, I don't like I said, I've coached a few people who work in Agile, but it's not my world.Joe Krebs 26:17Yeah. Okay. All right. So there's two reference points for everyone. I want to say thank you, Tracy. That's Tracy with the learning factor.ca. In Canada, if somebody wants to check out and have a starting point for a conversation with you about Kata. And what you can use, you willTracy Defoe 26:34find Kata Girl Geeks, we have a website and we're on LinkedIn too. If you want to join because you identify as female and you're interested in attending, it's just I want to join I want to join at KataGirlGeeks.com and Kata school Cascadia. We also have free resource board. So you'll find us at KataSchoolCascadia.org Or you can email me info@KataSchoolCascadia.org is where easy to find. And we have a whole big bunch of free resources and videos all laid out for people who are isolated or trying to learn on their own. So we want to Well, as I says on our website, if you're looking for the Kata community, welcome home. So we want people to feel at home and we want them to feel welcome. SoJoe Krebs 27:21alright, and there's even an invitation to start something there. So this is not just to join. This is also to create something if there is a gap or Yeah. Oh, yes.So I think you're the things you're doing with the Agile Kata. Marriage are amazing. Yeah, thank you.Tracy Defoe 27:38Thank you for that. Joe Krebs 27:40Tracy, I want to thank you and everything else will be on the show page of this episode. And maybe we continue the conversation if at some later point in time and see, you know what else is happening in the Kata world? Always appreciate it. Thank you.Tracy Defoe 27:55Thank you so much for having me.

Transcript: Joe Krebs 0:10 Agile FM Radio for the Agile community. www.agile.fm.Welcome to another episode of Agile FM. Today I have Claire Sudbury with me. She's the queen of questions at Made Tech, we're going to go through what that actually means she is out of Manchester, UK. She is a fellow podcaster. Also in the Agile space with a podcast that's called Making Tech Better. That title implies that we can be better, which is something we want to explore in this podcast, I'm going to share all the contact details LinkedIn, Twitter, how you can get in touch with Clare on the show page. But before we go right into the topic of Agile software development, I think that's where you had to find an umbrella term. That's for today. Welcome to the podcast.Clare Sudbery 1:00 Thank you. Hello.Joe Krebs 1:04 Thanks for joining me here to this to this podcast. And I have to confess, for a few episodes, we've been talking cultural topics, leadership topics, sometimes really scrum related topics, etc. This is very different because we're gonna explore the tech space a little bit. You're the host of a podcast that explores these techniques, that leads to better software, better technology, like better products using technology, we want to explore some of those now I have to also confess that my software engineering background a few years ago, I developed it in smalltalk and Java, etc. But it's been a while. So I'm super curious to see what's going on in the software development, what kind of trends we're gonna see, especially around XP. So what is the queen of question do?Clare Sudbery 1:54 That's a very good question. Well, so I mean, the most obvious place in which I am the queen of questions is the fact that I host a podcast. So I spend a lot of time asking my guests questions. But I also am just a person who asks a lot of questions. I've always been a person who asks a lot of questions. Whenever I'm a pupil in a classroom, I'm always that annoying person who has their hand hand up and is asking yet more questions of the teacher when everybody else is wants to go home. I always want to know more. I always want to understand things in detail. So it applies when I'm podcasting. But it also applies when I'm in technical leadership. So when I'm leading teams, as software engineers, I'm asking how could we do things differently? How can we do things better? Are we doing the right things? Are we even asking the right questions? So I'm asking questions about questions.Joe Krebs 2:46 Meta questions, wonderful.Clare Sudbery 2:50 But I'm also asking our clients, so we are a consultancy, I work for made tech and I'm asking our clients, you know, what are the problems that you really need to solve, which aren't necessarily always have questions, the problems that they think they need to solve? So it's also about knowing what are the right questions to ask to really get to the nub of the problem, and therefore make sure that we're on the right path to an effective solution.Joe Krebs 3:15 Yeah, this is awesome. I mean, the maybe today, this just makes you a little bit more uncomfortable, because I have some questions for you. But I noticed that in your profile, and one thing really stood out, and it was the title of a professional software developer, you labeled yourself in one of your professions, right. And it's interesting, the word professional, obviously, right software development as a lot of software, software development going on. But the word professional, there's, there's a lot in there, right? When you get in front of a software developer.Clare Sudbery 3:48 Now, that was actually the company that I worked for, had simply decided that that's what they were going to call software developers. And I do actually remember thinking that surely that word is redundant, because if we're being paid for it, then we are professionals. And so that was one of those were really it was outside of my control. There was simply a decision that this is what we are going to call our software developers. We're going to call them professional software developers. But it is it's a good question. Because funnily enough, I was talking to one of our podcast guests the other day, Charlene Hunter, about teaching software engineers, which is something that I also get involved in, I helped to train up our junior developers at made tech. And she was saying that in our training program, we are making a distinction between coders and professional software developers. So what we do is we take people we expect them to have learned to do some coding. And then what we say is, being able to code is not necessarily the same thing as being a professional software developer. So if you can write code, that's fantastic. That's a really good start. But just because you can write code doesn't necessarily mean that you can collaborate as part of a team to create a software product with users in mind that is developed for an organization that has a particular direction that it's trying to move in. And that has its own definition of where the value lies. So writing code in and of itself is not necessarily enough to be able to develop a significant software product that has users and will continue to develop and improve throughout its life. So I think that there is a distinction, in fact, being a professional software developer is more than just writing code.Joe Krebs 5:42 Yeah, I think it's also when I just think about like being professional about writing code, it's it also means to possibly say no to a release, if you don't feel like the quality is there, right or being professional about the quality, you're producing the quality you're observing possibly on the team being pushed into possibly where which you feel uncomfortable space and pushing back.Clare Sudbery 6:07 But there's so much in there. I mean, I've already my brains going off in five different directions. But there is the there is the pushing back element is something that software developers find extremely difficult. And I think to be honest, most people would, because it implies a certain level of conflict. And what's something that's really common that we see in software development is that we have stakeholders and business owners who have deadlines that they're trying to meet, and they become, and everybody becomes extremely focused on the deadline, and forget about quality because they're in such a panic to reach this deadline. Sometimes those deadlines are genuinely important. Like, you know, a thing, like the obvious trivial example is if you're working with a concert venue, and you're working to sell tickets to an event, well, once the event is gone, doesn't matter what you do, it's useless. So you that's a very hard deadline. And in fact, in the way that our podcast works is we deliver episodes every Tuesday morning at five o'clock, not every Tuesday morning, every other Tuesday morning at five o'clock once a fortnight, and where we are very strict about that. So that means that we have hard deadlines once a fortnight. But most of the deadlines that people are given are actually quite arbitrary, have been decided, based on quite odd criteria. When you look into it, actually, nobody's going to die. If you don't meet this deadline. People become absolutely fixated on the deadline. And often often the sprint structure of Scrum, software development and other forms of agile that focus on a sprint that can also become an arbitrary deadline. That means that people are are putting quality to one side simply because they feel like they're in a rush to meet this deadline.. It's incredibly difficult for people to say, No, slow down, stop, wait a minute, what about the quality, and particularly for software engineers to say, You know what this job that we do requires a lot of brainpower, it requires a lot of thought, it requires a lot of conversation. And if we feel that we have to be sitting at our keyboards tapping away writing code every minute of the day, and any time not spent, coding is wasted. Then actually, quality suffers. And not just quality, but our health, our mental health. But still people find it so hard to say, Whoa, you know what I would like time to think I'd like time to pause, I'd like to step away from my desk and go for a walk or have a meeting with a colleague have a conversation to a diagram. People find it very hard to say that in the face of the pressure to meet the deadline and to look productive. So yes, I think pushing back is is important, but also surprisingly difficult. And I think sometimes people say well, why didn't you push back without taking account of the fact that that is hard? Joe Krebs 9:22 Oh, it's definitely hard. Right? Just like while you were talking about the deadlines is like, I totally agree with you these deadlines. Sometimes they come out and you when you asked him questions about how did this deadline, this date, have something come up? It's like, hardly anybody knows how that date actually emerged. But that's the date. Sometimes I have seen dates that would fall on a Sunday. And I was like, what because it was the first of December, let's say, Sunday, let's say are you really planning on releasing on Sunday? No, no, no, of course not. Right. So and but people do think about these deadlines, obviously. Why? Because there's obviously a business reason. Hopefully associated with that, but what I want to explore with you a little bit is the other party just said, and that is the, besides the deadlines to pause to think. And that's something I want to run by you because I might be out of touch at this point. But I'm gonna run this by you. When I worked on software development projects myself. There was a high degree of visualization collaboration among team members, I would say and maybe that is the statement that is either right or wrong, it was we hear from you about whiteboarding electronically or in person, just the idea of collaborating together to for six people solving common, like a complex problem of some sort. I'm not saying that collaborating constantly. I'm not saying there will be lots of modeling or anything behind this, but I'm just saying like, I feel like lately, what I'm observing when I work with teams is more like the coding aspect and more chatter on Slack or, and things like that, less more like face to face to face. What's your take on that?Clare Sudbery 11:09 Well, first of all, I don't feel like really anybody can necessarily authoritatively make blanket statements about what's happening in the industry, because, you know, I only have my own experience to go on. And that experience, it will be broader than some because I've been working in consultancy for the last five years. So that means that I have been able to see across companies and across teams, so I haven't just been in one context for the last five years. But I wouldn't say that I have observed that as a trend. What I would say is that it is difficult, always always has been. And I suspect it always will be to persuade people that the best way to work is highly collaborative. So the best way to work, I would agree with what you were implying the best way to work is for people to spend time whiteboarding for people to spend time having those conversations for people to take a tech take a step back from the keyboard, and actually stop and talk and think about what they're doing. I think that it has also been particularly difficult in the last 18 months because of the pandemic and lockdown. So a lot of my colleagues have said how much they miss actual physical whiteboards. So now if we want to draw a diagram or have a in inverted commas whiteboarding session, we have to use tools like Miro, which are very good tools. But when you're not physically standing up and moving around and physically moving, post it around, I do think it you lose something, I think there's actually you know, there's something about the physical interaction with things that can really make a difference about how it interacts with your brain. So I do think that lock down has maybe exacerbated a tendency for software developers to want to work individually. And to just want to get stuck into looking at the code and not want to be bothered with having to talk to other people about it. I think that there is, I think we've been encouraged to categorize ourselves as developers of being a particular type of person that likes to have a one to one relationship with our computers and not be bothered to have to talk to other human beings. I particularly when I first started in my career, 25 years ago, I thought that that was the appeal for me, I'll be completely honest, I wanted to talk to a computer and not have to talk to people. I didn't like it when people came and stood at my elbow and tried to have real conversations with me, I preferred it if we could converse via email or, you know, the equivalent of slack. And that was when I wasn't working from home. So it was very easy to have physical conversations with people. And yet, I still prefered to have virtual conversations. And I had to be persuaded and I have very much been persuaded that now I realize now I prefer to I want you know, My ideal is to be in an office with my colleagues, to be able to use whiteboards to have a lot of collaboration, a lot of communication, a lot of time away from the keyboard. But I that was a journey that I went on. And that's a journey that I'm constantly bringing other people on as a consultant. And I think that there are lots of pressures that work against that one of them we've already talked about, which is the deadline. It's the idea that everybody must be productive. It's the idea. It's kind of treating the human beings as though they were components in a factory, that if they're not actually don't actually have their fingers on the keyboards and are not writing code, then they're not productive to this idea that you can measure productivity by lines of code, which is wrong, but it's beguiling. You know, it's you can see why People might think it might be true. And anything that stands in the way of that feels as though it's slowing you down. So it feels as though oh no, if I have to go and have a conversation with somebody I have, I have to go in a meeting, then all of those people in that meeting aren't producing code. So time is being lost. And, and that's, that is a conversation that as a consultant, I have to have over and over again, and I'm not sure that that will ever change. I think that in my ideal would be that everybody realizes that the gold standard is first of all, for for software engineers to be ideally pairing a high proportion of the time or even mobbing (mob programming) for people to regularly stop draw diagrams have conversations for people to give themselves time to think without feeling they have like they have to ask for permission for it to become standard for people to go for walks and give just give their brains time to think for people to know about the for instance, the fact that there's tons of research that suggests that our brains process things in the background, when we're not consciously thinking about them that actually we benefit from having time away from just banging our head against whatever problem it is we're trying to solve. But I don't, I don't know if we'll ever get to a point where that is just the accepted norm. I wonder whether and I have no I don't know anything about your career. But I wonder whether you fit the reason you feel like there's been a change is because this this kind of golden period that you had in the past was maybe just that you were working in an environment where people bought it and had managed to learn those lessons.Joe Krebs 16:40 Better? Oh, yeah. It was just more like a more visual thing. Maybe it was more common to go to a whiteboard, maybe it was so different at that time to go to a whiteboard, maybe it was more acceptable to say, Hey, I'm gonna go with my colleague XYZ on a long walk. And while we talk, we talk about a complex problem. And we come back with fresh new ideas. Why? Because I think that is, that's just something I took. But that could be just me by walking, and you're definitely closer to the, to the source here. In this case, where I want to talk a little bit about the social aspects of software development to like the pairing and everything. How would you get people to towards more pairing? How do you encourage people to do more pairing who feel like like you what you just said about yourself? Right? When I would be in dialogue with the machine, I'd be the person.Clare Sudbery 17:33 Yeah, yeah. And the way that I learned which I think is the best way is, is by having an experience of it. Because when I first joined the industry, I mean, I've been in the industry now for 21 years, but there was a gap in the middle of four years. So it's about 25 years since I first became a software engineer. And about 12 years in so about 15 years ago, my math is falling apart a bit at this point. But a while ago, I first heard of pair programming, and somebody mentioned it, and I said, Oh, what's that? And they said, Oh, it's when two people sit together. So software engineers sit together and write the code together all day, every day. And I said, that sounds ridiculous. And it sounds like hell. Horrible. Why would I want to be shackled to another software engineer all day, every day? What if I want the loo? What if I want to make a cup of tea? What if I, what if I feel like you know, and this is something that I never didn't necessarily feel confident to say out loud to anything, anybody other than my friends. But what if I feel like surfing the internet for a while and you know, I want a bit of downtime. And of course, actually, that's what everybody does. And, and I also thought that I have a very individual relationship with with the code, and somebody else would just get in the way of that. And, and then I tried it. And the way that I tried it was by being involved in XP workshops. So this was on my own time, I think the very first time I did any pairing was a day long workshop organized by XP, Manchester, which is where I'm based. And we split into pairs for short sessions. So I think it was something like four hour long sessions. And in each one, we wrote some code and then we threw it away. And then we joined another pair and started again and then at the end, we throw it away again. So those two things, they were very radical to me the idea that we might throw our code away, and also the idea that we might be working in pairs and I was really quite scared because I'm you know, I'm a little bit shy and I was convinced that everybody they knew more than me that they were all much more experienced. The other thing that the other thing that I was introduced to as part of this, the very same workshop was test driven development, which I was also new to, whereas a lot of these people had done it but before, and I just thought, Well, I'm not going to know what's going on, I'm going to expose my ignorance, I'm going to feel inadequate. And I'm going to slow down my pair every time because they're going to know what they're doing. And I'm not. And first of all, I discovered that they were very nice. They didn't mind if I slowed things down, they didn't mind that I asked the millions of questions that I always ask because I always have been a big asker of questions, they were happy to answer those questions. And that actually, a lot of the questions that I was asking, made them think as well as we use to them. And also, I discovered, there were actually things that I knew that they didn't know, which without the pairing I wouldn't have ever discovered. So I would have continued believing that I'm the only person in the world that Google's every other thing. And I'm the only person that forgets the names of things all the time, and I have to keep looking stuff up. And I don't carry an encyclopedia around in my brain, it's very easy to believe that everybody else knows exactly what they're doing. And you're the only one that doesn't, until you pair you don't realize, oh, actually, it's not just you, it's everybody. And also you realize that you there's a lot more value in what you know, than you realize, as soon as you're working with somebody else, and are able to teach them something that you know, then you start to see the value of your own knowledge. And then the other thing that I realized was that I absolutely have a tendency to disappear down rabbit holes. And again, that I'm not the only one. And when you're used to working alone, so I had been working in environments where not only did we not pair, but we didn't have daily stand up's, it was quite normal for you to be given a piece of work and then disappear for several weeks, there might be regular meetings, but they certainly weren't daily catch up's. And you were pretty much left to your own devices, which is fine until you get stuck. And if you don't feel confident to admit that you're stuck, then you get more stuck. And the more stuck you get, the harder it gets to ask for help. And the harder it gets to admit that you haven't actually made progress for a significant amount of time because you're stuck. And it's horrible, horrible, this awful kind of hole that you disappear into. And so that's that's one way in which it's very helpful to have somebody sitting right next to you who can instantly help you. But the other thing is that I mentioned before, which is going down rabbit holes, which is a slightly different thing. That's where you think you've worked out which direction you want to go in, and you've decided on a particular direction. And you actually might start to realize after a while, I'm not sure this is getting me anywhere. But I've started so I feel like I need to finish. It's kind of it's the sunk cost fallacy in miniature. When there's somebody sitting next to you, they're gonna say, What are you doing right now? Why are you doing that? You know, are we and you can say to each other, are we actually going in the right direction right now? Are we doing the right thing? Do we need to pause? And I mean, it's not a panacea, because it is entirely possible. And I'm sure many people who have paired will have had this experience, it's possible for a pair to disappear down a rabbit hole, you can both persuade each other that you're going in the right direction, they'll disappear down a rabbit hole, but it's less likely. And there are more checks and balances. And then yeah, I mean, I could go on for hours about all the benefits of pairing but but the other obvious one is that you share knowledge. So the other thing that was very much a feature of the early part of my career is that there would be people within the company within the team, who knew all the stuff, who'd been working on the product for a long time, who had deep domain knowledge and deep tech stack knowledge of the stack that we were working with. And we're really the only people who could solve a plethora of problems because they were the only people that have that deep knowledge. And that become this heart became this horrible self fulfilling prophecy that we can't ask that man over there for help, because he's too busy doing a really crucial job that nobody else can do. And he doesn't have time to share his deep knowledge with anybody else because he's too busy fighting all the fires that only he can fight. I just realized that I said he because at the time, I was the only female software developer on the team. But of course, it doesn't have to be a he. But, but you know that business of not being able to share knowledge goes away when you are regularly in the habit of pairing that there are nearly always two people who've had their eyes on any one piece of code. So there isn't only one person who knows how it works,Joe Krebs 24:54 as opposed to knowledge sharing where, people have purpose when they come to work. They want to learn they have a career path too, it's not like, they feel like, Hey, I learned something. Today I went to work, I learned something from a colleague, I got a new, you know, it could be a trick with a tool, it could be learning something about how to apply patterns or something like that could be anything that somebody will take home with them, it's this, this was worth worth spending at work and appearing, definitely encourages there.Clare Sudbery 25:26 And there's that lovely moment where you use a particular keyboard shortcut, or you use a feature of an IDE that your pair doesn't know about. They say, well hang on a minute. Oh, is that? That is cool. And you know, the amount that you learn as a result is fantastic. And I've been reminded of this recently with the podcast, in fact, because when we started making the podcast, it was very much my baby, and I was doing most of the work. And that became unrealistic. So I needed to teach colleagues how to, you know, do all the various different aspects of podcast production. And it was frustrating at first, because I had developed a rhythm and I had actually developed a much deeper knowledge than I didn't realize they had about how to produce a podcast and all of the various different editing and production tasks. And you know, how to record an interview, how to interview a guest how to lots and lots of different things. And I started to share that knowledge so that so that I wasn't the only person who could do it, it was just never a good position to be in, it's if you think that that's a good way of getting value as an individual it isn't. It's a millstone around your neck, you should never want to be the only person who knows how to do something. And so I started to teach my colleagues and at first, it was frustrating, because there were things that I could do really quickly. And I thought, I'll just tell them how to do it, and then they'll be able to do it too. And I would tell them, and first of all, they wouldn't get it instantly, because actually, I was given them really a lot of information. So they would come back to me with questions like hang on, I didn't quite get this bit, and what about this bit, and then second of all, the first time that they did it, they wouldn't do it as quickly as when I did it, not because there's anything special about me, but just because I had been doing it for longer. And that's that was frustrating, because the reason I was trying to hand off these tasks was to free my own time, and to just, you know, make the whole process more efficient. And initially, it didn't, it made it less efficient, because the you know, I was having to spend time teaching people, and they weren't yet be able to do it as fast as I could. But that, and it's very common that at that point people give up, because that happens all the time in software teams, people, you know, with the idea of the bus factor, I don't know if you if you heard that phrase, the bus factor, that somebody has a high bus factor, if if they are if they get run over by a bus, it will have a high impact on the teams. That gives them a high bus factor. And you want to reduce the bus factor. But in order to reduce the bus factor, you have to share knowledge. And in order to ship to share knowledge, you have to teach other people and you go through that whole process I've just described. And often people find that frustrating. And they give up. So they say, Oh, I tried to teach it to somebody else. But it was no good. They did. They didn't they didn't understand what I was saying. And it was too slow and too frustrating. So I've just decided I'm just going to keep holding all the knowledge to myself, not because I want to, but because anything else just feels too hard. And and that's very short termist. But but we know brains naturally are quite short term. So you have to, you have to encourage each other to take a long term view. But when you do you say okay, yes, this is short term pain for long term gain, that when I get all these people up to speed, I will be able to walk away at any moment and know that other people can pick up the slack. And that will in the long term be much more effective.Joe Krebs 29:01 Yeah. Clare. All what you just said I want to link to another topic. Okay. Yeah, because I think there's there's something in there. Obviously, the the social aspects of collaboration, building a product together, sharing, not being in silos. I'm going to make another general statement. And that general statement is about there's a lot of people that refer to agile as iterative development, let's say right? So there's a there's iterative development going on. And they're working in short cycles, etc, etc. But what's also important is that it's iterative, incremental. So the increment that to just to stick to a term out of the scrum world, but you know, is a piece which we want to build at the end at least once at the end of the sprint. And that is that is a product that is potentially releasable. Yes, this is where the general statement comes in. I've seen teams struggle trouble building increments sprint by sprint by sprint, not even multiple increments per sprint just like one. But it's and it's obviously, I don't know if that is it is related to let's say this the silo thinking that learning that pairing all of those things you just mentioned, asking for help, etc. But sometimes he you know, we see still answers today when I work with lesser experienced teams. They're like, well, we got the software down but not tested, right? Or we got we got a piece of software here but not integrated. So why is it that it's 2021 Ron Jeffries wrote this XP book many, many years ago? Why do we still struggle? What's what's so what do you think is behind that in software engineering teams? I mean, it's the push back, is it possible, the deadline? Is this the knowledge? But what do you see when working with him? So maybe I'm totally wrong, maybe on your site teams are producing increment by increment on a daily basis.Clare Sudbery 31:01 No, it's yet another thing that isn't easy, and does take effort and continued effort. And I think maybe what generally, what we're, what we're talking about here is the fact that people want there to be a manual, that you teach me how to do software development, I will learn how to do software development, and then I'll know how to do software development tick done. And it isn't that simple. It's it's continuous, you have to keep fighting these battles, keep having these conversations keep showing the value of doing things in certain ways. And the increment is a very important concept. So I tend to I like the phrase vertical slice. So the idea that what you want to do is deliver a vertical slice of your product from end to end. And that your definition of Done should be that it is in front of your users. So as you said, it's been tested, it's been integrated, it's been deployed, people are using it. And in order to have that mindset, you first of all have to have people who are who to skills cross a number of disciplines. So they have to understand how to make sure that testing is done, they have to know something about deployment. And that can be frustrating to people, I think, sometimes people, they want to be in a comfort zone. So people do tend to say, this is the thing that I like to do, this is the thing that I'm good at. So I'm going to stick to this thing. And then when I've done my bit, I'm just going to hand it off to somebody else and forget about it so that I can go back to doing the thing that I really enjoy doing. And in order to persuade people that it is worth seeing it through and caring about it all the way until it's in front of the users, you have to sometimes take them outside of their comfort zones. So that's one thing. Another thing is that it can be very tempting when you're looking for efficiencies, to think well, okay, these silos make sense, because you think of it like a production line, you know, my job is just to do this little bit of the process. And then I'm going to chuck it over the wall to the next person to do their little bit of a process. And that feels efficient. Because I can keep doing my little bits over and over again, I'm really quick at it, I know what I'm doing. But the problem is that unless something has gone all the way to production, you don't know whether you've built the right thing. You don't know if it works, you don't know whether it's going to come back again, with bugs or simply being told it's not fit for purpose. So it might not have bugs, but it might not be what our users actually wanted. Because the ability to have a dialogue with users and stakeholders and to really understand what the best thing is for us to create. That's highly complex, lots of things can happen. Even if you've got a really good relationship with your users, they can tell you exactly what they want. And then you deliver it and they realize that they were wrong. They didn't want what what they thought they wanted, or it doesn't actually do what they need it to do. There were things they hadn't thought of, or there are new things that have come into play. So getting something in front of your users quickly, so that when you discover that there are things wrong with it, because there always will no matter how effective your process there are ways of reducing the likelihood of that. But there will always be things that need to change. The quicker you can get things in front of the user, the quicker you can fix those problems. And the more likely it is you can remember how to fix it because when you made it in the first place, it was recently enough that you can still remember the detail. So that's that's why we want to deliver in vertical slices and why we want to deliver in increments but persuading people of that is a bit chicken and egg because until you have a very effective process that allows you to deliver vertical slices end to end. You won't see the benefit of it. and also you do have to persuade people that they're going to have to spend some time outside of their comfort zone that they're going to have to care about things that they don't immediately find interesting. You know, and also, you're gonna have to ask people to spend time with people that they might not feel comfortable about. So not everybody is delighted by the idea of being in contact with their users. Some people see this as being stressful people who are who are, you know, antagonistic and cause problems. And, and that's not because users are not necessarily like that. But it's because as soon as we start to divide ourselves, and it becomes very easy to get defensive. And as soon as two parties feel defensive, then each party feels as though they're, they're being attacked. And it's incredibly easy for groups of people to, to find themselves in that situation. And to start to see the I mean, there's, there's tons of psychology about it, the idea of the out group and the group. But as soon as you see a group of people as being other from yourself, then they they become net, potentially a source of stress. And it's, it's not simple to get development teams into a situation where they see their users as their collaborators, and they see their stakeholders as their collaborators. And they see that they can, they can take responsibility for and take an interest in, in all aspects of the software development lifecycle. It's not easy, and there are reasons why people will tend to gravitate into silos, and why people think that looks efficient. So it's a constant conversation, you have to prove it. And in order to prove it, you have to have certain things in place. So for instance, I'm a big fan of trunk based development, which is where every commit in the code goes to the main branch of your code, and then gets deployed as quickly as possible. Now, this is controversial, not everybody agrees with me. But there are a significant number of people who do that as soon as you create a feature branch, then you are diverging your codebase. And inevitably, at some point, you're going to have to merge that code. And by doing that, you're slowing down the speed at which your code can get in front of your users, you're not just slowing it down in time, you're also increasing the amount of complexity and therefore increasing the likelihood that something will go wrong, increasing the risk. So it's more likely that bugs will happen that merge conflicts will happen. And then you'll have to spend time fixing those bugs and fixing those merge conflicts instead of getting that code in front of your users. But in order to be able to get rid of branches, you have to work in a very specific way. You can't just write code in the way that you're used to, you have to think of every commit as potentially being something that will be deployed. And for a lot of people that sounds crazy, because they're used to pulling everything apart, and then putting it back together again. And and that you can't commit, you can't deploy every commit, that would sound crazy. To some people, it is possible, but it requires a different way of working, it's a skill that has to be learned. And then in order to learn it, you have to persuade people that it's worth learning. And it's it again, the reason it's chicken and egg is the reason you want people to learn, it's so that they can see the value of smart fast feedback loops, small vertical slices, getting things in front of the user as quickly as possible. But you can't demonstrate that until they have enough skill to be able to do that. In you know, and you have to persuade them why they would want to learn those skills in the first place by demonstrating it, but you can't demonstrate it if they can't do it. So, you know, it's it's long. Yeah, it's when you're seeing it work. It seems obvious. And it's frustrating if you can't persuade people. But if you haven't seen it work, it sounds painful, difficult and slow. So it's it's not easy.Joe Krebs 38:59 It's not easy, but it has a focus on the increment, right? Which is so so important, because that is that is value. And I can only agree with you all the teams that are producing increments. There is a, you know, it's definitely boosts morale on a team because it means that we have value produce, right. So in these short cycles, so but it is so hard to produce, because sometimes it's what you just mentioned, or the imbalance on of skills on a team that we have too many engineers and just not enough QA. And that is, you know, we might have a lot of code, but it's not QA and if you're breaking down the silos, and if you're working as a team, and you're learning and sharing and get out of your comfort zone. Yeah, that increment might be achievable. By the by the end of the sprint. So there's a lot in there. But you know, I often see that as a as a key element of development. So towards the end of our conversation you and I do have to say came back to and I cannot just say Ron Jeffries with XP books as well, obviously, can Beck's book there. So I've just shout that out. That's also an important book. In this thing, how do you feel about I just to the end of our conversation here about throwaway software, I see like software being like produced in shorter cycles. You know, the business world ideas being built on more and more software than it has been ever cars, everything includes software at this point, everything. So how do you feel about throwaway software, like instead of, you know, refactoring or solid software engineering practices to build code, and if needed, we're going to throw out the system and building a system because the business will change so fast about these trends?Clare Sudbery 40:40 Yeah, that was one of the things that came into my head when you talked Right, right back at the beginning, about quality about making sure that you have quality in your software where because actually, there are times, when you might say, in order to move quickly, we aren't going to dot every I and cross every T. Personally, I find that painful and difficult. Because I want to always produce a really good quality software piece of a really good quality product. But actually, yes, there are times and you what you have to do is you have to ask those questions, you have to say, is this something that is going to have longevity, and is this something that is going to be a crucial component that is going to be shared with other parts of our system, you know, so for instance, and it's not an easy thing to be able to detect. So for instance, software engineers are notoriously bad at knowing which bits of their code they should optimize. So you know, you will frequently see software engineers spending hours tweaking a piece of code to be the most efficient piece of code everywhere ever and, and not use too much memory and not not be too slow. And then once the whole thing is completed, you do some you run some performance tests, and you discovered that piece of code that they spent hours and hours and hours tweaking and optimizing hardly ever is hardly ever hit doesn't actually matter, it could have been 10 times as slow and it wouldn't matter because it's never called. Whereas the code that is called repeatedly and is slowing your product down is the one that you didn't realize, because you know, so premature optimization is something that you have to be aware of that. And you also have to know how to move fast. So for instance, you don't necessarily want to build a highly complex pipeline. At the beginning of your product project, you do want a pipeline, I would definitely say deploy as early as possible. I'm a big fan of The Walking skeleton, but don't necessarily make it all singing, all dancing, because what you might do is build in optimizations that you don't need. So wait until you're in production and then say, Okay, now what do we need to tweak? Where does the quality need to be? Which bits can we throw away? And it's not? I don't think there's an easy answer. So I think yes, there will, there will sometimes be things that you throw away, it's hard to know in advance which things they will be, there are definitely practices that you can use that will that will make it more likely that you can enhance and optimize your code. And I would definitely say building tests from the beginning, because they are almost almost always useful. And always be thinking about refactoring. But sometimes you know what that thing there might not need refactoring. It might be that nobody ever uses it. So yeah. And it might be that this thing here that you're building can be thrown away. And having that mindset that this is something that could be thrown away, is actually also very useful. The idea of building something and then throwing it away. And then building something else, which I mentioned a while ago, is something is a technique that's used in code cutters and in workshops. If you think of it as being disposable, then you then you can let go of it. And you can say, You know what, I'm going to build it throw away and then build another one. The problem is that if you say, Oh, it doesn't matter, because it's going to be thrown away. That's nearly always the thing that ends up being the absolute core. And in 20 years time, people are cursing your very existence. horrible thing.Joe Krebs 44:27 You want to really make sure it's will be the intended to throw away otherwise he's outlast you.Clare Sudbery 44:33 But it is important to recognize that that possibility and to always and this is why the increment is so important, right? This is why thinking small is really, really important. Let's do something tiny as a proof of concept. Let's not let's not design a giant system and try and build it. Let's design a tiny little example of whatever we believe is going to work and let's treat it as an experiment. That doesn't mean that we don't do it to a high standard. But if it's small, then everything is quicker. Everything is lower risk, you know, and you know, baking in quality is a lot quicker and easier when you're doing it to something small. And then you can throw it away when you discover that actually, it doesn't do what you thought it was going to do. You can have hypotheses, you can view it as an experiment. And that speeds you up.Joe Krebs 45:28 That was awesome, Clare. Good conversation. I know this was a little techie or today for the Agile FM listeners, it was a lot of use of the word software. If you have listened to this podcast and you're not in the software development space, you can replace the word software with probably any other word. It would still make sense, I guess. And, but this was a little bit more software related software development, projects and features, etc. Great insights. I think we covered a lot of ground here, but maybe maybe we start small and maybe you come back one day to Agile FM and more topics and add to it.Clare Sudbery 46:10 Fantastic. That would be fantastic. I'd love to Yes.Joe Krebs 46:14 Thank you so much. Clare Sudbery 46:16 Thank you for having me. Joe Krebs 46:18 Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.

Joe Krebs introduces the Scrummer Quiz 2021

Joe Krebs speaks through the lens of a manager with Johanna Rothman about micro-management, engagement, workspace, psychological safety, 1:1’s and feedback loops for managers.Johanna is the author of the “Practical Ways…” books series.

Transcript: Joe Krebs 0:10 Agile FM , radio for the Agile community, www.agile.fm. Welcome to another episode of Agile FM. Today I have Mark Kilby back to Agile FM. Because Mark was already here on the podcast in 2017. We spoke about remote teams at that point. And we're doing something very, very similar today, or at least we're going to kick it off this way. Mark, if you are not familiar with his work, is the author of from chaos to successful distributed agile teams, which was co-authored together with Johanna Rothman. Welcome.Mark Kilby 0:55 Thank you so much. I can't believe it's been four years. Yeah, yeah. The time has flown. Yeah, you know, we did our little pre conversation, and I didn't even make that connection. It's like, wow, it has been that long.Joe Krebs 1:11 Yeah. And the book has been out that long. Mark Kilby 1:16 The book well, so the, the ebook version came out in fall of 2018. The print version came out in early 2019. And, yeah, it's been doing well. And, of course, we saw a spike in March and April of 2020. Why? Yeah. So yeah, it's, it's, it certainly has been an interesting year for remote work. I'll summarize it that way.Joe Krebs 1:52 Right? Well, the book is filled with practical tips of how to work in a distributed way. So there's the word distributed is in the title, some teams just refer to it as virtual, some say remote. You chose distributed, they're not really interchangeable, right. So there's, there's a little bit something behind it. Some people are very, very specific and say it should be remote, because it's still in person, because you look at each other on video.Mark Kilby 2:21 So to be honest, and in Johanna and I have had this conversation, we just, we finally had to settle on something for the title. I don't like any of those terms. Because it sets up a bias. So if you say remote, within who's local, if you sent a virtual, well are some people real or not real. And, and the way we treated remote work or distributed work before 2020, that's that those biases were very much present. There was very much in us versus them. Then in 2020, us and then became all of us. And the big difference was very few people had a choice. Were those before 2020. Many of us chose to work remotely, we chose how to work remotely, we had a lot of time to develop that. Were, you know, this time last year, everyone was just trying to figure out, you know, do I need to work remote for a month, two months? No one, no one I don't think except for a few of us thought it was going to be, you know, over a year. And we're still in it as as the time of this recording, although there's light at the end of the tunnel.Joe Krebs 3:46 It's definitely light at the end of the tunnel. But I think there is there's a lot of learning that came out of these last 12 months, right? So we're recording this in March 2021. We have seen 12 months of distributed work. Let's just settle on this term here for for this podcast, right? So we have 12 months of distributed work. What is it? We we learned from this? I mean, there was a general misunderstanding or misconception about remote work was like remote teams don't deliver, right. So they're in their home offices and who knows what's going on in their home offices? Are they are they actually working like whatever its underlying kind of mistrust andUnknown Speaker 4:30 well, remote teams don't deliver, remote teams aren't innovative, remote teams can't respond well to change. So I heard many different myths around remote teams. And, and the funny thing is, it's really more around the organizational culture. So if the organizational culture supportive people kind of slipping through the cracks and not really producing it would matter whether you've remote or not. With remote work, because people are doing it by choice, they're coming in with a tension of, I want to do my best work possible. That's how we've recruited people. So when when I was working at as a full time internal coach, for the prior company I was at, we actually screened for that. So if somebody if somebody was wanting to work remote, just because oh, I can work at home. And again, this is pre pandemic, they were out if, if we heard, I want to work remote, because I want to work with a top level team, I want to do my best work, I want to be able to do my best work when I work at my best. That's what we listen for. And that's what we recruited for. When we when we heard that that's who we brought in, all those remote first companies are, that's who they're recruiting. That's who they been recruiting for years now. And these are not just small companies, if you look at companies like automatic, which produces WordPress and many other products, if you look at GitLab, and others, these are companies that are well over 1000 people. I mean, these are these are large companies that work completely distributed. No offices. SoMark Kilby 5:19 you see, all right, no, if you're just all or remote, it's actually very interesting, right? Because you just said like one of the myths is change, right, and being adaptable to change as a distributed team. And I mean, this change we just faced 12 months ago. I mean, it couldn't be a bigger change than that. I mean, it's like it proves that these that we are able to adapt to the situation, right?Unknown Speaker 7:01 Yes, yes. And those, those who were able to adapt well are starting to go, Hmm, this could work for us. Those that may. And I'm not generalizing this for everyone. But for those who are a little more resistant to change, they're probably going to ready to go back, although going back is going to be completely different. It's not going to be what they think, yeah. But the other thing is, on the emphasis around choice, some people need a separation between work and home life. Some in I totally understand that. And now having everything in one place, and when when it's hard for them to have that separation, they need the office, some need, who are more on the extrovert side of the spectrum, they need that constant interaction with others. There was one coach I worked with several years ago. She was brilliant, but she worked at her best when she talked through concepts. That's that's when the brilliance came through. And, and so I recognized early on, some people need that interaction, I did not, I'm more on the introvert side of the spectrum. That means I get more energy from ideas than interactions. So so if I so coming on the podcast, great giving a talk or even better being an open space, like we talked about earlier, I get tremendous energy from that. Because I can I can go through all kinds of ideas and share them and pick up new ones. But some, some deed that ability to vocalize instead of write and do other things. So they they need a different kind of choice. Where some be the choice of I need more control over my schedule. I don't need office hours, I need my optimum hours. So I think a lot of people are going to think about more about their choices as they have the option to go back. What are we going back means?Joe Krebs 9:19 So that's interesting. So you're getting your energy from in person the same way as you would get them from distributed kind ofUnknown Speaker 9:28 Oh, absolutely. Absolutely. The funny thing is, I was first Yeah, first week of March of last year, I was speaking at info Q London. And I was in invited by some other colleagues, Judy Reese, Lisette Sutherland. I had only met Lisette once. Before that in 2015. I had only met Judy once. There were two others there that I had never met, but we had conversed several times ahead good working relationship online for three to five years. And, and I'm able to do that, and I realize not everyone is so I don't think I am not on the remote is the future bandwagon. I don't believe it's for everyone. I think it's going to be an option moving forward. And so, so, so you so your listeners can, can breathe, breathe a deep breath, I'm not here to say remote is the way that's not what I'm here for.Joe Krebs 10:32 So Right. So it's interesting that you said over the remote guys. So there are folks that have pre pandemic, they had a nine to five job, let's say, right. And, and that there's nothing wrong with a nine to five, right? Mark Kilby 10:44 No, no. Joe Krebs 10:45 Right. So but then when they worked in, in a distributed way, the nine to five didn't exist so much anymore, right? So it was a different itUnknown Speaker 10:56 was, it was, it was more difficult to exist? Yes. Because now, especially during the pandemic, when some of us had kids at home, and kids at home trying to do schooling at home when they weren't set up for that they weren't prepared for that. When you had spouses, or significant others, you know, trying to figure out, okay, who has the maybe the one computer in the house, because maybe not everyone has multiple machines, or they maybe didn't have enough bandwidth. So they're dealing with all these challenges of timing, and resources, because they've been forced to work at home. And so the nine to five became near impossible for many people.Joe Krebs 11:42 Yeah, so and they might not go back to a nine to five to a point, right. So when they come back to find a different environment that's like, why am I here? And those office hours, so to speak, right, I could be doing something very much personal right now. And I'm going to add the hours at the end of the day when, you know, when a document is signed, and comes back from overseas, or whatever the business situation is like, it's the flexibility that that is very interesting that has this changed everything a little bit. Obviously, it came in from, you know, just hit us, you know, full speed, last March with the pandemic, but you also said something about productivity, they don't deliver and stuff. These are like the typical myths. Key. Can we roll this out? After 12 months? pandemic? I think we can, right?Mark Kilby 12:29 Oh, yes. Oh, yeah. Well, even even before the pandemic, when you when you have teams that look at, how can we work best together? And how can we work individually at our best? How do I, if I'm a if so I'm a morning person. So I know, for me getting up early five o'clock in the morning is a great time for me to start work, because that's where I'm gonna get my best work done. So there's a block of time where I do some solo work, because I can concentrate and get a lot of writing done helped develop the courses. And then there's time later in day for collaboration, where I can talk to you I can talk to partners, I can I can, the people I need to collaborate with, and I have those hours of overlap with that I set aside time for that. And then I block out other time for family, for exercise for other things that I need to also take care of, it's just not contiguous. Like in a nine to five job,Joe Krebs 13:33 that's fine. And there's definitely productivity, I think we see the companies are delivering products by software products coming out, I didn't see any kind of delays, or new releases or anything from something I think we just manage. I mean, yes, there is. Obviously this is maybe the psychological impact here with a pandemic where rather than the distributed world the for separating the two things that people feel like hey, this is not really working for me, I'm sitting in my house, but the thing is, you might be on a lockdown or you might be on you're just more isolated right now let's just fast forward a few years and and hopefully we're out of this pandemic by then. And we can free roam again in in offices, but we have a working model like this, we might come back to this and say like, you know what, this is actually pretty good if I'm not isolated if I'm not in a knockdown situation. So this model might be seen more positive right than it is right now.Mark Kilby 14:28 The pandemic was even difficult for me. So while I enjoy remote work, I also enjoy being in my community. So there's things my wife and I do to volunteer. I'm also active in the local Agile community. And that's been difficult because of things being shut down. Now fortunately, the local meetup has has adjusted well to online but some meetups completely shut down. Some it just like other services completely shut down. It just It just depends on who could support keeping going, who could support the social infrastructure. And and that's that's been the bigger stressor, I think over this last year for many people. So don't take that lack of connection as this is what remote is like all time. It's not.Joe Krebs 15:23 Yeah, exactly. Right. So the other thing is, like, I see I work with a lot of teams out there, they have back to back zoom meetings, right, one hour, another 30 minutes, zoom, another 30 minutes. By the end of the day, they had massive amount of zoom meetings with other tools, not saying Zoom is the problem here. But what I mean, obviously, there's a lot of online meetings, and they're all like the same, it feels like you're going from one segment after another after another. But you wouldn't really be able to tell from the outside that this the agenda has changed, right? It's just a continuation of the same topic.Unknown Speaker 15:59 What right because, well, they haven't they haven't stepped back, and really looked at what's the best way for us to communicate, what's the best way for us to stay in sync, what's the best way for us to move forward toward a goal. So those that have worked remote for a long period of time, realize there are times that we really need to be together. In a gathering, I'm not going to say meeting it for now, just say we need to gather, to decide on something we need to gather to debate something, we don't need to be together to give status to each other. We don't need to be together to to just give back and forth information. Some of that remote teams have figured out ways we could do this a synchronously, we can still carry on conversations asynchronously through any kind of medium, there's multiple ways to do that. And for the times that we really need to work with each other. When do we need to pair develop something so not just pair programming, but pair writing Pair? Pair creation, I've done lots of that over the last several years. And that's where you need to be in sync with the other person very closely. When When do example, from my last organization, I mentioned, the Senior VP did an excellent job of mixing asynchronous and synchronous communication. If there's any big change happening, he'd usually put a blog post out Sunday or Monday, there'd be a Wednesday all hands, and then he would have some asked me anything sessions after that. And he'd also have a special chat channel that people could reach out to him. So he had both ways of communicating so that people could say, Okay, I don't understand the implications of this change you just mentioned. Can you say more about that? So you, people who have worked remotely for a while realize you can use both asynchronous and synchronous and bounce that for number of things,Joe Krebs 18:11 right? That is awesome. So there's a lot to be even improved, right? Even beyond this. And maybe in a shared model where we do a little bit of both. Maybe there's a spin on it. Now we probably work this way.Mark Kilby 18:24 Even even retrospectives I've done a mix. I've actually I've done entire asynchronous rector's retrospectives. Awesome.Joe Krebs 18:32 Yeah. Cool. Yeah. And the technology. Alright, we have great tools. Just curious. Without you endorsing any tools, is there anything that stands out like on your on your list where you would say this is a really cool tool to work with in a in a distributed fashion?Mark Kilby 18:51 Well, boy, the tool set has changed so much in the last year. So you know, most people have seen zoom and all the changes happening there. I will say there, there is a wave of zoom contenders coming up out of the startup community, that will be interesting to watch, that will look nothing like zoom. So one in particular, I find, well, actually, there's there's a couple that are related. So if you look at tools like spatial chat, or wonder.me, both of those, take away the the walls of the breakout room. But you still can have breakouts, you could just move to different parts of space and just talk to people in that space. Or you can broadcast across if you have if it's a large conference, say several 100 people in these different small circles and say, Okay, I need to get something out to everybody. Here's, here's the keynote, or here's the announcement for a you might want to not miss this next presentation. So those tools have the way of reaching out individually small groups and much larger groups. or even even for conferences in, though you probably seen this one, hop in, has made huge strides. And they've had several acquisitions this year, too. So they're they're very much looking at how do you support hybrid events? And they're there. They're making some interesting moves there. So there's, there's, I think there's some interesting technologies that are happening and evolving. And the startup community, I think, is going to provide some, some, some interesting ideas over the next couple years, right. We'll see. Yeah, yeah. So still on top in two years.Joe Krebs 20:46 What's spatial? Just as an example, I've played around a little bit myself, but super interesting, because you see who's there on one screen, right? You don't hear them talk until you move closer to them. So it's like this. It's an audio thing that has changed, which is obviously extremely intriguing to for networking, etc. So really cool. Thanks. Now, I want to switch a little bit because you're working. Currently it is my understanding on a new book. And yet, the new book is about open space, exploring an open space mindset is the is the working title. I don't know if that's going to be the publishing title.Unknown Speaker 21:27 That's, that's the working title for now. And I'm co creating that with April Jefferson. So I say co creating because there's more than a book there. Yeah. So what we're doing is we're looking at some of the concepts, the principles, and the law of mobility. And how does that occur outside of the theater of open space? Where do people see that influencing how they work, how they interact in their communities. So we started sketching out several chapters, and we, we caught ourselves, putting many of our own stories in there. And we said, you know, this is about open space, we need to open this up. And so we started interviewing others, some in the Agile community, several outside of the Agile community. So we have some interesting, I will say the stories from outside the Agile community are probably even more intriguing. And how, how the law of mobility has showed up how the the right people have showed up, how the only thing that could happen, you know, what, what happened was the only thing that could happen for these particular people in certain situations. So we have many, many stories like that. We're also doing a series of workshops, we call them journeys, because we we go with them on the journey. So April and I are not, we don't see ourselves as instructors, we see ourselves more as guides, and we go on the journey with him. So we have we had a three hour reflection journey. What are different ways that reflection might look like for you? How will you step back and look at what's happened? And how you might reflect on different things that have happened? How did it happen? And how will you learn from that? So whether it's journaling, different types of grounding, we have some other unique things in there as well. We've got another one coming up soon on purpose. We've had some others on exploring options to think about your marketplace in an open space. So how do you how do you put the options out there to to see, and how do you how do you navigate those options? Right? So those those kinds of things we're curating for the folk in the project.Joe Krebs 23:50 It's also connect to your previous topic about distribution. Open Space In a distributed world. Open Space, it's very personal thing, right? When people sit next to each other shoulder to shoulder but I don't see that happening in 2021, necessarily, right?Unknown Speaker 24:06 No, no. But but it can also it can also help people explore how might you either work remotely or work with others who want to work remotely. So that that's were April, and I both have worked in person and remotely many, many different times. So that there is a bit of a theme under that as well.Joe Krebs 24:33 Right? So the the book obviously, is all about the the mindset of stories it's journey. Is there anything else you can share about the book are you in addition to that, like the structure the size because I've had Harrison Owen here on my podcast before. Creator of open space, right? What's interesting about this is that I feel like the Agile community took hostage of open space because Harrison himself, he came out of a very different camp, right? He came out of a different camp. So what you're describing in your journey stories is going back to the roots. Right?Unknown Speaker 25:16 We're we're very much trying to go back to the roots of open space. There's, and that's why I will say there are some, some agilists interviewed, but we were really trying to get a much broader set of stories. And where we're getting into those now. And it's it's interesting to see how the same principles show up in different ways for different communities.Joe Krebs 25:46 And it's my opinion here any any story to be shared, this is good. Why because open space is so eye opening, if you as a listener, listening to our conversation right now might not have experienced open space, give it a try. There's a lot of right now, obviously distributed open spaces around the world with different kinds of technologies. But it's it's liberating, right? Yeah, well, not surprisingly, it's a liberating structure.Unknown Speaker 26:13 Yeah, so and it's, it's in a way to emphasize, if you experience an online one, try to visit one with a different technology. So because then you'll realize it's not the technology. It's really about the space, how people curate that space, so that everyone in that space can freely share and learn from each other. That's really what that law mobility is about. If you're neither learning or contributing, you go somewhere else. And that is that is really a major element to any open space.Joe Krebs 26:49 Right? As awesome. So I'm looking forward to that release. When do you expect this roughly coming out for...Unknown Speaker 26:57 we're looking at the fall where we we still have chapters in in a bit of an outline mode, where we're going through the stories, figuring out where they will fit in some of the chapters. So it'll probably be an early draft here in the summer. And then hopefully get the final version out toward the end of the year,Joe Krebs 27:17 into the 2021. People can register already newsletters, etc. For that book and get announcements at MarkKilby.com.Mark Kilby 27:29 If they go there, look for books, they'll see the book listed and they can get on a special newsletter just for that book.Joe Krebs 27:35 Awesome. Cool. And if somebody wants to get in touch with you on Twitter, that is MKilby that's your Twitter handle. All of that stuff will also be on the show page, I have some links to the material, etc. That was a great conversation. Thank you. And I hope we get out of this pandemic soon. And see another version of distributed development following that and maybe a shared one, mixed one, whatever, whatever that is being called. ButMark Kilby 28:05 yeah, we could we could talk about this hybrid situations next time. That's a whole other set of conversations.Joe Krebs 28:13 Let's do that. Exactly. Awesome. Thanks Mark. Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.

Transcript: Joe Krebs 0:10 Agile FM radio for the Agile community, www.agile.fm. Thank you for tuning in to another episode of Agile.FM. Today I'm here with Chris Smith, who is the head of product delivery at Red Gate. And we have him actually explain a little bit what Red Gate does, but he's also posting information about the topic we're talking about here today on leadingagileteams.com. Our topic today is kind of a companion kind of podcast with something we have done just recently with Heidi Helfand and about dynamic reteaming. So this is the practical implementation on reteaming dynamic reteaming on the team at Red Gate. Welcome to the podcast.Chris Smith 0:59 Thanks. Thanks, Joe, thank you very much for having me on. Joe Krebs 1:02 That's awesome thing. So thank you for taking some time and spending some time with the listeners to talk about dynamic reteaming, we could say one more time. But last time I spoke with Heidi about the book, and some stuff that is important for people that are implementing this, but you're the person that actually implemented that at your company. Redgate.Chris Smith 1:21 Right, yeah, that's right. So, so already talked about a continuum of freedom for reteaming. So where maybe one end managers, organized teams and tell people where they're gonna go, and then at the other end, everyone has gets to choose where they work. And we're moving closer to that second stage where we give people much more influence over where they work, and which teams they're part of. And we do that every year. Joe Krebs 1:21 Right? Can you just give listeners maybe who are not familiar with Redgate, a little overview of just on a very high level? What is this company? What's the background? What's the size, geographical distribution, etc?Chris Smith 2:01 Yeah, sure. So. So Redgate are a small medium size software company, we are based in Cambridge, our development hub is in Cambridge in the UK, but we have sales offices around the world. And we create software for database professionals. So that database administrators, database developers, and our tools, help them do their really important jobs of creating, maintaining and operating the databases that support all our systems, corporate and consumer, there's a database in there somewhere, and our tools help the people that make those and look after them. In the last, in the last five years, we've been really focused on helping those database professionals bring the database into an agile and DevOps environment. So you know, agile delivery of application code has been around for years and years, often the database gets left behind, it's scary to change it, it's scary to integrate it in like an agile continuous delivery process. So it gets a kind of a waterfall back backdoor process that gets the changes out, and we want to bring that in there and get the database delivered agile-ly alongside application code. So that's been a part of our mission for the last five years. And, and, and yeah, we've got a whole range of of database products that we really hope will help help people develop databases in a really agile way. Joe Krebs 3:20 Yeah, that's actually a very good point is like, based on my experience working with teams with Agile teams. That is that is often a bottleneck if they are, you know, with a database administration, right, schema changes, etc. Right? So it's interesting to have like a product. So this is interesting for this podcast, right? Because we're dealing with a product that solvesor tackles a problem in the Agile community, but also Redgate itself is embracing agility. And obviously embraces some things that are about dynamic reteaming. Right. And that's our topic here for today. So tell me a little bit about how you came across this. Obviously, there is a book out there we I spoke with Heidi about but this is really about you taking some of those ideas into your organization. Now. How can how many times did you do reteaming? And how did you start with this? Chris Smith 4:16 So reteaming something is always happens. It always happened at every company I've been at, and where people join teams, people leave teams, teams, split teams have to end. And that's re-team and that's the creation of, of new teams. And but what we've been doing for the last three years is deliberately reteaming all of our teams or making an opportunity for everyone for me team off the back of our strategy, review process. So for the last three years, we've asked everybody in our product development teams, where they'd like to work in the coming year. Would they like to stick in the team they're in at the moment, or would they like to go and do something interesting they can see across the range of things that we have, we have 11, software development teams at the moment, they're all covering different kinds of products at different stages of their lifecycle, which means very different work. You know, if you're in a, you're working on a product that is very early stage, maybe creating iterating, quickly creating code that might not be super maintainable in the long term you're trying to learn, the whole point there is to learn fast. And you might find actually that you stopped doing the work you're doing because that product hasn't found its market and you go do something else. So it can be quite ephemeral. And then you've got other products that really well established me when I grow and scale their addressable market. And they have a different kind of work. They're about maintainability, and scalability and new features. And that works very different. So reteam to let people choose which of those kinds of work they'd like to invest their work life in for the next 12 years and beyond. So, we've done that for three years now. And it's gone, it's gone surprisingly, well, it's gone, it's gone really well. And people have been really happy with it from both the kind of team members that are involved in it, and the governance that the leadership of the organization. Joe Krebs 6:03 Right. So you have some metric points out there. So first of all, if you're doing this three times, while it tells me that it's kind of a success, because you would have stopped after one. You have success, right? And it's going very well. But you have some data points behind this too, right. And so I don't know if you know them from the top of your head, but there is some high percentage on satisfaction with this process among the employees, if not so much you but the employees that are impacted by this, can you share any? It doesn't have to be exact right? So but if you have anything that is like somewhere in the in the criteria, where you would say we're like in roughly high, I think I saw something on a blog post of north of 80% of satisfaction with the team that they picked, I think was even higher than ever.Chris Smith 6:51 Yeah, so in terms of what happened, certainly, the first time we did it, so we asked people, we made it very clear what was out there, what what possible pieces of work were possible teams are out there, what their mission would be, what they were trying to achieve, what their impacts were we were going to have. So they had all these choices about where they might want to work. And we asked them for their preferences. So what was your first preference? Where would you like to ideally go? What was your second preference? What was your third preference? Why was that? Why were you saying this was your first preference? Was it because of tech? Was it because of the lifecycle? And, and that was a big leap of faith like well, we'll ask these people will that create an organization that's effective is that fit for purpose for what we're trying to achieve? Like, it felt like he could have gone really safe, we could have had, everyone wants to be on the same team. But instead, we did get this spread of preferences and interest. So we were able to allow, I think it was around 85% of people got their first preference. 80% of people got their first preference in that first year. So we were able to meet their first preference where they wanted to work. And then I think it was 95% or something, they got one of their preferences. And the last few, we had to fit in with an option that kind of fitted their personal development, but wasn't an option they necessarily chose. So in the end, we got a very high level of satisfaction from our team members that they gone to somewhere that really spoke to them. So we ran that again, that the following year, again, very similar numbers. And in this last year, which we did entirely remotely we had 83% of our engineers who were in the team that was their first preference again. And 98%. Again, we're in the first second or third preference, and in the end, we moved 37% of our team members, which seems a lot, right. But it's been absolutely fine. And in the previous two years, again, a third of people move. So this is what I'm saying we're not we're not we're not completely taking all the teams apart. And putting everyone in different team. We're allowing people the freedom to move, right and the freedom to give strong influence of where they spend their working lives. And not all of them want to move but a decent number do and that's entirely supportable, we can cope with that. Absolutely fine. The last three years. Joe Krebs 9:15 It's awesome. 98% ended up with one two or 3 option, right? It's it's a very high number considering you know, delivery head of delivery like you would be assigning this you would have probably I would assume a lower percentage if you would assign people to teams, they might not like in the way they actually chose. Chris Smith 9:37 I honestly, when I when we first time we did this I did not know what to expect. It was as you mentioned, Heidi, I mean Heidi was a was a big influence on this, but I think you know, we call down. We'd call that at Red Gate, that we believe that the best way to make software is empowering teams with clear purpose, freedom to act and a drive to learn. We tried to make that principle we choose what we do behind that principle. And yet we'd have retained in the old fashioned way of like managers in a room deciding. And then Heidi kind of I actually saw Heidi, a couple of conferences, talk about her subject on every team. But hang on a minute. We're talking about giving people purpose and freedom to act. And I'm telling them what team to go in, what am I doing? And it was that kind of push it said, don't be a hypocrite. If you say that you want to give people autonomy and purpose and mastery. Ask them where they want to work. Give them that that opportunity to have a say, it was obvious when I'd seen that. Yeah, and but the first time, I didn't know what was going to happen, I thought I hoped it would, it would be a, I suspected that quite a lot of people would like to move, but not everyone would. Some people like the stability, it's the point in their career or the point in their life, or they're really engaged in their mission, and they don't want to move Thank you very much. But other people are looking for that opportunity. And by making it deliberate and making a date in the candidate, where we will talk about this, it is free I think a number of people up to move that wouldn't have wouldn't have otherwise tried something different. And also given them that opportunity to self-select onto a new purpose to self select a new mission. And I feel like a sense of ownership of of what they do in their career. So yeah, it was first time was a leap of faith. But following that, I don't think we'd ever go a different way now, because it works. Joe Krebs 11:25 Yeah, It's a, again, nerve wracking moment, right? If you're doing this the very first time and you're like, I have no idea how this very big event with so many people, it's gonna go and, you know, and it's big relief on the other side and, and prove that these things work. Once you go through it. Chris Smith 11:42 Yeah, I think it was definitely the fear, the fears I had before I did it. And maybe that reflects with with folks at home that might have the same fears. If we ask people where they want to work, they're all going to choose the same exciting team, they're all going to choose where there's the new tech, where there's, you know, Kubernetes, and everything else that we've seen exciting, or they're all going to leave a team that is maybe more, maybe one maintainability, or looking after a large, successful product, but maybe it doesn't, doesn't need a lot more features, it's kind of done, but it needs to be looked after, we're going to see all these people move away from the crown jewels and the most important, most important tools to the business. And ultimately, as a delivery manager, I'm gonna get fired, because of all my people. So that fear was definitely something we had to get over. And, and just sort of step into it. But I think we also thought about the fear that might be on the case of the people involved in the process. So you know, people don't love change in general. And so if you're in a team that you're feeling secure and accepted to actually leave is a big deal. And it can cause a certain amount of anxiety, I step away from that, that comfort area and go and do something else. So with the process of Redgate, we've tried to think quite deliberately about how we can make it reteaming without the anxiety, both for leadership in terms of oh my gosh, we're not delivering the things we need to, to the people involved is I've got to change teams, that is frightening. And so our practice isn't just, you know, we go along to one big session for two hours. And by the end of it, we decided what team we're on, we take a bit more of expanded approach, where we will make it very clear what options are available in the teams, then we will let people explore them in their own time, kind of asynchronously now with remote working. And then we will coach everyone individually. We have coaching sessions with everyone to say what have you seen? What are you interested in? Why are you interested in that? Let me understand your preferences. And there is a process where a set of folks have a set of leadership folks get together and look at those preferences that people have and look at the kind of organizational structure and the investments we need in different products. And can we make those work? And sometimes we'll have to ask people to come together for their second preference and not their first because that's really going to help us unlock this. Well, can I move in a couple of months when we've been able to disseminate the knowledge, it's in your heads and to the rest of the team? Because people are involved in this change? Because it's a change with them and not to them? They've been really open about those things. Oh, yeah, I'll go to my second choice. Happy days. I mean, I understand why that works. Or I will delay for three months no problem, because I can see that my unneeded in this thing before I move. Once you include those folks in this re-org some might call it then it becomes a much more collective experience and a much kind of a less anxious project. Joe Krebs 14:48 Yeah, it's interesting. Why because you might let's say I have a project one, then two and three as listed on my, my preferences right. And I might get assigned, let's say you as a department head without dynamic regime teaming to, let's say, option three. And for me, as a person being assigned to that team, I might have a negative association to it because I was assigned to it. But if I self select, and I pick three, all of a sudden, it's like I picked that I picked this team, and it was just my third option. But then I made this choice or sometimes, you know, human behavior might also deep down psychology always is like, was this somebody told me to be here, or I made the choice to be here. And even though it's the third option, I might still like Chris Smith 15:37 Yeah, absolutely. I mean, I'm Have you read the book, The Chimp Paradox?Joe Krebs 15:42 No.Chris Smith 15:43 It's by a chap called professor, Steve Peters, and he talks about, he introduces a model that helps you understand how the brain works. And it's very abstract, but it kind of helps me understand it. And that kind of, it talks about your kind of inner, inner, inner Chimp, but the kind of the thing that's, that's kind of captured in your amygdala, which is very, it's very reacts, it's very emotional. And effectively, your chimp doesn't like being told what to do. So by a manager telling you that you need to go into one, you will quite naturally quite physically have a real reaction to that. But it's normal for you to think, Well, why are you telling me I should have a say in this, I need to have some self determination. And you're right, like some people could actually choose that team project one themselves, because they've got the choice. And then their experiences that will be totally different from from being told to go in it. Because they're included, and we cared about what they thought and we looked after their, their psychology and their inner chimp. I think another thing that's happened, that I've noticed, having done this for three years that it's completely normal, I think for, for people to look for someone to blame, if there's a difficult time, on a project, like it's on a project, it's getting really gnarly, there's something very difficult to hear that we got some real hard things we got to do. And it's kind of normal to say, well, they've done this to us, you know, that we've been put in this situation. I've been putting this I'm a victim, I've been put in this situation. And it's really hard. Whereas you, we chosen now to be in these teams, we've seen what's coming and the gnarly work that's coming, and we self selected onto that, and we're gonna give it a crack. And we're going to do our best here. So there's much more kind of, as you say, sort of, they understand why they're here. And they have chosen it. So they they're gonna crack on with it. Much less us versus them now that I see the around team mission, and the kind of the difficult stuff that teams have to take on.Joe Krebs 17:40 I have a question like you've been with Redgate, prior to the time and you started reteaming, right. And so at one point, there was this moment where you said, I'm gonna try this, obviously, there could have been any kind of impulse, we said, you know, I, I need to do something like, I need to experiment with something, and it led to this process. But what was the time before reteaming? What were the challenges you were trying to solve? What was Redgate prior to reteaming? And just as compare now like, what was the business reason or the need to actually say we want to try something right? And then the path took you to that approach, which we now call dynamic reteaming. But just curious to hear, like, what was the trigger? So if somebody is out there and says, Well, you know, what was the problem that we're trying to solve?Chris Smith 18:28 Well, there was, there was that piece where yet we were talking about these principles for organization and not living them by doing things in a different way. So there's that part, which was, which was important, but I take your point, it wasn't it wasn't the pure business driver. I think we wanted to make a big change. And we wanted to restructure in a way, where, as I said, we were clear about what our product teams were for. So where they were in sort of Kent, Beck's 3x model, were they exploring? Were they expanding, were they sustaining, and the work was very different, we want to be very clear on that. And then when we're clear on inside product x you are in, you're in exploring products, you looked at the folks in that team, and you knew that wasn't the kind of work they wanted to do some of those folks, they wanted to do some of the other work. They wanted to do some of the scalability and the performance work that is in an expand or sustained products. So you can see people were in the wrong place, and being clear about what the products were trying to achieve. So there was a problem of how do we get them in the right place, while not destroying everyone's morale and having this big, crazy real, where people tell everyone else what to do. So there was that but also, I think we were seeing real silos in the organization. So Redgate for a long time has been a product company. We've got product teams, literally. And we built up teams to be autonomous and self sufficient as much as possible. And when they do that, they stop talking to each other completely Naturally, they solve their own problems and a team that's sits next to them literally next to them, you know, when we're allowed in the office, they wouldn't necessarily share what they were doing. And we end up with components that did the same thing across products. So we saw these, these silos. And we also saw, I mean, I used to totally believe in like that kind of stable team that stays together forever. And that's the best kind of team. And this has changed my thinking, because what you see there is not only those silos, but also people that become the expert in a thing and never leave. And they never can leave, because all the knowledge is in their brain. And all the knowledge around the teams becomes tacit, it becomes part of the groupthink of the team, not explicit. So it's not written down anywhere, because the silo know all these things. So we were we were having a less agile organization, as a result of that siloing that ossification, that when it said, right, it's time to create a new team on product X. We weren't used to changing teams, we weren't used to people leaving and we didn't capture the knowledge in a way that could be shared easily when new people joined. So we needed to get good at reteaming, which is kind of the central central premises of Heidi Helfand's book. So with reteaming now, I think what we've seen is breaking down some of those silos. If you think about it, in the last three years, each time about a third of people have moved. You think about that dissemination of skills and relationships across our organization, that it's easy for me now to go and talk to Team X. Because I know, Jeff, because Jeff used to work with me last year, but we reteamed an error in different things. But I had that connection. Now, we're breaking down some of those silos and building up a kind of an organizational network, but quite naturally was going away because of the strong silos. Joe Krebs 21:47 So innovation is therefore also like, there's a foundation for innovation, right? Because I might walk over to another person. I mean, you know, in your example, I think, Jeff, would walk over and have a conversation with that person and say, hey, you know what, I remember you from the last year's team we worked on together, and you mentioned XYZ, and I'm now seeing this. And that might be a big thing for us as a company. So as a platform for innovation,Chris Smith 22:11 we also had probably an issue with allowing people to progress, their personal development, their learning and development goals. So not everyone, especially engineers, that don't want to be the manager or the team lead or the or the whatever. Next, they wants to widen their skill set, they want to learn new technologies, they want to get more experience in different areas. Yeah. And you can do that by changing teams by saying, Okay, well, I want to, you know, some of our teams or some of our products or plugins, to Microsoft IDs, but I want to work on a web tool. So actually, I need to widen my web skills. And I can do that by moving to that is that is that is my personal growth. That's my personal development. I feel like I'm learning I'm happy when I'm doing that, can we be needed to enable those because we weren't doing it within the teams.Joe Krebs 22:59 So you have these events in the last event was a remote event. And so the first two were in person. The third one is remote. What's what's your takeaway from a remote event? And reteaming? Obviously, you might have gone into the same, like in the first one you had fear about this is going to work? Maybe another moment, a few weeks? I guess it's going to work in a remote way.Chris Smith 23:23 Yeah, it went, it went really well. And I think I was confident as we went into it, because our organization the same as many organizations that have been forced to, forced to work more remotely is to have people away from the office and working from home from from distributed workplaces, is we've picked up tools. And we've learned techniques over that nine months of doing that they've helped us understand, like, we've learned how to collaborate remotely, we're using tools, visual organization tools like mural, and Miro, yeah, things like that, using virtual meeting spaces, so we can have big collaborative sessions, we've learned and with those tools that we're going into, I was quite confident. But actually, if you'd have asked me a year ago, before we got good at remote working, I would have told you it couldn't happen. It's impossible. It's too connected. It's it's a kind of a it's an experiential event, you've got to get everyone in the room, and they all like spark off each other. But actually, it was, it was probably better. Well, remotely. I think a couple of the reasons were, if you put everyone in a big room, and they talk at the same time, you can't hear anything. So our virtual space, using a tool called spatial chat, meant that you could actually move around the room and hear specific people and encrypt everything else that we could actually share some of the collateral to explain to team members what their teams, what the different teams will be doing next year, we could share that upfront. And people could consume that asynchronously in their own time that could really deep dive into what we call team charters, which we're painting A picture of what a team would be like in the coming year, they could really invest in those. And also as, as leaders trying to visualize all these preferences and work out if they fitted a tool that online that captured how things were progressing, and you didn't have to write up the notes from the meeting, because it was there in the tool. And we used to go into a meeting room, and we used to stick post it notes on a wall to help move people around, I'll just gonna go to that team. Julie's gonna go over here, but the post it notes will just fall off the wall. And then you'd be like, what was the team, like the team is I've got to put the team back together, because the adhesive isn't good enough against these walls. So if it was none of that kind of like logistics problems in putting the jigsaw puzzle together, because the remote tools were so good for helping that. So yeah, I actually think when we get back to a hybrid world, probably at Red Gate, where we have people in the office and back at the office, we will probably go home, all of us to do this process remotely on purpose, because it worked out well. And use the kind of time in the office and social time, it's collaborative time, it's kind of connection time. And this can be a process that actually happens remotely, right.Joe Krebs 26:13 And you can even prepare the remote rooms. But sometimes you walk into a meeting room, and you have to prepare the room right here, I can actually prepare everything and you go in, that's might be a good time saver to.Chris Smith 26:24 Absolutely, I forgot that about working in an office, when you go into a room like one minute before it starts, it's just a garbage dump. And there's things everywhere and the wall isn't being cleaned down. And then when you're finished at the end, and there's only a minute left of the meeting, and you've got all this stuff on the walls, and the next person is waiting to come in, you've got to take everything off the wall before you say I forgotten and that's what happened. But that's that's gone now, when we're doing these things remotely,Joe Krebs 26:50 definitely has changed. You just mentioned something in your last comment about the team charter. And I want to explore this a little bit. Because if somebody listens to this right now, and we're talking about dynamic reteaming, and somebody's choosing Team A over B, or preferences, etc. They're not just going to make this out of the blue. Yeah, and this is gonna be this is not like personal favorites, I want to work with a specific person or something like that I like this person, there is a there is something that guides people in their decision making. Right? And that is the team charter. If I if I'm not mistaken, right? Can you just give listeners a little bit of an overview. So it's not like there is something behind it, which allows people to really self select the teams?Chris Smith 27:30 Exactly, we have to give people the full context, the full idea of what it will be like in these things. It's a big deal to swat team sometimes, and they need to know what they're stepping into. And he's got to visualize what life will be like in that team, I think. So the team charter, which is just a lightweight canvas, filled in by the leadership roles around the team, who are in place, before other folks have in place, they're there to shape what that team will look like before we get people involved in joining as developers and designers. It calls out the mission. So as I said, before, we're getting saying we need to give you clear purpose. So that needs to be there. Why, why is this team here? What's the impact this is going to have for Redgate? Like, what are you doing? And so we're going to call that out, we can say what this team own? What's the scope of your work? Do you own this product? Or these two products? Or this part of this larger product? What's What don't you own? There's a legal understand again, what that kind of thing that we're doing. And also, you know, by then we should know what the product strategy is, how are we going to be trying to make these metrics move? We're going to be trying to do some competitive features, or we're going to be moving into a new database technology, what is what is going to be the strategy behind this work? And we'll also talk about what's life going to be like day to day and that team. So is this a team that really likes mobbing a couple of our teams do a lot of mobbing even remotely. And really heavy on pairing, it's worth knowing that before you go, you don't want to arrive at that team. Being someone that's, that doesn't really enjoy mobbing so much. And that's all they do every day, you need to know what because there is some variety in practices and techniques across our teams. So about those. And also we talk about and this is an important part of it, as well as the constraints. So for this team to be functional and able to do the job, it's therefore we need these things. So we'll need some people with experience with this product before we have to have people that know how these products work. We need people that have this product this skill with this with this technology react C sharp will need these skills and will need a mix of experiments perhaps on senior to junior we can take a few people that we need to mentor but we really have to have a strong senior in there. So we encourage leaders to be very clear about what they think they need in their team. And for that to be open to everyone so they can say oh, I can see how I fit in there. Yes, I'm a junior but they're okay with a junior so that could really be a good fit for me. And they do mobbing which is a great way for me to learn. That's a team I'd like to go to I'm not so bothered maybe About the higher purpose right now for me in my career, it's best that I can learn from experienced person. So that's the team I want to go to. So it's quite a multifaceted view on, on what the team will be like. But and then lightweight canvas, it's not a lot of words, it's a canvas that that people can fill in and absorb quite quickly, I think.Joe Krebs 30:20 I mean, this is fascinating. I think this is important, right? Because people need to have the foundation for a decision, right? It's like, it's like, what is what is my skill level? Where do I want to go? Maybe there's a bridge between my current skill set and that future skill set. And there was a ton of people, if not the majority of people who like to learn, right? They want to learn some new skills, especially around technology. I mean, you want to just see something else, or you want to explore different product, or you know, what team you want to be associated with. But you mentioned, you had these three events, and they were annual events. So what if I pick the wrong team and made the wrong? Let's say, I pick number one team, and I got one, my first preference, and I got it, and I'm happy and I get started. And then I realize I'm not liking it. It's not my thing. Is there? Is there an opt out somehow? Or is that a static process for a year that I'm locked in into a team? How would that work that somebody like because it's dynamic, right? How do I possibly shift between teams, even after a reteaming event? How does that look like it? at Redgate.Chris Smith 31:26 Yeah, it looks like people sharing their experience with their line managers, and then as its people moving, I think this process has allowed us to get good at reteaming has allowed us to build up the kind of explicit knowledge, the team building activities that we know how to run, just an acceptance that people will move teams, we're not so surprised when a stable team has to change because they always change. Yeah, so we're, it's not like we'll do we'll change once a year, and then you're locked into next year? Because I think I think an interesting point is, is we always were like that Redgate. We always said, if you didn't like where you were, and you wanted to move, you can ask the moon, that's fine. Like everything that I've been Redgate in 10 years. It was always the case. But nobody ever asked to move. Yeah, it wasn't a thing that you did. But now it is. Because every year we said, look, it's totally fair to move, you're not criticizing your teammates, you're not saying you don't like your team leader, you're just saying you need to move your career or your personal development or because you need a change. That's fine. So it's now a normal thing. So I think it's much more likely people say, actually, I want to move media and providing the can because clearly, we want investment in certain teams, and we don't want to leave teams under invested. So they're quite fragile. We need a certain size of team for it to be for purpose, provided we can do that. We will move people and we have moved people in media, if that's what they would like. And again, people are very open to saying, well, we need to we need to hire somebody to take your spot. So it might be couple of months. It's like fine, as long as I know, you've heard me and you're going to I'm going to go over there. This is fine. I it's not a problem. I will. I'll keep you in this team until until we ready.Joe Krebs 33:15 Awesome. Yeah. Would you would you recommend anybody listening out there to go with that flow of yearly annual events? Or do you see any need for possibly shorter reteaming kind of experiences every six months or so? What is the pros and cons? And why did you guys settle for a year? Chris Smith 33:34 So for us, it's it's yearly because we had previously an annual strategy review process. So with all our different products, obviously, we are trying to be agile, we're trying to respond to the market and change and not plan too far ahead and then respond to what happens. But we do have a yearly process where we say where do we want to invest? We can spend this much on teams, we can add this many people do we want to invest in this product or that product to this and changes do happen? We double down on some products, we spend a bit less than others and we need to create a new product. So it is there's an obvious change point, there's an often obvious reflection point for us in our annual calendar. So doing it then makes sense. There is obviously an overhead to reteaming like this. I think I said it wasn't a two hour meeting where you drop in. And then by the end of it it's we prepare these charters on the back of Product Strategy. We get our leaders in place and then we have that prolonged interaction where we show everyone what what is on offer and then we get their preferences and then put them in a place overall this year it took us 15 working days 15 working days from hear the charters to your in your new team go. It wasn't we weren't doing the work during that 15 days, but clearly people's heads were thinking about what can I do next and it's a bit of a distraction. So if you're going Do something like this. It feels like quarterly would probably be a bit too often to be a bit too much overhead. I could sort of see it six months if there was a reason. Yeah. If there was like that driver that change in strategy, that means we're actually now it's reflection point, we should do that. Again, no big project has stopped a big one starting and actually, there's some opportunity see, I can sort of see it's doing that. But firstly, it's working annually. quite nicely. And actually, we've had some people say, I wouldn't want it any more often. Maybe every two years like you asking quite a lot. Asking once a year. It's not that often but I think there's there's there's a comfort people happy changes in the year for us seems to be a sweet spot right now.Joe Krebs 35:39 Yes. Wow, this is really awesome. Thank you for spending some time here and explaining some of the, you know, the ideas behind dynamic reteaming here, at Redgate. Okay, this is awesome. Thank you so much for for sharing those. And I just want to refer all the listeners also to your I call it the blog, the leadingagileteams.com Where you you know, somehow share your experiences from these events and experiences also throughout the year. So that's a great source for information. There's also some videos people can watch about you in action, so all cool stuff. Well, thank you, Chris, for that and I'm on the show page I'm gonna make all those links available for all the listeners. So thank you for your time.Chris Smith 36:25 No worries. Thank you very much for having me on. It's been a pleasure.Joe Krebs 36:27 Thank you for listening to www.Agile.FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.

Transcript: Joe Krebs 0:10 Agile FM radio for the Agile community. www agile.fm. Thank you for tuning in to another episode of agile FM. Today I have two guests to Christiaan Verwijs, and Johannes Schartau. They both wrote together with Barry Overeem a book called Zombie Scrum Survival Guide, which was released in November. It was released in November 2020. Why not on Halloween? That would have been the perfect release date for the Zombie Survival Guide on the 31st of October. But you came a few days after that. But first and foremost, welcome to the show. Welcome to Agile FM.Johannes Schartau 0:55 Thanks for having us Yeah,Christiaan Verwijs 0:57 thank you so much. It's a pleasure to be here.Johannes Schartau 0:59 I think to answer your first question, we won't name any names, but there was a big publisher involved in our book. And not all publishers are very agile. So that wasn't possible. That was also our goal. But you know, we took what we could. And that was November.Joe Krebs 1:20 November. Yeah, but just about that timeframe. So it's been a few months. Congratulations for the release. That is part of the professional scrum series that book, I think those are like five, six books or something like that in that series. So that's where we go Barry cannot be with us today on this show. But I will gonna talk a little bit about the survival guide. It hit the shelves, it's available, you're shipping it like crazy. So before we even get started, now that everyone here on on that show might be familiar with that. zombie Scrum, what is that? And why is it bad?Christiaan Verwijs 1:59 Yeah, well, it's pretty bad right to Hamas. Yeah, well, I think I think there's just some of the old scripting for zombie scrum instead. It's something that looks like scrum from a distance. So you have all the events, the artifacts, the accountabilities that you would expect, but there's no beating heart. And that usually manifests as in a complete lack of working software stakeholders are not involved. There is no, no autonomy for the team to make any decisions of their own about the product that they're working on. And nobody seems to care about it, or try to improve anything. And I think that's sort of the thumbnail description of zombie Scrum.Joe Krebs 2:41 Right. So what was the trigger for you guys writing it? I mean, what did you guys observe? Are there I mean, you're both training. Christiaan, you're a professional scrum trainer. Johannes you're an Agile coach. So I'm pretty sure you guys see a lot of Scrum out there. When working with clients, and what was the reason what triggered the book and like I said, there's something has to be done.Johannes Schartau 3:04 Well, several years ago, we talked about what we were seeing in the industry and what we could make some kind of impact. So that's how our collaboration got started. And even with a deep question of what would actually make a difference. And what we both saw, and we later got Barry involved, was that Agile has reached that kind of maturity stage. So when we started out, it was just this weird thing that some people did and would never really catch on. But then suddenly, it did and got really successful. So what we saw though, was that there were all these books on Scrum and Agile, and they were all describing this perfect future and all the benefits you can you could get from Scrum. But most people we talked to, they felt like they were trapped in a system that didn't deliver on that promise, and it felt lifeless to them. And they also felt stuck and not able to change the whole system. So that's kind of what we identified that these people really needed some help. And while everybody was just talking about this, this is how you do it. And this is what it looks like in the perfect world that wasn't really addressing the the issue that people were facing, that this was, this was not the way that was playing out in their environment. Right. And so that we thought it's kind of weird that no one is actually talking about it. Because with our clients every time we mentioned that, and also said, it's not just you it's something we see more often there was this big relief, like Oh, really, that's like, you know, I thought it was just organization, but maybe it's a bigger thing, and other people are also having the same issues. And once we we gave it a name, that's really when it took off. So we were kind of hesitant at first because the metaphor can be maybe confronting to people and maybe offensive, but we tested it. And the response was just absolutely, overwhelmingly positive. And like I said, often when we're just the fact that we gave it a name, gave people the ability to talk about it and also feel connected to other people. And that's, that's when we knew we had to go deeper. And after some workshops we did and talks to conferences, we thought we should really write a book about this. Yeah,Christiaan Verwijs 5:25 I think that that was something that we actually did somewhere in 2015, or 2016. That's when we started developing this idea, right. And to add the honest explanation of why we wrote a book, it's also that both Johannes, me and Barry, also, by the way, we have experienced scrum in teams where it works really well, where stakeholders are involved, where it's a lot of fun. I've been with a team for nine years, and it worked there. I mean, sure, we made mistakes. And we did some stupid stuff, some of which is in the book, by the way, but it works. And when I started looking, visiting other teams, I saw it wasn't always the case that it worked or not at all. And that kind of surprised me, because I wish for all teams to feel what it's like to work with Scrum effectively, and see how it actually helps them rather than be annoying or frustrating. And I think that that's also a big drive behind the book to show that it is possible and that you can do it.Joe Krebs 6:23 Yeah. I mean, it's interesting, right. So in the beginning of of Scrum, like in the early 2000s, there were books about how to get started with Scrum and so on. Right, that avalanche of books of Scrum introductions, etc. This is, this is a turning point, right? Because now we're talking about how to do Scrum. right! So there's a lot of people that have been trained to have been gone through training programs, etc, right. And now they're applying it and they're falling into this into this. You know, Zobie kind of behavior here, right? What are some some patterns that I'd say there is a listener out there listening to us right now? And he's just like, I don't know if I'm doing Zombie Scrum or not? Right? Like, what is it like a pattern? Maybe you can describe one of those patterns that you would say that is an indicator for your running a zombie Scrum?Christiaan Verwijs 7:11 Sure, I can take the first one. And you almost can probably add more to that. But I think the most important one that we see is that there is no working software at the end of the sprint. And if you put this in scrum framework terminology is there's no done increment that's that's released at the end or near the end of the sprint to stakeholders. And in the case of severe zombie Scrum, that never actually happens, or maybe a year down the road, maybe there are releases happening to an internal staging environment, but it's not actually going to customers that are paying for the product, it's not actually going to the people that are going to use it, it's just going to internal stakeholders, whoever they are. So this lack of working software at the end of the sprint, for us, that's one of the biggest indicators that you're probably dealing with zombie Scrum.Johannes Schartau 8:01 Right. And I just want to mention that we have a survey that you can take at survey at zombie scrum.org which is going to help you evaluate and we we designed the survey a while back. And it also kind of informed how we structured the book. So we have five big sections. First one is, what is Scrum? And does your challenge actually match what what scrum has to offer, because that's usually where it kind of starts, then what Christiaan said about shipping and getting the whole empirical process. So what is often makes this so empirical process control, loop started and new transparency, inspection adaptation that can only happen when you actually have a product that you can inspect. And if you don't have that, then the whole thing doesn't really happen. And you just Christiaan to just touch briefly on it. So what you want to do in in Scrum and with Scrum is to deliver something that stakeholders actually need, which is interesting that, you know, when you talk to zombie Scrum teams, they believe that is what they're doing. But one of the questions is, you know, who are your stakeholders? And that that kind of gets this whole discussion started? Like, where does the need for your product actually arise? Who benefits from it who invests in it? And we often find that zombie Scrum teams are far removed from the real source of that need, or the the value that you that you want to ship, right? And with that distance, there's this again, there's a disconnect between If you ship you get feedback, if you're actually delivering value, but you also need to get from the right people. And the scrum doesn't really explain what stakeholders are. So people often assume that it's built from accounting or, you know, someone inside the company that they kind of put in place as the stakeholder because often they other people can cause trouble for the team if they don't do what they're supposed to do. But that doesn't really mean that yeah, that that is where the product starts or where, where the whole loop kind of closes.Joe Krebs 10:22 I think that's that's an interesting thing. Right? So what do you what you said Christiaan? On on the done? Are you both talking about the the thing that is completed by the end of a sprint, right, that done increment is casually said, but this is, this is a tough thing to do. Right? And so this is not an easy thing to do. To be totally honest, right? And there might be a lot of people out there right now saying, Oh, we have we have something done by the end of the sprint, but it's not like we got something done. This is a this is a done increment, right? This is potentially shippable. And that's where we see a lot of Zombies. So this is not easy to do. Right? And we'll definitely make that Jahnnes thanks for that link reference, we're going to make that link reference also available on the Show page. So people can just click on it and assess themselves against Zombie now. This is not a rare occasion out there in the industry, right to be a zombie team. I think that's a fair statement. Right? So if you're thinking if you're listening right now, it's just all that it's not apply to me. You have any kind of percentage or anything like where you would say we're dealing with X amount, roughly. Obviously, we don't know every single team around the world doing Scrum. But do you have any indication based on the surveys you have so far? Like? What's the what's the percentage of zombie versus non zombie?Christiaan Verwijs 10:54 That's a good question. So roughly, it's about 60% of the teams that participated in the scrum team survey have quite moderate to severe zombie Scrum, it's very hard to define a cutoff point. But that's, that's one way to think of it. And most of the other teams like the 40%, other of the other teams have some elements of it. And there are some things in there too. They're doing really well in all areas. But that's as you say, it's it's quite rare. And I think that's okay, too, right. It's the mission or what scrum asks of teams, and especially if the organization's those teams are part of, it's really hard. And in the book, we describe it as sort of exercising, like if you start lifting weights, the first time you do it, you can maybe lifted once or twice, and then you have insane muscle ache the next day. But if you do it more often, and you start building the muscle to do it frequently, and also increase the weights that you can lift and it's the same with Scrum, the first few times it will be very hard to release an increment that's even close to done. But the next time it will be easier the next time it will be easier and so forth. So it's a journey. And that's okay.Johannes Schartau 12:49 We just want to do create that awareness that that is what that's the goal behind Scrum. And often people don't actually know that, or they don't know how far it actually goes. Because there are layers of organizational dysfunction between what they perceive as good Scrum and what the theory is. And it doesn't mean like everybody has to ship daily, for example, that's not what it means. But it kind of has to match the the speed of learning or the feedback loop that you're involved in. And it makes the whole thing come alive. And that's just the knowledge, like robbing people of the illusion that they're already doing really well. And that is something that we were aiming for just to to create some healthy tension, right, just to make people question and question what is happening in the environment and asking the questions. How far do you want to take this? What is really helpful for us? How quick do we need to be? And that is definitely different for every team, but just asking those questions for us. That's kind of the beginning of getting out of that zone. Right?Joe Krebs 14:03 Well, so I mean, I could play devil's advocate right now and say, You know what I have I have a team that is a zombie team. And you know, they're doing Scrum check. You know, I could check off a checkbox and say, like, we're doing Scrum, and we're compliant with Scrum. And we're doing, we're doing, we're doing that Zombie Scrum, but at least I'm doing some Scrum, right. How would you encounter like somebody like one an executive leadership level of saying like, there's some significant business loss around being a zombie team, right? Is there anything you we could make a case for, like, even if you're doing a zombie Scrum and you feel like hey, my organization, there's, there's a ton of Zombie Scrum, but at least I am doing Scrum and they're having the daily Scrum and they're having all these kinds of events, and I can check, check, check, check. What's the business loss behind it? What's the benefit of going non zombie and and making them survive to speak in the language of The title of the bookJohannes Schartau 15:04 do you want to go ahead, I can take it, Christiaan Verwijs 15:06 you start Johannes Johannes Schartau 15:07 okay.Well, it's difficult to put a number on it. But what we talked about in the book is that most organizations really optimize for efficiency. And that's kind of the prevailing mindset that they believe they set up some kind of process, get people really, really busy. And then something valuable is just going to turn out in the end. And that's usually not the case. And that is actually where scrum can be really helpful that it helps it be more effective in the sense of learning whether what you're trying to do is actually going to work. And that doesn't only mean you creating more value quicker or getting more cash. But it could also mean just finding out that something doesn't work, and then having the ability to stop it. And that's something that also organizations are usually not good at just saying, we should get off this dead horse and do something else and redistribute our more resources to something that is more promising. And so if you if you're trapped in that zombie scrum environment, that feedback mechanism is really delayed. And so you will definitely invest into things that don't return anything for much longer time. Again, this is going to be different for organizations. But I mean, I've worked with organizations, they had release cycles of nine years, for example, and just imagine, like nine years would go, what we thought the world was going to look like, and what it looks like now and then just having this massive splash of software and go like, Oh, this is what it is. Now, how helpful is that? You know, like it's if anything changes in the meantime, you don't have the time to change it anymore. And you, you definitely you won't be able to capitalize on that. On that change.Joe Krebs 16:56 Nine years feels like yesterday when we started.Christiaan Verwijs 17:02 So be Yeah, absolutely. And it's let's be honest, for many organizations, this is the reality, right? It's what you described Joe's, what a lot of organizations do they check the boxes, and we're doing Scrum. So everyone has a certificate. But hey, it's not working. So we need some other framework or light or certificate or something to make it work. But what we tried to do in the book is something that I was kind of missing in many books about Scrum is that usually other books talk about the how, what are you doing as part of Scrum? And that's really important. But why are you doing that? And how does this help the bigger picture? So what we really did put an effort into his to explain why are we actually doing Scrum? What's the advantage for the organization. Ultimately, it's about risk management, right. So if you release more frequently, and you can validate those assumptions, if you don't release every nine years, but maybe start with every few months, then at least you can validate if your assumptions were correct, and you're not wasting money, potentially a lot of features that no one's looking for. And ultimately, I think that's the best way to explain it to management, upper management in organizations, it's going to save you money, it's going to save you a lot of efforts that you don't have to spend on building something that no one's looking for. And if you do it right, you will have happier stakeholders, happier customers. And if you're a commercial organization, or a non commercial organization, that's what's keeping you alive. Right? Right.Joe Krebs 18:34 Yeah, absolutely. And then also you know, morale maybe where folks might be in zombie , wow. This is this is empowering, talk talking about empowering you both are very hip on liberating structures where it is it's part of, of your day to day life and Johannes you even founded the user group in in Hamburg, Germany. And how important is it for teams to use I'm not saying liberating structures but techniques and you know, like these, these micro tools in their day to day work, how important is it to use those to prevent possibly zombie Scrum? What's What's the connect to you?Christiaan Verwijs 19:19 Yeah, I think you always want wants me to start. liberating structures are really the core of everything that we do. And I can speak for Barry for me and Johannes altogether. And it's not a it's not about liberating structures as a as an approach, but it's about what they make possible. And I think one of the reasons why organizations get stuck in zombie Scrum is because everyone's trying to solve impediments only within their own little area, like within a team or are in a department but ultimately, you need to bring people together and make sure that they all have a voice in what what actually is the problem that we're trying to solve. Why are we not releasing frequently? Why are no stakeholders present, and then work together to overcome those challenges. And this is why liberating structures are so helpful because they make that possible to give everyone a voice everyone in the team, your stakeholders, management, the people from marketing to people from sales, get them into a room or a virtual room, use liberating structures and overcome those problems together.Johannes Schartau 20:25 Yeah, there's this kind of sentiment in the Agile community that you just do let people figure it out, well, just people will talk about it, and then it's going to work. But in our experience, you need something else, you need to structure that interaction and make it actually effective. And that's, that's why we like liberating structures. And like Christiaan said, you can use anything else, it's mainly about getting people engaged at the right time for the right kind of problems. I mean, you don't want everybody deciding everything all the time. But there are definitely parts where it is so beneficial to include more people. And especially if it's about like making sense of your own environment and tackling your own problems, finding solutions for your own problems. That is where, especially in that whole change that scrum kind of elicits in an organization because it causes tension, and then you need to deal with that. But you cannot just have that traditional model of, you know, we will we need to escalate to the manager or something. But often, it's really that you need the people on the ground to kind of make sense of what is happening collectively and then find solutions on their own. And then maybe ask for for help. But with, at least I'm speaking for myself, but prior to liberating structures, it didn't really have the tools to actually make that happen. It just was. Sometimes it was just like, Okay, I'll just get people into the room. And then we were just arguing all the time, and people were frustrated. So that's kind of the gap that liberating structures fills for me.Joe Krebs 21:59 Yeah, that's interesting way because I, in my my classroom activities, there was this one activity I always did. And I had no name for it. And I just did it. And every time I did it, it was a great thing. And then this book came out. And I was like, Oh, I can't believe like, let's take a look at this book. Right? If there is this technique, and I didn't was it was the shift in shale, right? And so I was like, Oh, it has a name now is a shift in share, right. And so I find that is, that's good. That is these patterns are proven in a way that it's this is not only me doing something in the classroom, right or in a project, but it's, there's also others found useful and actually picked up someone created it and then and then you get this confidence into your facilitation to write as a facilitator, this is not something I just came up with. This is done many, many times and many different people and whatever the route is of that technique. AndChristiaan Verwijs 22:54 I think it's also good to mention that the creators of liberating structures Keith McCandless and Henri Lipmanowicz. They came up with this 20 years ago, almost, I think, even even longer, I think in South America, and that was one of the first experiments took place. It's been around for a long time, but it never made it never connected to the Agile community. And I think, well, we were probably not the first but you're always an i, we you always had you read the book, I think, right. And you shared it. And we were excited about it started trying it out.Johannes Schartau 23:26 I in 2014, I met someone in the states who was from Seattle, and he was actually working with Keith, and he introduced me, and then it kind of took off. And that's how I got introduced. But it was really about like when I had the first experience of what that was, and it was actually in a phone conference. But it works so well that I just thought what is this? Because we had been talking for think 45 minutes, it wasn't a one hour call. It went nowhere. Everybody was just like, Yeah, okay, so what else could we talk about? And then the guy just said, Okay, let's do this. And then let's do this. And then let's do that I was within the last 15 minutes was like 100 times more productive than the first 45 and I Yeah, people you just need to experience that. And it just helps teams also to it helps them feel productive and effective. While collaborating with can be really frustrating when you have some kind of Scrum Master Agile coach who always wants you to collaborate, and it doesn't feel like it leads anyway, it kind of feels like a waste of time. And if you if you get people to collaborate and it feels beneficial, and they're like, Hey, we actually got something really important off today. That has like a really good effect on the whole self organization team autonomy side of Scrum. Yeah.Joe Krebs 24:48 Yeah, totally away just like you know, like, you know, the second day whenever these things are being introduced in an open space since 2009 at a conference in in New York, we do it every year and people are asking for it, right? Just saying, like, you're not doing a conference without open space, right? And it's like now it's like, Okay, we're coming, right? So. So it's like, it's like it really becomes part of the DNA of a culture and cool. Another thing you mentioned Christiaan is the something called certificates here, just want to bring this out, there's a ton of certifications going on. And just recently, I spoke with someone who said, there's a, an incredible number, I forgot the number. To be honest, I don't want to put in a wrong number out here. But an incredible number of people are being certified in scrum number is rising. And we're talking Scrum Alliance and scrum.org. All of those certificates are being handed out. But Zombie Scrum is increasing, too. So those two things are not going necessarily together, right. So one might actually create the behavior on the other side. What's What's your take on that? Both of you guys, but I know Christiaan is, is a scrum trainer was already versus others like me. Yeah. Yeah.Christiaan Verwijs 25:58 So I can only say positive things about significance, right? Because I'm a trainer. No, I think it's interesting. Well, you could say that the rice and certifications can also be a sign that more and more people are starting to work with Scrum. And I can also explain why you're seeing more zombie Scrum, because it's so Zombie Scrum is just a large percentage of all the teams that are working with Scrum. But at the same time, I think there's also something to say for the idea that sometimes, and we also get those people in our classes is that the only reason they're there is to get the certificates. And that's what they need, because they can put it on the resume and or companies actually look for those certificates without asking anything else, just do you have that certificate, okay, then you're a scrum master. But obviously, it's much harder to do all these things, to be a good product owner, to be a good developer to be a good scrum master to be a good at any of those other roles that you can get certificates for. And sometimes I feel like that message is lost in the certification industry. And that can that can definitely be a problem. And I think that that's what we're seeing, in some cases. Absolutely. What's your take on that Johannes because...Johannes Schartau 27:12 I'm so well, it's difficult to say because, for example, I am a certified team coach for the scrum Alliance. And I would just have to say I can only report really positive things about the whole process. I like what the scrum alliance is doing at the moment. And I also like at scrum.org, the, the later PSM classes really need you to reflect and they are essentially a learning journey. And that is something that I find really valuable, at least for me, I know that through that, gaining that certificate, my effectiveness as an Agile coach has really increased just because I had to, I had to talk about I had to write about my mental models, and just had to reflect on what it is that I'm actually doing. Because often I feel like we are, we're kind of using our intuition. But that doesn't always help with clients. So for example, if you want to tell them, This is how I look at your situation, or this is a model that we can use to assess your system together. And this is how I define success. How do you define success, and let's, let's see what that means for our work, for example, that is something that I learned just simply from telling other people about what it is that I'm doing while I'm working with a client. And that is really beneficial. So maybe the rise in certification should be accompanied by the encouraging people to pursue these higher certificates that really evolve, they really need a lot of effort for people to grow into. And maybe like the first step should be just clarify, John, if you get the certificate, it just means you have him you have read the scrum guide multiple times. And that's good, that's better than what other people do. But what you really what you should really strive for is something else. And so it's difficult, but I'm not against certificates. I have I personally have gained some really valuable experience from them. I can see why people don't like them. So I guess I'm somewhere in between.Christiaan Verwijs 29:26 Nobody, I think of what you say it's a good point. Like it's not it's not certificates in themselves. That's the problem, but the way in which you achieve them. So is it is it a two day class or a one day class or even a bit of money that you pay for it? Or is there a learning journey that's part of actually getting that certificate? And that's what you're saying? Right? That's what's so important. You need to have that learning journey. Yeah, I agree with that. Absolutely.Joe Krebs 29:52 Yeah. It's like owning a driver's license doesn't make you necessarily a good driver. Christiaan Verwijs 29:55 Yeah, exactly. Yeah, yeah. Joe Krebs 29:57 So, but it's also good To for me, personally, I feel like this certification is good. So I know what somebody else knows when they carry around that certificate. Why? Because there's like a, I want to say a standard of some sort, but at least like, you know, there was some, some evidence was about about the knowledge etc, if you don't have that it's just like this, there's probably a lot of conversation about what the things were, etc. And they could be quite different. Towards the end of our podcast here. I want to talk a little bit about something you just mentioned about Scrum guide, there was just recently a new scrum guide, I think it just fell exactly on the time when you guys published a book, what I want to hear your, your take on this because it's, it's the new scrum guide. Is that good against Zombie Scrum, like the product goal, for example, the the emphasis on that the addition of the product goal or the emphasis on the sprint goal, the commitment levels etc are these good things for Zombie or against Zombie Scrum?Johannes Schartau 30:58 Biggest thing for me personally, it's kind of going in the right direction, I don't think the scrum guide itself can solve the root cause, which is you know, people just have different expectations or different imagined different things of what what Scrum is. And so they kind of bring that view and it makes them read the scrum guide in a certain way if they actually read it, because a lot of people don't. It was funny, because while we were writing the book, we were informed that there would be a new scrum guide. And we also knew what was going to be in it. And then the question was, should we change our book, but we kind of realized that most of what we wrote about is was actually compliant. So Christiaan, correct me, but for example, the, what we the whole chapter on on self organization. That was for us, that was one of the most interesting ones to write because we kind of knew what should be in there. But we also, we had to take our time to spell out what that is and what we actually believe, because it's, it's difficult to grasp. And one of the things we started out with was about when we started defining self organization and trying to compare it to self management, right. And so what we wrote about was, for example, that the scrum guide actually kind of means self managing instead of self organizing. And that was something that was actually addressed later, not because of us, but it just kind of happened at the same time. That was really interesting. Yeah,Christiaan Verwijs 32:36 it was pretty cool. And I think that in our book, we pay a lot of attention to shared goals. The term product goal, we can't use that yet in our book, because the scrum guide wasn't updated yet. But we talked about having a vision strategy, a sense of where the product is going. We also talk a lot about sprint goals. So that's definitely something that's very much aligned with the changes that were made. But I do agree with Johannes. And I think that no matter how you write the scrum guide, it's not going to prevent zombie Scrum. It's a bit like, like, in a sense, sometimes think like it's a bit like the Bible, right? It's to describe what is actually a good moral person. But we've been spending 2000 years to figure out what it actually says about how to be a good moral person, no matter how many perspectives you add to it, it doesn't actually clarify it, you have to talk about it with the people around you. And that goes for the scrum guide as well. You have to make sense of this within your organization with with your teams and with all the books that are available, the blog posts, podcasts, etc. Yeah.Joe Krebs 33:39 Cool, guys, I want to thank you guys for spending a little bit of time with me where the listeners talking about the new book, The zombie scrum Survival Guide, published by Christiane Verwijs, Johannes Schartau and Barry Overeem. And it's available, obviously for to be purchased to prevent Zombie Scrum. And I feel like I feel like we could have another show at some point, which is talking about liberating structures to take like, besides this book, we could continue to conversation about another topic. But that's for another time. How was that? Johannes Schartau 34:15 Great, Christiaan Verwijs 34:15 sounds great. And if people are interested in the book, they can go to zombiescrum.org. We have information there on where to get the book. You can also get it at every bookstore that you can imagine. Joe Krebs 34:27 Awesome. I want to make all these links available in the show page. And as well as links to you guys and how are people get in touch with you? No, not beyond the book things other things that might be of interest. Thank you so much. Johannes Schartau 34:40 Thank you. Christiaan Verwijs 34:40 Thank you. Joe Krebs 34:42 Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.

Transcript:Joe Krebs 0:10 Agile FM, radio for the Agile community. www.agile.fm. Welcome to another episode of Agile FM. Today I have John Kern with me who is a one of the authors, a co author of the Agile Manifesto. He enjoys loud cars, travel, climbing beer, individual freedoms, small governments. That's what his Twitter profile says. So welcome to the podcast, John.John Kern 0:44 Thank you, Joe. Appreciate it.Joe Krebs 0:46 Yeah, we could talk about a lot of things here, including beer and travel, and you do travel quite a bit. But the one thing I want to talk about is the Agile Manifesto. We are recording this in February 2021. And that is also the 20th anniversary of the Agile Manifesto. So very timely recording you and I want to reflect a little bit on that day that weekend you guys had in Utah. So this is the how do you feel about this anniversary? Just like curious. It's been 20 years. And you know,John Kern 1:18 yeah, I remember that the 10th anniversary. Yeah, that was kind of shocking. That was already 10 years. And 20 certainly seems like it flew by. So it's it's pretty amazing that the opportunity I've had that much of an impact over 20 years on so many millions of people is really humbling. And the fact that it's still relevant still worth talking about you, I think, is is a fairly amazing feat of happenstance. Frankly, nobody knew this would take off and anyone would care about it. Even 20 days from the day we we left Snowbird. SoJoe Krebs 2:12 yeah. So I mean, obviously, nobody could know what would come out of this weekend, right? It could have been just a fun weekend of skiing. Or there's more and there was more there is after 20 years, we're still talking about every time I talk about the Agile Manifesto, and I refer to it to folks I work with professionally. I always say this is a site. That is probably the one website in the internet that not a single pixel has changed in 20 years. I think. John Kern 2:41 That's a great point. Joe Krebs 2:41 Yeah, it's like it's still the same, right? And but there is something about that, that it is still the same. So it's still relevant in the same way, we're still talking about very similar topics and coaches, maybe on different levels, but they're also talking about the same topic. So it shows how instrumental this, this was. So thank you for that. How do you feel? How do you feel about agile in 2021? Now, like, I mean, obviously, there was a lot of things going on in the in the early days in 2001, 2002, financial crisis and all that kind of stuff that that was now we're in the middle of a pandemic. But so we went through a lot as a society, but from, from a community's perspective, where are we what how do you feel about agile as a as a topic in the community in the industry? And what companies out there do with it?John Kern 3:32 Well, I think the weather, you know, I would say part of the problems that maybe anything like this face is is how folks embrace it, how they interpreted how they practice agile. So there's, it's been this way from pretty much the day we published it. It obviously resonated obviously struck a chord. I feel we got to the gist of the kind of how humans endeavor to build software. But yet, there's always going to be I don't want to say it's the Crossing the Chasm type thing. But, you know, there's still plenty of frustratingly non agile going on in the name of Agile. And I think that that's just you, the sort of the beauty of the Agile Manifesto is its its humility. Its its brevity. Its ambiguity, shall I even say, right? It's not it's not. It's not prescriptive. Yes. And that means you have to think and that means you have to apply it in context. And that means you have to be curious and to humble about your, your ways of working. And so I think those that get it it's a boon, right? There are kickass agile teams and agile companies and Agile and Lean companies, right? You can see there's a radical difference of those who get it, practice it, live it, breathe it. And then those who treat it more as a prescriptive, they might have latched on to Scrum or, or SAFe or, you know, some very prescriptive and then not moved on from there, you know, just still locked into a different I don't want to say draconian, but a different command and control way of being agile, I think, you know, that's, you can't have perfect, perfect interpretation of such a small document. So, you know, I It's understandable, but I think that's, you know, that's still going on, and I, you know, I hope folks push can push through that really get more of the benefit of the agile mindset, not just a handful of prescriptive recipes.Joe Krebs 6:23 Right, very much like a declaration of independence, but also not. There's also room for interpretation. And that makes it so so flexible, right? John Kern 6:32 Yeah, and with all due humility, I think I draw a parallel to a unique group of individuals came together, thought up some pretty amazing intense words, about in on the Declaration of Independence about how to how to govern people. Yeah, we were more of course, just the software side of things. But yeah, it's, it's getting to the gist of the problem domain, so to speak. And, you know, I think it's, it's very similar, how do you and you know, France, for example, screwed up, you know, their, you know, revolution, but and was not built on the right principles? versus, you know, the freedom that the Declaration of Independence, right, talked about? So I think Agile is very similar. You can it's interpreted and think you're going along that way, and still end up being a kind of a command and control, not happy place to work. But you're agile,Joe Krebs 7:38 It's, that's what I what I often see is when people are talking about the Agile Manifesto, but they're not even aware of the 12 principles, right? It's just like the four value statements. And obviously, those are very vague and purposely, right. And that really leaves room for interpretation either way, and you're ending up with an organization so called Agile. That is, that is really far away from what you might be thinking of agile, or I will be thinking of agile, when are you are you nervous that this is might get washed away that term overtime? I mean, it's been around for 20 years, but with the current trends we're going through, do you feel like at one point, people will be like, alright, is agile? We don't have a handle on it, there is no clear definition. Are you nervous? Or are you feel like there is there will there's light at the end of the tunnel that will we're getting to this state of what do you guys thought of 2001?John Kern 8:32 But that's a good question. I wouldn't be nervous because it's not my job to, to, to, you know, force people to get it. You know, it's, it's, I treat it as a personal practice, because it really does start with you. It's not, you know, organizations want to have an Agile transformation. But it starts with the individual. It starts with understanding, as you said, it's not only the the four tenets, but the the principles and, and even more, because we were humbled, like the one of the top words is uncovering. It's not even uncovered, right, we're not even past tense. You know, we didn't act as if we had, you know, God's gift to the answers of the world for software development, but we said we're uncovering because we're learning I practice a lot of Defense Department, heavyweight stuff and created in self defense kind of as a taxpayer a lighter weight methodology to work with my Defense Department. Customers, you know, so even there and you're we're constantly are we really left, in my mind left it clear that it's still going on. That was a certain point in time what we uncovered And what we were trying to address and heavyweight processes. And you know, I think going forward, you can, in my mind, those bullets still apply. Principles are still valid, and what you do with them, I'm not so much troubled, and I'm hopeful. I think this might, you know, this, this anniversary might inject because there's people, it's shocking to say there's, there's people that didn't hear of anything but agile in the industry now. They didn't, they didn't experience what, what I experienced with MIL standard 2167, or heavy waterfall type processes or some of the crazy stuff that was, you know, the elements that we were trying to combat in terms of heavyweight process. So a lot of people don't even know those existed. You know, it's a good opportunity to maybe reinvigorate some some of those who might have slipped into learned helplessness, you know, in a large organization, like, Oh, that's right, there's, there's, uh, there, it could be a light at the end of the tunnel, let's, let's return to some of these basics. Let's, let's try to try to get back to what Agile was all about in the beginning. So I'm hopeful, but yeah, like, whatever. You know, IJoe Krebs 11:31 It was Arie van Bennekum, I spoke with here on Agile.FM a little while ago. And he was the one who actually said, John was the guy who said that everybody leaves their ego in front of the door before you come in at that weekend. So it was and that goes back to your statement about being humble, right? There were lots of people 17 of them different opinions. What was Why were you there? We know like people that were from, from scrum there was DSDM was extreme programming. So it was a broad mix of different kinds of streams, I would say at that point, right of development things were but just curious whetherJohn Kern 12:14 there was the, you know, the XP contingent. I was there because I was working with Peter code. And we were doing Feature Driven Development, we had to get rebuilt TogetherSoft at the time, a wonderful UML modeling tool that I remember messing around with Bob Martin with. So yeah, I mean, I co-authored some things, but I was not famous, like the others in the room. So I was on the coattails of Peter Coad. And Peter said, This sounds like they're right up your alley, John. So I attended and participated heavily, because because of my Defense Department days, and my pension for being pragmatic, and lean, and absolutely, to deal with the ambiguities of software development, I had a lot of opinions.Joe Krebs 13:09 And you you're the one that I came across your notes from the event, right? So you captured notes and everything, you release those, it's almost like, it's like a museums artifact, almost like the personal notes from the from the weekend. And maybe we can hyperlink those on the Show page as well, for people to see. So that is all great stuff. What are you focusing on these days yourself? I know you do quite a bit of traveling, but from a software perspective. What are you focusing on these days?John Kern 13:40 Well, right now I'm working at adaptavist adaptiveness.com, who you would think might be a little odd, because they are the probably by any reasonable measure, the biggest, badassed, best Atlassian partner, you know, and, and in many circles, the agilistas, you know, will shun Jira, or something like that. I've been using JIRA and Confluence since whenever the hell it came out. And I was using other tools before that. And I've been pitching for 20 years, people process and tools in that order. And tools are a real third distance. And I've sold tools, but I know where they live, you know, it's the people first. So. So there was an opportunity there. And one of the gentlemen one of the reasons why I knew somebody who worked there who insisted that I talk talk, talk to the CEO. So we're setting up more of a Innovation Center and helping other companies learn how to have more of an agile mindset. It's really hitting the people and culture side of things and process and tools. But it's the more of the kind of agile mindset and the workshops and some of the we combined and some elements of motivation, orientation and engagement. And we're also working with Heidi Araya who's, who has a lot of experience with larger organizations than I do, for example. And so we're really striking out on a pretty fascinating core, because until I met John, you know, some of the things that that, that we began talking about, and he helped shed light on about ways that people make their meeting different different, like leadership development profiles. So I learned why, in some cases, a technique that I would use worked like gangbusters with a team. And other times I've talked, and I'd be like, Knock Knock, Knock Is this thing on? You know, do you can even hear. And he, he, let me understand that? Well, actually, they weren't receiving on the frequency that you were transmitting. And sort of like, I may have been two steps in front of them, where the other team, I might have been only one step in front of them, and they could, they could, they, you know, was just slightly uncomfortable, but they could move their two steps was like a cliff. You know, so. So we're really, I think, opening up more of the realm around. I've been preaching it for a long time that the good people of their own will create a process. They don't need to read about anything in Scrum or write some somebody would you know, that they were really good focused on a vision, trying to get somewhere will create a process, I always say, you know, that a good people will trump every other thing that you tried to do. And they'll even create tools, right? It's just just now you have some places to start, if you want to, you know, begin with Scrum, or begin with anything, any kind of, you know, Kanban, or agile, lean any of that stuff. But it all boils down to the leadership and the people. And everything else is far secondary. So that's kind of what we've been doing. It's pretty fascinating to me, because we're, you know, really helping teams, and leadership, engage and understand a little bit more about their culture and their social networks or organizational network analysis, that kind of thing. You know, are they siloed? Are they control oriented with their motivation? So, so it's, to me, it's a, it looks like it could be the next wave of really trying to make an impact with the team, by understanding a lot of the, you know, where people are at today, and help nudge them towards a place in the future. But don't, you know, don't make them take two steps at once, one step at a time. Right. You know, so I think that's, that's pretty fascinating stuff. To me.Joe Krebs 18:03 It was very interesting. Why because you all pointing out the cultural difference. And that's, that's something I see right now also, as a as a very big trend right now. Or we're designing adaptive having a culture of agility across the entire organization, then you do see, and this is, and I had worked with, just as an example, with Spotify in the past, right? People are now looking at, like, how do we map Spotify model to our organization? And it's, again, it's the, hey, we'll just use a process from somebody else, and we apply it to us, right? And then you get frustrated, why wouldn't work again, just to your point here, right? It's the, the incremental approach is taking step by step and taking a cultural from A to Z, but you know, every cultural or every organization is different set up and people and everything. And so there's just the whole idea of it. So we're falling into the same traps again, right,John Kern 18:55 Yeah, that's, that's, that's a good way to put it. And the other thing that I kind of keeps me grounded is, since probably 2005, I've worked on a program for firefighters. So it's kind of a pro bono do good work, to help save lives and property and things like that. So I write code every week, I do BDD and TDD and deploy and that kind of thing. And it's extremely rewarding to get high NPS scores to get really good feedback from our customers. Because it's, it's real, right? I mean, agile. I experienced it myself how real it is. And being able to impact customers and get that kind of feedback that keeps me my fingers on, you know, and I've recently led teams through development so I'm kind of a favorite word is definitely building products doing software that's fun and tangible. And when engineering soJoe Krebs 20:05 exactly what in this is what the manifesto is, the word software in it too, right? So there's a reason why that exists. And you pointed out earlier, there are listeners now on this podcast that might not have seen actually the, you know, the wrong way of doing it, or the one that is possibly causing a lot of difficulties and challenges. Are there a waterfall, for example, right. Now, what's interesting is that I think the manifesto came just at the right time. And we recently had time to mature into something, because what we're seeing now also is very different compared to 2001. Is, is the fact that in 2001, was we supported businesses with technology. Now, the business is technology, right? So a lot of companies are the when you said what your business is, like, it is cold, right? Was this before it was like, Hey, let's get a product from out of the way hours or something like that. And there was like IT solutions to support that, but it has drastically changed. Not talking about, like planes and embedded systems, and you name it. I mean, there's so much software everywhere in cars, you know? How do you how do you see all that complexity being handled, like more from a technical perspective, rather than the Agile Manifesto here, but what's your, what's your outlook? Is this going to? Most likely it's gonna get even more? So more complex? software is increasing?John Kern 21:28 Yeah, in the scary part, as as an aerospace engineer, I would normally regularly, sarcastically say, if most buildings or aircraft or cars were built, like our software, or enterprise software, not a chance that I'm stepping in that building or walking over that bridge or right, because I submit the software and industry what I have to to focus on my shoulders that can fight it out about this, because you can you can argue both both sides. But in general, the the industry, I think, is very young still as an engineering discipline. And some would argue it's not even an engineering discipline, right. So I would say it's a lot of a lot of ad hoc. Not such good practices. But I'm assuming most folks applying software in what you might call a critical life critical or safety critical systems are still falling back on classic designs for failsafe, like, I'm pretty sure the elevator is going to still use a mechanical failsafe and not trust software. So but it certainly is scary to think the more systems and we started to see some, you know, the 737 max and started the a few things that are all of a sudden popping out of that's a pretty bad bug. Yeah, or bad testing or bad whatever. Certainly, we'll you know, we'll learn from it. And it's not like, you know, everyone's probably seen that the bridge there oscillating bridge, and wherever it was in Portland, or Oregon, or some or Seattle, you know, that that was an engineering, like, oh, turn that into oscillating vortices. All right, you know, with the wind, who knew? So yeah, it's not to say that everything will always be perfect. But it is a little scary to think of how how software in the past 20 years, really has become so dominant, and, you know, I used to say about technical debt, it can get so bad that you can go bankrupt. And the more that you are, is a software company, the more you better really care about being lean and agile and, and have a architecture and, you know, TogetherSoft 20 years ago, we rewrote the software probably every 18 months from scratch. Because we couldn't because we learned so much and we couldn't, we didn't do a good job of maybe always refactoring it but said screw it, just start over knowing what we know now, we architected make it leaner and meaner and then carry on, you know, keep both things going, you know, BaseCamp, you can still get the old version. Like there's a lot of different ways to think about solving problems. And you know, I think that the the more innovative companies will grab onto it, do it right because they'll understand talking to some a team In the development team about TDD and BDD, and hearing a developer, the ones that slow me down. Well, my you know, you're not born knowing you're not born with some knowledge. But you know, things like what will look quality will a QA people, write, write, these tests, man know, like, the gap between under like understanding the holistic aspect of what we do to try to deliver outcomes and the interdependencies between, you know, for me, having tests is like, a confidence booster. Right? I feel more comfortable. I'm not saying they're perfect. But it was more comfortable. Did it take more time? Maybe the first time but, but Right? It's that it's like, how do you? How do you break that mentality? Right, that now we just have to constantly be grinding out code. And we don't actually track all the debug later on, we don't actually track that we built the wrong thing we don't. So that kind of stuff is frustrating as hell, yeah. Or, you know, our profession.Joe Krebs 26:10 I mean, I'm just this goes to the point of, you know, software getting more and more complex, you know, in the coming years, and there's just a trend, and I think it's gonna continue, right. It's obviously that more software is being included, I think, into lawn mowers everywhere, right? So it's like, so, software is going to be everywhere. And it becomes more important to have a good quality strategy around these things. Because we might have fatal accidents, we might have issues. So quality is a key thing. And that is that is deeply rooted in the Agile Manifesto. So I think that is the, you know, we were lucky in 2001, that you guys did this and wrote this, because it's going to be a guiding principle now for for these organizations who are dealing with this complexity. I always tell engineers, when I work with them through coaching and training, I always tell them, like the line of code they're writing is not the expense of you writing their line of code. It's, it's maintaining that line of code. Right? So and obviously, refactoring or rewrites are necessary, because the cost of that long term listing has to be upgraded, maintained, and possibly there's a side effect of defects on that line of code. So the writing the line of code, it's true, like minimal compared to, compared to the following costs.John Kern 27:24 Yeah, that's so true. I would often say, you know, when someone puts something cryptic, like, it's not the one time you wrote it, it's like the 1,000th time someone's gonna read this later. Exactly. That's the penalty. Right? That's good. And it could even be your future self. Right. So yeah, it's, it's trying to build that, that, that professionalism, the craftsmanship and the, again, the understanding of beyond the the silo that you might think you're in being a broader thinking, individual understanding, we're trying to, we're trying to build something long term, hopefully, for for a piece of software. And we're trying to make our customers happy. And yeah, there's, there's good ways and bad ways to make that happen. You know, I liken it to two different styles of gardens. If I if I might do an analogy, my, my parents were big into square foot raised bed garden. So people probably have seen raised beds, so you don't trample on it and stamp down them. And then he could work compost into it. And the square foot technique was different plant you know, you have different boards with different holes on different centers, different types of plants needed to be planted on for it. Anyway, he also planted things cooperatively, like something could grow underneath another thing that would be beneficial. So it was a some of the most productive soil on the planet probably. And then you can have a giant garden, somebody's different tactic, maybe full of weeds. Not pretty to look at, not with nice wood chips in between the ego walk along, you can see his family aid, charities and the asparagus might not be pretty but it produces,Joe Krebs 29:16 it produces Yeah.John Kern 29:19 And the two CEOs running to those two different farms, you think they have a chance of comparing you know, input versus output any kind of process efficiency or right our industry is so bereft of being able to understand effort versus output and and you could even say well, I don't care I can get really cheap labor on that that big pile of land and out under every year and weeds at all, and it produces enough and I have cheap labor. And I just rewrite it every every year. Right? So I don't know the right I actually don't know the right answer because some industries It might be cheaper to throw it away and start over again. Yeah, in other industries, it might be worth to building a beautiful manicured English garden or something, right? Who knows what the answer is? No, no, no, no need to be, you know, gardens of Versailles. But we also don't all need to be, you know, weeds, you know, a garden full of weeds. I can barely find the plants. Is it a challenge in our industry? Yeah,Joe Krebs 30:28 I agree. And it's a it's a great metaphor. No, thanks for that. Just by the end of our podcast here on our time together, is you you do travel a lot, and you travel to some remote places, as far as I can tell, right? And is there any kind of place you encounter where you still hear people's Agile Manifesto? What? Because it's always there's like, are you not not talking about your celebrity status? I know, we, you. You know, you're you're humble and everything. But are there still areas in this planet where you would encounter and people would not necessarily know that a there was an agile manifesto you've traveled to and that you were part of that?John Kern 31:11 I don't know. It's a good question. Because I gave a talk with a group out of a few cities in China. They were big into it. I will say that. I think a couple years ago I was down in Colombia with with a friend of mine Ryan Lockard, who brilliant DevOps guy and beer maker friend of mine and I think it was their first we we keynoted their first I believe scrum day event, right? So it's gone de Colombia or something like that. But I will say that Colombia and I also spoke with a group in Mexico City and, and agile, agile Greece. In in each of those cases, especially the ones I was in first I was in person in Colombia and in person in, in Athens. It was it was like the early days of the manifesto. I mean, it was so heartwarming. Folks, were so excited about the possibilities. And I really don't want to say it was like the first time that they were learning about it, but it seemed like the community was was just beginning to blossom. I think agile Greece is a little more mature but but certainly struck me the in Colombia just wonderfully optimistic, and hopeful folks, and and when people come up, you know, what their pictures taken or thank you for the aftermath. I mean, that that is so meaningful to me, because in some small way, what we did in Snowbird had such a positive impact on people flocked. that's meaningful. I mean, it's, it's real, right? It's, it's not, it's not fake, and you can feel it in their gratitude. And it just, it was lovely to see that kind of enthusiasm again. So that's fun. Yeah,Joe Krebs 33:33 totally. I can see and especially in those early days, right where you were like, wow, we're already seeing the initial signs of this there's more to it and this is going to be long lived. I mean, I can only speak for myself here. There was a lot of things in my life I got tired of very, very quickly not agile way to there's something to this this lifelong learning. There is always something to be uncovered, discovered. So it's, it's really fantastic so, and Agile FM my podcast wouldn't be called Agile FM without you guys, so thank you. Why don't you think you will next time we'll talk about beer or we talk about other things on your list. But this was all about the Agile Manifesto's 20th anniversary. Thank you, John.John Kern 34:21 Thank you, Joe. And I'd be happy to talk about any any other subject anytime.Joe Krebs 34:29 Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www agile.fm. Talk to you soon.

Joe Krebs speaks with Vasco Duarte about the lack of management support and why this role is so important for the future world of work and if the role “Scrum Master” is still appropriate or if it should be renamed.