Podcasts about Extreme programming

(05:29) Brought to you by Swimm.io⁠⁠⁠⁠Start modernizing your mainframe faster with Swimm.Understand the what, why, and how of your mainframe code.Use AI to uncover critical code insights for seamless migration, refactoring, or system replacement.Tired of API dependencies slowing down your development and testing?Dive into my conversation with Tom Akehurst, creator of WireMock, and discover the art of using API mocking to build successful software in complex distributed environments.Key topics discussed:The origin story of WireMock, born from integration challenges at DisneyHow WireMock became a leading API mocking tool with millions of monthly downloadsInsights on building and maintaining successful open-source projectsThe key benefits of API mocking for developer productivity and experienceThe shift from the traditional testing pyramid to a “testing trophy” approachLeveraging API mocking for API-first design and rapid prototypingThe distinction between API mocking and contract testingThe future of API testing and development in the age of microservices and AIWhether you're a seasoned developer or just starting out your journey in API development, this episode provides valuable insights into the power of API mocking and the journey of building a successful open-source project.  Timestamps:(02:11) Career Turning Points(08:08) WireMock OSS Success Story(15:15) Welcoming & Aligning with Contributors(18:05) Benefits of WireMock & API Mocking Tools(19:59) API Mocking & Testing Pyramid(22:05) API Mocking vs Contract Testing(25:25) The Economics of API Mocking(27:27) API First Design(32:32) Impact to the Developer Experience & Productivity(35:32) Working More Effectively with Distributed Systems(38:15) API Virtualization/Simulation(41:13) AI Advancement in API Development(44:25) Building API for AI Agents(47:25) 3 Tech Lead Wisdom_____Tom Akehurst's BioTom Akehurst is the creator of WireMock, the open source API mocking tool, which he's now been working on for well over a decade. Lately he's also the CTO and co-founder of WireMock, Inc., where he's helping complex engineering organisations effectively adopt API simulation techniques in order to build better software faster.Tom has been developing software for over 20 years. He's built large-scale web systems for media, travel, hospitality, retail and government, applying lean, eXtreme Programming, Continuous Delivery and DevOps principles along the way.Follow Tom:LinkedIn – linkedin.com/in/tomakehurstEmail – tom@wiremock.orgWireMock – wiremock.org_____Our SponsorsEnjoy an exceptional developer experience with JetBrains. Whatever programming language and technology you use, JetBrains IDEs provide the tools you need to go beyond simple code editing and excel as a developer.Check out FREE coding software options and special offers on jetbrains.com/store/#discounts.Make it happen. With code.Manning Publications is a premier publisher of technical books on computer and software development topics for both experienced developers and new learners alike. Manning prides itself on being independently owned and operated, and for paving the way for innovative initiatives, such as early access book content and protection-free PDF formats that are now industry standard.Get a 40% discount for Tech Lead Journal listeners by using the code techlead24 for all products in all formats.Like this episode?Show notes & transcript:techleadjournal.dev/episodes/210.Follow @techleadjournal onLinkedIn,Twitter, andInstagram.Buy me acoffee or become apatron.

Is Agile still relevant in today’s fast-paced world? Brian and Joshua Kerievsky reveal the four game-changing principles of Modern Agile that prioritize safety, empowerment, and continuous value delivery. Overview In this episode, Brian Milner sits down with Joshua Kerievsky, a pioneer in the Agile community and the creator of Modern Agile. They discuss how Agile practices have evolved, the critical role of safety and empowerment, and how to deliver value continuously in today’s fast-paced world. Don’t miss these insights into creating better teams, products, and results through simplicity and experimentation. References and resources mentioned in the show: Joshua Kerievsky Industrial Logic Joy of Agility by Joshua Kerievsky Modern Agile #33 Mob Programming with Woody Zuill #51: The Secrets of Team Safety with Julie Chickering Badass: Making Users Awesome by Kathy Sierra The Power of Habit by Charles Duhigg The Lean Startup by Eric Ries Experimentation Matter: Unlocking the Potential of New Technologies for Innovation by Stefan H. Thomke Agile For Leaders Mike Cohn’s Better User Stories Course Accurate Agile Planning Course Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Joshua Kerievsky is the founder and CEO of Industrial Logic and author of Joy of Agility. An early pioneer of Extreme Programming, Lean Software Development, and Lean Startup, Joshua is passionate about helping people achieve genuine agility through principle-based approaches like Modern Agile. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back. And this is another episode of the Agile Mentors podcast. I'm here as I always am. I am Brian Milner and today I am joined by Joshua Kerievsky and really excited to have Joshua here with us. Welcome in Joshua. Joshua Kerievsky (00:16) Thank you so much, Brian. Happy to be here. Brian (00:19) Very excited for Joshua to be here. Joshua's been around for a while. He's been doing this for a long time. He said, you know, when we were talking before, and he's been involved with Agile before, it was called Agile. And, you know, that probably tells you all you need to know there. But a couple other things here about him, just so that you kind of can place him a little bit. His company is Industrial Logic, Inc. and he's the CEO and founder of that company. He has a book called Joy of Agility that's out there that I highly recommend. It's a really great book. And he's also closely associated with something that maybe you've been aware of, maybe you've heard of, maybe you haven't, but something called Modern Agile. And that's what I thought we'd focus on here for our discussion is really to try to understand a little bit about it. especially for those of you, maybe you haven't heard of it, haven't been around it before. So... Why don't we start there, Joshua? Tell us a little bit about what was the need that was trying to be filled with something like modern Agile. Joshua Kerievsky (01:19) Well, it goes back to a conference I attended in Prague back in around 2015. And I was giving a speech, a keynote speech there, and that ended. And then I went and said, well, I'm going to go join the OpenSpace. And I was just looking at what people were talking about at the OpenSpace. And at that point in time, I had already been experimenting with a ton of stuff that just kind of different from what we had been doing 10 years earlier or even later than that. I mean, just this was new things that we were doing, whether it was continuous deployment or ideas from lean startup or ideas from the pop and dykes and lean concepts applied to agility or just a lot of things that were just different. And none of the sessions I was seeing in the open space seemed to be talking about any of that stuff, like giving up story points or moving away from sprints until continuous flow. just nothing was being talked about. So I just said, well, I'm going to host a session, and I'll call it, I don't know, a modern Agile. And so that's as far as I got in terms of thinking about the name. I just wanted to run a session where we could talk about, there's a lot of new things we're doing that kind of display some of the older ideas. And they're very useful, I found. So the session ended up getting a lot of attention. 60, 70 people showed up there. So we had a big group. And it was well received. People were fascinated by the stuff that they weren't aware of. And so I then repeated this open space event in Berkeley. Like a month later, was Agile Open Door Cal in Berkeley was running and did it again. And again, there was tremendous interest. in this, so much so that I decided to write a blog and wrote the blog and started getting more conversations happening. And that sort of began the movement of describing this thing called Modern Agile. And it took a few twists and turns in the beginning, but it wasn't sort of, I guess, if anything, I felt like Agile needed to be a little more simple. in terms of what we were explaining, because it was starting to get very complex with frameworks, enterprise frameworks coming along like safe and just too many moving parts. And so what ended up happening is I wrote some things and people started to notice, there's kind of like four things there that are really valuable. One of them was The names changed a little bit over time. But anyway, what ended up was four principles emerged. And that really became modern Agile. Brian (03:58) That's awesome. just for listeners here, I've pitched attending conferences in the past. If you've listened to this podcast, you've heard me say that, and I'll create things come out of that. And here's an example, right? This is something that was open space discussion. Open space, if you're not familiar with that, at conferences, can, if there's an open space day or a couple of days, then anyone can present any topic they want. And whoever shows up is who shows up. And this one got a lot of attention. And a movement grew from this open space topic, which is awesome. So let's talk. You mentioned there's four principles here. And I like the distinction here we're making also between the frameworks and the practices versus the cultural aspects or the philosophy behind it. And returning to those roots a little bit more from what Agile originally was. So you mentioned there's kind of four areas of this. Let's walk our way through those. I know the first one, or one of the first ones here is make people awesome. So help us understand, what do you mean by make people awesome? Joshua Kerievsky (04:59) Probably the most controversial of principles, because you'll get people coming along saying, wait a minute, people are already awesome. What are you talking about? And it comes from my, I'm a big fan of Kathy Sierra. And her blog was incredible. And her book, she wrote a book called Badass, Making Users Awesome. And in her book, she was really wonderfully clear about Brian (05:07) You Joshua Kerievsky (05:24) that teams that build products ought to focus on the user of the products more than the product itself. In other words, she would say, don't try to create the world's best camera. Try to create the world's best photographers. Big subtle difference there. Like that is focusing so much on empowering the users, making them awesome at their work or whatever they're doing, whether it's art or accounting or whatever, whatever your product does, how can you give them something that elevates their skills, that gets them to a point of awesomeness faster? And that's what she was talking about. So I thought, what a wonderful message. And initially, I used language like make users awesome. you know, having been an entrepreneur myself and created products and sold them and You learn a heck of a lot when you make your own product. And we've made several products over the years at Industrial Logic, probably the most successful of which was our e-learning software. And that has taught me so many, so many lessons. One of them is you have to serve an ecosystem of people. You can't just make your main user awesome. What about the person who's buying the software? How do you make them awesome in terms of helping them buy something that's going to get used? If they buy your e-learning and they never use it, they've wasted a lot of money. So we've got to make sure that their reputation is intact because they made an excellent investment and it got used and it got into valuable, it created value in the company. So how do I make the buyer awesome? How do I make the person that like rolls out the licenses to people awesome? How do I make their experience awesome? How do I make my colleagues awesome so that we love what we're doing and really enjoy working together? So it kind of morphed from make users awesome to make people awesome. And it's so expanded. If anything, we set the bar higher. And all of the principles of modern agile are like unachievable. They're all kind of high bars, right? But they're the goal that we go towards. So that really is it. It's about creating Brian (07:23) Ha Joshua Kerievsky (07:35) you know, wonderful, you know, the in Great Britain, they use awesome kind of sarcastically sometimes, right? They'll say, well, that's awesome. You know, and so for them, it would be brilliant. You know, I thought of making an English version. We have many translations of modern agile, and I thought of making an English version, which would be a proper British English version, make people brilliant. But it's meant to be to empower folks to give them something. And it's so it is. Brian (07:43) Ha You Joshua Kerievsky (08:04) It does have a product focus in the sense of we're typically building a system or a product that someone's going to use and it's going to give them skills they didn't have before or abilities they didn't have before that are going to be very valuable. Brian (08:18) Yeah, I love that. And there's a sort of a servant nature to that servant leaders, not servant leadership as much, but servant nature of I'm serving these people and how do I, how do I serve them in a way that really empowers them? Kind of reminds me of like, you know, the, the great principle with, with dev ops of just, know, if I can, if I can empower the developers to be able to do these things on their own. And so they don't need someone else to come and check the box and do everything for them. You're making them awesome. You're empowering them to be more than they were otherwise. Joshua Kerievsky (08:54) Yes, yes, absolutely. I I think we've seen a history in the software field of a lot of tools coming along and helping. It's not just tools, it's also methods as well. I mean, I'm entirely grateful to the Agile software development movement because it helped nudge everything towards a far better way of working and to make us more awesome at our craft. yeah, you have to have a North Star though. If you're going to build something, You have to know, what are we going for here? What are we shooting for? And with Cathy's influence, again, it's not so much make the greatest product in the world. It's, that focus on the users, the people who are going to be using the work, using the product. Brian (09:34) That's really good. Let's talk about the second one then on my list here, the make safety a prerequisite. What was the point here behind this principle? Joshua Kerievsky (09:40) Yes. So starting probably around 2011 or so, I could not stand going to the Agile Conference anymore. It had just become too commercial and too filled with just people hocking stuff. And it just was bothering me too much. I couldn't go. So I ended up going to South by Southwest, which is an Brian (09:54) You Joshua Kerievsky (10:09) Enormous conference tens of thousands of people show up So it'd be 20,000 30,000 40,000 people showing up for these for this event, which is musical film technology just it's just wild and I came across this book by Charles Duhigg called the power of habit. He was there that year and In that book. Well, first of all that particular year was 2012 that I went my first year there it poured The rain, it was every day, it was unusual for that time, but it was just like pouring rain. So what could you do? I bought some books and I was sitting there in my room reading them. And I'm reading this book, The Power of Habit, and I come across this chapter called The Ballad of Paul O'Neill. Now who the heck's Paul O'Neill? Well, it turns out Paul O'Neill is this incredible guy, a complete business maverick. He ended up becoming the treasury secretary under Bush and not. in 2000 for a short period of time, but that's another story. And he ran Alcoa for about 13 or 14 years. And so the Ballot of Paul O'Neill is very much about what he did at Alcoa to turn the company around. And in essence, you could say he made safety a prerequisite. That safety was his guiding light in turning that company around, which meant left people empowered to do all kinds of things. So it went way beyond safety, but started there. And it's an incredible story. I've written about it in Joy of Agility. I got so into Paul O'Neill that I ended up interviewing his main lieutenant. And then I got a chance to interview him a couple of times. the man's a genius. He passed away a few years back. Absolute genius. this concept of safety started to really pull at me in the sense that I felt, first of all, extreme programming, and I'm a big practitioner of extreme programming, brings a tremendous amount of safety to software development. It may not be as explicit in saying safety, safety, safety. When you look at extreme programming, doesn't really talk about safety, but it's implicit. And these days, Kent Beck's much more vocal about, you One of his missions is to make software development safer for geeks. But safety to me is almost like I found my home. Like safety was something that, what I learned through Paul O'Neill was that it's a doorway to excellence. And he transformed a hundred year old company with safety. I would complain about companies we were working with that were 25 years old and had an embedded culture. Like, how are we gonna change this company? But safety started to be this thing that I hadn't really thought enough about, and making it explicit opened up a lot of doors, right? And I became very interested in the work of Amy Edmondson, who's extremely famous today, but back then she was not so famous. And huge fan of hers. I, you know, I can email her and she'll email me back and she wrote a nice thing about my book. So. She has done some incredible work there. And so when we talk about safety in modern agile, it's psychological safety. It's financial safety. It's any of the safeties. There are many safeties that we could talk about. And it looks at all of them, right? It's brand safety, software safety in terms of security. you know, of the software and on and on and on. So make safety prerequisite is vast and big in terms of what we're trying to do there. Making it a prerequisite means it's not an afterthought and it's not a priority that shifts with the winds. It is permanent. It is something that we know we have to have in place. And it's very, very hard to achieve. Just like make people awesome is hard to achieve. Boy, is make safety a prerequisite difficult. Brian (13:43) Hmm. Yeah, I love Amy Edmondson's work as well. I'm just kind of curious. does the safety kind of inclusive of things like quality as well? Do you intend that to be part of what you mean by safety? Joshua Kerievsky (14:11) Well, mean, to the extent that it makes it safer to do good software development. So if bugs are happening all the time, you can't make people awesome, typically if you don't have quality. If you have really poor quality, nobody's being made awesome. They're experiencing all kinds of problems with your product. So make people awesome and make safety a prerequisite are very much tied together. That is, there is no real excellence without safety. You could think you're having an excellent experience, so that all of a sudden there's a major problem, and boy, are you unhappy. So they really go hand in hand. You could have the most incredible restaurant, and then one day you've got food poisoning happening. Great, no one's come to your restaurant. So you will not make anyone awesome if you don't make safety a prerequisite, and quality is part of that. Brian (14:57) Awesome. Well, let's move on to the next one then, because the next category is one that just resonates with me a lot. Experiment and learn rapidly. What was kind of the thought behind this one? Joshua Kerievsky (15:06) Yeah, and this is one where it that's shorthand, if you will, because you can only fit so many words on a wheel there. But it's important to know that that really means experiment rapidly and learn rapidly. And that comes a lot out of it in the influences of something like Lean Startup. I'm a huge fan of that book and of Eric's work, Eric Reese's work. Brian (15:13) Ha Joshua Kerievsky (15:29) And the fact that we can experiment rapidly and learn rapidly rather than just building everything and then learning slowly. Right? How can we do cheap experiments quickly to decide what's important to work on and what isn't? Let's not build stuff nobody wants. Let's find more time with our customers and understand their needs better so we can build the right things that make them awesome. In other words, and a lot of these are interconnected. In many respects, modern Agile is a Venn diagram. ideally want all four principles to be overlapping. And right there in that middle is where you really want to be. Not easy. But experimenting, learning rapidly, yeah. So challenge yourself to find ways to do quick, cheap, useful experiments. You can do lot of unuseful experiments. Amazon experienced that. There's a story in my book about how Amazon had to start just shepherding the experiments a little more and having some better criteria. Because you could do an endless array of experiments and not get anywhere. There's a wonderful book called Experimentation Matters by a Harvard business professor. Wonderful book as well. But I love experimentation and learning. And I see it as critical to building great products. So that's that principle there. Brian (16:46) Yeah, there's a real difference, I think, in organizations that put value on that learning process. if you see it as a valuable thing, that we invest time to gain knowledge, then that really can truly make an impact when you go forward. I know I've talked about this in classes sometimes where people will say, isn't it a little bit selfish from the organization to try to always just figure out what's going to sell the best? or what's going to work the best in advance of putting something out. My response is always, well, yes, there is a benefit to the business, but there's a benefit to the customer as well because they would rather you work on things that they care more about. Joshua Kerievsky (17:24) That's right. Yeah. I mean, we once put out an experimental product to a large automotive company. And we were really excited about it. We had a whole list of features we wanted to add to it. But we were like, you know what? Let's just get this primitive version kind of in their hands just to see what happens. it turned out that we learned very rapidly that they couldn't run the software at all. There was some proxy. that was preventing communication with our servers from their environment. So it was like, excellent. We learned really quickly that instead of those fancy new features we want to add to this thing, we're going to fix the proxy problem. And to me, that's the nature of evolutionary design is that we create something, get it out there quickly, and learn from it rapidly and evolve it. So it goes hand in hand with that as well. Brian (18:11) That's awesome. Well, there's one category left then, and that is deliver value continuously. So what was the genesis of that? Thinking about delivering value continuously. Joshua Kerievsky (18:19) So that was heavily influenced by my own journey into continuous delivery and continuous deployment and that whole world. We got into that very early. I was lucky enough to catch a video by Timothy Fritz, who he worked with Eric at IMBU. And he coined the term continuous deployment. And that video is actually no longer on the Brian (18:43) Ha Joshua Kerievsky (18:44) But this was something that I became enamored of was doing continuous deployment. And we started doing it at Industrial Logic with our own e-learning software back in about 2010. And by the time you get to like 2015, it's like, hey folks, there's this thing where you can do a little bit of work and ship it immediately to production in a very safe way, a safe deployment pipeline. It's friggin' awesome. But the principle doesn't just apply to that because this modern agile is not just about software development. It's how can I work in a way that gets value in front of people as fast as possible? So for example, if I'm working on a proposal, great, I'm not going to work for two weeks and then show you something. I'm going to put something together, a skeleton, I'm going to show it to you and say, what do you think? Does this add value? Where would we improve this? Blah, blah, Again, going hand in hand with evolutionary design. continuous delivery of value is something that is a way of working. With artists that I work with, they'll do a quick sketch or two or three sketches of something first before we start settling in on which one do we like the best and how do we want to craft and refine that. So there's a way of working in which you're delivering value much more finely grained and approaching continuously instead of in bigger batches. Brian (20:05) Yeah. I love the connection there between artists as well, because I've got a background in music, and I'm thinking about how when you go to write a song or create a new work like that, you start off with the roughest of demo tapes, and you move from there to increasingly more sophisticated versions of it until you finally have the finished product. But no one thinks that's strange or thinks that's weird in any way. But you're right. Sometimes there's this attitude or kind of I think in some organizations of, we can't let anyone see that until it's absolutely finished, until it's done. Joshua Kerievsky (20:39) Yeah, yeah, and that maybe that's that there's some fear there, you know, because they don't want to be thought of as, you know, being lesser because they put something rough in front of someone. Whereas I view it as a, you know, to me, it's a sign of weakness when you when you only send something polished because you haven't had the courage or the sense of safety to put something rough where we can make better decisions together early on. So. There's a lot of learning, I think, around that. But it's a challenging principle of its own, deliver value continuously. And people would say, well, what does value mean? Value is one of those words where it's unclear, because you could improve the internal design of a software system. Is that value? It probably is. But you've got to be able to quantify it or prove that it's going to help make things more graceful in terms of flowing features out. yeah, quantifying, communicating what the value is. is important. I'm also a big fan of maximizing the amount of work not done, as it says in the manifesto. So how can we do less and deliver more sooner? Our motto in industrial logic now is better software sooner. And a lot of these principles go straight into that. that drives it. Brian (21:38) Yeah. That's really great. Yeah, I love these four principles and I think that they really represent a lot. There's a lot that's baked into each one of these things. And I'm sure as you kind of put this together with the community and started to talk more about it, I'm sure there were some challenges. I'm sure people came up to you and said, well, what about and how about this? Is there anything now looking back on this that you'd say, gosh, we really... really didn't quite cover this or, know, this is maybe I could fudge it and squeeze it in this area, but you know, there's this other thing that I really think would be important to kind of mention here as well. Joshua Kerievsky (22:28) Well, you know, it's funny, because I thought I was going to write a book. I started collecting stories. I love telling stories, and I find stories to be a great way to help educate people. Not the only way, right? But as part of some of the workshops I give, you tell a story. Hopefully it's a story that's sticky, that sticks in the person's brain. And over the years, I collected stories like that, stories of agility. I thought I'd be writing a book about modern agile when I started writing Joy of Agility. Gradually, as I wrote more and more stories, they didn't quite fit into all those four principles. And I think the lesson I learned there was that I was starting to talk about what pure Agile means, the word Agile. What does it really mean to be Agile? Whereas modern Agile is really almost in the context of product development, of building services or products for people. Whereas Agile itself is even more pure. And so the... the book itself got into the difference between quickness and hurrying, which you can relate to this. You could say experiment and learn rapidly. Well, OK, maybe we shouldn't rush it. Don't rush. Be quick, but don't hurry is one of the mantras in Joy of Agility. So adapting, right? Adapting, we talk about adapting all the time. So to be agile, you need to be able to adapt quickly. These four principles in modern agile don't say anything about adapting. Brian (23:46) Ha Joshua Kerievsky (23:48) So that's kind of implied, but it's not there. So it's a different lens on agility. If anything, I'd say the make people awesome principles are not meant to. It created some dislike, I'd say, from some people. It could have been called empower people, potentially, although a lot of people really love make people awesome. I don't know so much what I'd change there. I'd say we have a .org. So it's a modernagile.org is a website. There's a pretty large Slack community, which, know, four or 5,000 people on that. We don't certify anyone in modern agile, so there's no certifications, but it's something that is neutral in the sense that whether you practice Scrum or Kanban or Safe or whatever, these principles can influence you. And, you know, but again, this all came out of like, when I went to that open space conference in Prague, I had no idea I was going to talk about modern agile. You know, it was not like a predetermined thing. It was just like, my God, they're not talking about the modern ways we're doing stuff. So, and I always encourage people to, you know, keep pushing the limits and keep modernizing. I said to my own company the other day, our wonderful ways of working that we've been doing now for years that have evolved, they're probably antiquated as of today. You know, with generative AI, what would we do differently? Let's have a perspective on our own work as it needs to be modernized constantly. So the term modern in modern agile means always be modernizing, always be looking. Okay, I've had people say, well, Josh, some things don't need to be modernized. There's things that are just evergreen. They're classic. I'm like, absolutely. I'm not changing evolutionary design anytime soon. I find it to be quite useful in so many contexts. So yes, there's the evergreen stuff. And then there's the stuff where you can, indeed, discover a better way. The manifesto itself says, we are discovering better ways of working. Great. Keep that going. Keep modernizing and looking for easier, simpler, quick, easy grace. as the dictionary definition of Agile says, how can we work with quick, easy grace? That's always going to be improving, hopefully. Brian (26:12) Love that, yeah. And you're right, I mean, think there's some, to some people I think that there's, I guess at times an attitude of, you this is all new stuff or this is a brand new concept and something they don't really see the connection backwards in time to how these things are all built on other ideas that have been progressive over the years. So the idea of, yeah, this is, you know, we're, we're not saying that certain ideas are bad because now we're trying to modernize them. We're just saying we're trying to apply that same principle forward into kind of the context of today, which I don't see anyone should have a problem with that. Joshua Kerievsky (26:48) That's right. That's right. Well, and if you are experimenting and learning rapidly with your own process, which I highly encourage, chances are the way you work today will be different than it was yesterday. You will be exploring, like we use discovery trees today. We didn't use them before. Years ago, no one knew what a story map was. There wasn't such a thing as a story map. Now we have story maps. There's constant improvement happening. And you've got to be open-minded and willing to try new things and drop old stuff. We thought sprints and iterations and extreme programming was absolutely fundamentally part of the way to work. Then we started experimenting with dropping them and turned out, wow, this is pretty cool. We like this. It works pretty darn well for our purposes. That came through experimentation. some of our experiments were terrible, just terrible. It's not an experiment if you already know the outcome. keep pushing the limits of what can make you happier and more joyful at work in terms of producing great stuff. Brian (27:46) Awesome. That's great stuff. Well, I can't thank you enough for coming on, Joshua. This is great stuff. just, you know, we'll put all the links to the books mentioned and everything else in our show notes for everybody. But as Joshua said, you can go to modernagile.org and find out more about this if you'd like to. You'll find information there about Joshua himself or his company again is Industrial Logic, Inc. And, you know, his book again, just to mention that, Joy of Agility. We were talking how some people get that title a little mixed up or whatever, but it's just the three words, joy of agility. So just look out for that book. I think you'll find it a rich resource for you. Joshua, thanks so much for coming on. Joshua Kerievsky (28:25) Thank you, Brian. Thanks to you. Thanks to Mountain Goat and the folks there. And I really appreciate chatting with you. It was really wonderful.

Merci à Aurel d'avoir partagé sa vie et sa carrière pour le moins atypique avec nous ! Notes de l'épisode : LinkedIn d'Aurel : https://www.linkedin.com/in/aurel-estoup/ Maeevick's Bazaar : https://maeevick.substack.com/ Hexagonal Architecture : ⁠https://maeevick.substack.com/t/hexagonalarchitecture Découvrir Haskell : https://haskellbook.com/ Extreme Programming : http://www.extremeprogramming.org/

Extreme Programming mit den Coding Buddies.Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Melissa Perri is the founder of Product Institute, author of Escaping the Build Trap, and host of the Product Thinking Podcast. She has worked with startups, Fortune 50 companies, and everything in between to help them build better products and level up their product teams. In our conversation, we discuss:• The history of the product owner role• The differences between product owners and product managers• How to transition from product owner to product manager• The evolution of and problems with the SAFe framework• How large non-tech companies can improve their product practices• Much more—Brought to you by:• Pendo—The only all-in-one product experience platform for any type of application• OneSchema—Import CSV data 10x faster• Coda—The all-in-one collaborative workspace—Find the transcript at: https://www.lennysnewsletter.com/p/product-owners-melissa-perri—Where to find Melissa Perri:• X: https://twitter.com/lissijean• LinkedIn: https://www.linkedin.com/in/melissajeanperri/• Website: https://melissaperri.com/• Product Institute: https://productinstitute.com/• Podcast: https://www.produxlabs.com/product-thinking—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Melissa's background(02:12) The rise of the product owner role(06:37) Understanding Agile and Scrum(08:27) Challenges in Agile transformations(10:41) The history of the product owner role(13:58) The Scrum Guide(15:43) Product owner responsibilities(21:01) Adopting Scrum in organizations(26:21) The origins and implementation of SAFe(35:20) Why Melissa doesn't recommend SAFe(40:33) Advice for implementing a digital transformation(49:12) An example of SAFe adoption(51:27) The value of experienced product leaders(56:53) Career paths for product owners(01:04:14) Transitioning from product owner to product manager(01:06:41) Be careful relying on certifications(01:11:43) Evaluating existing product owners(01:16:55) Final thoughts on Agile and product management—Referenced:• Escaping the Build Trap: How Effective Product Management Creates Real Value: https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X• Lean UX: https://leanuxnyc.co/• Scrum: https://www.scrum.org/• What is Extreme Programming? https://www.agilealliance.org/glossary/xp/• Capital One: https://www.capitalone.com/• The Agile Manifesto: https://www.atlassian.com/agile/manifesto• Ken Schwaber on X: https://x.com/kschwaber• Jeff Sutherland on X: https://x.com/jeffsutherland• Kanban: https://www.atlassian.com/agile/kanban• What is a kanban board?: https://www.atlassian.com/agile/kanban/boards• Ron Jeffries's website: https://www.ronjeffries.com/• Jeff Patton on X: https://x.com/jeffpatton• The Scrum Guide: https://www.scrum.org/resources/scrum-guide• OpenSky: https://www.openskycc.com/• SAFe: https://scaledagileframework.com/• Dean Leffingwell on LinkedIn: https://www.linkedin.com/in/deanleffingwell/• Capital One scraps 1,100 tech positions: https://www.reuters.com/technology/capital-one-scraps-1100-tech-positions-source-2023-01-19/• Product management theater | Marty Cagan (Silicon Valley Product Group): https://www.lennysnewsletter.com/p/product-management-theater-marty• Marty Cagan on LinkedIn: https://www.linkedin.com/in/cagan/• Jeff Gothelf on X: https://x.com/jboogie• Shruti Patel on LinkedIn: https://www.linkedin.com/in/shruti-patel-32bb573a/• Product Thinking Podcast: Mastering Product Focus: Balancing Legacy and Innovation with Shruti Patel: https://www.produxlabs.com/product-thinking-blog/2024/9/25/episode-190-mastering-product-focus-balancing-legacy-and-innovation-with-shruti-patel• Melissa Douros on LinkedIn: https://www.linkedin.com/in/melissadouros/• Mind the Product: https://www.mindtheproduct.com/• Athenahealth: https://www.athenahealth.com/• McKinsey: https://www.mckinsey.com/—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

Edward Hieatt (@edwardhieatt, Chief Customer Officer @mech_orchard) talks about app modernization and the advancements and developments to increase progress.SHOW: 867Want to go to All Things Open in Raleigh for FREE? (Oct 27th-29th)We are offering 5 Free passes, first come, first serve for the Cloudcast CommunityRegistration Link - www.eventbrite.com/e/916649672847/?discount=Cloudcastfree  Instructions:Click reg linkClick “Get Tickets”Choose ticket optionProceed with registration (discount will automatically be applied, cost will be $0)SHOW TRANSCRIPT: The Cloudcast #867 TranscriptSHOW VIDEO: https://youtube.com/@TheCloudcastNET CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT OUR OTHER PODCAST - "CLOUDCAST BASICS" SHOW NOTES:Mechanical Orchard (homepage)Startup led by ex-Pivotal CEO lands $50M to modernize apps (TechCrunch)Topic 1 - Welcome to the show. Tell us about your background, and then give us a little bit of background on Mechanical Orchard.Topic 2 - Many of the MO team come from Pivotal (especially Pivotal Labs), as well as being involved with the Agile Manifesto, Extreme Programming, etc. How did the mission of the company get focus on modernizing existing applications?Topic 3 - Modernization projects have traditionally been really costly, with a low success rate. Why is now the right time to focus on this area?Topic 4 - I'm really interested in how MO technology works. It seems like a variation of a digital twin, mixed with some AI capabilities. Give us the big picture of how this is a different approach to modernization.Topic 5 - How much culture/process change is needed with MO to be successful? Topic 6 - What do the stages of success look like with your approach to application modernization?FEEDBACK?Email: show at the cloudcast dot netTwitter: @cloudcastpodInstagram: @cloudcastpodTikTok: @cloudcastpod

BONUS: Mastering Remote Work in Agile Teams With Antony Marcano NOTE: We want to thank the folks at Tuple.app for being so generous with their stories, and supporting the podcast. Visit tuple.app/scrum and share them if you find the app useful! Remember, sharing is caring!   In this BONUS episode, Antony, co-founder of RiverGlide and Head of Engineering at Ford Digital, joins us to share his experiences and insights from 30 years in software development, including 25 years in Agile practices. As a technical practitioner, leader, and consultant, Antony reflects on navigating remote work, overcoming challenges, and setting up successful remote software teams, while exploring future trends in the industry. The Shift to Fully Remote Work Antony reflects on his first fully remote software project, which took place during the pandemic when everyone was forced to work from home. While his team had been working together for 12 months, they struggled with traditional video conferencing tools that lacked the ability to support pair programming or mob programming effectively. This is when Antony and his team discovered Tuple, a tool that allows for seamless control sharing and a co-located pairing experience. "Switching to Tuple was a game-changer for us in making remote pairing feel as interactive as in-person collaboration." Overcoming Challenges in Remote Collaboration The biggest challenge Antony identifies in remote work is the loss of serendipitous moments—those random watercooler conversations that often lead to innovation. To address this, Antony encourages teams to create opportunities for these moments by structuring time for informal interactions and fostering a safe and open communication culture. "You can't recreate the watercooler, but you can create opportunities for innovation by encouraging open-door policies and setting up shared virtual spaces." Building Effective Remote Teams For Antony, real collaboration is critical to the success of remote teams. He grew up on XP (Extreme Programming) and believes in the power of pairing and mob programming. Antony emphasizes the importance of maintaining good practices from in-person work, such as prioritizing mental well-being, while adapting to the unique needs of remote teams. "Collaboration is not just about tools—it's about mental well-being, trust, and giving the team what they need to succeed." Keeping Teams on Track with Clear Goals Antony shares his approach to ensuring that teams remain aligned with clear goals and progress tracking. His teams focus on delivering small, incremental slices of work and using techniques like limiting Work In Progress (WIP). Rather than viewing user stories as a list of tasks, Antony encourages teams to focus on the user benefit and desired outcomes. "It's about the ‘why,' not just the ‘what.' User stories should focus on the goal, not just be a list of tasks." The Future of Remote Work in Software Development Looking ahead, Antony predicts that tools will continue to evolve, with AI playing a more significant role in software development. He discusses the possibility of having AI participants in pairing sessions and shares his concerns about the convergence of tools that may lose focus over time. Antony encourages developers to experiment with new technologies and remain open to change. "AI is the next frontier in software development, and we need to embrace how it can enhance our remote work experiences." Recommended Resources for Mastering Remote Work Antony notes that while many resources on remote work are often too generic, there are valuable tools and practices software teams can adopt. He recommends regularly rotating hosts during remote pairing sessions and setting aside time for retrospectives and discussions about the bigger 'why' behind the work. "When pairing, rotate roles, reflect regularly, and always focus on the bigger ‘why' to keep your team aligned and motivated." About Antony Marcano Antony is the co-founder of RiverGlide and Head of Engineering at Ford Digital. With 30 years of software development experience, including 25 years in Agile practices, he is a respected leader, coach, and consultant. Antony has contributed to books and journals and is a keynote speaker at global conferences and universities such as Oxford and McGill. He is also the co-creator of 'PairWith.Us,' and remains a hands-on technical practitioner, specializing in Agile development and leading teams to excel in agility. You can link with Antony on LinkedIn visit RiverGlide.com, or check out RiverGlide TV on YouTube.

In this special episode of Book Overflow, Martin Fowler joins Carter and Nathan to discuss his book Refactoring: Improving the Design of Existing Code. Join them as Martin shares why he wrote Refactoring, how the art of refactoring has changed, and how he views the book's legacy!https://martinfowler.com/-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Refactoring: Improving the Design of Existing Code by Martin Fowler and Kent Beckhttps://amzn.to/4enmuox (paid link)The Art of Agile Development, 2nd Edition by James Shore and Shane Wardenhttps://amzn.to/47TiM3D (paid link)Make No Law: The Sullivan Case and the First Amendment by Anthony Lewishttps://amzn.to/3zJ3K3O (paid link)----------------00:00 Intro01:58 Motivation for writing the book09:45 Refactoring, Extreme Programming, and testing19:17 Estimating, Unknowns, and Complexity23:40 Trust and High Performing Teams30:32 refactoring in the wild: imitate, assimilate, innovate, best practices and sensible defaults43:39 Legacy of the book and rational for second edition47:35 What are the role of books now? Evergreen content, Long-form content in a world of short-form content.01:03:21 Book Recommendations01:09:12 Closing Thoughts----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

Join us in the latest episode of "The Engineering Room," a monthly series featuring long-form discussions with influential figures in software development. In this episode, Dave talks with Dragan Stepanović, a principal engineer renowned for his efforts to evolve engineering cultures and eliminate bottlenecks. Dragan shares his journey in extreme programming (XP), emphasizing its profound impact on building collaborative and efficient teams. He dives into his fascinating research on pull requests, where he analyzed over 40,000 pull requests to uncover patterns in code review processes.If you're passionate about enhancing your software development practices through proven methodologies, this discussion is a must-watch. Remember, only our Patreon supporters get access to the full video episodes of The Engineering Room - thank you for all your support!----Dragan on X/Twitter - https://x.com/d_stepanovic?lang=en Dragan's Blog Posts - https://dragan-stepanovic.github.io/Patreon: https://www.patreon.com/continuousdelivery

Listen to this interview of Darja Smite, Professor, and Eriks Klotins, Senior Researcher — both at Software Engineering Research Lab (SERL), Blekinge Institute of Technology, Sweden. We talk about the paper From Collaboration to Solitude and Back: Remote Pair Programming During COVID-19 (Agile Processes in Software Engineering and Extreme Programming 2021). Eriks Klotins : "In research paper publishing, it's been my experience that especially junior researchers will misunderstand what is expected and what is required. And I can say personally, I enjoy reading papers where the authors have stepped away, in a good direction, from the accepted practice in paper writing — certainly much more than when reading a paper where someone has just tried to fill in a template of sorts, but the product of that effort makes no good sense.” Learn more about your ad choices. Visit megaphone.fm/adchoices Support our show by becoming a premium member! https://newbooksnetwork.supportingcast.fm/new-books-network

Listen to this interview of Darja Smite, Professor, and Eriks Klotins, Senior Researcher — both at Software Engineering Research Lab (SERL), Blekinge Institute of Technology, Sweden. We talk about the paper From Collaboration to Solitude and Back: Remote Pair Programming During COVID-19 (Agile Processes in Software Engineering and Extreme Programming 2021). Eriks Klotins : "In research paper publishing, it's been my experience that especially junior researchers will misunderstand what is expected and what is required. And I can say personally, I enjoy reading papers where the authors have stepped away, in a good direction, from the accepted practice in paper writing — certainly much more than when reading a paper where someone has just tried to fill in a template of sorts, but the product of that effort makes no good sense.” Learn more about your ad choices. Visit megaphone.fm/adchoices

Kent Beck is an original signer of the Agile Manifesto, author of the Extreme Programming book series, rediscoverer of Test-Driven Development, and an inspiring Keynote Speaker. I read his TDD book 20 years ago.   Topics of Discussion: [3:46] What led Kent to extreme programming? [7:52] What critical practices have stood the test of time? [10:58] The role of software design in Agile Development. [13:11] The inspiration behind Tidy First? [16:16] Why software design is both a critical skill and an exercise in human relationships. [22:05] What is “normalizing symmetry”? [25:04] Empirical design. [28:09] Design changes tend to be reversible. [30:41] Experimentation with the GPT phase of AI on publications. [35:13] Advice for young developers and programmers.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! KentBeck.com Tidy First? Test-Driven Development Extreme Programming Explained Implementation Patterns   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

In this PST Spotlight episode, PST Ryan Ripley interviews Reggie Gardner about his experiences. Reggie Gardner's journey into Scrum started with his interest in Extreme Programming and teamwork. He gradually applied Scrum principles while leading a small team. He eventually became a recognized expert and Professional Scrum Trainer (PST) due to his success in scaling Scrum in a larger development effort. Come along for Reggie's Journey!

Kent Beck, Chief Scientist at Mechanical Orchard, and inventor of Extreme Programming and Test-Driven Development, joins SE Radio host Giovanni Asproni for a conversation on software design based on his latest book "Tidy First?". The episode starts with exploring the reasons for writing the book, and introducing the concepts of tidying, cohesion, and coupling. It continues with a conversation about software design, and the impact of tidyings. Then Kent and Giovanni discuss how to balance design and code quality decisions with cost, value delivered, and other important aspects. The episode ends with some considerations on the impact of Artificial Intelligence on the software developer's job. Brought to you by IEEE Software and IEEE Computer Society.

BONUS: The Art of Slicing Work with Anton Skornyakov This episode features Anton Skornyakov, an expert in Agile methodologies and the author of "The Art of Slicing Work: How to Navigate Unpredictable Projects." Let's unpack the concept of slicing work and explore how it can revolutionize productivity and project management. Inspiration Behind The Book "Focusing on 'what's the result we want from this discussion' shifts our mindset towards more practical, outcome-oriented conversations." Anton shares what drove him to write his book. In his coaching practice, he noticed that many organizational discussions were mired in theory rather than focusing on actionable outcomes. By centering the conversation on "the next step" and the desired results for the upcoming two weeks, teams can move from abstract planning to concrete, actionable steps. Understanding Slicing Work "Think of work like a large dinner; slicing it into dishes rather than tasks offers flexibility and maintains the connection between different work elements." In his book, Anton introduces the concept of Slicing Work using the metaphor of preparing a large dinner. He explains that traditional task division (horizontal slicing) often leads to a loss of flexibility and a disconnection between different parts of a project. Instead, he advocates for vertical slicing, where each slice represents a complete unit of value, enhancing coherence and team productivity. Common Barriers to Slicing Work "Old habits and upfront software design practices prevent effective work slicing; adopting Test-Driven Development (TDD) can help overcome these barriers." Anton discusses the habitual and educational barriers that prevent effective slicing of work. Many professionals are trained to focus on their specific expertise and to plan extensively before starting actual development, practices which can impede the flexible and iterative nature of Agile methodologies. In this segment, we refer to Extreme Programming and the pattern of the tracer bullet. The Slicing Work Mindset "Empowering teams to feel they can reshape their work structure is crucial for successful implementation of work slicing techniques." Implementing work slicing techniques can be straightforward technically, but the real challenge often lies in changing the organizational mindset. Anton points out that teams may understand the concept intellectually but often struggle with feeling empowered to change existing processes. Addressing Leadership Skepticism "Instead of promoting slicing, I discuss potential risks with leaders to help them see the value in breaking down projects to manage risks effectively." When faced with leadership skepticism, Anton shifts the conversation from slicing work per se to managing project risks. By identifying what could go wrong and finding ways to address these risks incrementally, leaders can see the practical benefits of adopting slicing work techniques. The Future of Work with Full Adoption "By turning Agile up to 11, micromanagement becomes obsolete, and teams are empowered to focus on transparent, result-driven discussions." Anton envisions a future where complete adoption of slicing work principles leads to a significant transformation in how teams and stakeholders interact. With a focus on frequent, tangible results and pragmatic discussions, organizations can achieve greater transparency and reduce the need for micromanagement. About Anton Skornyakov Anton Skornyakov is the co-founder and managing director of Agile.Coach. He has coached nearly a hundred organizations and thousands of people in the art of slicing work. His insights are distilled in his latest book, "The Art of Slicing Work," which encapsulates a wealth of stories, lessons, and principles from his extensive experience. For more information, visit slicingwork.com. You can link with Anton Skornyakov on LinkedIn.

Bio Dr. Jeff Sutherland is the inventor and co-creator of Scrum, the most widely used Agile framework across the globe.  Originally used for software development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to solve complex projects in start-ups and Fortune 100 companies. Scrum companies consistently respond to market demand, to get results and drive performance at speeds they never thought possible. Jeff is committed to developing the Agile leadership practices that allow Scrum to scale across an enterprise.   Dr. Sutherland is the chairman and founder of Scrum Inc. He is a signatory of the Agile manifesto and coauthor of the Scrum Guide and the creator Scrum@Scale. Jeff continues to teach, create new curriculum in the Agile Education Program and share best practices with organizations around the globe. He is the founder of Scrum Inc. and coauthor of, Scrum: The Art of Doing Twice the Work in Half the Time, that has sold over 100,000 copies worldwide.    Social Media:                 LinkedIn: linkedin.com/in/jeffsutherland                 Twitter: @jeffsutherland Website: Scrum Inc https://scruminc.com               Books/ Articles: The Scrum Guide by Jeff Sutherland and Ken Schwaber http://www.scrumguides.org/index.html Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland The Scrum Fieldbook by JJ Sutherland Agile Competitors and Virtual Organisations by Steven Goldman, Roger Nagel and Kenneth Preiss https://www.amazon.co.uk/Agile-Competitors-Virtual-Organizations-Engineering/dp/0471286508 Accelerate: Building Strategic Agility for a Faster Moving World by John P. Kotter Leading Change by John P. Kotter Process Dynamics, Modeling and Control by Babatunde A. Ogunnaike and Harmon W. Ray A Scrum Book: The Spirit of the Game by Jeff Sutherland, James Coplien, Mark den Hollander, et al    Interview Transcript Ula Ojiaku: Hello everyone, my guest today is Dr Jeff Sutherland. He is the inventor and co-creator of Scrum, the most widely used Agile Framework across the globe. Originally used for Software Development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to deliver complex projects in startups and Fortune 100 companies. Dr Jeff Sutherland is the Chairman and Founder of Scrum Inc. He is a signatory of the Agile Manifesto and co-author of the Scrum Guide and the creator of Scrum at Scale. Jeff continues to teach, create new curriculum in the Agile education programme and share best practices with organisations around the globe. He has authored and co-authored a number of books which include Scrum: The Art of Doing Twice the Work in Half the Time – which has sold over 100,000 copies worldwide. In this episode, Dr Sutherland shares the backstory of how he and Ken Schwaber developed the Scrum framework. I was pleasantly surprised and proud to learn that one of the inspirations behind the current Scrum framework we now have was the work of Prof Babatunde Ogunnike, given my Nigerian heritage. Dr Sutherland also talked about the importance of Agile Leadership and his current focus on helping organisations fix bad Scrum implementations. I'm sure you'll uncover some useful nuggets in this episode. Without further ado, ladies and gentlemen, my conversation with Dr Sutherland.   Ula Ojiaku: Thank you, Dr. Sutherland, for joining us on the Agile Innovation Leaders podcast. It's a great pleasure to have you here. Jeff Sutherland: Glad to be here. Looking forward to it. Ula Ojiaku: Fantastic. So could you tell us about yourself? Jeff Sutherland: Well, I grew up in a small town in Massachusetts. And I always felt that I would go to West Point of the United States Military Academy, even at a very young age. And I finally made it there. I spent four years there. And I went on to a program where a certain number of cadets could join the Air Force. And I told the Air Force, if they made me a fighter pilot, I would move into the Air Force, which I did. I spent 11 years as a fighter pilot in the Air Force. And most of the operational aspects of Scrum actually come from that training. My last tour in the Air Force was actually at the US Air Force Academy, I was a professor of mathematics. And I had gone to Stanford University in preparation for that position. And I had worked closely with the, at the time he was Head of the Department of Psychiatry, became the Dean of Stanford who had studied under my father-in-law, he had become an MD under my father-in-law, who was a brilliant physician. And I was working on research papers with him, both at Stanford and at the Air Force Academy. And I asked him for guidance. And I said, I'm thinking about, given all the work we've done in the medical area. Starting in Stanford, I'm thinking maybe becoming a doctor - become an MD. And he strongly recommended against that he said, ‘you'll just go backwards in your career, what you need to do is you build on everything you've done so far. And what you have is your fighter pilot experience, your experience as a statistician, and a mathematician, you want to build on that.' So, I had already started into a doctoral program at the University of Colorado School of Medicine, which was not far from the Air Force Academy. And so, I talked to my department Chairman there who offered me a position in the department running a large research grant, funded by the National Cancer Institute and so, I decided to exit the Airforce and join the medical school. While I was finishing up my doctoral degree. And as soon as my doctorate was finished, I became a professor of Radiology, preventive medicine and biometrics. I was a joint across multiple departments. And I was doing mathematical research on modeling, particularly the human cell on a supercomputer, (to) determine what caused cancer. And to do that required extensive mathematical research as well as the medical research. But at the end of the day, what we found was for any complex adaptive system, like a human cell, or a person or a team, they go through different states. And they're moved from one state to the next by some kind of intervention. And so, if you understand what causes those changes… turned out in the case of cancer, there were four different states that led to a tumor. And in every state, there were certain interventions, and if you knew what they were, you could prevent them and prevent cancer. Or you could even, to my surprise, take a cancer cell and make it go backward into a normal cell. So, this fundamental understanding is the theory behind Scrum. So, while I'm doing this all at the medical school, a large banking company came by and said, ‘you know, over the medical school, you guys have all the knowledge about the technologies; the new technology, we're using (for) banking, you're using for research.' And they said, ‘you guys have all the knowledge but we have all the money and they made me an offer to come join the bank'    Ula Ojiaku: [Laughs]You couldn't refuse Jeff Sutherland: Not just me, it was my family. So, I wind up as Vice President for Advanced Systems, which was effectively was the CTO for 150 banks that we were running across North America.   Each was, you know, a dozen, 50, 100 branches. And of course, we were mainly doing the software, installation and support to run the banking operation, which is largely computer stuff – (this) is what banks run off. And as we're building these systems with hundreds and hundreds of developers, one of the first things I noticed is that all the projects were late. And I look at what they're doing. And they're using this process where they spend, you know, six months defining requirements, and then they put all the requirements into a Gantt chart. And then they, they plan on taking six months to build something, but it's never done. Because as soon as they start testing that they find there's all kinds of things that are broken. So, virtually every single project of the bank is late. So, as a head of technology, one day I walked into the CEO's office and I said, ‘Ron,  have you noticed all your projects are late?' He said, ‘Yes'. He says, ‘Every morning at least five CIOs or CEOs of the banks, they call me up.' And he says, ‘they scream at me.' I said, ‘wow', I said, ‘You know, it's going to get worse, not better. Because these guys are using this, these Gantt Charts.' And I showed him one. And then being a mathematician, I mathematically proved that every project would be late at the bank. And he was stunned. And he said, ‘what should I do?' I said, ‘we need a completely different operating system in the bank.' This is back in 1983. ‘Let's take one business unit. Let's take the one that's losing the most money, okay, the worst business unit' Ula Ojiaku: They have nothing to lose then. Jeff Sutherland: And it was the automated teller division that was rolling out cash machines all over North America. It was a new technology and they had a ton of problems. So, I said, ‘let's take that unit and every one, sales, market, support, installation, we're going to split them down into small teams. And we're going to have Product Marketing come in on Monday with a backlog prioritized by business value. And at the end of the week, on Friday, we're going to deploy to 150 banks.' ‘And I'm going to train them how to land a project every week, just like I trained fighter pilots to land aircraft. I'm going to give them a burndown chart, we're going to throw away the Gantt Chart, I'm going to give them a burndown chart to show them how to land the project.' So, he said, ‘Well, that's gonna be a big headache.' I said, ‘look, the bank needs to be fixed.' He said, ‘Okay, you got it.' So, I took that unit. I told them, ‘I know it's gonna take several weeks,' today we call them sprints, ‘for you to be successful.' Because as new pilots, trained to land, these high-performance jets, they tend to come in high and then they have to come around and try to land again, they over and over, they practice until they can nail it. And it took them six weeks, six sprints to actually nail the end of the week (and) deploy (to) 150 banks. But within six months, it became… it went from the worst business unit in the bank to the most profitable business unit in the bank. And the senior management said, ‘you know, Jeff, here's another 20 million dollars to throw at whatever that thing you're doing  it's the most profitable thing in the bank, we're gonna put more money in that. So that was the first prototype of what we call today Scrum at Scale. Now, I've been CTO of 11, or CTO or CEO of 11 different companies. And for the next 10 years, I prototyped that model and advanced technology teams until in 1993, at a company called Easel Corporation, we found that because of the tooling we were building and selling to customers, we needed to build the tool with what today we call Agile Practice. Ula Ojiaku: Yes Jeff Sutherland: And we need to train the customer to use the tool by having teams do an agile practice. So, in order to train our customers properly in 1993, we actually had to formalize what I've been prototyping for 10 years. And we wrote it down and at the time we were reading this paper, we're going through 1000 papers in the journals I, you know, I had done many new technology. And, in every one of them, you have to read everything that's ever been done so that you can go beyond. You can use everything that's been done, but then you go beyond, okay? Ula Ojiaku: Yeah Jeff Sutherland:  So, it's a tremendous amount of research to launch new technology. And at about the 300th paper in our file, it was a paper out of the Harvard Business Review, which really surprised me, by two Japanese Business School professors, Professors Takeuchi and Nonaka. And in there, they described the best teams in the world. They were lean hardware teams that reminded them of a game of rugby, they said, ‘we're going to call what they're doing Scrum Project Management.' So, I said to the team, ‘we need a name for this thing that we're going to train our customers in, and let's call it Scrum.' And off we went. So, for the next two years, we were actually using Scrum within Easel deploying products. But it was not public, to the general industry. And Easel got acquired by a larger company. And at that time, I felt that this needed to be rolled out into the industry because we had benchmarked it with the best tooling in the world from the leading productivity company, and showed that it was… that (it) went 10 times faster. The quality was 10 times better, which is what you need for a new technology innovation. And so, I felt it was ready to go to the industry as a whole. So, I called up an old friend, Ken Schwaber. And he was a CEO of a traditional Project Management software company, a waterfall (methodology). He sold these methodologies with 303 ring binders, a software package that would make Gantt Charts. So, I said, ‘Ken, I want you to come up and see the Scrum, because it actually works and that stuff you're selling doesn't work – it makes projects late.' And he agreed to come in, he actually came up, he met with me. He stayed for two weeks inside the company, working, observing the Scrum team. And at the end of those two weeks, he said, ‘Jeff, you're right. This really works - it's pretty much the way I run my company.' He said, ‘if I ran my company with a Gantt Chart, we would have been bankrupt a long time ago.' So, I said, ‘well, why don't you sell something to work that works instead of inflicting more damage on the industry?' So, he said so we said ‘okay, how (do) we do it?' I said, ‘it needs to be open source, it needs to be free.' Ken felt we needed to take the engineering practices, many of which appear today in extreme programming… Ula Ojiaku: Yes Jeff Sutherland: …and let Kent Beck (creator of eXtreme Programming, XP) run with them because Kent had been sending me emails, ‘Jeff, send me every...', he had been following the development of Scrum, ‘…send me everything on Scrum, I'm building a new process. I want to use anything that you've done before and not try to reinvent anything.' So, he (Ken Schwaber) said, ‘let Kent take the engineering practices, we'll focus on the team process itself.' And we agreed to write the first paper on this to present at a big conference later that year. And writing that paper was quite interesting. Ken visited DuPont Chemical Corporation, the leading Chemical Process Engineers there that they had hired out of academia to stop chemical plants from blowing up. And when Ken met with them, they said, describe what we were doing in the software domain. They said, ‘you know, well, that process that traditional project management is a Predictive Process Control System. We have that in the chemical industry.' ‘But it's only useful if the variation in the process running is less than 4%.' They said, ‘do you have less than 4% change in requirements while you're building software?' Ken says, ‘no, of course not! It's over 50%!' And they started laughing at him. They said, ‘your project's going to be exploding all over the place.' ‘Because every chemical plant that has blown up has been somebody applying a predictive control system to a system that has high variability. You need to completely retrain industry to use Empirical Process Control, which will stop your projects from blowing up. And they said, here it is, here's the book, they had the standard reference book for Chemical Process Engineering. And in there, there's a chapter on Empirical Process Control, which is based on transparency, inspection, and adapting to what's happening in real time. Okay, so those are the three pillars of Scrum that are today at the base of the Scrum guide. Ula Ojiaku: Do you still remember the title of the book that the chemical engineers recommended to Mr. Schwaber by any chance? Jeff Sutherland: Yeah, so I have a, when I do training, I have a slide that has a picture of the book (Process Dynamics, Modelling and Control). It's written by Ogunnaike and Ray. But that is the root of the change that's gone on in the industry. And so then from 1995, forward, Ken and I started working together, I was still CTO of companies. And I would get him to come in as a consultant and work with me. And we'd implement and enhance the Scrum implementations in company after company after company. Until 2001, of course, Scrum was expanding but Extreme Programming in 2001, was actually the most widely deployed. They were only two widely-deployed agile processes at the time of Scrum and Extreme Programming. Extreme Programming was the biggest. And so, the Agile Manifesto meeting was convened. And it had 17 people there, but three of them were Scrum guys - that had started up Scrum, implemented it in companies, four of them were the founders of Extreme Programming. And the other 10 were experts who have written books on adaptive software development or, you know, lightweight processes, so, industry experts. And we, we talked for a day and everybody explained what they were doing and there was a lot of arguments and debate. And at the end of the day, we agreed because of this book, Agile Competitors, a book about 100 hardware companies - lean hardware companies, that have taken Lean to the next level, by involving the customer in the creation of the product. And we said, ‘we think that we all need to run under one umbrella. And we should call that Agile.' Ula Ojiaku: So, did you actually use the word umbrella in your (statement)? Oh, okay. Jeff Sutherland: Often, people use that right? Ula Ojiaku: Yes, yes Jeff Sutherland: Because at the time, we had Agile and Extreme Programming, and now everybody's trying to come up with their own flavor, right?  All under the same umbrella of ‘Agile'. And that caused the both Scrum and Extreme Programming started to expand even more, and then other kinds of processes also. But Scrum rapidly began to take dominant market share, Scrum today is about 80% of what people call Agile. The reason being, number one, it was a technology that was invented and created to be 10 times better. So, it was a traditional new technology developed based on massive amounts of research. So, it worked. But number two, it also scaled it worked very well for many teams. I mean, there are many companies today like Amazon that have thousands of Scrum teams. And Extreme Programming was really more towards one team. And (reason number) three, you could distribute it across the world. So, some of the highest performing teams are actually dozens of teams or hundreds across multiple continents. And because of those three characteristics, it's (Scrum has) dominated the market. So that brings us to in 2006, I was asked by a Venture Capital firm to help them implement Scrum in their companies, they felt that Scrum was a strategic advantage for investment. And not only that, they figured out that it should be implemented everywhere they implemented it within the venture group, everybody doing Scrum. And their goal was to double their return on investment compared to any other venture capital firm. They pretty much have done that by using Scrum, but then they said, ‘Jeff, you know, we're hiring you as a consultant into our companies. And you're a CTO of a healthcare company right now. And we don't want to build a healthcare company, we want to build a Scrum company.' ‘So, why don't you create Scrum Inc. right here in the venture group? We'll support it, we'll do the administrative support. We'll write you a check - whatever you want.' So, I said, ‘well, I'm not going to take any money because I don't need it. I understand how that works. If the venture capital firm owns your company, then (in the) long term, you're essentially their slave for several years. So, I'm not taking any money. But I will create the company within the venture group. If you provide the administrative support, I'll give you 10% of the revenue and you can do all the finances and all that kind of stuff. So, that's the way Scrum Inc. was started to enable an investment firm to launch or support or invest in many dozens of Scrum companies. Ula Ojiaku: That's awesome Jeff Sutherland: And today, we're on the sixth round of investment at OpenView Venture Partners, which was the company the six round is 525 million. There's a spin out from OpenView that I'm working with, that has around this year, 25 million. And over the years, just co-investing with the venture group I have my own investment fund of 50 million. So, we have $570 million, right this year 2021 that we're putting into Scrum companies. Agile companies, preferably Scrum. Ula Ojiaku: Now when you say Scrum companies is it that they facilitate the (Scrum) training and offer consulting services in Scrum or is it that those companies operate and you know, do what they do by adopting Scrum processes? Jeff Sutherland: Today, Scrum Inc sometimes help some of those companies, but in general, those companies are independently implementing Scrum in their organizations.   Ula Ojiaku: Right Jeff Sutherland: And okay, some of them may come to Scrum training, maybe not. But since Scrum is so widely deployed in the industry, Scrum Inc, is only one of 1000 companies doing Scrum training and that sort of stuff. So, they have a wide variety, wide area of where they can get training and also many of the startups, they already know Scrum before they started the company. They are already Agile. So, what we're interested in is to find the company that understands Agile and has the right team players, particularly at the executive level, to actually execute on it. Ula Ojiaku: No matter what the product or services (are)… Jeff Sutherland: Products or services, a lot of them are software tooling companies, but some of them are way beyond that, right? So, turns out that during COVID… COVID was a watershed. The companies that were not agile, they either went bankrupt, or they were crippled. That meant all the Agile companies that could really do this, started grabbing all the market share. And so, many of our companies, their stock price was headed for the moon during COVID. While the non-agile companies were flatlined, or are going out of business, and so the year of COVID was the best business year in the history of venture capital because of Agility. So, as a result, I'm spending half my time really working, investing in companies, and half of my time, working with Scrum (Inc.) and supporting them, helping them move forward. Ula Ojiaku: That's a very impressive resume and career story really Dr. Sutherland. I have a few questions: as you were speaking, you've called Scrum in this conversation, a process, a tooling, the technology. And you know, so for some hardcore Agilists, some people will say, you know, Agile is all about the mindset for you, what would you say that Scrum is it all of these things you've called it or would it be, you know, or it's something (else)...? Jeff Sutherland: So, certainly the (Agile) mindset is important. But from an investment point of view, if the organization can't deliver real value, quickly, agile is just a bunch of nonsense. And we have a huge amount of nonsense out there. In fact, the Standish group has been publishing for decades. 58% of Agile teams are late over budget with unhappy customers. So, when you get these hardcore Agilist, that are talking about mindset, you have to figure out ‘are they in the 42% that actually can do it or are they in the 58% that are crippled?' My major work with Scrum Inc. today is to try to get to fix the bad Scrum out there. That is the biggest problem in the Agile community. People picking up pieces of things, people picking up ideas, and then putting together and then it doesn't work. That is going to that's going to be really bad for agile in the future. If 58% of it continues not to work. So, what we found, I mean, it was really interesting. Several years ago, the senior executive (of) one of the biggest Japanese companies flew to Boston wanted meet with me. And he said to me, ‘the training is not working in Japan for Scrum.' He said, ‘I spent 10 years with Google, in Silicon Valley. So, I know what it looks like what actually works. And I can tell you, it's not working in Japan, because the training is… it's not the training of the Scrum that is high performing. And in fact, our company is 20% owned by Toyota, and we are going to be the trainers of Toyota. And we cannot deliver the training that's currently being given to Toyota, it will not work, it will not fly. And we want to create a company called Scrum Inc. Japan. And we're a multibillion-dollar company, we're ready to invest whatever it takes to make that happen.' To give them the kind of training that will produce the teams that Takeuchi and Nonaka were writing about in the first paper on Scrum. And as we work with them to figure out what needs to be in that training, we found that the Scrum Guide was only 25% of the training. Another 25% was basic Lean concepts and tooling, right? Because the original Scrum paper was all about Lean hardware companies. So Lean is fundamental to Scrum. If you don't understand it, you can't do it. And then third, there are certain patterns of performance that we've developed over the years, we spent 10 years writing a book on patterns - Scrum patterns. And there's about a dozen of those patterns that have to be implemented to get a high performing team. And finally, scaling to multiple teams. It turns out, right about this time I started working with the Japanese, I was at a conference with the Agile Leadership from Intel. And they told me that they'd introduced Scaling Frameworks into Intel division, some of which had more than 500 Scrum teams in the divisions and the Scaling Frameworks had slowed them down. And it made the senior executives furious and they threw them all out and they said, we did not want to hear the word Scrum at Intel anymore. But you guys need to go twice as fast as you're going now. So, they came to me, they said, ‘we're desperate. We have to go twice as fast. We can't even use the word “Scrum”. What should we do?' And they blamed me, they said, ‘Sutherland you're responsible you caused problem, you need to fix it.' So, I started writing down how to do what today we call Scrum at Scale. And everybody, you know, most of those people in the industry were implementing IT scaling frameworks. They were all upset. ‘Why are you writing down another framework?' Well, it's because those IT frameworks do not enable the organization to show Business Agility, and win in the market. And in the best companies in the world, they're being thrown out. So, I've had to write down how do you add, how do you go to hundreds and thousands of Scrum teams - and never slow down as you're adding more and more teams. You know, every team you add is as fast as the first team when you start. Yeah, that's what Scrum at Scale is all about. So, there's two primary things that I'm focused on today. One is to fix all this bad Scrum. Second is to fix the scaling problem. Because it turns out that if you look at the latest surveys from Forbes magazine, and the Scrum Alliance on successful Agile transformations - I learned recently, that almost every company in the world of any significance is going through an Agile transformation or continuing transformation they'd already started years ago. And 53% of them do not meet management expectations. And the MIT Sloan Business Review did an analysis of what happens if an agile transformation fails, and 67% of those companies go out of business. So, this is becoming really serious, right? To be successful today, if you're competing in any significant way, you have to be agile. And number two, if you try to be agile and fail, you have a 67% chance going out of business. And the failure rate is 53%. So, this is the problem that we're wrestling with. And half of that 53% failure is due to the bad Scrum we talked about, but the other half is due because of the leadership not being Agile. Ula Ojiaku: I was just going to say, as you said something about the leadership not being agile. In my experience, you know, as an agile coach in some organizations whilst the teams would embrace you know, Scrum and embrace Agility - the practices and the processes and everything. There's a limit to, you know, how much they can get done… Jeff Sutherland: Absolutely… Ula Ojiaku: …if the leadership are not on board. So… Jeff Sutherland: …you hit this glass ceiling. So, I've been, you know, giving presentations on Agile Transformations around the world. And I can remember multiple times I've had 300 people in the room, say, and I say okay, ‘How many of you are agile, in Agile transformations or continuing the ones you'd started?' Of course, everybody raises their hand. ‘How many of you have waterfall traditional management that expects you to deliver all the old Gantt Chart reports that we always got, and don't understand what you're doing?' There's 300 people in the room and 297 people raised their hand. I said, ‘you need to give your leadership the book by Professor Kotter called Accelerate.' Professor Kotter is one of the leading change experts of the world. Ula Ojiaku: And he also, yeah, He also wrote ‘Leading Change' as well - the book, yes. Jeff Sutherland: And in that book, he says, if the leadership of the Agile part of the organization is traditional in their mindset and requirements, the Agile Transformation will eventually fail 100% of the time. Ula Ojiaku: Those are sobering statistics in terms of, you know, the failure rate and how much of you know the success hinges on business agility and the leadership being agile as well and taking the time to know and care what it means. Yeah. Jeff Sutherland: And what's happening is that the Agile Leadership today, if you look at some of the companies that have been most successful during COVID, one of them is John Deere Corporation, the biggest farm equipment manufacturer in the world, probably the oldest. Their stock price went up more than Amazon during COVID. And the board of directors gave their Agile Leadership, the Agile Coaches, Scrum Masters, the highest award in the Corporation for producing that result. So that's another reason I'm trying to communicate to Agile people. The success and survival of your company depends on you. You think your management's going to save you but no, if they are old-style people, they are going to run that company out of business. And you need to either save it before it goes out of business or run to another company before bad things happen. Ula Ojiaku: It's impressive that, you know, John Deere being a farm equipment manufacturer… I think they were ahead of the curve you know, (compared to some of their contemporaries in that industry as well) and embraced agile ways of working. Do you know how their Agile Leadership were able to quantify their contributions to the company? Jeff Sutherland: John Deere started to get Agile more than 10 years ago. So, they've been at it a long time. But in recent years, they really started to build… build internally… Agile leadership, you know, based on my work and they started applying that across the company. I mean, the major focus has not been software actually – it's been in other parts of the company. What has to happen to run a company that's building tractors? Well, there's all kinds of things that have to happen, you know - purchasing, there's legal, there's acquiring all the pieces, it's putting them together at the assembly line, you know, software is a piece of it. You know, that's probably the easiest piece to fix with Agile, it's the rest of the company that's the challenge. They have started doing that really well which is reflected in their stock price. Ula Ojiaku: Amazing. So, you said something about you know, you're out to fix a couple of things, the problem with bad Scrum out there. And, you know, the problem with scaling agile. Jeff Sutherland: Right Ula Ojiaku: So, with respect to the first one, the point about bad Scrum, what in your experience would be the root cause of bad Scrum implementations in organizations? Jeff Sutherland: There're about 11 things, that if you fix them, the team will go twice as fast. And it's multiplicative. So, you know, we have extensive data on, you know, really big companies. What's the difference between the fastest team and the slowest teams? The fastest teams are 2000 times faster than the slowest teams. So why is that? Well, first, the team has to be small. The optimal team size is four or five people. If you have a 10-person team, that's going to take at least 50% longer to get anything done. If you go out, look at the team size, you'll see companies have even not only ten-people teams, they have 15 people in a team, 25 people in a team, okay? Those teams are never gonna meet Agile performance. Second, the backlog needs to be really ready in a sense of small, it's clearly understood, it's properly prioritized. So, you need somebody managing that backlog that can get it right, because we have extensive data for multiple case studies showing the team's production doubles immediately. As soon as you get that backlog right. So you go into many companies, you'll see, there's still arguing about what's the top priority, right? Or everything's top priority. That's just gonna create a massive mess. Third, teams are constantly interrupted. You know, the only teams I know that aren't interrupted are people… these teams and defense contractors working on top secret stuff. And they work in a locked room, the door, it says ‘no managers can enter' and they don't get interrupted. But for the rest of us, there's always somebody coming in wanting something else done. And there's a way to manage that using a pattern we call the interrupt buffer. And if you don't have that pattern implemented properly, you're gonna go half as fast. If you're lucky, you might go half as fast. Ula Ojiaku: And what do you say the Scrum Master has a part to play in making sure the interrupt buffer is there and it's enforced? Jeff Sutherland: The scrum master needs to set this all up. Fifth, in high performing teams, we see this pattern called swarming, where multiple people are working on a story together. That increases the process efficiency, which doubles the performance of the team. So, if people are specialists working independently, that team is going to be really slow. So I'm up to number five, there are six more things, but you probably want to go through them. It's very clear, what makes agile teams suck, we know exactly why. And it needs to be fixed. So, I appeal to anyone listening to this help fix bad agile, it's hurting us all. Ula Ojiaku: Thank you for sharing that. Would this be in any of any of your books or in any of your articles that you've written? Jeff Sutherland: Yeah, it's everywhere and (in) everything I've written, but the best summary, it's the red book Scrum … Scrum, The Art of Doing Twice the Work and Half the Time And we've had people pick, pick this up. A CEO in Kenya came to New York to one of my courses, he said, ‘Jeff, I just read your book. And I'm CEO with three new energy startups in Kenya. And my teams implemented that, and they're going… they're doing three times the work and a third of the time. So, your book is too conservative.' He says to me, this guy, he only read the book, he had no training. So, this book is enough to really get off on the right foot. And if you're having problems, it's enough to fix things. In fact, recently before COVID when we could get everybody together, we had an Apple employee in the class and she said, Jeff, do you know why Apple always meet its states? I said, no, you know, Apple is really secretive. They don't tell anybody anything. She says ‘it's because they do Scrum by the book.' So, I said, ‘What book?' She says, ‘The Red Book - Scrum, The Art of Doing Twice the Work and Half the Time - they do it exactly by the book.' So, again, my message to the Agilists out there: Apple is winning. They are the most valuable company in the world. And it's because they do Scrum exactly by that book. So, you probably should read it. Ula Ojiaku: Definitely. So going by the book, would you say there's any wriggle room for adapting to one's context, or is it about you know, going, ‘check- we've done page 123…' Jeff Sutherland: Well, the whole thing about adapting is fundamental to Scrum. So, one of the things I'm constantly doing in my talks, training, is I'm going back to before Scrum and reading a paper from the leading researchers on complex adaptive systems, in which they mathematically proved, you model things on the computer, that systems evolve more quickly, if they have more degrees of freedom, up until you hit a boundary where the system goes into a chaotic state. So, from the very beginning in Scrum, maximizing the freedom and the decision capability of the team has been fundamental. And we talked about this as self-organization. Now, unfortunately, that term has been so misused, misunderstood that we had to take self-organization out of the Scrum guide. And what we inserted was self-managing. And we put next to it goals, okay, the theme is self-managing to achieve a goal. And to make that happen, they need a commitment to do that. And so, this is one of the fundamental things for Agile teams that work that they have that self-managing commitment to achieve a goal. And the teams that are not working, they're fuzzy about that, right. So, we want the maximum degree of adaptation, the thing that they don't want to change is the basic structure that's in the red book, if they change that, it has the control mechanisms to allow the maximum degree of self-organization - not to go off the rails. Ula Ojiaku: Right. Jeff Sutherland: So, we see a lot of Agilists, ‘oh, you know, let's just tweak the framework this way or that way.' And then the self-organization takes a team off the rails, and then they fall into that 58% that can't deliver, they're late, they're over budget, the customers aren't happy. And so, this is the really one of the hardest things to communicate to people. There're certain things that you absolutely have to be disciplined about. You have to be more disciplined to get a great Agile team than in all ways of working. And that discipline is what allows the maximum degree of self-organization and self-determination, right? So, understanding those two things together, you know, it makes it makes people's brain explode, right? It's hard. Ula Ojiaku: But it works. Jeff Sutherland: But it works right.  Ula Ojiaku: You've already mentioned a lot of books in the course of this interview session, and these would be in the show notes. So, would there be anything any final word of advice you'd have for the leaders that would be listening to this podcast in terms of their transformation journey? Jeff Sutherland: So, one of the things we did to Scrum at Scale is that the difference between that and most of the other scaling frameworks is that it's all about the leadership. So, we need an operating leadership team, that is a Scrum team that needs a Scrum Master, a Product Owner, backlog. And its objective is to improve the Agile implementation of the organization. On the prioritization side, we need a leadership team that, led by a Chief Product Owner, that is prioritizing backlog across the organization. So, you know, I've had the Chief Product Owner of Hewlett Packard in my course, he had a $200 billion portfolio. He learned from that class. Says this class is pretty good.' He said, ‘In just one slide I figured out how to get $20 billion more a year with no additional resources'. Just by understanding how to work the framework right? At the $200 billion level. Ula Ojiaku: And you're talking about the Scrum at Scale course, right? Jeff Sutherland: No, this was a product owner course. Product Owner course. He came to it. We're now doing a Scrum at Scale… we're actually doing a Chief Product Owner course. So, a Product Owners at Scale course which it has been really well received by the leading Agile Practitioners. (They) really like that because they need to work more in the large than in the small often. Ula Ojiaku: Definitely. That means this available on the Scrum Inc site? Jeff Sutherland: Yes. Ula Ojiaku: Okay. Jeff Sutherland: So, one of the things I would recommend I would really recommend is the Scrum Field Book. It's a bunch of case studies for organizations, large and small, that have tried to take the whole organization to Scrum. Well, thank you so much, Dr. Sutherland - it's been a great pleasure having you and hopefully we could have a you know, follow up conversation sometime. Jeff Sutherland: Yes. Thanks for inviting me and glad to do it again. Ula Ojiaku: That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com. Also share with friends and leave a review. This would help others find the show. I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com. Till next time, take care and God bless!    

Go ahead and bravely demand the next feature right after the completion of the last! This week on Troubleshooting Agile, Squirrel tells us why he likes to be more demanding than Kent Beck. Links: - Kent Beck: https://en.wikipedia.org/wiki/Kent_Beck - Tidy First: https://tidyfirst.substack.com/p/tidy-first-in-one-page - Extreme Programming: https://en.wikipedia.org/wiki/Extreme_programming -------------------------------------------------- Order your copy of our book, Agile Conversations at agileconversations.com Plus, get access to a free mini training video about the technique of Coherence Building when you join our mailing list. We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us at info@agileconversations.com -------------------------------------------------- About Your Hosts Douglas Squirrel and Jeffrey Fredrick first met while working together at TIM group in 2013. A decade later, they remain united in their passion for growing organisations through better conversations. Squirrel is an advisor, author, keynote speaker, coach, and consultant, helping companies of all sizes make huge, profitable improvements in their culture, skills, and processes. You can find out more about his work here: https://douglassquirrel.com/index.html Jeffrey is Vice President of Engineering at ION Analytics, Organiser at CITCON, the Continuous Integration and Testing Conference, author and speaker. You can connect with him here: https://www.linkedin.com/in/jfredrick/

Original signer of the Agile Manifesto, author of the Extreme Programming book series, rediscoverer of Test-Driven Development, and inspiring Keynote Speaker. I read his TDD book 20 years ago.   Topics of Discussion: [4:06] What led Kent into extreme programming, and realizing that technical mastery alone is not enough for project success. [6:24] The significance of extreme programming. [9:15] The Agile Manifesto. [10:46] The importance of taking responsibility seriously. [14:06] What was the inspiration behind Tidy First? [16:27] Why software design is an important skill. [17:31] The human aspect dominates in design. [19:40] You can make large changes in small safe steps. [23:09] Normalizing symmetry. [30:17] Preserving flexibility in design through empirical and reversible changes rather than rather than speculative or reactive design. [31:51] Kent's experimentation with the GPT phase of AI on publications. [32:11] Rent-A-Kent to get better answers around software development. [37:19] Advice for young programmers.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Rent-A-Kent Tidy First? by Kent Beck Test Driven Development, by Kent Beck Extreme Programming Explained, by Kent Beck with Cynthia Andres Implementation Patterns, by Kent Beck   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

In this first episode, Dave Farley chats with Martin Fowler. Martin is a widely read author having written definitive works on several important topics, including Refactoring, NoSQL, UML, Extreme Programming, and several books on patterns. He also has a very widely read website that captures more of these thoughts, and more collections of patterns too at ➡️ https://martinfowler.comDave and Martin discuss a wide range of ideas, from new work in patterns in distributed systems and Data Mesh, to the fundamental principles of software development that matter, whatever the technology or problem that you are solving.xx

Angela Johnson is a Certified Scrum Trainer (CST), founder of the Collaborative Leadership Team, and the author of The Scrum Master Files: Secrets Every Coach Should Know. A self-proclaimed “professional people geek”, Angela helps companies successfully implement Scrum and Agile to achieve their goals and objectives, as well as people to get certified as scrum masters. Her expertise includes Kanban, eXtreme Programming, Facilitation and Organizational Change for business agility.

My guests for Episode #495 of the Lean Blog Interviews Podcast are Catherine Chabiron and Fabrice Bernhard, who are discussing her new book Learning to Scale at Theodo Group: Growing a Fast and Resilient Company. Episode page with video, transcript, and more Catherine Chabiron is a board member for the Institut Lean France, a member of the Lean Global Network, like the Lean Enterprise Institute. Catherine is an established expert in Lean management with a professional journey spanning over 40 years. She has experience in a range of service and support functions, including IT, Logistics, Sales, Finance, and HR, both in France and globally. As a Lean executive coach, her expertise in Lean thinking has been largely shaped by her experiences within the automotive industry, where she has lived and breathed the Lean philosophy. This has been further enriched by her regular visits to the Toyota supply chain in Japan, an experience that has offered her unique insights and an in-depth understanding of how a learning culture operates. So, speaking of Theodo Group, we're also again joined by their chief technology officer and co-founder, Fabrice Bernhard. He co-founded Theodo in Paris in 2009, which has grown on average 50% yearly for the last 8 years and generated 90M€ revenue in 2022. He is now based in London to help with the international expansion. We delve into the broadened application of lean principles in our discussion with Fabrice Bernard and Catherine Chabiron. Bernard shares how Theodore Group implemented Lean as a strategic pillar in their operations, using it as a toolbox to create sustained growth and maintain competitive edges. They systematically addressed business challenges using TPS, Extreme Programming, and Scrum to conjure the “agile magic” of a small, integrated team at scale. Don't miss out on the chance to hear about cultivating a Lean culture that goes beyond strategy and tool adoption. By fostering an environment of continuous learning, teamwork, and the relentless pursuit of excellence, Theodore Group effectively established Lean as the backbone of their company's culture. We also expound on broader societal challenges that can be addressed through Lean methodologies and the journey of A3 thinking in fostering deep understanding and collaboration. This episode takes an expansive look at Lean practices, demonstrating its adaptable, innovative, and ethically conscious nature across different industries, proving its potency in driving companies towards sustained growth. Questions, Notes, and Highlights: What are your Lean origin stories? Lean as a strategy at Theodo Group? How did the two of you come to work together? First met in Japan, right? What led to the book? Startup vs Scale-up? Six Planet Lean articles – LINK Sharing Lean thinking with your CEO and other leaders? How do you embody Lean? A lot of virtual work now? If so what does Gemba mean? What does continuous improvement mean to you? How do leaders foster a learning culture? How does continuous improvement address not just the scaling challenge but societal challenges? Why are the current ways of scaling a company broken? Big Company Disease? Silos and process trumping customers, compliance over initiative The podcast is sponsored by Stiles Associates, now in its 30th year of business. They are the go-to Lean recruiting firm serving the manufacturing, private equity, and healthcare industries. Learn more. This podcast is part of the #LeanCommunicators network. 

"Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek" - takiego rodzaju User Story są niestety dość typowe i w zasadzie niewiele dobrego wnoszą do projektu. A trudności, jakie często pojawiały się przy formułowaniu wartościowych User Story, skutkowały się pojawianiem różnych technik wspomagających ich rozpoznanie. Kuźnią wielu pomysłów były prace zespołów stosujących Extreme Programming w projektach Chrysler C3 i Connextra... Kompleksowe podejście zarówno do identyfikacji User Stories jak i ich dalszego wykorzystania z projekcie zaproponował w końcu w 2014 roku Jeff Patton, proponując warsztatową technikę User Story Mapping.W tym odcinku Better Software Design dodajemy więc User Story Mapping do naszego analitycznego toolboksa. A moim gościem w tej rozmowie jest Michał Bartyzel, który bardzo mocno wykorzystuje tę technikę w swojej codziennej pracy z zespołami. W tym odcinku rozmawiamy z Michałem między innymi o:bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,wykorzystaniu USM w projekcie,różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,sposobach prowadzenia warsztatu analitycznego.Materiały dodatkowe:It's All in How You Slice, artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story MappinguThe New User Story Backlog is a Map, drugi po artykule istotny wpis Pattona na temat problemów z historyjkamiUser Story Mapping: Discover the Whole Story, Build the Right Product, książka Jeffa z 2012 roku, przedstawiająca technikę User Story MappinguStory Map Concepts oraz Agile Story Essentials, krótkie i rzeczowe podsumowania pokazujące zasadę działania USMPolecam także zajrzeć na stronę Michała, a w szczególności na prowadzonego przez niego bloga.Zapraszam!

This episode will be available only to Apple Podcasts subscribers through January 3rd, 2024. My guests today are Catherine Chabiron and Fabrice Bernhard, discussing her new book "Learning to Scale at Theodo Group.” Today, we delve into the broadened application of lean principles in our discussion with Fabrice Bernhard and Catherine Chabiron. They both share how Theodo Group implemented Lean as a strategic pillar in their operations, using it as a toolbox to create sustained growth and maintain competitive edges. They systematically addressed business challenges using TPS, Extreme Programming, and Scrum to conjure the "agile magic" of a small, integrated team at scale. Don't miss out on the chance to hear about cultivating a Lean culture that goes beyond strategy and tool adoption. By fostering an environment of continuous learning, teamwork, and the relentless pursuit of excellence, Theodo Group effectively established Lean as the backbone of their company's culture. We also expound on broader societal challenges that can be addressed through Lean methodologies and the journey of A3 thinking in fostering deep understanding and collaboration. This episode takes an expansive look at Lean practices, demonstrating its adaptable, innovative, and ethically conscious nature across different industries, proving its potency in driving companies towards sustained growth.

Ralph Hempel spoke with us about the development of Lego Mindstorms from hacking the initial interface to running Debian Linux as well as programming Mindstorms in Python. Happy 25th birthday to Lego Mindstorms! Pybricks is a MicroPython based coding environment that works across all Lego PoweredUp hubs and on the latest Mindstorms elements. The creators are David Lechner and Laurens Valk. Ralph was the first person to boot a full Debian Linux distro on the brick, see EV3Dev, a Debian Linux for Lego Mindstorms EV3.  BrickLink was originally a site for third party resellers of new and used Lego sets and elements. The site was purchased by the Lego Group a few years ago. It's still a great place to buy individual parts - for example a 4 port PoweredUp hub to run the new PyBricks on :-) ReBrickable is a site dedicated to taking off-the-shelf Lego sets, and creating something new with the set. In particular see the MOCs Designed by LUCAMOCS, fantastic Technic vehicles as well as interesting designs for vehicle subsystems. Yoshihito ISOGAWA - YouTube is an absolute genius at coming up with practical applications of new LEGO Elements. Ralph recommends his books as “awesome to read”. LEGO uses 18 Cucumbers to build real Log House  Ralph highly recommends Test Driven Development for Embedded C  by James Grenning (who has been on the show: 270: Broccoli is Good Too, 109: Resurrection of Extreme Programming, and 30: Eventually Lightning Strikes). Origami Simulator and Elecia's origami generating python code on github Transcript Nordic Semiconductor empowers wireless innovation, by providing hardware, software, tools and services that allow developers to create the IoT products of tomorrow. Learn more about Nordic Semiconductor at nordicsemi.com, check out the DevAcademy at academy.nordicsemi.com and interact with the Nordic Devzone community at devzone.nordicsemi.com.

In this episode, Dave and Jamison answer these questions: There aren't a lot of engineering management growth resources in my company. It's a relatively small company with about 50 engineers. My manager doesn't have time to properly mentor me. And I'm not sure I would want him to because I feel like his advice isn't always the best. Where can I go for management mentorship or other learning resources? Is it worth exploring non-engineering managers on other teams? Or leaning more on my peers? Or should I be looking for outside advice? A recent episode mentioned awkward Zoom silences. My experience is the exact opposite. I recently switched teams at the same company. This new team has a Zoom room open for the entire work day. The first person to start their day begins the Zoom and the last to leave ends the meeting. They do “mob programming” using a command line tool that switches users every few minutes along with all the strict rules of Extreme Programming - a driver, navigator, etc. But they also do everything in groups: story refinement, diagrams, documentation, everything. Live collab, all day, every day. I'm one month into this transfer but worried that this isn't a good fit and that I made a horrible mistake. ALL the other engineers here rave about how this is the greatest thing ever. Am I the weirdo for not liking it? I feel like I am of split-mind to only either speak or type (but not both) and have not yet rediscovered my coding flow. Mostly I just wanted to roll a perception check with you: Am I the weirdo for not liking all this collaboration and 100% Zooming, or would this workflow drive most other engineers mad as well? Any pep talk about sticking it out would be appreciated.

Konstantin Ribel: Rebuilding Scrum Team Dynamics To Overcome Remote Work Anti-Patterns Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Konstantin recounts a team's struggle rooted in prioritizing individual tasks over collective effort. Daily meetings centered on status updates fostered a fragmented and siloed work environment. The team working remote made the issue even worse, making it hard to have face-to-face interaction and pair-working. All of these patterns resulted in underperformance. Konstantin advises regular team gatherings, emphasizing the importance of on-site collaboration. He underscores the human element, urging teams to function cohesively as people. Featured Book Of The Week: The Miracle Morning by Hal Erold In this segment, Konstantin delves into how his morning routine, inspired by "The Miracle Morning," by Hal Erold has profoundly influenced his role as a Scrum Master. He emphasizes the critical link between personal and professional development, crediting the book "Extreme Programming Explained" for its condensed wisdom. Konstantin highlights Kent Beck's mantra of "do more of what works" and expresses a preference for pair working, acknowledging its occasional impracticality. He consistently applies the insights gained from this book, advocating against the anti-pattern of delayed feedback in his work with teams.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Konstantin Ribel Konstantin drives organizational success through innovative thinking, simplifying processes, and building high-performing teams. With a strong track record in change management and process optimization, he leads agile transformations and applies systems thinking for adaptable, thriving businesses in dynamic industries. You can link with Konstantin Ribel on LinkedIn. 

Stephanie is engrossed in Kent Beck's Substack newsletter, which she appreciates for its "working thoughts" format. Unlike traditional media that undergo rigorous editing, Kent's content is more of a work-in-progress, focusing on thought processes and evolving ideas. Joël has been putting a lot of thought into various tools and techniques and realized that they all fall under one umbrella term: analysis. From there, Stephanie and Joël discuss all the productivity tricks they like to use in their daily workflows. Do you have some keyboard shortcuts you like? Are you an Alfred wizard? What are some tools or mindsets around productivity that make YOUR life better? Kent Beck's Substack Tidy First? (https://tidyfirst.substack.com/) Debugging: Listing Your Assumptions (https://thoughtbot.com/blog/debugging-listing-your-assumptions) Dash (https://kapeli.com/dash) Alfred (https://www.alfredapp.com/) Rectangle (https://rectangleapp.com/) Meeter (https://apps.apple.com/us/app/meeter-for-zoom-teams-co/id1510445899) Vim plugins (https://github.com/thoughtbot/dotfiles/blob/main/vimrc.bundles#L32-L50) from thoughtbot's dotfiles, including vim-projectionist () for alternate files Go To Spec VS Code plugin (https://marketplace.visualstudio.com/items?itemName=Lourenci.go-to-spec) Feedbin (https://feedbin.com/) Energy Makes Time by Mandy Brown (https://everythingchanges.us/blog/energy-makes-time/) Transcript: AD: Ruby developers, The Rocky Mountain Ruby Conference returns to Boulder, Colorado, on October 5th and 6th. Join us for two days of insightful talks from experienced Ruby developers and plenty of opportunities to connect with your Ruby community. But that's not all. Nestled on the edge of the breathtaking Rocky Mountains, Boulder is a haven for outdoor lovers of all stripes. Take a break from coding. Come learn and enjoy at the conference and explore the charm of Downtown Boulder: eclectic shops, first-class restaurants and bars, and incredible street art everywhere. Immerse yourself in the vibrant culture and the many microbrew pubs that Boulder has to offer. Grab your tickets now at rockymtnruby.dev and be a part of the 2023 Rocky Mountain Ruby Conference. That's rockymtnruby.dev, October 5th and 6th in Boulder. See you there. JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I have a new piece of content that I'm consuming lately. That is Kent Beck's Substack [chuckles], Kent Beck of Agile Manifesto and Extreme Programming notoriety. I have been really enjoying this trend of independent content creation in the newsletter format lately, and I subscribe to a lot of newsletters for things outside of work as well. I've been using an RSS feed to like, keep track of all of the dispatches I'm following in that way so that it also kind of keeps out of my inbox. And it's purely just for when I'm in an internet-reading kind of mood. But I subscribed to Kent's Substack. Most of his content is behind a subscription. And I've been really enjoying it because he treats it as a place for a lot of his working thoughts, kind of a space that he uses to explore topics that could be whole books. But he is still in the phase of kind of, like, thinking them through and, like, integrating, you know, different things he's learning, and acknowledging that, like, yeah, like, not all of these ideas are fully fleshed, but they are still worth publishing for people who might be interested in kind of his thought process or where his head is at. And I think that is really cool and very different from just, like, other types of content I consume, where there has been, like, a lot of, especially more traditional media, where there has been, like, more editing involved and a lot of time and effort to reach a final product. And I'm curious about this, like I mentioned, trend towards a little less polished and people just publishing things as they're working through them and acknowledging that the way they're thinking about things can change over time. JOËL: It sounds like this is kind of halfway between a book which has gone through a lot of editing and, you know, a tweet thread, which is pure stream of consciousness. STEPHANIE: Yeah, that's a really great insight, actually. And I think that might be my sweet spot in terms of things I enjoy consuming or reading because I like that room for change and that there is a bit of a, you know, community aspect to Substack where you can comment on posts. But, at least in my experience, has seemed, like, relatively healthy because it is, you know, you're kind of with a community of people who are at least invested or willing to pay [chuckles] for the content. So, there is some amount of good faith involved. His newsletter title itself it's called "Tidy First?" And so, that almost implies that it's, like, something he's still exploring or experimenting with, which I think is really cool. It's not like a I have discovered, like, the perfect way to do things, and, you know, you must always tidy first before you do your software development. He's kind of in the position of, this is what I think works, and this is my space for continuing to refine this idea. JOËL: I'm curious: are there any sort of articles that you've read or just thoughts in general that you've seen from Kent that are particularly impactful or memorable to you? STEPHANIE: Yeah. One I read today during my investment time is called Accountability in Software Development. And it was a very interesting take on the idea of accountability, not necessarily, like, when it's forced by others or external forces like a manager or, you know, your organization, but when it comes from yourself. And he describes it as a way to feel comfortable and confident in the work that he's doing and also building trust in himself and in his work but also in his teams. By being transparent and literally accounting for the things that he's doing and sharing them, communicating them publicly, that almost ends up diminishing any kind of, like, distrust, or shame, or any of those weird kind of squishy things that can happen when you hide those things or, like, hide what you're doing. It becomes a way to foster the good parts of working with other people but not in a necessarily like, resentful way or in a hierarchical way. I was really interested in the idea of accountability, ultimately, like, for yourself, and then that ends up just propagating to the team. JOËL: That's a really interesting topic because I think it sort of sits at the intersection of the personal and the technical. STEPHANIE: Yeah, absolutely. He mentions more technical strategies or tasks that kind of do the same thing. You know, he mentions test-driven development, as well as, like, a way of holding yourself accountable to writing software that, you know, doesn't have bugs in it. So, I think that it can be applied to, you know, exactly both of those, like, interpersonal stuff and also technical aspects too, anyway, that's what's new in my world. Joël, what about you? JOËL: So, this year, I've been putting a lot of thought into a variety of tools and processes. And I think I've come to the realization that they all really fall under one kind of umbrella term, and that would be analysis. It's a common step in some definitions of the traditional software development lifecycle. And it's where you try to after you've kind of gathered the requirements, try to break them down and understand what exactly that means from a technical perspective, what needs to happen. And so, a lot of the things that have been really fascinating to me this year have been different techniques that I can use to become better at that sort of phase. STEPHANIE: Wow. That's very powerful, I think. And honestly, the first thing that comes to mind is, how do you make time for it? JOËL: I think we all do it to a certain extent. You know, you pick up a ticket, and there is a prose description of some work to be done, hopefully not telling you directly, like, just go make a change to this class, but here's a business problem to be solved. And then you have to sort of figure out how to break it down. So, this can be as simple as, oh, what objects, what classes do I need to introduce for this change? But it might be more subtle in terms of thinking, okay, well, what are the edge cases I need to think about? Where are things that could fail, and how am I going to handle failure? So, there's a variety of techniques that you can use to get better at all of these. You can use them kind of at the micro level when thinking about just a ticket. You can use them when working on a larger epic, a larger initiative, a whole project because I think analysis fits into kind of all of these levels. And so, I think those are the techniques that have been most exciting to me this year and that have really connected. STEPHANIE: That is very exciting. It's triggering a lot of thoughts for me about how I incorporate analysis into my work and how that has actually evolved; where I think before, earlier in my career, I assumed that the analysis had been done by someone else who knew better than me or who knew more than me. And that by the time that you know, a piece of work kind of landed in my lap, I was like, okay, well, I just want to know what to do, right? Like, I want someone else to tell me what to do [laughs]. But now I think I have taken it upon myself to do more of that and, like, have realized that it's part of my role. And sometimes it will now be kind of a flag or, like, a signal to me when that hasn't been done. And I can tell when I receive a ticket, and it's, like, maybe missing the business problem or doesn't have enough information. And determining whether that is information that I need to go and find out, or if there's someone else who I can work together with to do that analysis with, or having a better understanding of, like, what is within my realm of analysis to do, and what I need to encourage other people to do analysis for before the work is ready for me. JOËL: I think there is an interesting distinction between more traditional requirements gathering and analysis, where traditional requirements gathering is getting all that business problem information from product people, from customers, things like that. The analysis step is often a little bit more about breaking down a business problem into, like, what are the technical ramifications of that? But there can be a little of a synergy there where sometimes, once you start exploring the technical side of it, it might bring up a lot of edge cases that have impacts on the product side, on the business side. And then you have to go back to the businesspeople and say, "Hey, we only talked about sort of the happy path. What happens if payment is declined? What do we want to do there?" And now we're back in sort of that requirements gathering phase a little bit more rather than purely analysis. But it can come out of an analysis phase where you've done maybe some state machine diagramming to try to better understand how things flow from one phase to another. Or maybe you were building out a truth table for some complex logic and realized, wait a minute, there's an edge case I didn't handle. It's not a strictly linear process. The two kind of feed into each other and, honestly, into the implementation side as well. STEPHANIE: Yeah, I'm with you there. I'm thinking about a piece of work that I've been working on, where we were thinking of doing a database migration and adding some new columns to a table. But the more I dug into it, the more I realized that that was the first idea or the immediate idea that came from a need that I had limited information about. And what was nice was I was able to sit on it for a little bit, get some input from others. And I realized that there were all of these things that I couldn't answer yet. And someone, I think literally asked in a code review if you've already done this analysis, between knowing that these columns will be the kind of extent of what you need versus, you know, will the data end up needing more columns? And should the data model be a little more flexible to that potential change? And they said, "If you had already done this analysis, then, like, otherwise, it looks good to me." And I was like, "Oh, I didn't." [laughs] And that encouraged me to go back to some cross-functional members of the team and ask more questions. And that has taken more time. That was another challenge that I had to encounter was saying like, "Yeah, we started this, and we made some progress. But actually, we need to revisit a few things, like a few parts of the premise, before continuing on." JOËL: Are there any techniques or approaches that you particularly enjoy when it comes to doing an analysis or that maybe are go-to's for you? STEPHANIE: Reminding myself to revisit my assumptions [laughs], or at least even starting by being really clear about what I'm assuming, right? Because I think that has to happen first before you can even revisit them is having an awareness of what assumptions you're making. And I actually think this is where collaboration has been really helpful, where I've been working on this task with another developer on my team. And when we've been talking about it, I found myself saying, "Oh, I'm assuming this," right? Or, like, I'm assuming that the stakeholder knows what they need [laughs]. And that's why we're going to do it this way, where we were kind of given the pieces of data that we should be persisting. And the more that we had that conversation, the more I realized, like, actually, like, I'm not convinced that they have that full picture of, like, what they need in the future. And because we're making this decision now, like, we are turning, you know, literally from, like, the abstract into, like, a concrete change [chuckles] in the database, now seems like...now that we're faced with that decision, it seems like a good time to revisit the assumption that I was making. And that has proved helpful in making ultimately, like, a more informed decision about, like, which way to go technically. But I personally have found a lot of value in verbally processing it with someone else. It's a lot harder for me to identify them, I think, when I'm in my own head. JOËL: That's really interesting that you keyed in on the idea of assumptions. I typically think of assumptions being, like, so important mostly in debugging rather than analysis. In fact, I wrote a whole blog post about why listing your assumptions is so important as part of your debugging process. Now, like, my mind is spinning a little bit. I'm like, oh, I wonder if I could use some of those, like, debugging techniques as part of more of my analysis step. And could that make me better? So, I think you've put me on a whole, like, thought track of, like, oh, how many of these debugging techniques can I use to make my analysis better? So, that's really cool. STEPHANIE: Yeah, and vice versa. So, a few minutes ago, I'd asked you how you make time for that analysis. Because I was thinking that, you know, in my day-to-day work, I'm juggling so many things. I often find myself running out of time and not able to do all of it. And that, I think, leads us really well into our topic for this episode, which is productivity tricks and ways that we make the most use out of our limited time. JOËL: I think I may have a maybe a bit of a controversial opinion on productivity tricks. I feel like a lot of productivity tricks don't actually make me that much faster. Like, maybe I save a couple of minutes a day, maybe 5 or 10 a day with productivity tricks. And, sure, that adds up over the course of a year. But there are other things I could do in terms of, like, maybe better habits, better managing of my schedule that probably have a much more significant impact. Where I think they are incredibly valuable, though, is not directly making me better with my time management but managing my focus, allowing me to kind of keep in the flow and get things done without getting sidetracked. Or just kind of giving me the things that I need in the moment that I need them so that I'm not getting on to a subtask that I don't really need to be doing. STEPHANIE: Yeah. I really like that reframing of what helps you focus because as I was brainstorming ways that I stay on track for my work, I think I ended up discovering a similar theme where it wasn't so much, like, little snippets and tools for me, as opposed to how I structure all of the noise, I guess, in my day-to-day work and being able to see what it is that I need to care about the most right now. JOËL: I think one of the things that I've tried to do for myself is to make it easy to have access to the information and the tools that I need. Probably one of the most useful bits of that is a combination of the documentation viewer Dash and the...I'm not sure what it would be called– launcher, productivity manager tool for Mac. Alfred, with a CMD + Space, it brings up this bar I can type into. And then you can trigger all sorts of things from there. And so I can type the name of a language or some kind of keyword that I have set up and the name of a method. And then, all of a sudden, it'll show me everything like, you know, top five results. And I can hit Enter, and it will bring up the documentation for that. So, if I want to say, oh yeah, what is the order of the arguments for Enumerable's inject method (which I constantly forget)? You know, it's a few keyboard shortcuts, you know, CMD + Space Ruby Enumerable inject. It's fuzzy finding, so I probably don't even need to type all of that. Hit Enter, and I have the documentation right in front of me. So, that makes it so that I can get access to that with very little amount of context shifting. STEPHANIE: Yeah. I like what you said about how the tools are really helping you, like, narrow down, like, the views of, like, what is most important for you in that moment, and it's doing a little bit of that work for you. I think the couple of tools and apps that I actually did want to share are kind of similar. One MacOS app I really like is called Rectangle for windows management, which is really crucial for me because I don't enjoy like, swiping and tabbing between applications. I would much prefer just seeing, usually, just two things. I try to keep my screen limited to two different windows at once because once it gets more than that, I'm already just, like, overwhelmed [laughs]. And as I'm trying to focus a little bit more on just having, like, one thing be the focus of my attention at a time, Rectangle has been really nice in just really quickly being able to do my windows resizing. So, I usually have, like, either things split between my screen half and half. Like, right now, I have your face on my screen as we record this podcast, and then my notes editing software for taking notes about what we talk about. During my development workflow, it's usually, you know, just my editor, my terminal, and then maybe my browser ends up being, like, the thing that I tab into. But I'm able to just, like, set that all up, and as I need those windows to change depending on what my focus has been shifted to, to kind of make more space for whatever I'm reading, or looking at, or processing visually. The keyboard shortcuts that Rectangle...that I have now, you know, ingrained into my fingers [laughs] has been really helpful. It's like, I'm not fussing with just, like, too many things open. JOËL: I have yet to, like, dive into a window manager. I'm still in the clunky world of CMD tabbing. But maybe I should give that a try. STEPHANIE: For me, it has helped even just, like, identify the things that I need to give more space to on my screen and aggressively, like, cut everything else [laughs]. So, that's a really great MacOS app. And then, the other one is actually kind of a similar vein. It's called Meeter, M-E-E-T-E-R. And it has been really helpful for managing my meetings, especially my video call meetings where the video call software that's being used for the meeting may be variable. And also, when I have multiple email addresses that meetings are being sent to, you're able to sign into all of your calendar accounts. And it provides a really nice view of all of your meetings. It has a really, like, minimal, I guess, design in your toolbar, where it shows you how many minutes until your next meeting. And from that toolbar button, you can click to go to the video conferencing software directly for whatever meeting is up next. And you don't have to, you know, scramble to open Google Meet, or Zoom, or Webex, or whatever it is. And that's [chuckles] been nice, again, just kind of, like, cutting down on the amount of stuff that I need to remember and shift through to get to my destination. JOËL: I think I'm hearing kind of two themes emerge out of some of the things that we've shared. And I'd like to maybe explore them a little bit; one is the power of keyboard shortcuts. And I think that's maybe what a lot of us think of when we think of productivity apps, at least developers, right? We love keyboard shortcuts. And then, secondly, I think I'm hearing automation, right? So, you don't have to go through and, like, find that email or calendar link to find the Zoom link or whatever. It shows up in your toolbar. So, maybe we can dig into a little bit of the idea of keyboard shortcuts. Are you a person who like customizes a lot of keyboard shortcuts? And is that a part of your kind of productivity setup? STEPHANIE: Well, a while ago, we had talked about not keyboard shortcuts in the context of productivity, but I think I had mentioned that I was trying to use my mouse less [chuckles] because I was getting a little bit of wrist pain. And I think that actually has rolled into a little bit of, you know, just, like, more efficient navigation on my computer. I think my keyboard shortcut usage is mostly around window management, like I mentioned. I do feel like I have, like, a medium amount of efficiency in my editor. Sometimes, when I'm pairing with other people who use Vim, I'm, like, shook by how fast they're moving. And I have figured out what works for me in VS Code, and I don't think I need to get any faster. You know, I've just accepted that [laughs]. In fact, it's almost, like, the amount of speed and friction that I have, in my experience, is actually a little more beneficial for the speed that my mind works [laughs]. It kind of helps me slow down when I need to think about what I'm doing as opposed to just, like, being able to, like, do anything at my fingertips, and kind of my brain is just not able to think that fast. And then navigating Slack, which is where I also spend a lot of my time on my computer. Now, using Slack with my keyboard shortcuts has been really helpful because, again, I'm not, like, mindlessly browsing or clicking around. I'm just looking at my unread messages. One non-keyboard shortcut I really like with Slack is Command + K, which is the jump-to feature. And so, I'm using that to go to a specific channel that I know I'm looking for or my own personal DMs, where I keep a lot of notes as well. And, honestly, I think that's, like, the extent of my keyboard shortcut usage. I'm curious what your setup is in regards to that, though. JOËL: I think I'm similar to you in that I have not kind of maxed out the productivity around keyboard shortcuts. You'd mentioned the jump to in Slack. Several pieces of software have something kind of like that. It might be some sort of omnibar, or a command palette, or something like that, where you really just need to know...CMD + K, or CMD + P, CTRL + P are common ones. Then you can sort of, like, type a few characters to just describe the thing you want to do, or a search you want to make, or something like that. Just knowing that one keyboard shortcut for your one piece of software gets you, I don't know, 80% of the productivity that you want. It's kind of amazing. I love the idea of an omnibar. STEPHANIE: Yeah, I hadn't heard of omnibar as a phrase before, but that feels very accurate. I like that a lot, too, where it's, like, oftentimes, I don't do whatever particular thing enough necessarily for it to justify a keyboard shortcut, for me at least. I'm still able to be fast enough to get to, like I said, that final destination or the action that I want to take with a more universal shortcut like that. JOËL: In my editor...so I use Vim, and I got used to Vim's keyboard-based navigation. And that is something that I deeply appreciate, maybe not so much for speed but being able to almost kind of feel one with the machine. And the cursor moves around, and I don't have to, like, think about moving it. It's really a magical sort of feeling. And it's become so much muscle memory now that I can just sort of...the cursor jumps around, things change out. And I'm not, like, constantly thinking about it to the point where now, if I'm in any other editor, I really want to get those shortcuts or, I guess, maybe not shortcuts but a Vim-style navigation, keyboard-based navigation. STEPHANIE: Yeah, it sounds like it's not so much the time savings but the power that you have or the control that you have over your tools. JOËL: Yes. And I think, again, the idea of focus. Navigation has stopped becoming a thing where I have to actively think about it. And I feel like I really do just sort of think my fingers are on the keyboard. I'm not having to, like, do a physical motion where I switch my hands. Like, I'm typing, and I'm writing code, then I have to switch my hand away to a mouse to shift around or, like, move my hand off the home row to, like, find the arrow keys and, like, move around. I just kind of think, and the cursor jumps up. It's great. Maybe I'd be the same if I'd put a lot of time into getting really good at, you know, maybe arrow-based navigation. I still think the mouse you have to move your hand off. It breaks just in the tiniest little way the flow. So, for me, I really appreciate being fully keyboard-based when I'm writing code. STEPHANIE: Right. Being one with the keyboard. As you were talking about that, I very viscerally felt, you know, when you encounter a new piece of technology, and you're trying to navigate it for the first time, and you're like, wow, like, that takes so much mental overhead that it's, you know, just completely disruptive to the goal that you're trying to achieve with the software itself. JOËL: Yeah, it is a steep learning curve. So, we've talked about custom keyboard shortcuts in the editor. But it's common for people to augment their editor with plugins, maybe even some kind of, like, snippet manager to maybe expand snippets or to paste common pieces in. Is that something that you've done in your editor setup? I think you said you use VS Code as your sort of daily editor. STEPHANIE: Yeah, that's right. I actually think I almost forgot about some of my little bits of automation because they are just so spelled for me [laughs] that I don't have to think about them. But you prompting me just now reminded me that there are a few that I'd like to shut out. Snippets-wise, I mostly use them for when I'm writing tests and just having the it blocks or the context blocks expand out for me so I don't have to do any of that typing of the setup there. And since I do use a terminal outside of my editor...I know that some people really like kind of having that integrated and being able to run tests even faster without having to switch to a different application, but I like having them separate. There is a really great plugin called Go to Spec where you can be in any, you know, application code file, and it will pull up the spec file for you. I've been really enjoying that, and that is what helps my test writing be a little more automated, even though I'm having it in separate applications. JOËL: That is really useful. So, as a Vim user, I also have a plugin that does something similar, where I can switch to what's considered the alternate for a particular file, which is typically the spec, or if I'm in the spec, it'll switch to the source file that the spec is testing. STEPHANIE: And then, I do have one really silly one, which is that I got so sick and tired of not remembering how to, you know, type the symbols for string interpolation in Ruby that has also become a snippet where the hash key and the [inaudible 28:48] brackets can [laughs] populate it for me. JOËL: I love it. So, Stephanie, I'd like to go back to something you were talking about earlier in the show. When you were sharing about what was new in your world and, you mentioned that you subscribe to the Substack and that you subscribe to, actually, a lot of newsletters, and you said something that really caught my attention. You were saying that you don't want these all cluttering up your email inbox. And instead, you send all of these to an RSS reader application. What kind of application do you like to use? STEPHANIE: I use Feedbin for this. And I actually think that this was recommended by Chris Toomey back in the day on a previous Bike Shed episode before you and I hosted the show. But that has been really awesome. It has a just, like, randomly generated email address you can use when you sign up for newsletters. You use that instead. And I really like having that distinction because I honestly treat my email inbox as a bit of a to-do list, where I am archiving or deleting a lot of stuff. And then the things that remain in my inbox are things that I need to either respond to, or do, or get back to in some way. And then yeah, when I've completed it, then that's when I archive or delete. But now that we do have all this great content back in email form, I needed a separate space for that, where I similarly kind of treat it as, like, a to-read list. And yeah, like, I look at my unreads in the newsletter RSS reader that I'm using and go through that when I'm in a blog-reading kind of mood. JOËL: I really like that separation because I'm kind of like you. I treat my inbox as a to-do list. And it's hard to have newsletters come in and, like, I'm not ready to read them. But I don't want them in my to-do, or, like, they'll just kind of sit there and get mixed in and maybe, like, filtered down to the bottom. So, having that explicit separation to say, hey, here's the place I go to when I am in a reading mood, then I can read things. I think there's also I've sort of trained myself to only check my email during certain times. So, for example, I will not check my work email outside of working hours. But if I'm on the subway going somewhere and I've got some time where I could do some reading, it would probably be a good thing to be going through some kind of newsletter or something like that. So, I either have to remember to go back to it, or what I tend to do is just scroll Twitter and hope that someone has shared that link, and then I read it there, which is not a particularly effective way of doing things. So, I might try the RSS feed reader tool. What was it called? STEPHANIE: Feedbin. JOËL: Feedbin. All right, I might try to get into that. STEPHANIE: Yeah, I look forward to hearing if that ends up working for you because I agree, having the two separate spaces has been really helpful because I don't want to get distracted by my email/to-do list inbox if I'm just wanting to do a bit of reading, enjoy some content. So, one more theme around productivity that I don't think we've quite mentioned yet, but maybe we've talked a little bit around, is the idea that it's, at least for me, it's a product of time and energy. So, even if you have all the time in the world, you know, you can just stare into space or, like, stare at a line of code and not get [laughs] anything done. JOËL: I know the feeling. STEPHANIE: Right? I am kind of curious how or if you have any techniques for managing that aspect. When your focus is low like, how can you kind of get that back so that you can get back to doing your tasks or getting what you need to do done? JOËL: If I have the time, taking a break is a really powerful thing, particularly taking a break and doing something physical. So, if I can go outside and take a walk around the block, that's really helpful. And if I need a shorter thing that can be done in, like, five minutes or something, I have a pull-up bar set up in my place. So, I'll just go up and do a few sets there and get a little bit of the heart rate slightly up, do a little bit of blood pumping. And that sometimes can help reset a little bit. STEPHANIE: Nice. Yes, I'm all for doing something else [chuckles]. Even when you know that this is a priority or is kind of urgent or whatever, but you just can't get yourself to do it, I've found that asking myself the question, "What would make this task easier for me right now?" has been helpful during those moments. And, for me, that might be grabbing a friend, like, maybe I'm blocked because I'm really just unmotivated. But having someone along can kind of inject some of that energy for me. And then, there's a really great blog post by a woman named Mandy Brown. It's called Energy Makes Time. And she talks about how doing the things that fill our cup, actually, you know, even though it seems like how could we possibly have time to be creative, or, like you said, maybe do something physical, those seem, like, lower on the priority list. But when you kind of get to the point where you just feel so overwhelmed and can't do anything else, and you just go do those things that you know feel good for you, you kind of come back with a renewed perspective on your to-do list. And you can see, like, what things actually aren't that critical and can be taken off. Or you just find that you have the capacity or the energy to get the things that you are really dreading out of the way. So, that has been really helpful when I just am feeling blocked. Instead of, like, feeling bad about how unproductive [chuckles] I'm being, I take that as a sign of an opportunity to do something else that might set me up for success later. JOËL: Yeah. I think oftentimes, it's easy to think of productivity in terms of, like, how can I maybe eliminate some tasks that are not high value through clever automation, or keyboard shortcuts, or things like that? But oftentimes, it can be more about just sort of managing your focus, managing your energy. And by doing that, you might have a much higher impact on both how productive you feel—because that's an important thing as well, in terms of motivation—and, you know, how productive you actually are at getting things done. STEPHANIE: Right. At least for me, like, not all TDM is bad and needs to be automated away, but, like, my ability to, like, handle it in the moment. Whereas yeah, sometimes maybe I've just run the same few lines that should be just a script [chuckles], that should just be, you know, one command, enough times that I'm like, oh, like, I can't even do this anymore because of just, like, other things going on. But other times, like, it's really not a big deal for me to just, you know, run a few extra commands. And, like, that is perfectly fine. JOËL: I love writing a good Vim macro. Yeah. So, it's important to think beyond just the fun tools and the code that we can write. Kind of think a little bit more at that energy and that mental level. That said, there are a ton of great tools out there. We've named-dropped a bunch of them in this episode. For our listeners who are wondering or who weren't, like, necessarily taking notes, we've linked all of them in the show notes: bikeshed.fm. You can find them there. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

In this captivating episode, host Gunesh Patil sits down with Lisa Crispin, a renowned author and influential figure in Agile testing, for an exploration of her remarkable journey in software testing, and a deep dive into the ever-evolving world of Agile methodologies. The podcast begins with a trip down memory lane as Lisa recounts her early days in customer support during the 1980s. She shares vivid anecdotes of dealing with irate customers on the other end of the line, takes us back to a time when software was deployed via tapes, and she sent fixes via mail. The technology landscape of the era, including Wang OS, DB2, SQL, PCs, Xerox Star, Apple Lisa, and Next, provides a colorful backdrop to her journey. As the conversation shifts gears, Lisa offers insights into the evolution of Agile methodologies, reflecting on Agile then and now. She shares experiences from the world of Extreme Programming and notes how, contrary to popular belief, customers didn't always crave frequent changes. Lisa unveils what she considers the secret ingredient of Agile: releasing small, frequent chunks of software. She suggests that the fifth Agile value should be "Joy." The discussion touches on the magic of Agile Testing Mindset and the pursuit of joy within teams. Listeners gain valuable insights into biases, including confirmation bias, and how these biases can affect teams and lead to catastrophic results. Lisa underscores the importance of diverse teams in covering all bases and minimizing biases. Prepare to be inspired and enlightened as Lisa Crispin shares her incredible journey and offers valuable wisdom on Agile methodologies, testing mindset, biases, and decision-making in this thought-provoking episode. Whether you're a seasoned professional or an aspiring tester, this conversation promises to broaden your horizons and spark your curiosity. This episode is sponsored By ShiftSync, a Tricentis Community. It is a community for anyone interested in all aspects of quality engineering, from left to right across the software development spectrum. Join here https://bit.ly/LT-SS-Reg-Podcast  ➥ Telegram Channel Follow on: Apple | Google | Amazon | Spotify | Gaana | JioSaavn 

“The goal is not Agile. The goal is not DevOps. The goal is not Cloud. The goal is value, time to value, safety, happiness, and quality." Jonathan Smart and Simon Rohrer are the co-authors of “Sooner Safer Happier”. In this episode, Jon and Simon shared how we can deliver better outcomes in a more humane way of working, by delivering better value sooner, safer, and happier. They shared several principles, patterns, and anti-patterns described in the book, such as focusing on outcomes, the leadership as team number one, intelligent flow, creating alignment, and having the ability to unlearn and relearn.   Listen out for: Career Journey - [00:03:41] The Age of Digital - [00:06:29] Patterns & Anti-Patterns - [00:11:15] Better Value Sooner Safer Happier (BVSSH) - [00:13:18] Focus on Outcomes - [00:17:06] Empower the How - [00:19:28] Role of Leadership - [00:23:30] Leadership Team is Team #1 - [00:26:41] Intelligent Flow - [00:31:28] Stop Starting, Start Finishing - [00:34:43] Building Alignment - [00:36:48] Limited Velocity to Unlearn and Relearn - [00:40:10] 4 Tech Lead Wisdom - [00:43:41] _____ Jonathan Smart's BioJonathan Smart is co-founder and CEO of Sooner Safer Happier, a thought leader and a coach. He has been an agile and lean practitioner since the early 1990s and the lead author of the award winning and bestselling ‘Sooner Safer Happier: Patterns and Antipatterns for Business Agility'. He is also the founder of the Enterprise Agility Leaders Network, a member of the Programming Committee for the DevOps Enterprise Summit, a member of the Business Agility Institute Advisory Council, a guest speaker at London Business School, and speaks at numerous conferences a year. Simon Rohrer's BioSimon Rohrer has been a hands on practitioner across both software engineering and enterprise architecture for over twenty-six years, and has had a passion for agile software development since picking up the eXtreme Programming white book in 1999. He's passionate about an eclectic and pragmatic approach to modern ways of working, incorporating lean, agile, systems thinking, DevOps and other principles and practices at the right pace and in a human context in enterprises, typically with a legacy of existing technology and a drive to do things better. Follow Jonathan and Simon: Jonathan Smart's LinkedIn – linkedin.com/in/jonathansmart Simon Rohrer's LinkedIn – linkedin.com/in/simonrohrer Website – soonersaferhappier.com Slack – soonersaferhappier.com/community _____ Our Sponsors Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/144 Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

On today's episode, we discuss how organizations need to adapt or die.Angela Johnson is a “professional people geek” with over 25+ years of experience working with teams and leaders in both project management and Agile environments. As a Scrum Master, she found her passion in helping teams and leaders work together more effectively. In 2010, she founded Collaborative Leadership Team, offering Agile education and coaching services to start-ups, Fortune 100 and 500 companies. Angela's expertise extends beyond Scrum to include Kanban, eXtreme Programming, Facilitation, and Organizational Change. She is a Certified Scrum Trainer® and Certified LeSS Practitioner with a background in Communication and Management. Based in Minneapolis, Minnesota, Angela is a proud mom, wife, and teammate. Key Takeaways:Agile and Scrum methodologies were developed to address challenges in delivering value faster and reducing rework. They have become popular in the technology world for their ability to adapt to changing needs.Agile frameworks like Scrum promote transparency, making work visible and breaking down silos. This enhances communication, avoids misunderstandings, and minimizes wasted time and rework.Agile emphasizes breaking work into smaller, manageable chunks, allowing for faster feedback loops and early issue identification. This enables quicker value delivery and eliminates the need for lengthy development cycles.Agile and Scrum enable organizations to adapt quickly to market changes. By pivoting based on real-time feedback, organizations reduce the risk of delivering products or services that no longer meet market demands.Agile and Scrum value effective communication and collaboration, while still emphasizing the importance of documenting shared understanding and agreements.Agile is not a one-size-fits-all solution. It's important to assess whether Agile methodologies align with the specific business problem and context. Instead of blindly following Agile methods, organizations should identify their actual problem and goals, ensuring the chosen approach serves their purpose.Agile principles, such as transparency, iteration, and daily check-ins, can benefit various organizational contexts beyond software development, improving communication and efficiency.Limiting work in progress and prioritizing tasks effectively enhances productivity and value delivery, avoiding the scenario where everything is a priority, but nothing gets done effectively.Empowering teams and fostering shared knowledge leads to higher engagement and productivity. Cross-training and trust reduce dependency on individual expertise and prevent bottlenecks.Transparency and adaptability are crucial in times of change and challenge. By being transparent, exploring options, and adapting together, organizations can successfully navigate obstacles and ensure their survival and successTop 3 Takeaways:1. If everything is “priority”, nothing is. Pick one thing that's going to get you focused and you're going to see more productivity.2. Schedule more frequent check-ins. Be more transparent. 3. Team = we, not me. If you deem yourself an expert in something you should be able to teach. How to connect with Angela:Website: https://thescrummasterfiles.com/LinkedIn: https://www.linkedin.com/in/angelajohnsonscrumtrainer/

Guests: Logan Finch, Principal Engineer at Cromulence [@cromulencellc]On Linkedin | https://www.linkedin.com/in/logan-finch/On Twitter | https://twitter.com/hack_a_satJason Williams, Co-Founder and CEO of Cromulence [@cromulencellc]On Linkedin | https://www.linkedin.com/in/jason-williams-5858c3On Twitter | https://twitter.com/hack_a_satAaron Myrick, Project Leader at The Aerospace Corporation [@AerospaceCorp]On Linkedin | https://www.linkedin.com/in/aaron-myrick-677b8474/____________________________Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/sean-martin____________________________This Episode's SponsorsImperva | https://itspm.ag/imperva277117988Pentera | https://itspm.ag/penteri67a___________________________Episode NotesIn this episode of Redefining CyberSecurity with Sean Martin, Logan Finch, Jason Williams, Aaron Myrick discuss the history and evolution of the Hack-A-Sat program, which aims to bridge the gap between the cybersecurity and aerospace communities and showcase the capabilities of extreme programming and hacking to secure space systems. The Moonlighter CTF challenge is a key part of the program, which emulates real-world attacks on space systems, and the guests share insights on the different disciplines involved in securing space systems.This episode also explores the ethical considerations of hacking and cybersecurity, the importance of diversity in the space and cybersecurity industries, and the need for collaboration between the different communities to create a holistic approach to securing space and satellite systems. The group highlights the importance of a new mindset and approach to securing these systems, which are critical to our lives and the economy, and showcases the capabilities of the cybersecurity and aerospace communities.____________________________Watch this and other videos on ITSPmagazine's YouTube ChannelRedefining CyberSecurity Podcast with Sean Martin, CISSP playlist:

About Angela Johnson: Angela Johnson calls herself “professional people geek.” She is a Certified Scrum Trainer, Agile Guide and author of The Scrum Master Files, Secrets Every Coach should know.    She has 25+ years of experience working with teams and leaders in both project management and Agile environments. Angela started her career in technical support, quickly advancing to programming, database administration and project management. She realized that her passion was not in Gantt charts and status reports but in helping people work together more effectively within organizations. Becoming a Scrum Master enabled her to serve teams.    In 2010, she founded her company to bring Agile education and coaching services to a diverse group of start-ups, Fortune 100 and 500 companies. Angela identified that the best way to learn more about the highs and lows of Scrum adoptions was to immerse her own company into this way of working. In 2014 she renamed the company to Collaborative Leadership Team and began the same journey her clients were undertaking.   Collaborative Leadership Team uses Agile to manage the company and has the privilege of serving others in a variety of industries including: software, hardware, services, marketing and more. The breadth and depth of CoLeadTeam's experience extends beyond Scrum and includes Kanban, eXtreme Programming, Facilitation and Organizational Change for Business Agility.   Angela is a Certified Scrum Trainer®, and a Certified LeSS Practitioner. She holds a Masters of Business Communication from the University of St. Thomas. She believes her greatest roles are mom, wife and teammate.   In this episode, Jordan and Angela Johnson discuss: Problems that are universal to organizations  The relationship between autonomy and psychological safety  The four values of the Agile Manifesto  Practicing radical daily transparency   Key Takeaways: Scrum is all about not having somebody hierarchical above you telling you what to do and when to do it. It's a self-organizing self-managing team. A leader's job is to create alignment and make sure that everyone across the board is able to implement new strategies like scrum and agility.  In order to introduce autonomy and personal responsibility in an organization, the environment has to become psychologically safe and people are able to openly bring up problems that come to light.  Being agile is all about your organization's ability to pivot or adapt. Here are the four values of the Agile Manifesto: Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.  The key to cultivating an agile team is to practice daily radical transparency. For you to be agile, and be able to pivot in time to prevent a disaster or seize an opportunity, you've got to know where your organization is.  “The leader has to set the tone and be very clear - because people will make things up in the absence of clear direction. ” —  Angela Johnson   Connect with Angela Johnson:   Website: https://thescrummasterfiles.com/  LinkedIn: https://www.linkedin.com/in/angelajohnsonscrumtrainer/    Connect with Jordan:  For executives wanting a complimentary executive coaching conversation: jordan@jordangoldrich.com  Website: www.workplacewarriorinc.com Twitter: https://twitter.com/jordangoldrich1 Facebook: https://www.facebook.com/jordan.goldrich Instagram: https://www.instagram.com/jordangoldrich/ LinkedIn: https://www.linkedin.com/in/jgoldrich/

From a trainee reconversion program in the early 80s, Lisa took us on a fantastic testing journey. From discovering Agile before its time, living through highly collaborative Waterfall projects, to embracing XP and being one of the first to challenge the absence of "Testers" in the first installments of the method. Lisa spoke of how she came to write her first book, working with legends of our industry and kept being fascinated by quality.Here are the links from the showhttps://www.twitter.com/lisacrispinhttps://octodon.social/@lisacrispin@mastodon.socialhttps://www.linkedin.com/in/lisa-crispin-88420a/https://lisacrispin.com/https://leanpub.com/agiletesting-condensedhttps://agiletester.cahttps://agiletestingfellow.comCreditsCover Legends by HoliznaCC0 is licensed CC0 1.0 Universal License.Your host is Timothée (Tim) Bourguignon; more about him at timbourguignon.fr.Gift the podcast a rating on one of the significant platforms https://devjourney.info/subscribeSupport the show

Emmanuel placed the start his journey in the 80s in a computer club. He described how he learned GW-BASIC and became hooked. He told about his love for music and how his parents encouraged him to pursue "real studies." He explained how he went to the USA to study Computer Science, music, and Japanese... and became a theater composer. He discussed his first job as a programmer and being bored (and bad at it) until he discovered eXtremeProgramming. He talked about learning TDD, exploring what became Katas, and creating a coding dojo.  He spoke about finding psychotherapy, becoming a psychotherapist, and much more. This was a wild ride worth every minute.Here are the links from the showhttps://changer-grandir.org/https://mc-mallaret.fr/CreditsCover Legends by HoliznaCC0 is licensed CC0 1.0 Universal License.Your host is Timothée (Tim) Bourguignon; more about him at timbourguignon.fr.Gift the podcast a rating on one of the significant platforms https://devjourney.info/subscribeSupport the show

#5amMesterScrum Show 1,037 Live - Using bugs to get the team to work together, a neat little technique to get better quality and a little team work moving along the way (We Team Wednesday) - Today's topics: (1) Bugs are the perfect introduction place for XP or Extreme Programming on a small reasonable scale.  And we can use Priority and team norms to trigger the teaming activity. Please like and subscribe and share 5amMesterScrum.  Please send me your topics.   You are are doing Great Please Keep on Sharing. 5am Mester Scrum 5am Mester Scrum Show 1,037 went live on Youtube, LinkedIn and Facebook We Team Wednesday 6/7/2023 from Philadelphia, PA  Happy Scrumming, video version: https://youtube.com/live/KLLDNqVi4M0 Social Media: - search 5amMesterScrum or #5amMesterScrum  and you should find us and if not please let us know LinkedIn, Youtube, Facebook, Instagram, Twitter, TikTok     Podcasts: (search 5amMesterScrum)   

BONUS: From Scrum Master to Engineering Lead, how to prepare the transition with Tim Bourguignon We start this episode, reflecting on Tim's journey of realizing the importance of working collaboratively and embracing agile methodologies. Tim noticed early on that he drifted to teaching and providing assistance to others rather than actively developing software. After a while, he moved to consulting in Agile, and in that role, he noticed recurring patterns and struggled with unclogging processes that seemed to be missing something crucial. Over time, frustration set in. He felt like he was fighting an uphill battle and highlighted the disruptive nature of Agile, which aimed to uncover and solve problems but often revealed bigger and deeper underlying issues. The big problem with Agile adoption, and what we can do to prepare for it With time and experience, Tim realized that leadership was a crucial factor in the team's success. He observed a recurring pattern where leadership was either blocking progress or not fulfilling their role effectively. This realization led him to recognize the significance of leadership's involvement and the impact it had on the overall performance of the team.  From developer, to coach, and finally to leader: learning to help teams at all levels of the organization Tim shares his journey at WeMaintain and discusses the challenges of scaling while maintaining agility. Before joining, and during the interview process, Tim already sought to identify the problems he could help solve but couldn't pinpoint a specific issue. His boss expressed concerns about managing fast growth while staying agile. Initially, WeMaintain had two teams working efficiently from a backlog, releasing frequently, and measuring their progress. But, they wanted to grow the company without resorting to a traditional approach of multiple teams working on the same problem, which often led to communication issues. Instead, they advocated for compartmentalized teams with strong ownership and defined success metrics for each team based on specific business streams. Each team had the necessary skills and accountability to achieve their success metrics, ensuring a shared responsibility for success. From coach to leader, and the critical lessons learned on the way Tim reflects on the differences between his current approach and what he observed in the past, when he was the coach trying to help teams and organizations. He emphasizes the importance of taking personal responsibility as a leader when facing problems within a team. Previously, their clients would assume that the leaders were right and focused only on changing the teams, and he wanted to avoid that anti-pattern at all costs. Tim shares the tip of starting with leadership and establishing a clear vision, emphasizing the impact of lacking a clear vision and passionate individuals on the organization. When it comes to reflecting on our performance, Tim recommends evaluating oneself against the 12 principles of the Agile Manifesto and highlights the necessity of enabling developers to communicate directly with customers to foster agility. Scaling with Agility: Building Compartmentalized Teams and other strategies for growing companies, and staying Agile Tim's current focus is on stream-aligned teams and metrics. Tim recommends the book "Team Topologies", whose authors have been guests on the podcast. Tim also shares the tip of asking teams to create a portfolio of metrics that demonstrate they are working on the right things. Various teams have found interesting metrics to track their progress. The PDCA cycle and DORA (DevOps Readiness Assessment) metrics are mentioned. The guest highlights a positive sign of organizational health, with a rate of 1.5 deployments per day across the entire product group. They suggest having frequent discussions with people throughout the organization and implementing practices like showcasing Monday morning deliveries and sharing post-release messages on Slack as early documentation for stakeholders. The book "Accelerate" is also recommended for further insights into metrics. In this final segment, we also refer to Extreme Programming.

Get ready for an electrifying episode of DrunkenPM Radio as I welcome the esteemed James Grenning to unravel the world of Test Driven Development (TDD). Agile 2023 is just around the corner, and during the conference, James will be leading a workshop called "Your First Test-Driven Development." While TDD is not a new concept, it remains unfamiliar to many tech professionals who didn't come from a development background. That's precisely why I reached out to James and invited him to join me for this inspiring podcast. If you're immersed in Agile or managing technology projects, and TDD is still a mystery to you, this is a must-watch. TDD is a game-changer, and understanding it is crucial for your professional growth. I assure you that this episode will significantly impact your job in the best way possible. Now, let's talk about the best part of this podcast: our incredible guest, James Grenning. He personifies the epitome of old-school OG Agile Royalty. Not only is James one of the co-authors of the Agile Manifesto, but he also penned the definitive book on TDD. That's not all—James is the brilliant mind behind Planning Poker, a technique that has revolutionized Agile estimation. Stay tuned as we delve into this fascinating topic towards the end of our conversation. But wait, there's more! At the conclusion of our interview, James will unveil a remarkable system he designed and developed for his training classes. When off-the-shelf solutions fell short of meeting his requirements, James took matters into his own hands. His ingenuity and determination to deliver top-notch training are truly awe-inspiring. Don't miss out on this captivating podcast episode. James Grenning's wisdom and expertise will reshape the way you approach your work. Join me as we embark on a journey of discovery and empowerment with one of the brightest minds in the world of Test Driven Development. (This podcast was originally recorded using video. You can find that version here: https://youtu.be/k5OaxLCIzzI) James's Book Test Driven Development for Embedded C (Pragmatic Programmers): https://bit.ly/43CMsP0 James's session at Agile 2023 Your First Test-Driven Development at Agile 2023 https://events.agilealliance.org/Agile2023/session/1423798/your-first-test-driven-development-james-grenning Monday, July 24, 2023, 2:00 PM - 5:00 PM Lafayette 4 Contacting James Web: https://wingman-sw.com/about LinkedIn: https://www.linkedin.com/in/jwgrenning/ Twitter: https://twitter.com/jwgrenning Agile, Extreme Programming, XP, Scrum, TDD, Test Drive Development, James Grenning, Dave Prior, Reluctant Agilist, drunkenpm, Drunken PM Radio, Planning Poker, Estimation, Wingman-SW, Agile Development and Design Techniques,

Marjorie placed the start of her journey during her work as an agronomist when she wrote her first R lines of code. She explained how her childhood in southern France brought her to study plants, create a hydroponic startup, work on risk and project management, and slowly become interested in web development. We spoke of her Bootcamp and how she found her first job. We discussed eXtreme-Programming and Mob-Programming, and what it's like to be a newbie in a teaching environment.Here are the links from the showhttps://www.linkedin.com/in/marjorie-aubert-full-stack-developer/CreditsCover Legends by HoliznaCC0 is licensed CC0 1.0 Universal License.Your host is Timothée (Tim) Bourguignon; more about him at timbourguignon.fr.Gift the podcast a rating on one of the significant platforms https://devjourney.info/subscribeSupport the show

CEO of Industrial Logic, author of Joy of Agility Episode page with video, links, transcript and more Joining us for Episode #475 of the Lean Blog Interviews Podcast is Joshua Kerievsky, the founder and CEO of Industrial Logic, one of the oldest and most well-respected agile consultancies on the planet.  Since 1996, Joshua and his global network of colleagues have helped people in teams across many industries leverage the wisdom and power of modern product development methods. An early pioneer and practitioner of Extreme Programming, Lean Software Development and Lean Startup, Joshua most recently crafted “Modern Agile” to help people and organizations benefit from a principle-based approach to agility. Joshua is passionate about helping people produce awesome outcomes via genuine agility. He is an international speaker and author of books including most recently, Joy of Agility: How to Solve Problems and Succeed Sooner. In today's episode, we discuss how “agility” doesn't strictly mean “Agile” in software. How was Joshua inspired by leaders including former Alcoa CEO Paul O'Neill? What can all kinds of organizations learn about the art of evaluating experiments in ways that lead to more improvement and greater innovation? Questions, Notes, and Highlights: What's your “origin story” when it comes to these methods? Agile is an adjective… “ready ability to move with quick, easy, grace” — resourceful and adaptable It's not just about speed, but also quality? Do you recall when you were first introduced to “Lean” — was it via “Lean Startup” early days? The Industrial Logic name? “Process” sounds bad? Why is that? Toyota – enabling bureaucracy vs. limiting bureaucracy SAFE experiments Paul O'Neill admiration – safety  2012 The Power of Habit book What does safety mean in software? The risk of mistakes — expensive $$ decision… small tests of change??? The art of evaluating experiments? Keep going? Pivot or persevere? For those who don't know, what's “agile” vs. what you describe as “agility”? This is NOT a book about software development Driving out fear like Deming? The podcast is sponsored by Stiles Associates, now in its 30th year of business. They are the go-to Lean recruiting firm serving the manufacturing, private equity, and healthcare industries. Learn more. This podcast is part of the #LeanCommunicators network. 

Join Brian and his guests, Janet Gregory, and Lisa Crispin, as they share their expertise on integrating testing into Agile teams. Discover how to bridge the gap between programmers and testers for collaboration and success. Overview In this episode of the "Agile Mentors," Brian Milner sits down with Janet Gregory and Lisa Crispin, founders of Agile Testing Fellowship, to discuss integrating testing into Agile teams. They discuss the history of the divide between programmers and testers and the importance of collaboration and communication between the two groups. Listen in as they explore the different levels of holistic testing, the mindset shift needed for bug prevention, and the tools and strategies for planning and estimating testing activities. Plus, the role of AI in testing. Listen Now to Discover: [00:05] - Brian Milner introduces the guests for this episode, Janet Gregory and Lisa Crispin, who are advocates for integrating testing into Agile teams and the Founders of Agile Testing Fellowship. [02:25] - Lisa explains the most important goal for collaboration and success. [03:34] - Janet talks about the history of the gulf between programmers and testers. [05:09] - How to bridge the gap between programmers and testers and the value of collaboration. [07:29] - What the values of Agile and Extreme Programming emphasize. [09:49] - The mindset shift needed for bug prevention. [11:17] - Managers behaving badly—Brian shares a story about how measuring the wrong things can drive the wrong behaviors. [12:13] Brian discusses the micro view of testing instead of a system view. [12:17] How to handle intense forms of testing that take a long time to complete. [14:02] Janet explains the different levels of testing and that teams should determine where testing belongs based on when it can be performed earliest. [15:23] Avoiding a "hardening sprint." [16:48] Lisa shares how to use visual models like the agile testing quadrants and the holistic testing model to help plan and communicate the testing activities needed throughout the software development lifecycle. [17:25] The website where you can find the training written by Lisa and Janet, including “More Agile Testing” and “Agile Testing Condensed” (recently released), and where you can download the FREE Mini-book "Holistic Testing: Weave Quality into your Product." [18:29] - Brian introduces the sponsor for the podcast, Mountain Goat Software. If you are thinking about getting certified as a Scrum Master, check out the resources and training options where certification classes are available every week. [19:26] - The key to fitting testing into a normal sprint cycle and integrating testing with other system pieces. [20:52] - Janet shares a tip for ensuring testing is not overlooked. [20:59] - Lisa shares how to remind teams to do testing at the right time. [22:31] - Why have a visible reminder for testing? [23:54] - The importance of accounting for testing and not treating it as a separate thing to do. [24:37] - Lisa shares her experience using planning poker for estimation and her preference to get every story the same size so they can be completed in a day or two. [25:50] - Janet suggests sizing stories and estimating tasks, why she estimates her tasks herself, and what she’s learned in that process. [26:44] -How to reduce the time needed in estimation meetings: Lisa shares some insight to identify when a story is too big and needs to be split up. [27:35] - The importance of conversation and understanding to avoid creating a wall between programmers and testers during estimation. [28:03] - Another tool in the toolbox: how Chat GPT will revolutionize testing (and who it might replace). [29:01] - There will never be enough time to do all the testing required. [29:31] - Lisa highlights how AI as a tool saves time with testing and allows more time for critical thinking skills. [30:12] - The need for a human presence in the use of AI. [31:19] - Janet shares information about her and Lisa's two courses, Basic Strategies for Agile Teams and Holistic Testing for Continuous Delivery, based on the Holistic testing model of looking at testing activities throughout the software development lifecycle. These courses can be found here. [36:37] Lisa mentions that her book, “Assessing Agile Quality Practices” helps teams identify where they are and where they can improve, using a framework that looks at ten different quality aspects. Plus, information on the book they are working on now on how to facilitate an assessment. [39:03] - Brian provides a list of resources available from Lisa and Janet, including their books “Agile Testing Condensed: A Brief Introduction” “Agile Testing,” “More Agile Testing,” and Assessing Agile Quality Practices and their "Holistic Testing: Weave Quality into Your Product” free download. [40:14] - Join the Agile Mentors Community to continue the discussion. If you have topics for future episodes, email us by clicking here. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode. References and resources mentioned in the show: Agile Testing Fellowship Agile Testing - The Book Agile Testing Condensed: A Brief Introduction More Agile Testing Holistic Testing: Weave Quality into Your Product Assessing Agile Quality Practices Mountain Good Software's Advanced Certified Product Owner course Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lisa Crispin is the Co-founder of the Agile Testing Fellowship, an author, and an Agile tester and coach, who helps practitioners deliver quality software frequently and sustainably. Janet Gregory is the Co-founder of the Agile Testing Fellowship, an author, and a consultant, specializing in building quality systems and helping companies promote agile quality processes.

Johannes Lindman: Lessons in Communication and Trust for Scrum Masters, helping teams overcome adversity Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Johannes Lindman shares a story about a small team he worked with for a few months leading up to a major release. The team was focused on delivery and even had checklists to ensure that they were well-prepared. However, they encountered a problem that they had not anticipated and had to stop and acknowledge their failure. The team was surprised because they believed they had prepared well and were not sure how they missed the issue. The team started to point fingers and look at one person who did not talk much. They realized that they were not talking about the problems they were afraid of and needed to be super honest with each other. Johannes notes that the team trusted each other as individuals, but they did not pick up on each other's signs. In the end, the team learned the importance of communication, honesty, and trust. They realized that they needed to work on their communication skills and ensure that everyone felt comfortable speaking up when there was an issue. Featured Book of the Week: Extreme Programming Explained by Kent Beck In this segment, Johannes shares the impact that the book "Extreme Programming Explained" by Kent Beck had on his career. Johannes explains that the book helped him in many ways, and he found so many valuable ideas in it. He recalls the mantra  "make it work, make it right, make it fast," which he believes summarizes the essence of the book's philosophy. He credits the book with helping him to become a better developer and to embrace a growth mindset.  [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!   About Johannes Lindman Despite many years of experience Johannes still learns new things every day in order to stay relevant. This aligns with his curiosity on life and people.  You can link with Johannes Lindman on LinkedIn.

Johannes Lindman: Failing Safely, Tips for Successfully Implementing Extreme Programming in a Team Environment Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this podcast episode, Johannes shares his experience with extreme programming and test-driven development. Johannes recounts his experience working with a team where he assumed a lot of things about their needs and desires. He quickly realized that his eagerness to bring his own value to the table was getting in the way of the team's success. Johannes learned that it is essential to listen and watch the team and to ensure that they are asking for help rather than assuming that he knew what they needed. He advises that it is essential to slow down, be humble, and not be pushy. Johannes also shares several tips for helping teams to fail safely, turning up the volume on transparency, and showing small failures. He notes that it is important to reflect on what is happening and to determine if the possible failure is catastrophic or not. If it is not catastrophic, then it is best to let it go and be patient for the right moment.  [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company. About Johannes Lindman Despite many years of experience Johannes still learns new things every day in order to stay relevant. This aligns with his curiosity on life and people.  You can link with Johannes Lindman on LinkedIn.

En este episodio hablamos de agile, empezando por sus fundamentos: el manifiesto ágil.Textos RecomendadosNivel BasicoRobert C Martin “Clean Agile”. Es una muy buena introducción centrado en los desarrolladores y solo en la gestión de proyecto. El foco esta en Extreme Programming y es una lectura fácil. Recomiendo el Audio Book.Jeff Shutherland “Scrum: The Art of Doing Twice the Work in Half the Time”. De el creador de Scrum es un libro básico sobre el proceso SCRUM. Es de muy fácil lectura pero no cubre agile solo Scrum. Recomiendo el Audio BookNivel IntermedioSi ya [tienes los fundamentos de agile, y no me refiero al proceso, si no a los conceptos interiorizados:Geoff Watts “Scrum Mastery” Explicación más detallada de lo que un Scrum Master puede hacer para ayudar a su equipo ir más allá.Geoff Watts “Product Mastery” Lo mismo que el anterior pero centrado en el rol de Product Manager.Nivel AvanzadoLyssa Adkins “Coaching Agile Teams”. Una obra maestra para aquellos que quieran ir más allá. Es denso y con muchos matices que una persona nueva en el campo difícilmente comprendería.Referencias del episodioEventos de la comunidad de MongoDB

Transcript: Joe Krebs 0:20 Today I'm here with Staffan Noeteberg, who is the author of two books that is mono tasking that was released in 2020. And a little bit earlier, Pomodoro technique illustrated, I believe it was in 2011 that was forwarded by the one of the creators of the Pomodoro Technique, Francesco Cirillo and Henrik Kniberg. So what we have here with Staffan is a person that is very well connected with the Agile community as well as it is super interesting topic of mono tasking, what we want to talk about today, he's an Agile coach. He lives in Stockholm, Sweden, as well as in Istanbul, Turkey. If I'm informed here correctly, he has trained 1000s of people on improving their personal productivity. He has sold over 700,000 copies of his book. I'm super thrilled to have you on the podcast. Thank you for being here.Staffan Nöteberg 1:22 Thank you for having me. Joe Krebs 1:23 Yeah, this is this is awesome. We want to talk today really about mono tasking, that is that is obviously your latest book. And we want to connect a few dots because this could be super interesting for everybody listening to this podcast today from two angles. One of them is individually improving productivity as a as a person you know, in everyday life situations as well as professionally at work. But also how we can connect mono tasking maybe to agile teams and agile roles, maybe we can touch on that as well. So I think these are the two angles we want to explore here a little bit today. Mono as part of that title, if I go back in times and I'm like just thinking about audio mono was something that I would now relate with something negative right mono is like it's simple and and everything we're like all thinking about stereo at this point Dolby Stereo. Using mono in terms of tasking is something for the future. What is mono tasking, Staffan? Joe Krebs 2:30 It is interested that you mentioned that mono mono is something negative, because I think that the in job ads maybe 10 years ago, 20 years ago, there were often the demand for people that were they were looking for property property that said you you can juggle many balls at the same time, that's where our, that's what we're looking for. And nowadays, maybe they say you should be able to finish something to complete something. And that's and in order to do that maybe you shouldn't stop so many things and all these Kanban things that has been popular now for 20 years in software industry is very much about this stop starting and start finishing. So weekly meats and things like that, but I mean the mono tasking method then came out I wrote this Pomodoro technique book which is a personal productivity method. It's a particular concern about focusing on focusing. So, how do you really focus but I wanted to see this broader and I read many many personal productivity books and I think most of them almost everyone or almost none of them consider complexity and cohesion. I will explain what I mean by cohesion they like these books are often create order these books this these methods these processes are often made by engineers people like like you and me programmers or software engineers and the idea in them is often to like keep a list or multiple lists of in like in shipshape and Bristol fashion, you say ship ship in Bristol fashion in the US, or is that a British idiom?Joe Krebs 3:36 Which one is that?Staffan Nöteberg 4:28 Ship shape and Bristol fashion is one of my favorite idioms. We are doing everything under control and everything. We need to add the unit at the link in the show notes. Joe Krebs 4:51 We will definitely be in the data link for that. Yes.Staffan Nöteberg 4:53 Yeah. So so the idea of most personal productivity method is to have a lot of lists and they should be be perfect all the time. And they should contain a lot of ideas, everything that you you plan to do and why you're doing it. And so, and then there's the processes are often kind of, if else logic. So, if this happened to that, if that happened if this, but they are, I mean, that may work for you and me and other engineers, but for most people, it demands too much discipline. And it doesn't really accept that there are humans that are willing to use these methods, I wanted to create something that is more creative and more suitable for humans. So it's not like you're a silo, and you are fed from the top with the new tasks, and you work on them, and you complete them and just throw them out. Because there is some cohesion, you have your co-workers and, your teammates, and you have your stakeholders, your your product managers, you have your customers, and all these people, they change the mind, sometimes sometimes they say they want something. But they changed, they changed the mind, or they didn't explain it in a way that you understood, really started to do something else. So it's not really only about taking it as completing it. And doing that as fast as possible. And with the highest quality. It's more like you're putting in a big ecosystem. And you need to manage within that ecosystem. And I think that in that way, if you think of personal productivity in that way, it can be hard to have, like saying that you should do exactly like this, and exact like that maybe we should think more in arranging your environment and your circumstances, to have the best the best possibilities to succeed. So I started to read a lot of books and papers about what science says about human cognition, and evolutionary psychology and so on, I tried to create a method, which is little bit different from other methods that like embraces the human intuition and the human cognition and human heuristics, so that you don't have to maintain your there, you don't have to maintain all this list and doing all this documentation, and instead can use your intuition and in most cases, do the correct choices anyway, because we as humans are very good in this complexity, if we use our intuition to see what is most important than what what is not most important.Joe Krebs 7:52 Right? So it's interesting, right? So first and foremost, I'm thrilled to hear that I'm not the only one who experiences stakeholders changing their minds on things. So I'm kidding. Obviously, I think this is a, this is a huge problem in our, in our, you know, work in general, I think that's typical. But it's also fascinating what I've heard, I don't know if you would second that is that humans are pretty much incapable of multitasking. Right? So it's some basic things we can do. We can walk and talk at the same time, or I don't think that's going to cause a conflict. But we cannot work on two different kinds of systems at the same time, that causes a conflict, obviously. And that's where we're transitioning. So you're saying already with mono tasking, you're saying like, work with a reduced list of task, right? I believe you were mentioning something about like five shortlist or something like that, or like five items, or five tasks or something. And why is that? Why is why is the list? Short? We're not saying we're working on five items at the same time, right? We're just saying there's a list of five items. Where, Why? Why the number five? And why is it so short? Or why does the list exists? What What's your reasoning behind it? I'm just curious.Staffan Nöteberg 9:12 So you're right about multitasking that most people we cannot multitask if you don't have to pay attention to things like breathing and work at same time. But most people can't pay attention to more than one thing. And when we think that we are doing that, like we're listening to lecture and we're taking notes, were actually task switching. So we're switching back and forth. And when we're task switching, we make more errors, science shows and researchers and we're slower and we forget about good ideas. And in general, it's not the best way to complete things from what we learned in Lean, for example, when we're doing many things and so one one idea here in the book is our in this method is the shortlist as you mentioned, and the shortlist is like, in the morning, from the top of your head, write down five things on a paper on the piece of paper, instead of looking at your, you know, in, in my trainings, I am an exercise where we're asked people to, to, to write down every source of tasks that they have. And they think less about them and say, I have some things in my brain, I have something in my email inbox, I have some things in Trello. And I have some things in JIRA, I have some things on my refrigerator, and I have some post it's on my display. And there's a lot of sources of all these tasks. And then the next step is to look at all these and say, roughly how many tasks do I have in each of these. And usually, it aggregates to something between 80 and 200. So like, if you have 200 tasks there, if you have 100 tasks, it's impossible to make a prioritization to choose the best one because you can think about 100 tasks at the same time and see which one of these is most important right now. So instead, when you start morning, write down maximum five tasks on a piece of paper in front of you. Maximum five, and these are small tasks, so they should estimate them. If you estimate roughly you don't have to write down, it should not be things that takes more than two hours or something like that should be things that the tasks that take 10 minutes, two hours, some something in this, if they're bigger than YouTube, break something out and put them on on your list. And this is not the plan. It's not a competition or some kind of gamification, so that this is the sort of fight that I'm doing to complete today. It's more like moving away the tension of of gamification, instead of saying, These are my five candidates for my next, the one I'm going to pay attention to next, right, and then you don't have to think about anything else, all the other 100 tasks that you have promised someone or that you have thought about that you pressed you do. So because you have in front of you only these five, five is not magic, of course, but five is, is a number that usually we can look at five things and maybe compare them together. If it comes to 6, 7, 8, 9, then we have to make to look at some of them. So maybe you should have have have less than five, but not not more than five, I believe for most people. Yeah. And then then you pick one of these and say, I'm going to focus on this one. And you set an alarm, maybe to the next hour or something like that, to remind you to not stay too long, because maybe when you have worked with at one after an hour, you need to take a break or maybe you should reprioritize because he didn't believe that this was this was going to take this long time that that it took so you need some alarm to wake you up and then use your stop focus on on that that single task. And during the day if if something comes up, you get a new idea, either either you should write it down and put it somewhere else. Or you need to trade away something from your shortlist. You should never have more than five things on your on your shortlist. And this this many people try this and say it works for some people doesn't work but you need to you need to try yourself and be you know you we are different. So it might not be suitable for everyone.Joe Krebs 14:04 But I think you just answered my next question. I just want to clarify because that is the bridge to my next topic about agility here is so that the list is maximum five, right? Let's say this as a as a number here to work with, right? What would happen if like that stakeholder out there changes his mind and there would be a sixth item or a seventh item, because there is the risk that the list is going to grow. So you're saying like keep it at five, right? Something has to go from there. Yep. Just to keep it manageable,Staffan Nöteberg 14:35 maximum five, maybe have completed something so you'll have four three. Okay. And of course, these numbers are heuristics. You can use any number but it's good to put the limit and see how much but five is a good starting number. According to me at least.Joe Krebs 14:54 Yeah, there is also in your book. I don't I don't know the from the top of my head. Add, I don't know the exact details here right now. But you also have some advice on the time-boxing, right? How much time would be dedicated to these tasks. So let's say you're starting a task, let's say at 10.25am. In the morning, that timer would be set to 11 o'clock or something like that, right? So there's some some concrete advice at your book. But the time box is relatively manageable and short too right?. So it's short working increments before you take a break. Staffan Nöteberg 15:24 Yeah, a break or reprioritize, you looked at your shortlist again, and see, should I continue with this one? Or do that? One, do something else, maybe because I completed that one, or maybe something else became more prioritized. But you trust during that period that time box, your trust, your prioritization, I think that you shouldn't you distinguish between focusing and prioritizing. So when you have decided to focus, then you need to explore it. That and oh, and trust that you have chosen the right one, if something else comes up, write it down or, or something like that, but don't change your business idea. Every few minutes, just because something comes up.Joe Krebs 16:15 Yeah. Interesting. So so what I what I would like to touch on is and I think that is to connect with you have with the Pomodoro Technique, right, where it's also a time or is involved in time intervals. So time boxing, just in the Agile world, in general is a is a is a good strategy. Now, I do know that let's say in Scrum, the product backlog is not necessarily a list of tasks, why but it's just to see a container of things to be to be worked on eventually, but also the sprint backlog has has items in it. Let's say a product backlog very often has more than five items in it. How would you idea like map to like some some agile teams, you know missing? Some of those mono tasking techniques could be applied to a personal level? Is there anything we can do as a team is anything as an Agile team could do like a scrum team or a kanban team or somewhere that says like, we're gonna start introducing and mono tasking techniques to make us more productive, effective as a team. But also help us with the prioritization ordering effort as well, as you know, just like staying focus is is there any connect between those techniques?Staffan Nöteberg 17:33 I think so one thing is, of course, you can learn from my monitor skin that and then scale it to the team level and think what would that mean to do the same thing on the team level. But another thing is that what I talked about cohesion, so the team members are part of the same ecosystem as you are. And if you're a team, then you probably have a shared goal, you have the same goal. Otherwise, you're more like a group of people that have the same manager or something like that. But if your team you have the same goal, so So what what you're looking for, is to succeed with the school together. And if you're all skilled in this method, the monitors method, which which is a lot a lot of thing about how to progress and how to cooperate and how to treat stakeholders and recharging and so. But if you're all successful, I think you also responsible since you have a shared goal, to support each other, to help each other to be better at Mono tasking or whatever personal productivity method you're using. So you, as I said, we want to arrange an environment and circumstances so that we can be productive as individuals. But that also, since we have a shared do need that we need to create circumstances environment for teammates, so that they can be successful, then there are, of course, mob programming and pair programming, and then you're working together. But when we work individually, we need to help each other to work individually in a good way. Also, it's not not only that, I take care of my environment and my circumstances so that I can do mono tasking or Pomodoro, or GTD (Getting Things Done) or something else. It's also the issue to help other people with thatJoe Krebs 19:26 Yeah. So one thing I wanted to clarify and this is this is a great connect between the team and the individual and how this technique applies on different kinds of levels. I think that's great. There's obviously a lot to take away from teams have a very long laundry list of things to do, right? And just feel like they are not getting you know, like their time or they're not using their time necessarily wisely. That's what they're thinking and but they might not know like, what is the what's the missing thing and maybe it is something like that to really focus on on a few things. Now, here's something that I want to clarify this with you? If I read this, right, if I heard thi right, it's fascinating because, you know, way, way back when I was running, I did like cross country kind of running myself, there was always this thing of, if there was a hill, let's say, you would always try to run up the hill. And if you if you had to take a break, you know, for whatever reason, it was right on the top of the hill, not before the top of the hill, because you wanted to make sure it's easier to restart running again. So stopping at the hill was always like seeing something like very hard to restart running again, because you're already in the middle of a hill. But it was always when you're on the top of the hill was very easy for you to run. Now you're mono tasking is like by task. The second is don't finish the task at the end of the day. Because it makes it easier to start and transition into the next day. When I saw that, I was like thinking about that. I was like, that is very interesting. Tell me like how, because it's so opposite to how people think. Right? So it's like finishing a task before they go home. And let's say at the end of the day, and might put these 1015 minutes extra in, and then I would just want to finish my tasks, but you're saying mono tasking says don't finish it all by the end of the day? Because it makes it easier to start in the morning. Can you elaborate a little bit on this? Because I think that's great.Staffan Nöteberg 21:20 Yeah. So there was a researcher 100 years ago in Berlin called Bluma Zeigarnik. I think she came from Russia originally. But she worked in with psychology research in psychology in Berlin. She and her friends went to the coffee shops in Berlin. Every day and sister was psychologist, they had some psychology researchers that had a lot to talk about with each other. And so they stayed there for hours. And they ordered things and they discussed things and then they ordered more and discuss things. And after some hours, they call for the waiter and said, Hey, waiter can can we pay now. And then the waiter always knew exactly how much they had ordered, even though he didn't take any notes. And that was a little bit provocative to a group of psychologists, researchers. So they made an experiment one day. So they they sat there discussing ordering, discussing ordering, and they say hey, can we pay, and the waiter knew exactly how much they had ordered, and they paid. But then they stayed there for another 30 minutes, then the call for the waiter again. And when the waiter came there, they asked him, Hey, how much did we pay 30 minutes ago? And what do you think he answered?Joe Krebs 22:56 He didn't know.Staffan Nöteberg 22:58 He didn't know. He said, I've dropped out How could I know now. So he knew about it, as long as it was like an open Task to remember this. But as soon as, as they had paid it dropped it. So it didn't take in place in in his brain. And this was interesting, but this experiment is not very scientific, because it was only one person's very small sample. But Illuma went back to her office and made an experiment with, like, the first 150 people or something like that. And they got 20 tasks each small things like creating a clay finger or translating something from German, to to French, or, or something. And what it didn't know was a part of this experiment was that in 10, out of these 20, they were interrupted. So blue mark came there and said, Oh, I see you're working with task number six. Yeah, stop that and go on and work with task number seven. And afterwards, when when when they had finished everything. Bluma said like, can you write down now all the 20 tasks that you worked on on paper? And you know, if you have 20 things you have done, you won't remember all of them. So then she counted at the fact was that those that are interrupted in the remember twice as many of these compared to those that they had completed. So things that we haven't finished that we have started but we haven't finished demand room in our brain. But you can see in a positive way that we are still analyzing them and working on them and thinking about them. So if we end the day, usually, if you're commuting, and you think that before I go home, I need to complete this. And then I will take a bus or take my car or something home. But if you think in the other way, and think like, before I leave the office, I need to stop something, and leave in the middle I should have a read test if I'm a software engineer. So you stop something and you leave in the middle, then the next morning, you will be much eager to start with that one. And we knew about procrastination, that the hardest time that whatever we procrastinate, most is in the morning, if we can just stop procrastinating in the morning, then we will continue for the whole day because we have started something. So if instead stop something before we go home, then then we will be very eager to start with on that one. Immediately, when we come to the office usually will not tell this in trainings, someone raises their hand and say like, Hey, I'll try that. And if I do that, I can't sleep for the whole night because I have a problem. Of course, you shouldn't try it, you shouldn't do this. But for many people who are trying this, this is really helpful.Joe Krebs 26:19 Wow, this is this is cool that this is quite interesting that that person had sleep problems by trying this. Why? Because part of mono tasking is also you know, taking care of things like sleep and breaks and, and healthy living. Why? Why is that like part of money? It's an interesting, it's an interesting approach. It's so with all that research and science that goes into something like this. It's also like to do take breaks, and to purposely slow down. I don't know if that's exactly at those time limits of these tasks are describing but also to, to just to sleep, and have a healthy lifestyle that includes nutrition and everything. Why why is that so important? Staffan Nöteberg 27:05 so the method or the book is divided into six different areas where one is called recharge, creative thinking. So these sorts of things, the six things that I suggest that you should think about to be able to mono task, to be able to focus. And one of these students reached out creative thinking says, I mean, I'm not the expert of all the Healthy Living, I'm personally. But what I found, and I think most people agree on this is that if you are going to be the best version of yourself, if you are going to be the best due tomorrow, then you will have a much better probability or higher probability of being that if you have a healthier living, if you sleep the same hours every night, if you eat fruits and vegetables, if your exercise. And if you don't do that, it will be much harder to focus and focus on one thing.Joe Krebs 28:11 Yeah, that is that is also important for agile teams, where I would do very often I'm, you know, working with teams or organizations, but that is not part of the ritual, right? And for a variety of reasons, and sometimes it's just like, you know, what the things are in organizations, but it is an important piece to point out like we're humans, we're part of this, of, let's say, any kind of method and recharging is a key thing, right? How is something like that being incorporated into an into an Agile team, right? On an individual level? I think that's a great idea, and probably easier to do, right? Because it's me influencing my own thing, but how does it work on a team? We're not gonna say you guys go into sleeping chambers during the day and taking breaks or anything like that, but how would that look like on a on a team level?Staffan Nöteberg 29:04 I think first I want to say that it's not that you shouldn't be an Olympic athlete, it's more like, you can always be a bit better than than what you were yesterday. But I think in an Agile team, you know, in extreme programming, there's one of these best practices was first called 40 hours a week, and then it was changed to a sustainable pace. If I remember correctly, it was a long time ago, I read this book. I think it's part of this, it. Ultimately, it's a personal responsibility, of course, but as a team, you can create a culture where it's not cool to stay the whole night to fix some bugs or something like that. You need to have a sustainable base. As Kent Beck pointed out already, and if I think no, this is a credit card, that if you overcharge the credit card, you can buy something right now that you couldn't buy otherwise, but you will have to pay with interest in the long term and that that's the same for teams. I think that if they have a culture where they don't take care of the people in the team, when it comes to breaks, and weekends and other things, then they will have to pay with interest in the long term.Joe Krebs 30:33 Yeah. Yeah, no, definitely I agree. And that was part of Extreme Programming even before Agile Manifesto. So this is deeply, deeply rooted, sustainable pace and having you know, if there was an overtime in a sprint, or iteration that there wouldn't be one in the following. So there was some form of balancing going on your book itself, which is great. I like visuals in a book, right? You drew them yourself. Which is, which is also great to see those notes and supported by visuals. I just like to read books like this, I think it just reinforces but you also say in this mono tasking, it's better for teams to or individuals to write by hand. Notes in journaling, rather than on a laptop.Staffan Nöteberg 31:20 I think depends on what you're going to use use it for. If if writing something that you want to distribute to the that you want to save for a long time, it's much better right in a computer, of course. But if you want want your brain to digest things to analyze it, in, we learn from doing things not from listening, when we listen to something like your podcast, you might get inspired but if we don't do something about it, or think about it or discuss it with someone then we will have forgotten about it one week later. So there are a lot of research showing that if if you write down something in need to like, think and that's especially if if you draw something if you make a mind mapping more or try to try to think of it in in pictures, what does this mean all the diagrams connecting,Joe Krebs 32:25 sketchnoting, for example?Staffan Nöteberg 32:27 Yeah, exactly. Then you learn more it stays in your head because in the brain the memory in the brain is not like a structured database. It's not like SQL, it's more like many many fragments of associations. And when you have new you learn something new and when you hear something new, you need to connect it to some of these fragments and when you think about it more then maybe some door opens in there are some fried fragment comes up some other Association and you can connect your your new learning to that one. And if you have a discussion about something like something you hear in this podcast or something new you learn that you have written down or so then it's more much more likely that you will save it actually and have it connected to some some other Association Yeah. And as I understand it, it's not an issue that or memory is not big enough we can read would be it would be possible to know a lot more than anyone has known so far. And the problem is that we it's not structured in in the heads we need to it's a different thing than the computer database and we need to connect it so we can pick it up when it when it's suitable. Joe Krebs 34:00 Yeah very very interesting stuff and obviously the book is filled with lots of material like this a lot of individuals and teams might find useful applying in their in their day to day work. Did you write your book using mono tasking? Did you use some of those techniques like like you basically just you know took your method in your in your own writing.Staffan Nöteberg 34:24 I did exactly like that. But I'm saying that this doesn't mean that this is the best method for everyone. But I think that if you read something like this, a book like this, then you will learn a lot of things and maybe you can try some some of these and test them and maybe some some will suit you and some will not suit you but you will learn more about your own productivity.Joe Krebs 34:53 Absolutely. I also see coaches Scrum Masters leaders working within organizations increasing agility, he's taking some of the research you have put together in that book, and providing the evidence to really run some experiments within the organization. Right. So there's continuous improvement going on, within organizations, change management. And some of those concept could be, could be applied to any of these efforts and run some experiments on are they showing the same impact as they will do in an individual productivity improvement also on on other levels, so I think it's might give some food for thought for. For some, some employees in organizations listening to the answers, I'd take a piece of that and run an experiment and see how that goes to just like the task switching or preventing task switching, and possibly do take the breaks and things like that we discussed. We're not finishing a task by the end of the day, things we have discussed here in this podcast together and just like try some experiments, but again, the book has many, many more. You also mentioned in your in your book, someone I think there was a little side story, where somebody actually got a promotion probably not only because of that, but somebody got a promotion and one thing was that somebody started listening to podcasts in their transition time going from home to work. And using that transition time effectively somebody listened to podcasts and got a promotion out of it now I cannot guarantee by listening to Agile FM that you will be getting a promotion out of this thing but you might be listening to this in your car right now while driving so please drive safely. But transition time is also part of mono tasking and and to use that wisely could be having really really good benefits. So thank you Staffan for being my guest today and sharing your thoughts great thoughts on mono tasking here with me? But more importantly with all the listeners out there that possibly already or will be becoming interested in mono tasking. Thank you so much, Staffan.Staffan Nöteberg 37:02 Thanks, you it's been a pleasure to talk to you.Joe Krebs 37:06 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.

Angela Johnson is the author of “The Scrum Master Files: Secrets Every Coach Should Know.”  As a Certified Scrum Trainer (CST), Angela helps others successfully implement Scrum and Agile to achieve their goals and objectives. She has helped clients transform in the areas of: agency/services, software, hardware, marketing, learning and development and more. The breadth and depth of Angela's experience extends beyond Scrum and includes Kanban, eXtreme Programming, Facilitation and Organizational Change for business agility. She is a graduate of Hamline University (B.A.) and the University of St. Thomas (M.B.C.) Angela resides in Minnesota where she loves working virtually which allows her to serve in her most important roles of wife and mom. In this episode we discussed: Her journey from project manager to business owner and author Common sense success methods for working with teams Lessons she learned from her author experiences with both ghostwriting and self-publishing Why having purpose is important Connect with Angela Johnson at: Website: https://collaborativeleadershipteam.com/ LinkedIn: https://www.linkedin.com/in/angelajohnsonscrumtrainer/ Twitter: https://twitter.com/AgileAngela   Thank you for listening! Be sure to follow the show so you don't miss the next episode! You can connect with Dr. Robin on LinkedIn, Facebook or Instagram or contact me via email at: robin@purpose-based.com Go to: https://www.createmasterfulcourses.com to get her free training on "How to Turn Your Book into a MASTERFUL Course" Also, you can learn more about Leadership Purpose and her books at: https://www.robinlowens.com/ Talk to you soon! Episode edited by Podcast Manager - LJS Creative Services https://www.ljscreativeservices.co.nz

My guest for Episode #198 of the My Favorite Mistake podcast is Kevin Goldsmith, the chief technology officer at DistroKid, the world's largest distributor of digital music. ** I WANT TO WRITE MY BOOK (ad) ** Kevin is an experienced leader of high-profile, high-performing product, research, and shared technology engineering organizations. An often-invited speaker on building strong engineering teams at conferences internationally – often talking about learning from failure. Has extensive experience building products using Lean, Kanban, Scrum, and Extreme Programming methodologies. In this episode, Kevin tells his favorite mistake story about the launch of “Spotify Now” when he was an engineering leader at Spotify. Why was there pressure to launch? What mistake did Kevin and team make regarding data from a small group of initial users? How did Spotify leverage its culture of “handling failure well”? What did Kevin learn? Questions and Topics: How do you balance the cost of lost customers vs. the cost of embarrassment? Being surprised by the results of experiments Was Spotify Now a problem of a bad concept or bad execution? Or Bad design? Losing customers as “the cost of learning” Organizational learning to not get into this situation again? Doing retrospectives on EVERYTHING to remove the stigma? The Forbes article that Kevin was quoted in People who strongly believe in “accountability” — punishing failures — can you change their minds? Failure vs. mistake? — how would you compare those words? Tell us a little bit more about DistroKid – strengthening this culture of learning from mistakes? Video and Blog Post by Kevin: Fail Fast, Fail Smart… Succeed! by Kevin Goldsmith Blog post version of the story at Spotify Please follow, rate, and review via Apple Podcasts or Podchaser or your favorite app — that helps others find this content and you'll be sure to get future episodes as they are released weekly. You can also become a financial supporter of the show through Anchor.fm. You can now sign up to get new episodes via email, to make sure you don't miss an episode. This podcast is part of the Lean Communicators network. --- Support this podcast: https://anchor.fm/favorite-mistake/support

Key things discussed The connection between business agility and OKRs in private equity The role of OKRs in alignment and focus within an organization The principles shared by various frameworks such as OKRs, Scrum, and SAFe The importance of understanding and implementing frameworks effectively The benefits of dynamic team organization and shuffling based on OKRs The value of discussing outcomes rather than specifying outputs and having conversations about OKRs The dangers of chasing the next shiny thing without fully understanding and implementing it The connection between agile principles and OKR success The role of transparency, collaboration, and psychological safety in creating a successful environment for progress and continuous improvement The challenges and opportunities in improving work environments and creating meaningful progress in organizations. Show Notes [03:04] Yuval walks us through his background in IT and product development and begins using agile practices in his work. After moving to the US in 2015, he started consulting and coaching different types of organizations and began incorporating OKRs into his work with agile processes and helping organizations improve their use of OKRs. [04:33] Yuval walks us through his experience in private equity The role of OKRs and business agility in private equity The investment hypothesis How to apply agility to the process of finding the right way to reshape your go-to-market strategy [09:03] Yuval dives deep on when OKRs are not applicable [11:03] Yuval shares his insights and examples of best applications of OKRsOKRs are an alignment framework [12:43] A look at how Prezi, a presentation software, and their OKR-friendly way of managing the work in their organization [14:47] A look at the different frameworks (OKR, Scrum, SAFe) [16:03] The pitfalls of not getting the value or understanding the different frameworksHow organizations struggle to get value out of OKRs [19:41] High-level overview of Ron Jeffries and Scrum One of the three founders of the Extreme Programming software development and The Agile Manifesto Ron Jeffries' article: “We Tried Baseball and It Didn't Work” [20:35] What makes Scrum great? A relatively simple and lightweight framework that's really laser focused on achieving empiricism The structure of Scrum and how it can be used to develop the business How to create a rhythm of making progress in an environmental uncertainty with Scrum [28:06] Scrum became popular and spread quickly Many people using Scrum did not fully understand the principles and applied it with traditional project management approaches These people saw Scrum as a template rather than a continuous improvement process This led to the development of "Scrum Theater" or "Zombie Scrum" where people were just going through the motions of Scrum without fully understanding and implementing its principles When an approach becomes too popular, the knowledge about it becomes thinned out and there are more people who are just following it because it is popular, leading to more haters of the approach [33:31] Yuval discusses how OKRs should be used for goal alignment and focus on outcomes, in conjunction with evidence-based management. He stresses the importance of empiricism and empowering teams to achieve outcomes. [37:06] Yuval is discussing the concept of empowerment in agile processes and how it leads to better solutions and motivated employees. He emphasizes the importance of providing teams with the necessary knowledge and expertise and allowing them the autonomy to come up with and execute experiments within certain constraints. He also discusses the role of frequent feedback and access to leadership in empowering teams. [42:06] Jenny and Yuval are discussing how empowering teams to achieve a specific goal can lead to innovative solutions and improved business performance. The importance of empowering teams to achieve goals and the motivation and effectiveness of empowered teams The role of constraints in providing direction for teams while still allowing for flexibility and creativity The value of fast feedback loops and cross-functional collaboration in achieving outcomes The dangers of micromanaging and a lack of safety in communication The concept of "scheduled chicken" in which multiple groups work towards a deadline without being transparent about issues or challenges. The use of OKRs to align organizations around goals and focus on outcomes The benefits of using empiricism and focusing on outcomes rather than activities The concept of evidence-based management, which involves continuously evaluating progress and adjusting course as needed [46:25] Quick Fire Questions for Yuval: What's your Dream with a Deadline? Yuval's goal is to help organizations create environments that allow people to have an impact on work processes and to provide more case studies on this topic in the next few years. Can you share an example of a meaty strategy execution challenge, and how did they overcome it? Relevant links: Prezi's product development approach Ron Jeffries, one of the three founders of the Extreme Programming software development Fixing OKR Theater Using Agile/Scrum Principles Ron Jeffries' article on Scrum: “We Tried Baseball and It Didn't Work” Scrum.org Evidence-Based Management Guide Yuval Yeret's article on OKR Theater and OKRs in Name Only  Zombie Scrum, an article by Barry Overeem on Scrum.org "Fixing your OKRs”, an article by Yuval Yeret About Our Guest:Yuval Yeret is an expert on agile methodologies and OKRs, with experience in coaching and consulting a variety of organizations on their agility journey. With a background in IT and product development, he has helped businesses improve value and profitability through private equity deals and digital transformations.Follow Our Guest:Website | LinkedInFollow Dreams With Deadlines:Host | Company Website | Blog | Instagram | Twitter

Kevin started his story in the 80 & the 90s but quickly said, "Coding found me more than I found it." We then discussed his (very early) Bootcamp and how he went from one job to the next, slowly feeling less incompetent. We talked about ADHD, networking, people & organizational problems, and environment variables. We then dug our heels into eXtreme Programming and the Spine model: Needs, Values, Principles, Practices, and Tools, and how it helps us create better teams and organizations. Here are the links from the show:https://www.twitter.com/KevinTretheweyhttps://www.linkedin.com/in/kevinthttps://kevintrethewey.com/hypotheseshttps://explore.aihttps://spinemodel.infoTalk: "When creating software, what really matters?" @DevConf Johannesburg 2019 https://www.youtube.com/watch?v=IjLMtFE6MEEBook: XP Explained by Kent Beck https://amzn.to/3OYyZtaCreditsCover Heliotrope by Blue Dot Sessions is licensed CC BY-NC-ND 4.0.Your host is Timothée (Tim) Bourguignon, more about him at timbourguignon.fr.Gift the podcast a rating on one of the significant platforms https://devjourney.info/subscribeDev InterruptedWhat the smartest minds in engineering are thinking about, working on and investing in.Listen on: Apple Podcasts SpotifySupport the show

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The team Elly was working with had a very large number of items in progress (high WIP). This was also a result of the team being under a lot of pressure to deliver. The team was motivated to deliver, but was also feeling down because of the inability to deliver all they wanted, when they wanted. Elly started to help the team by understanding their context, and then trying to understand where the work was being held up. She started learning Value-Stream-Mapping, a technique that helped identify the bottlenecks, something she had learned about in the book The Goal by Goldratt. Through that research work, Elly found out some options to improve the flow of work for that team. Listen in to learn what those were, and what technique she used to help the team! In this segment, we talk about the concept of Shifting Left, and Extreme Programming. Featured Book of the Week: Nonviolent Communication by Rosenberger In Nonviolent Communication by Rosenberger, Elly found a book that helped her as a Scrum Master, but also in other aspects of her life. The book offers a model of communication that tries to focus on resolving conflicts, and helps us become more self-aware of how we communicate with others. In this segment, we also talk about the hand-brain model, and the two thinking/acting systems (System 1 and System 2) that Kahneman describes in the book Thinking Fast, Thinking Slow. How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta!   About Elly Griffith-Ward Elly is an Agile Coach at a major e-commerce company. Previously in user research (and a royal food historian). She aims to 1) improve the experience of work through reducing mental load, improving communication and forming strong teams 2) shift the focus from managing the worker to managing the work by focusing on flow and waste. You can link with Elly Griffith-Ward on LinkedIn and connect with Elly Griffith-Ward on Twitter.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Sometimes we face teams where team members start, and then get used to making decisions on their own without involving the rest of the team, or communicating those decisions to their colleagues. In this team, the people were changing, and the new team members were not “given” the right to speak, which led to the oldest team members making all of the decisions on their own. Mher noticed that this was causing a motivation problem in the team, and started to work with the team to overcome this anti-pattern.  Featured Book of the Week: Scrum, the art of doing twice the work in half the time by Sutherland In Scrum, the art of doing twice the work in half the time by Sutherland, Mher found a book that was easy to read and understand, which reminded him of what Agile, Scrum, and Extreme Programming are all about. The book includes stories and the “why” behind Scrum's impact.    How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta!   About Mher Nalbandyan Mher works at Mbition in Berlin, where they develop the next generation of information systems for Mercedes-Benz. You can link with Mher Nalbandyan on LinkedIn and connect with Mher Nalbandyan on Twitter.