Podcast appearances and mentions of Kent Beck

BONUS: Software Engineers are Paid to Solve Problems, Not Write Code! With John Crickett In this BONUS episode, we explore a thought-provoking LinkedIn post by John Crickett that challenges a fundamental misconception in software engineering. John shares insights on why engineers should focus on problem-solving rather than just coding, how to develop business context understanding, and why this shift in perspective is crucial in the age of AI. Beyond Writing Code: Understanding the True Value of Software Engineering "A lot of us come to software engineering because we care about building, and missed the goal: solving a problem for a customer." John Crickett explains the fundamental disconnect many software engineers experience in their careers. While many enter the field with a passion for building and coding, they often lose sight of the ultimate purpose: solving real problems for customers. This misalignment can lead to creating technically impressive solutions that fail to address actual business needs. John emphasizes that the most valuable engineers are those who can bridge the gap between technical implementation and business value. In this section, we refer to John's Coding Challenges and Developing Skills websites. The Isolation Problem in Engineering Teams "We have insulated people from seeing and interacting with customers, perhaps because we were afraid they would create a problem with customers." One of the key issues John identifies is how engineering teams are often deliberately separated from customers and end-users. This isolation, while sometimes implemented with good intentions, prevents engineers from gaining crucial context about the problems they're trying to solve. John shares his early career experience of participating in the sales process for software projects, which gave him valuable insights into customer needs. He highlights the Extreme Programming (XP) approach, which advocates for having the customer "in the room" to provide direct and immediate feedback, creating a tighter feedback loop between problem identification and solution implementation. In this segment, we refer to the book XP Explained by Kent Beck. The AI Replacement Risk "If all you are doing is taking a ticket that is fully spec'ed out, and coding it, then an LLM could also do that. The value is in understanding the problem." In a world where Large Language Models (LLMs) are increasingly capable of generating code, John warns that engineers who define themselves solely as coders face a significant risk of obsolescence. The true differentiation and value come from understanding the business domain and problem space—abilities that current AI tools haven't mastered. John advises engineers to develop domain knowledge specific to their business or customers, as this expertise allows them to contribute uniquely valuable insights beyond mere code implementation. Cultivating Business Context Understanding "Be curious about what the goal is behind the code you need to write. When people tell you to build, you need to be curious about why you are being asked to build that particular solution." John offers practical advice for engineers looking to develop better business context understanding. The key is cultivating genuine curiosity about the "why" behind coding tasks and features. By questioning requirements and understanding the business goals driving technical decisions, engineers can transform their role from merely delivering code to providing valuable services and solutions. This approach allows engineers to contribute more meaningfully and become partners in business success rather than just implementers. Building the Right Engineering Culture "Code is always a liability, sometimes it's an asset. The process starts with hiring the CTO—the people at the top. You get the team that reflects your values." Creating an engineering culture that values problem-solving over code production starts at the leadership level. John emphasizes that the values demonstrated by technical leadership will cascade throughout the organization. He notes the counter-intuitive truth that code itself is inherently a liability (requiring maintenance, updates, and potential refactoring), only becoming an asset when it effectively solves business problems. Building a team that understands this distinction begins with leadership that demonstrates curiosity about the business domain and encourages engineers to do the same. The Power of Asking Questions "Be curious, ask more questions." For engineers looking to make the shift from coder to problem-solver, John recommends developing the skill of asking good questions. He points to Harvard Business Review's article on "The Surprising Power of Questions" as a valuable resource. The ability to ask insightful questions about business needs, user requirements, and problem definitions allows engineers to uncover the true challenges beneath surface-level requirements. This curiosity-driven approach not only leads to better solutions but also positions engineers as valuable contributors to business strategy. In this segment, we refer to the article in HBR titled The Surprising Power of Questions. About John Crickett John is a passionate software engineer and leader on a mission to empower one million engineers and managers. With extensive expertise in distributed systems, full-stack development, and evolving tech stacks from C++ to Rust, John creates innovative coding challenges, insightful articles, and newsletters to help teams level up their skills. You can link with John Crickett on LinkedIn.

In episode 80 of o11ycast, Ken Rimple and Jessica Kerr chat with Kent Beck about the emerging world of AI-assisted coding. Beck shares his experiences with "augmented coding," discussing the benefits, challenges, and the evolving relationship between developers and AI agents. They explore how these tools are changing software development practices and what it means for the future of coding.

In episode 80 of o11ycast, Ken Rimple and Jessica Kerr chat with Kent Beck about the emerging world of AI-assisted coding. Beck shares his experiences with "augmented coding," discussing the benefits, challenges, and the evolving relationship between developers and AI agents. They explore how these tools are changing software development practices and what it means for the future of coding.

This week Carter and Nathan read Donella Meadows' Thinking in Systems. A foundational primer on systems thinking, the book explores how stocks, flows, feedback loops, and leverage points shape everything from ecosystems to organizations. Join them as they discuss how systems thinking applies to software engineering, the hidden structures behind burnout and tech debt, and how to make high-leverage changes in complex systems.-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Thinking in Systems by Donella H. Meadows https://amzn.to/4cMB35k (paid link)Tidy First?: A Personal Exercise in Empirical Software Design by Kent Beck https://amzn.to/3RoB9pR (paid link)Refactoring: Improving the Design of Existing Code by Martin Fowlerhttps://amzn.to/43Wqk5Q (paid link)Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neal Fordhttps://amzn.to/3Y7CNjk (paid link)One Nation Under Blackmail, Vol. 1: The Sordid Union Between Intelligence and Crime that Gave Rise to Jeffrey Epstein by Whitney Alyse Webbhttps://amzn.to/3RsMt4f (paid link)Slow Productivity: The Lost Art of Accomplishment Without Burnout by Cal Newporthttps://amzn.to/3EH8MAe (paid link)The Software Engineer's Guidebook: Navigating Senior, Tech Lead, and Staff Engineer Positions at Tech Companies and Startups by Gergely Oroszhttps://amzn.to/3ExwPSa (paid link)What Is ChatGPT Doing ... and Why Does It Work? by Stephen Wolfram https://amzn.to/4iuSUim (paid link)----------------00:00 Intro 01:41 About the Book03:43 Thoughts on the Book08:07 Covering the Foundations and Defining Terms16:36 Feedback loops22:31 Overconfidence and why models lead us astray.35:56 Paradigms and Framing49:30 Leverage Points01:02:04 Final 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

This week Carter and Nathan read the Kent Beck's The Good News Factory. A sequel to Tidy First?, The Good News Factory explores the economics of software and instructs tech executives on how to produce teams that are constantly delivering good news. Join them as they discuss balancing feature development and systems improvment, the economic incentives of software, and more!-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.--------------------------------------------------------------------------00:00 Intro12:23 About the Book14:08 Thoughts on the Book16:24 Features, Structure, Coupling, and Cohesion33:13 Responding to Organizational Changes42:12 3X: Explore, Expand, and Extract56:54 Final 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

Artificial intelligence is radically transforming software development. AI-assisted coding tools are generating billions in investment, promising faster development cycles, and shifting engineering roles from code authors to code editors. But how does this impact software quality, security, and team dynamics? How can product teams embrace AI without falling into the hype? In this episode, AI assisted Agile expert Mike Gehard shares his hands-on experiments with AI in software development. From his deep background at Pivotal Labs to his current work pushing the boundaries of AI-assisted coding, Mike reveals how AI tools can amplify quality practices, speed up prototyping, and even challenge the way we think about source code. He discusses the future of pair programming, the evolving role of test-driven development, and how engineers can better focus on delivering user value. Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Inside the episode... Mike's background at Pivotal Labs and why he kept returning How AI is changing the way we think about source code as a liability Why test-driven development still matters in an AI-assisted world The future of pair programming with AI copilots The importance of designing better software in an AI-driven development process Using AI to prototype faster and build user-facing value sooner Lessons learned from real-world experiments with AI-driven development The risks of AI-assisted software, from hallucinations to security Mentioned in this episode Mike's Substack: https://aiassistedagiledevelopment.substack.com/ Mike's Github repo: https://github.com/mikegehard/ai-assisted-agile-development Pivotal Labs: https://en.wikipedia.org/wiki/Pivotal_Labs 12-Factor Apps: https://12factor.net/  GitHub Copilot: https://github.com/features/copilot Cloud Foundry: https://en.wikipedia.org/wiki/Cloud_Foundry Lean Startup by Eric Ries: https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898 Refactoring by Martin Fowler and Kent Beck https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599 Dependabot: https://github.com/dependabot Tessl CEO Guy Podjarny's talk: https://youtu.be/e1a3WuxTY-k  Aider AI Pair programming terminal: https://aider.chat/ Gemini LLM: https://gemini.google.com/app Perplexity AI: https://www.perplexity.ai/ DeepSeek: https://www.deepseek.com/ Ian Cooper's talk on TDD: https://www.youtube.com/watch?v=IN9lftH0cJc Mike's newest Mountain Bike IBIS Ripmo V2S: https://www.ibiscycles.com/bikes/past-models/ripmo-v2s Mike's recommended house slippers: https://us.giesswein.com/collections/mens-wool-slippers/products/wool-slippers-dannheim Sorba Chattanooga Mountain Biking Trails: https://www.sorbachattanooga.org/localtrails Subscribe to the Convergence podcast wherever you get podcasts, including video episodes on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5-star review and like the podcast on YouTube. It's how we grow.

In this special episode of Book Overflow, Kent Beck joins Carter and Nathan to discuss his book Tidy First? Join them as Kent reflects on the artistry of programming design, the importance of optionality, and how the Time Value of Money applies to software engineering! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- Tidy First? https://amzn.to/4atHiKa (Paid Link) ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan'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

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.

Recorded on-stage at Øredev 2024, Fredrik talks to Kent Beck and Beth Andres-Beck about development practices, code reviews, and more. Unfortunately, sound quality is a lot worse than it should be. We apologize, and invite any sound processing wizards out there to get in touch if they have solid ways of improving it. Has there actually been a backlash - a move toward more rigid processes? And what can we do about that? The development process is a shadow cast by the power structure, and in big organizations, you need someone who's job it is to read all the documents. Also: improving code reviews, and how breaking the build can land you in a room with exactly the right people. Many thanks to Øredev for inviting Kodsnack again, they paid for the trip and the editing time of these keynote recordings, but have no say about the content of these or any other episodes. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlundand @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Øredev All the presentation videos from Øredev 2024 Kent Beth We're good at writing software - Kent and Beth's keynote Waterfall Cowboy coding Delightful code reviews - blog post by Beth, there doesn't seem to be a video to link to Beth's blog post about code reviews Kent's newsletter Support us on Ko-fi! Titles The waterfall's coming back Cowboy teams How to critique effectively A lot easier to manage All the way to the forest All I had to do was break the build

Recorded on-stage at Øredev 2024, Fredrik talks to IT security expert David Jacoby about his way into IT security. What was it like to get interested in computer security early on, and to try start working with it before there really was an awareness of even the need for more security information? And when did the switch happen from annoying but harmless viruses and malware to the modern information stealing and blackmailing? Finally, a horror movie tip. Many thanks to Øredev for inviting Kodsnack again, they paid for the trip and the editing time of these keynote recordings, but have no say about the content of these or any other episodes. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Øredev All the presentation videos from Øredev 2024 David Why do cyberattacks persist? Unmasking the hidden vulnerabilities in digital transformation - David’s keynote doesn’t seem to be out in video form yet Kent Beck Beth Andres-Beck Kent and Beth’s keynote BBS Sanne Femling - on the program committe for Øredev 2024 Outpost24 - where David was employee #1 PCI DSS - payment card industry data security standard DORA - digital operational resilience act Junkie - the MS-DOS virus. “Like a few other viruses by that time, it caused more panic than any actual damage.” Ransomware The police trojan Tucker & Dale vs. evil Support us on Ko-fi! Titles BBS systems and common acquaintances Don’t talk about the keynote Do some hacking on stage For you, I’ll do it 30 years as an ethical hacker Somehow cheat the system A cat and mouse game Still way behind

Recorded on-stage at Øredev 2024, Fredrik talks to Kent Beck and Beth Andres-Beck about development practices, code reviews, and more. Unfortunately, sound quality is a lot worse than it should be. We apologize, and invite any sound processing wizards out there to get in touch if they have solid ways of improving it. Has there actually been a backlash - a move toward more rigid processes? And what can we do about that? The development process is a shadow cast by the power structure, and in big organizations, you need someone who’s job it is to read all the documents. Also: improving code reviews, and how breaking the build can land you in a room with exactly the right people. Many thanks to Øredev for inviting Kodsnack again, they paid for the trip and the editing time of these keynote recordings, but have no say about the content of these or any other episodes. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Øredev All the presentation videos from Øredev 2024 Kent Beth We’re good at writing software - Kent and Beth’s keynote Waterfall Cowboy coding Delightful code reviews - blog post by Beth, there doesn’t seem to be a video to link to Beth’s blog post about code reviews Kent’s newsletter Support us on Ko-fi! Titles The waterfall’s coming back Cowboy teams How to critique effectively A lot easier to manage All the way to the forest All I had to do was break the build

How do we actually organize people to consistently deliver value and enjoy the process? This, Eric Bowman (CTO @ King) says, is the core challenge facing any CTO. In this thought-provoking episode, Eric shares insights from his remarkable career in gaming (The Sims, King), e-commerce (Zalando), and navigation technology (TomTom), offering a unique perspective on building high-performing teams and effective tech organizations. Listen in to explore:

In this episode of Book Overflow, Carter and Nathan discuss Tidy First? by Kent Beck. Join them as they discuss when you should prioritize tidying your code over feature improvements, what tidying means, and the Beck's thoughts on software and the time value of money! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- Tidy First?: A Personal Exercise in Empirical Software Design by Kent Beck https://amzn.to/40uOEtL (paid link) Refactoring: Improving the Design of Existing Code (2nd Edition) by Martin Fowler https://amzn.to/3C9d5mq (paid link) Building Evolutionary Architectures: Automated Software Governance by Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage https://amzn.to/4fmoIVC (paid link) A Philosophy of Software Design, 2nd Edition by John Ousterhout https://amzn.to/4ecmYgv (paid link) The Practice of Programming by Brian Kernighan, Rob Pike https://amzn.to/4fuMP4b (paid link) ---------------- 00:00 Intro 03:14 About the Book 05:41 Thoughts on the Book 11:17 Techniques and Approaches for Tidying (Part 1) 36:20 How to prioritize and manage tidying tasks (Part 2) 47:30 Optionality, Reversibility and The Philosophy of Tidying (Part 3) 01:05:38 Final Thoughts ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan'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

In this episode of the Design. Build. Hunt. Podcast, Josh talks with his client Kent Beck from NC to discuss his habitat management journey and how it all paid off with an opening day velvet buck.  Have a topic you want us to explore in future episodes? Reach out and let us know! To learn more, check us out online at whitetailpartners.com, on YouTube, on Instagram, or on Facebook. Find the Whitetail Partners Habitat Consultant for your region here. Learn more about Whitetail Partners Design and Management services here. 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.

"Software design is about human relationships."Cette citation de Kent Beck incarne à merveille les convictions de notre invité Nicolas Ruffel. Pour cet épisode, c'est Jean-Fabien, Directeur de Kaïbee Lyon, qui prend le micro et le relais de Pierre, et démarre ainsi un cycle pour mettre en lumière les talents de l'IT lyonnais.Jean-Fabien a eu le grand plaisir d'interviewer Nicolas donc, Responsable R&D de Tennaxia et coach d'équipes, mais surtout un des fers de lance de la qualité logicielle et plus spécifiquement du software craftsmanship à Lyon.La table des matières est appétissante :Un peu d'histoire pour démarrer, celle de la qualité logicielle : pour constater qu'il y a 25 ans tout était déjà écrit ou presque, et que si elle a évidemment à voir avec la technique, la qualité logicielle est peut-être avant tout affaire de rapports humains là aussi.Un peu de philosophie et de science ensuite, avec Edgar Morin et la pensée complexe, pouvant venir en aide aux managers façonnés depuis leurs études par la pensée linéaire et la recherche de solutions.Et finalement surtout il sera question d'aventure humaine, parce qu'une entreprise, c'est d'abord et avant tout une aventure humaine ! Plus précisément comment Nicolas met les personnes et leurs interactions, au cœur de la qualité logicielle. Un peu de teasing ici : peut-on concilier aventure humaine avec le fait de ne jamais se voir ?Et malgré tout ça, on a trouvé encore un peu de place pour échanger sur ce qu'on peut mettre en place pour développer, diffuser et maintenir une culture de la qualité logicielle en entreprise. Belle écoute !

 Andy discusses the importance of iteration and feedback in the development process. He emphasizes the difference between iteration and incremental progress, sharing a story from Kent Beck's 'Extreme Programming Explained' to illustrate the concept. Mon-Chaio returns next week when they will discuss the Peter Principle. Stay tuned! References Extreme Programming Explained - https://archive.org/details/extremeprogrammi00beck

In this episode of Remote Ruby, Jason, Chris, and Andrew reunite after six months to dive into the details of the upcoming RubyConf 2024 with program chairs Kinsey Durham Grace and Jim Remsik. The discussion covers various aspects of the conference, such as the emphasis on more technical talks, the introduction of several keynotes including Matz and Kent Beck, and the revival of the Madison Ruby conference.Additionally, the episode highlights the Scholar and Guide Program, which aims to help newcomers at the conference. They also delve into the history of past Ruby and Rails conferences. Both Kinsey and Jim share their journeys and experiences within the Ruby community, outlining their vision for this year's RubyConf in Chicago.Kinsey Durham Grace WebsiteKinsey Durham Grace X/TwitterJim Remsik LinkedInJim Remsik Blog-FlagrantJim Remsik X/TwitterRubyConf Chicago-Nov 13-15, 2024Madison Ruby, Madison, WI-Aug 1-2, 2024Ruby CentralScholars and Guides ProgramThree Dots and a Dash-ChicagoHoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you. Jason Charnes X/Twitter Chris Oliver X/Twitter Andrew Mason X/Twitter

Proft Streams BookTranscript:Agile FM radio for the agile community. Today I'm thrilled to have Luke Holman with me in the podcast here of Agile FM and I can't believe After all these episodes I had so far I haven't had you on the show, which is a big miss. You are a renowned expert in agile methodologies an author. And I think a lot of people know you from the innovation games which is a framework for collaborative decision making problem solving.You have experience that dates back way, way back into the 1990s, pre Agile, but also I heard recently that you were involved in the 2003 Agile conference. So yeah, a while back. Welcome to the show, Luke. [00:00:46] Luke Hohmann: Joe, I am so happy to be here. I've known you through the community. We've seen each other at conferences.And so it's a, it's quite an honor to be here. Thank you so much for inviting me to participate. Thanks [00:00:58] Joe Krebs: Yeah, no, absolutely. We could talk about the innovation games and fill an entire show, but today we could, but today we want to talk a little bit about value profit stream, the agile community as often. This is the recordings taking place on the 25th of June, 2024 is a little bit in a turmoil. The Agile community as a whole, there seems to be some different kind of directions people are going, looking at the roles. It's maybe a good time to talk about what value is, how we can present value because at the end of the day is, it's like, how do we sell agility within an organization or for organizations?[00:01:44] Luke Hohmann: I think it'd be a good thing to talk about. There, there's so many aspects of this that are interesting, but let's try a few. And I'll also talk about the rule of self interest in the Agile community. When we talk about value we think about it in terms of our Profit Streams book and our Profit Streams work as What are the set of tangible and intangible benefits that a product or service we use solution as the single term for product and service or any blend thereof.So it's just a little easier because we're here to solve problems for our customers. So we think of both the tangible and intangible benefits. And for the tangible benefits, we help companies create mathematical equations that capture the benefits. And we often work with our clients because technical people are good at being efficient in terms of doing things like saving time.But the reality is most companies don't need to save time. They need to have the time converted into a metric that they can understand for their business purposes. One of the examples we use in our book, and it's been proven in many of our client engagements, Is we were working with a trucking company, and they were going to be buying software that saved their drivers time.So drivers in the trucking industry have to keep detailed logs of their hours of service to make sure they're taking breaks, etc. And this solution enabled the data to be acquired automatically by connecting into the engine bus. And they knew if the truck was on and if it was moving and all that kind of technological internet of things capability that we love.And there's so many things that we can do. So the company that we were working for, and this was Qualcomm had the solution. They went to the trucking organizations and said, Hey, we can save you 20 to 30 minutes a day in driver time. And Joe, we were able to prove this. Absolutely through, the data, like the data was very clear.And the trucking company's executive said we don't really care about that. Because our drivers are union and they are paid for eight hours. So saving me 30 minutes of a driver's time doesn't actually save me money. It doesn't do anything for me. So we had to go back to the drawing board with Qualcomm and find out how to reroute drivers using the new systems so the trucking companies could deliver another package or two in a day because that's how they made money through package delivery.Or the other part of this would be the intangible side and intangible benefits can be quantified on the intangible side for challenging deliveries. We were able to allocate more time in the driver's schedule so that customer satisfaction improved. And as customer satisfaction improved, we would see less churn among customers.Oh, my package was delivered well. I want to use this company again. My, my package was delivered without any breakage. I want to use this company again. So the first step of value is to actually take a step back and try to quantify the tangible and intangible aspects of value. And then I'll just real quickly, I'll finish that off.The second of the determination of value is what we call direct and indirect benefits. A direct benefit is something that you will recognize as a benefit and it materially affects your purchase or use decision. An indirect benefit is something that you recognize, you'll say, yes, the benefit exists, but it doesn't influence you.And I'll give you a kind of a standard example. My wife and I were out shopping for a new car. I cared a lot more about the styling and color. She just doesn't care about that. And and she would readily agree yeah, that's a good looking car, but it doesn't affect my purchase decision.Whereas I was, hey, that's a really good looking car. I think I bought it. And so now let's take it into the business context. The solutions that we're creating, which are often very sophisticated, there's a collection of benefit. It's not a single benefit. And collection of benefits, you create a network of how the customer perceives those benefits.So let's go back to a trucking company that is focused on customer satisfaction is not going to really care about the not care as much. I shouldn't say they care. They don't care at all, but they're not going to care as much about like driver satisfaction. But let's say you're a trucking company and a part of.The world where it's hard to attract drivers. Now your network of benefits might emphasize driver satisfaction. So understanding not just what benefits are, but how a given market segment is going to perceive the collection of benefits is really the foundation of our approach, and then from there, what we do is from the benefits, We can derive the customer return on investment model.We can derive your pricing and packaging model. We can help you develop your solution so that you know that you're building a sustainable offering. And I'll close with this Joe. The foundation of profit streams is sustainability. If you're running a business, Or frankly, if you're running a household, you have to have a positive flow of cash coming into your business or your house, right?We can't, other than the government who prints money, right? Like a business has to have a profit to survive, to sustain itself. Now, in some cases, profits can be misused or we can have unsustainable business practices. But if you look at true sustainability involves.Three related areas. One is your solution itself has to be sustainable over time as your customers evolve as their needs evolve Your solution has to evolve to be relevant and to meet their needs So with the first part of this is solution sustainability The second part of this is economic sustainability Are you charging a price that will keep your company in business?But are you also factoring in your customers total cost of ownership? So that your customer perceives what you're selling to them as a good value something they want to keep The relation going right? We want to have economic sustainability and then the third kind of sustainability is relationship sustainability when we Sell software.We're not actually selling software. We're selling a license to use the software So the distinction is that i'm holding in my hand a pen You If I sell you my pen, I've transferred rights to you. You now own the pen. You can do what you want with it. I don't sell you software. I license software for you to use.So there's a license agreement and that license agreement determines our relationship as the provider to the customer. There's other relationships that matter. Every software package that is created has technology and licenses associated with it. So the provider is in licensing work, and there's relationships that they need to maintain.And of course, the kind of the capstone of all of these things is our relationship to society and to other parts of the world. Of the global infrastructure in which we live. And what I mean by that is if you're in Europe, you need to honor GDPR. If you're in the United States, you have to honor California CCPA.If you're selling certain kinds of fintech software, you might have to be PCI or SOX two compliant. If you're in the healthcare industry, you'll have to be HIPAA compliant. If you're in the education industry, you have to be. FERPA and COPA compliant. So the idea of compliance to us is part of that relationship.What is the relationship your company wants to have with various regulatory agencies? Are you going to try and be an organization that honors those relationships and fulfills your compliance requirements? Or are you going to be an organization that's going to try and skirt those requirements? And perhaps engage in questionable or provably unethical behavior, and so all of that is what comprises profit streams.[00:10:42] Joe Krebs: Yeah, this is it's very interesting. And as you were elaborating on this, especially on the economics, sustainability It's interesting, right? Because I think we all have seen situations as a consumer before where we felt like I need a certain service or a product, but I felt like this was too, too expensive.I've felt abused based on a very specific situation I'm in and I'm requiring a service or a product. I feel like everybody can relate to that. So finding that kind of fair spot, yeah. In terms of sustainability, I can totally see that as well as the other ones as well. So I think that's a great example.Now, if somebody hears the word profit stream, at least the first thing that came to mind for me said, what's the difference to value stream, right? [00:11:24] Luke Hohmann: That's a great question. And we should know the distinction between a profit stream and as a value stream. I credit this to my friend Avi Schneider who is well known in the scrum community.Avi, after reading the book, he said, Luke, I've come to learn and realize that all profit streams are value streams, like all squares are rectangles. But not all rectangles are squares. So the distinction that I like to talk about Joe is that typically a profit stream is going to be more aligned to what SAFe calls an operational value stream and the development value stream of SAFe would be a cost center.So now let's look at value streams and let's look at specifically operational value streams. We think of profit streams as those operational value streams that are generating revenue for a company. And so not all value streams generate revenue. For example, there are value streams provided by. Government entities that don't provide revenue, but provide services that maintain our society, which we need, and those are fantastic.But not all not all value streams are profit streams. And that's a good distinction. When the other thing that's interesting, and I give a talk on this. Is when we look at value streams, especially the operational value stream, you start to find that. We have a starting condition and we go through a sequence of steps and we get an ending benefit.Actually map in your operational value stream. When revenue occurs, you'll find that many things are costs until the very end. It's like value streams are rainbows, right? The pot of gold is at the end. And so you really have to make sure that you're understanding the steps in that operational value stream.And what we work on with our clients is that we try to help them understand the economic sustainability of looking at that sequence of flow to make sure that you are generating enough revenue at the end to support the whole flow and looking at ways you might be able to pull revenue sooner so that you can sustain yourself.[00:13:45] Joe Krebs: All right. How do you respond to somebody who is like possibly interested? Here's the word profit stream. Obviously I see dollar signs and signals and cha-ching and all of those kinds of things. For an agile audience out there who might say, Hey, but what about the team spirit? And what about sustainability of a team's, fun and learning environment?Aren't they contradictory to this? I guess the answer to that is no, right? But it's the, [00:14:14] Luke Hohmann: of course, all of those, Joe and for the listeners, Joe and I were chatting before the podcast we often do. And one of the things that I really find disappointing in the agile community is a lot of agile people seem to have this kind of disdain for management or this disdain for leadership.[00:14:32] Joe Krebs: And I think of it exactly the opposite. Business leaders over the last 20, 25 years have shoveled hundreds of millions of dollars into agile practices and transformations between the training and the tooling and the infrastructure. And they've gotten benefit from agile. I'm very proud of all the things that software people do.Earlier today I was getting a blood test. And I walked in and there was a kiosk and you just typed in your phone number scanned your driver's license and you were checked in. Software people did that. And I think what we do as software people is really cool. Yeah. Hardware and software. We designed a solution that was amazing.And of course, Joe, we want to have sustainable practices, not just in our business relationships with our customers, but true sustainability means sustainability with our employees, with our practices. With what Kent Beck wrote about very early in the community with XP, like XP is about sustainability.So to say that profit is antagonistic to sustainability is to have a very flawed understanding of what sustainability is and or what profit is. I've been a serial entrepreneur. I've started and run and sold a couple of companies. And it's really a lot of fun when you're an entrepreneur and you can give out bonus checks because you had a great year Yeah, it's not so fun when you had a bad year and you're cutting salaries or you're doing other You know doing a layoff or whatever.And so for the people in the agile community who talk about humanness of our developers my response is Yes, heck yes, we, those are things that promote sustainability. Those practices, the training the better tooling, the better computers, they require money, they require a profit.And most of us work for a for profit company. It is, I think it's pretty above average that people would be working for profit rather than for the non profit sector. Should we go a little concrete about some data points, metrics, because I don't want to I'm just going to say the word.We really don't have to go down that path at all in this kind of conversation. I think we have debunked the word velocity as a metric or something like that. I don't think we have to talk about that. But what are. Measurements, like if somebody would say, Hey, this sounds very interesting. Definitely trucking sounds good, but I'm in a totally different domain.In terms of this, I would what's a good starting point for people to say, like, how do I measure these profit streams from an IT perspective or, Yeah. [00:17:18] Luke Hohmann: And Joe if I'm not answering the question in the way that you're intending the question that's okay.I started as an engineer and for everyone listening, Joe and I had a really, a geeky out moment when I, when we started, but I started as an engineer. And then I became a manager of engineer and then I became, vice president and all that kind of stuff. And I was always trying to create the best solution for my customers.And along and in that journey, I found product management. I thought, Oh, wait a minute. Product managers are the people who are designing the solution and working with designers on the user experience side. And they're in the center of the world of this thing called creating a great solution for customers.And through that. conversation, I started to realize, Hey, I'm responsible for creating a return on the investment of the company I'm working for. And from there, I started to learn the basics of finance. And I started to, understand how to read a balance sheet, how to read what is EBITDA what's the difference between CapEx and OpEx.What is the terms of the license agreement? What is, what can go wrong in a license agreement? If it's not crafted correctly for a company, how do I know if I'm making enough money, has my economic, let's go back to the engineers has my economic model factored in a pay raise for my team next year, because there's inflation and if there's inflation and I want to pay my developers more money, How do I manage that with my margins?Either my costs are going down, which might happen. And, maybe my software part of the solution is the same price, but my hardware margins are improving because I have cost of scale manufacturing. Maybe I don't, I'm a pure SAAS company and I'm picking up some lower costs because of hosting costs are dropping.How do I economically think about these elements? So the, what I would say is this is one of those areas where Agile has to do nothing more than embrace what has been existing for a long time, which is economic models Don Reinerson's work on flow. Looking at possibly throughput accounting, but educating ourselves, educate product managers, educate themselves on what's in our book, which is not just how do I economically model, but how do I actually. Set the price point. How do I determine the packaging of what features go in? What edition of my offering and do I charge? So those kinds of things are to me they're not taught as much as they should be in the agile community, but that's why we wrote the book. [00:20:10] Joe Krebs: Oh, absolutely. I agree with you.And I think indirectly you are answering the question, at least for me, right? Because I do see certain data points being captured within agile teams that are contradictory to what you're saying right now. These are like the velocity discussions and that are happening within teams. And then all of a sudden they happen on the leadership level, whereas you're saying, actually, some of those conversations are still existent as they were before agile, but they're still applying it.Just they have to be maps. I feel like you're having a much more adult mature kind of conversation about this. And I think we're actually experiencing within teams on the ground. [00:20:48] Luke Hohmann: Yeah I think the Agile community has gotten a little wrapped up around the Axel about, I helped form the first conference in the Agile Alliance series in 2003 with Alistair Coburn and Ken Schwaber and Rebecca Wirfs Brock and a few other people.And Todd Little, and let me tell you, no one at that conference was walking around arguing about the fine distinctions between output and outcome metrics and things like that. We both have a friend, Kenny Rubin, and he's written very beautifully about this. But trust me, in the very early days, we weren't arguing about those.It's like people drink fine wine and argue, Oh, are you getting black current or dark cherry flavors in the wine? No, just have a glass of wine and enjoy it. Um, and what's happening is we're forgetting that sometimes you do need to track certain basic metrics just as a mechanism Of I think consistency and let's say you're an athlete.Let's say you wanted to run a marathon. The number of miles you run in a week or the total miles that you've run in training for American a marathon could be a vanity metric. Oh, but at the end of the day, it's also the truth that you're not going to go run 26 miles if you didn't train And a training program is going to tell you how many miles you need to run Per week and if you're not tracking how many your miles you're running per week You're not going to hit your end goal of running the actual marathon So I think that so many other aspects of what we do, there's a very healthy way to look at velocity and velocity metrics and looking at flow metrics and unhealthy ways of looking at it and rather than throwing everything into a bucket of healthy and unhealthy, we should use the agile principles of retrospection.This metric and the way that we're using us, helping us advance towards our goals. Yeah. And it is, we should probably keep doing it. And if it's not, we should look at what we need to change. [00:22:52] Joe Krebs: Yeah. It's very interesting. I also, while we were talking about the marathon, I was also thinking yes, there's definitely mileage.This is an important piece, if part of your training program, but it's sometimes, and I don't know if that makes sense, I think sometimes we're measuring how many minutes we also have used for stretching, and yes, it is. a great technique to become a marathon runner, but I don't think from purely stretching, you're becoming a good marathon runner.I think it's together. And I think it's also for metrics like these things have to balance each other out. If you're having 90 percent stretching and 10 percent running, maybe that's the wrong [00:23:25] Luke Hohmann: that's where wisdom comes in. And that's where not always trying to invent everything from scratch, right?If you were, if you really were going to go run a marathon, you'd probably go talk with other runners. You'd probably go to some running websites that like runner's world that has reputable training plans. You'd get a sense of the balance of the metrics. So it's. It's very rare that one metric on a development organization is going to be the only metric that you needed.And again, this is where people start to it's good to have these discussions to calibrate. But it's like the definition of done, right? At the definition of done, you might say our definition of done is no stop ship bugs where stop ship is defined as P one and sev zero, like separate priority severity.Then you get into people who are like if I have no stop ship bugs, but I have a bunch of small bugs, can I still ship? And I'm like, I don't know like maybe no, maybe yes. What's the, we should have a conversation about that. And the metrics are designed to use to guide us into the conversations that are most beneficial, just like.So if I looked at a team that had velocity metrics, and they were reasonably consistent. And I saw an anomaly, like a dip. I, as a manager, if I didn't already know, I would go to the team and say, Hey, I noticed that your velocity dip, everything. Okay. And if the team says actually, no Joe went on a ski trip and broke his arm and our velocity dip, cause he was in the hospital.And we're all really worried about Joe. Wow, that stinks. Maybe we should send Joe some flowers or some get well, but now I know why velocity dipped. Yeah, and it was a special cause and it'll resolve itself. Um, now the other element could be our velocity dipped because we completely misunderstood the requirement and I'd be like, okay maybe we should toss that into a retrospective.There's so many good retrospective techniques. Maybe we should toss that into one of our retrospective techniques and see if that's a special cause or if there's some other potential issue that the team might be facing. And then the team goes, Oh yeah, no, we think we're okay. It was just this one time.We didn't really understand the requirements are no, we're actually in a new area of our solution and all of us are experiencing this new thing and we need more training or we need X to really get ahead of the issue. So metrics are important, right? We keep score, right? We keep track of things.[00:26:03] Joe Krebs: Yeah. So it's interesting, right? Because we, you mentioned before that there is this general amount of metrics. Don't want to repeat them necessarily, but these are like the business metrics. And these are the things that our businesses are already using on an enterprise level with or without agile.Why are we having such a hard time in the agile community to translate that? Obviously, your book will help in the translation of all of those things. But what do you think of the pitfalls? [00:26:29] Luke Hohmann: I actually think one of the pitfalls is how some of the agile methods have defined what a product owner is.You'll see agile methods say a product owner is responsible for value. Which is great, but then they don't define it. And so we've got a generation and I spent most of my formative business careers here in silicon valley, not all of it, but a lot of it So i'm used to a silicon valley style of a product manager Knowing how to run a spreadsheet knowing how to do pricing and being trained And what we're finding, I think, Joe, is that there's this tremendously large number of people who are associated with products, but don't have this training and pricing.They don't have this training and licensing. I'll, one of the things I do with my clients is I'll walk into a situation where they're, they need to, make an improvement economically. And I'll just go to the product managers and I'll say, when was the last time you read your own license agreement, your own terms of service on your website?And they'll be like, Oh yeah. never! Like, okay we should read it. And I'll give you an example of kind of the weird things that can happen in license agreements. We were working with a smaller company. And their license agreement with, so they served larger companies and it was a conversion company.I don't want to go much further than that. Yeah. They had a contract with a larger company that said every time the larger company made a request to the smaller company and the smaller company agreed to that request, their maintenance agreement would automatically extend for one more year. So every nine months, the big company would make a request to the small company.On a very small change, the small company would make a very small change. And then now they're saddled with a responsibility for another year of support. And I said, okay this two sentence clause in your license agreement is now costing you almost 300, 000 a year. Now for a big company, you may not notice it, but this was a company with less than 8 million in revenue.That's a noticeable number for a company with eight million right now. It's still a nice company. Don't it's not it's a very good business but i'm like this two line sentence in your license and the product manager was like wow I didn't know how to interpret that. I think we're seeing this challenge in the agile community because too many Organizations have allowed this skills of pricing and economic sustainability modeling to activity.Yeah, let's say you're, let's say you're agile. I don't care what flavor of agile you're using, pick one. I don't, there's so many, it's like going to the ice cream store. So you pick one and you're putting out more value at what point. Should you raise your prices because you've added so much value?At what point should you adjust your packaging? We work with a client who they kept on shoving features into their solution Which sounds great, right? But then their sales started to slow down and that the head of Product contacted me and said it's really weird luke Every time we're adding more features our sales team is telling us it's harder to sell that's a packaging problem because what's happening is people are saying Your solution now includes Features that are not relevant to me Therefore I want a lower price because i'm not using them.That's right And the right solution is to say okay now that our product has grown in sophistication We're gonna go take this market that wasn't segmented And we're going to make it a finer grain segmentation, and we're going to really understand the needs of these customers and take this wonderful platform we've built and offered these solutions or these features to this market segment, these features to this market segment.And after we did that work with that client. Their sales returned to a healthy growing number because people bought what was relevant for them. [00:30:49] Joe Krebs: This is awesome. Luke, we started off with also with a side comment or I might have started with this agile community being in some form of transition.Yes. And I want to end with this for our podcast as well. Now we talked a little bit more from the company's perspective, from the leadership level what I have noticed, and I don't know if you would share that thought is there's a lot of agile coaches in the transformation space and organizations, and they don't really know for sure if their work actually had an economic impact for the organization.Like they say like it feels better or it feels, we feel more profitable, but do we have evidence of what we had before to what we have now? How could profit streams help future coaching and coaches out there on, not from a product perspective, but more from a transformations perspective, how can profit streams help them to make a case for themselves to actually say, Hey, the agile community is alive and kicking.Why? Why? Because we are. Increasing the economic side of organizations by X, Y, Z, what kind of parameters would, what coaches need to tweak to say okay, these are like the parts of our puzzle where we can actually make a case for ourselves and say Hey, agile coaching is important. Agile teams are important.You call them the ice cream flavors. The agile processes out there are important for you to be successful for whatever is hitting your organization in the future. How would they use that kind of profit stream?[00:32:20] Luke Hohmann: I'm inspired by there's a gentleman that if you haven't had him on your podcast, you really need to get him.His name is Peter Green and he runs a company called Humanizing Work. He's a known in the Scrum community and he used to be one of the leaders at Adobe and Adobe's transition to more agile practices. And I remember that one of the metrics that Peter really tracked was just one thing, defects found in production.And remember I said that there was only, development teams need multiple metrics, but in this case, he was using the one metric that really resonated with his leaders and he showed his leaders how when defects in productions were reduced, customer satisfaction increased when customer satisfaction increased, renewals increased.The cost of customer care went down because there's fewer defects. And fewer upset customers, developer satisfaction went up because instead of fixing bugs, you're building new features. And so what he did was. He took the time to translate something that was just a number of defects found in production into how it expressed itself in a relevant profit oriented way.So my advice to the agile coaches out there is if you believe that you're creating a more effective, more efficient, more effective, doing the right things, more efficient, doing them effective, doing them well. If you think you're creating and contributing to this organization and, for example, I'm an agile coach and my team is quote unquote happier.What does that actually mean? What, we know that stable teams, like we have data on stable teams, that stable teams produce fewer bugs. That's an argument for stable teams. So what is the data that shows that coach is creating an economic impact that is relevant to the organization? And I am said this for decades.I am always concerned that people focus on trying to achieve the happiness of developers. When I think that the happiness of developers is an outcome of other elements, meaning if I'm a developer and I have Dan Pink, if I have reasonable autonomy, I have reasonable mastery, I, I have a purpose, right?Then I'm happy. But focusing on happiness doesn't mean I'm getting autonomy. Giving me autonomy, making sure I'm trained, making sure I have a purpose. Those and I definitely think that the many of the coaches I've seen, um, they don't always understand what the deeper opportunities might be.[00:35:08] Joe Krebs: Yeah. This is some awesome advice here. And I did not have Peter on the podcast and Peter, if you're listening to this, expect a call from me. Thank you, Luke. This was really insightful. And obviously I will share the book information for all the material on the show page of Agile FM, I just want to say thank you for sharing a very different view on things from what I had in the past in terms of guests and just chat a little bit about profit streams and make this really tangible for people of what they need to, establish within the organization to be successful and ready for the future.[00:35:42] Luke Hohmann: Yeah. And Joe, thank you. I'm going to leave just two more things for the listeners. I think they're important right now. We do think the agile community, many of us who've been there a while. And many of the leaders, we think the agile community is in some form of transition or some form of change, which means.It's up to you as a listener to decide what you think that future is and then work towards that future. A few years ago, my colleague Jason Tanner and I, we sat down and we were at an offsite and we said to ourselves, where do we really believe a future or part of the future of Agile has to be? And we decided that a part of the future of Agile has to be a return to the economics. of understanding profit and sustainability, and we acted accordingly, right? We wrote a book. We've got a partner program. We're doing consulting work. We're seeing our consulting business and profit streams is skyrocketing in terms of growth because we're finding that companies are going, wait a minute, You guys are right.You're We've invested in agile. How do we measure the return and how do we make sure that we're creating a profit? So and i'm not arguing that people have to buy into our perspective What I am saying is if you assert that the agile community is changing You can't just sit there and complain about it You have to decide what part of that future you want to create And what part of that future you want to be a part of and from there?You Your life will have purpose. Your life will have direction. And I think that's part of what's happening in the agile community right now. We're seeing this kind of Oh, what are what is our future? And where are we going to be? And how is it going to work as people are trying to decide? And I would invite people to reflect on their own and make a decision on their own about what they think that future is going to be, right?[00:37:40] Joe Krebs: Look, there's something very similar to what my kids are hearing in school every day. Make it a great day or not, the choice is yours. [00:37:47] Luke Hohmann: Oh, I love it. That's a great way to close. Luke, thank you so much.

Refactoring code can be a big job and take weeks or months. But what about just doing a bit of 'tidying'? This month, we talk about Kent Beck's new book, *Tidy First?*.

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.

Bio Luke Hohmann is Chief Innovation Officer of Applied Frameworks. Applied Frameworks helps companies create more profitable software-enabled solutions. A serial entrepreneur, Luke founded, bootstrapped, and sold the SaaS B2B collaboration software company Conteneo to Scaled Agile, Inc. Conteneo's Weave platform is now part of SAFe Studio. A SAFe® Fellow, prolific author, and trailblazing innovator, Luke's contributions to the global agile community include contributing to SAFe, five books, Profit Streams™, Innovation Games®, Participatory Budgeting at enterprise scale, and a pattern language for market-driven roadmapping. Luke is also co-founder of Every Voice Engaged Foundation, where he partnered with The Kettering Foundation to create Common Ground for Action, the world's first scalable platform for deliberative decision-making. Luke is a former National Junior Pairs Figure Skating Champion and has an M.S.E. in Computer Science and Engineering from the University of Michigan. Luke loves his wife and four kids, his wife's cooking, and long runs in the California sunshine and Santa Cruz mountains.    Interview Highlights 01:30 Organisational Behaviour & Cognitive Psychology 06:10 Serendipity 09:30 Entrepreneurship 16:15 Applied Frameworks 20:00 Sustainability 20:45 Software Profit Streams 23:00 Business Model Canvas 24:00 Value Proposition Canvas 24:45 Setting the Price 28:45 Customer Benefit Analysis 34:00 Participatory Budgeting 36:00 Value Stream Funding 37:30 The Color of Money 42:00 Private v Public Sector 49:00 ROI Analysis 51:00 Innovation Accounting    Connecting   LinkedIn: Luke Hohmann on LinkedIn Company Website: Applied Frameworks    Books & Resources   ·         Software Profit Streams(TM): A Guide to Designing a Sustainably Profitable Business: Jason Tanner, Luke Hohmann, Federico González ·         Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers (The Strategyzer series): Alexander Osterwalder, Yves Pigneur ·         Value Proposition Design: How to Create Products and Services Customers Want (The Strategyzer Series): Alexander Osterwalder, Yves Pigneur, Gregory Bernarda, Alan Smith, Trish Papadakos ·         Innovation Games: Creating Breakthrough Products Through Collaborative Play: Luke Hohmann ·         The ‘Color of Money' Problem: Additional Guidance on Participatory Budgeting - Scaled Agile Framework ·         The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries ·         Extreme Programming Explained: Embrace Change 2, Kent Beck, Cynthia Andres ·         The Mythical Man-Month: Essays on Software Engineering: Brooks, Frederick Phillips ·         Understanding Comics: The Invisible Art, Scott McCloud ·         Ponyboy: A Novel, Eliot Duncan ·         Lessons in Chemistry: A Novel, Bonnie Garmus, Miranda Raison, Bonnie Garmus, Pandora Sykes ·         What Happened to You?: Conversations on Trauma, Resilience, and Healing, Oprah Winfrey, Bruce D. Perry ·         Training | Applied Frameworks   Episode Transcript Intro: Hello and welcome to the Agile Innovation Leaders podcast. I'm Ula Ojiaku. On this podcast I speak with world-class leaders and doers about themselves and a variety of topics spanning Agile, Lean Innovation, Business, Leadership and much more – with actionable takeaways for you the listener.  Ula Ojiaku   So I have with me Luke Hohmann, who is a four time author, three time founder, serial entrepreneur if I say, a SAFe fellow, so that's a Skilled Agile Framework fellow, keynote speaker and an internationally recognised expert in Agile software development. He is also a proud husband and a father of four. So, Luke, I am very honoured to have you on the Agile Innovation Leaders podcast. Thank you for making the time. Luke Hohmann Thank you so much for having me, I'm very happy to be here, and hi everyone who's listening. Ula Ojiaku Yes, I'm sure they're waving back at you as well. I always start my conversations with my guests to find out about them as individuals, you know, so who is Luke? You have a BSc in Computer Science and an MSc in Computer Science and Engineering, but you also studied Cognitive Psychology and Organisational Behaviour in addition to Data Structures and Artificial Intelligence. AI is now making waves and is kind of at the forefront, which is interesting, you had the foresight to also look into these. So my question is, what took you down this path? Luke Hohmann Sure. I had a humble beginning in the world of technology. I worked for a large company, Electronic Data Systems, and it was founded in the mid 60s by a gentleman named Ross Perot, and it became a very, very large company. So my first job at Electronic Data Systems was working in a data centre, and we know what data centres are, but back then, data centres were different because they were predominantly mainframe-based data centres, and I would crawl underneath the floor, cabling the computers and cabling networking equipment. Now, when we think networking, we're really thinking one of two kinds of networking. We think of wireless networking or we think of some form of internet networking, but back in those days, there were varieties of network protocols, literally the standards that we use now weren't invented yet. So it was mainframe networking protocols and dial ups and other forms of networking protocols. From there, I worked my way from beneath the ground up. I had some great managers who saw someone who was worthy of opportunity and they gave me opportunity and it was great. And then eventually I started working in electronic data systems and there was, the first wave of AI came in the mid 80s and that's when we were doing things like building expert systems, and I managed to create with a colleague of mine, who's emerged as my best friend, a very successful implementation of an expert system, an AI-based expert system at EDS, and that motivated me to finish off my college degree, I didn't have my college degree at the time. So EDS supported me in going to the University of Michigan, where as you said, I picked up my Bachelor's and Master's degree, and my advisor at the time was Elliot Soloway, and he was doing research in how programmers program, what are the knowledge structures, what are the ways in which we think when we're programming, and I picked up that research and built programming environments, along with educational material, trying to understand how programmers program and trying to build educational material to teach programming more effectively. That's important because it ignited a lifelong passion for developing education materials, etc. Now the cognitive psychology part was handled through that vein of work, the organisational behaviour work came as I was a student at Michigan. As many of us are when we're in college, we don't make a lot of money, or at university we're not wealthy and I needed a job and so the School of Organisational Behaviour had published some job postings and they needed programmers to program software for their organisational behaviour research, and I answered those ads and I became friends and did the research for many ground-breaking aspects of organisational behaviour and I programmed, and in the process of programming for the professors who were in the School of Organisational Behaviour they would teach me about organisational behaviour and I learned many things that at the time were not entirely clear to me, but then when I graduated from university and I became a manager and I also became more involved in the Agile movement, I had a very deep foundation that has served me very well in terms of what do we mean when we say culture, or what do we mean when we talk about organisational structures, both in the small and in the large, how do we organise effectively, when should we scale, when should we not scale, etc. So that's a bit about my history that I think in terms of the early days helped inform who I am today. Ula Ojiaku Wow, who would have thought, it just reminds me of the word serendipity, you know, I guess a happy coincidence, quote unquote, and would there be examples of where the cognitive psychology part of it also helped you work-wise? Luke Hohmann Yeah, a way to think about cognitive psychology and the branch that, I mean there's, psychology is a huge branch of study, right? So cognitive psychology tends to relate to how do we solve problems, and it tends to focus on problem solving where n = 1 and what I mean by n is the number of participants, and where n is just me as an individual, how do I solve the problems that I'm facing? How do I engage in de-compositional activities or refinement or sense making? Organisational behaviour deals with n > 1. So it can deal with a team of, a para-bond, two people solving problems. It can deal with a small team, and we know through many, many, many decades of research that optimal team structures are eight people or less. I mean, we've known this for, when I say decades I mean millennia. When you look at military structure and military strategy, we know that people need to be organised into much smaller groups to be effective in problem solving and to move quickly. And then in any organisational structure, there's some notion of a team of teams or team engagement. So cognitive psychology, I think, helps leaders understand individuals and their place within the team. And now we talk about, you know, in the Agile community, we talk about things like, I want T-shaped people, I want people with common skills and their area of expertise and by organising enough of the T's, I can create a whole and complete team. I often say I don't want my database designer designing my user interface and I don't want my user interface designer optimising my back end database queries, they're different skills. They're very educated people, they're very sophisticated, but there's also the natural feeling that you and I have about how do I gain a sense of self, how do I gain a sense of accomplishment, a sense of mastery? Part of gaining a sense of mastery is understanding who you are as a person, what you're good at. In Japanese, they would call that Ikigai, right, what are the intersections of, you know, what do I love, what am I good at, what can I make a living at and what do people need, right? All of these intersections occur on an individual level, and then by understanding that we can create more effective teams. Ula Ojiaku Thank you. I've really learned something key here, the relationship between cognitive psychology and organisational behaviour, so thanks for breaking it down. Now, can we go quickly to your entrepreneurship? So there must be three times you started three times a company and you've been successful in that area. What exactly drives you when it comes to establishing businesses and then knowing when to move on? Luke Hohmann Sure. I think it's a combination of reflecting on my childhood and then looking at how that informs someone when they're older, and then opportunities, like you said, serendipity, I think that's a really powerful word that you introduced and it's a really powerful concept because sometimes the serendipity is associated with just allowing yourself to pursue something that presents itself. But when I was young, my father died and my mum had to raise six kids on her own, so my dad died when I was four, my mum raised six kids on her own. We were not a wealthy family, and she was a school teacher and one of the things that happened was, even though she was a very skilled school teacher, there were budget cuts and it was a unionised structure, and even though she was ranked very highly, she lost her job because she was low on the hiring totem pole in terms of how the union worked. It was very hard and of course, it's always hard to make budget cuts and firing but I remember when I was very young making one of those choices saying, I want to work in a field where we are more oriented towards someone's performance and not oriented on when they were hired, or the colour of their skin, or their gender or other things that to me didn't make sense that people were making decisions against. And while it's not a perfect field for sure, and we've got lots of improvement, engineering in general, and of course software engineering and software development spoke to me because I could meet people who were diverse or more diverse than in other fields and I thought that was really good. In terms of being an entrepreneur, that happened serendipitously. I was at the time, before I became an entrepreneur in my last job, was working for an Israeli security firm, and years and years ago, I used to do software anti-piracy and software security through physical dongles. This was made by a company called Aladdin Knowledge Systems in Israel, and I was the head of Engineering and Product Management for the dongle group and then I moved into a role of Business Development for the company. I had a couple of great bosses, but I also learned how to do international management because I had development teams in Israel, I had development teams in Munich, I had development teams in Portland, Oregon, and in the Bay Area, and this was in the 2000s. This is kind of pre-Agile, pre-Salt Lake City, pre-Agile Manifesto, but we were figuring things out and blending and working together. I thought things were going pretty well and I enjoyed working for the Israelis and what we were doing, but then we had the first Gulf War and my wife and I felt that maybe traveling as I was, we weren't sure what was going to happen in the war, I should choose something different. Unfortunately, by that time, we had been through the dot-bomb crisis in Silicon Valley. So it's about 2002 at the time that this was going on, and there really weren't jobs, it was a very weird time in Silicon Valley. So in late 2002, I sent an email to a bunch of friends and I said, hey, I'm going to be a consultant, who wants to hire me, that was my marketing plan, not very clever, and someone called me and said, hey, I've got a problem and this is the kind of thing that you can fix, come consult with us. And I said, great. So I did that, and that started the cleverly named Luke Hohmann Consulting, but then one thing led to another and consulting led to opportunities and growth and I've never looked back. So I think that there is a myth about people who start companies where sometimes you have a plan and you go execute your plan. Sometimes you find the problem and you're solving a problem. Sometimes the problem is your own problem, as in my case I had two small kids and a mortgage and I needed to provide for my family, and so the best way to do that at the time was to become a consultant. Since then I have engaged in building companies, sometimes some with more planning, some with more business tools and of course as you grow as an entrepreneur you learn skills that they didn't teach you in school, like marketing and pricing and business planning etc. And so that's kind of how I got started, and now I have kind of come full circle. The last company, the second last company I started was Conteneo and we ended up selling that to Scaled Agile, and that's how I joined the Scaled Agile team and that was lovely, moving from a position of being a CEO and being responsible for certain things, to being able to be part of a team again, joining the framework team, working with Dean Leffingwell and other members of the framework team to evolve the SAFe framework, that was really lovely. And then of course you get this entrepreneurial itch and you want to do something else, and so I think it comes and goes and you kind of allow yourself those opportunities. Ula Ojiaku Wow, yours is an inspiring story. And so what are you now, so you've talked about your first two Startups which you sold, what are you doing now? Luke Hohmann Yeah, so where I'm at right now is I am the Chief Innovation Officer for a company, Applied Frameworks. Applied Frameworks is a boutique consulting firm that's in a transition to a product company. So if this arm represents our product revenue and this arm represents our services revenue, we're expanding our product and eventually we'll become a product company. And so then the question is, well, what is the product that we're working on? Well, if you look at the Agile community, we've spent a lot of time creating and delivering value, and that's really great. We have had, if you look at the Agile community, we've had amazing support from our business counterparts. They've shovelled literally millions and millions of dollars into Agile training and Agile tooling and Agile transformations, and we've seen a lot of benefit from the Agile community. And when I say Agile, I don't mean SAFe or Scrum or some particular flavour of Agile, I just mean Agile in general. There's been hundreds of millions of dollars to billions of dollars shoved into Agile and we've created a lot of value for that investment. We've got fewer bugs in our software because we've got so many teams doing XP driven practices like Test Driven Development, we've got faster response times because we've learned that we can create smaller releases and we've created infrastructure that lets us do deployments automatically, even if you're doing embedded systems, we figured out how to do over the air updates, we've figured out how to create infrastructure where the cars we're driving are now getting software updates. So we've created for our business leaders lots of value, but there's a problem in that value. Our business leaders now need us to create a profit, and creating value and creating a profit are two different things. And so in the pursuit of value, we have allowed our Agile community to avoid and or atrophy on skills that are vital to product management, and I'm a classically trained Product Manager, so I've done market segmentation and market valuation and market sizing, I've done pricing, I've done licensing, I've done acquisitions, I've done compliance. But when you look at the traditional definition of a Product Owner, it's a very small subset of that, especially in certain Agile methods where Product Owners are team centric, they're internal centric. That's okay, I'm not criticising that structure, but what's happened is we've got people who no longer know how to price, how to package, how to license products, and we're seeing companies fail, investor money wasted, too much time trying to figure things out when if we had simply approached the problem with an analysis of not just what am I providing to you in terms of value, but what is that value worth, and how do I structure an exchange where I give you value and you give me money? And that's how businesses survive, and I think what's really interesting about this in terms of Agile is Agile is very intimately tied to sustainability. One of the drivers of the Agile Movement was way back in the 2000s, we were having very unsustainable practices. People would be working 60, 80, death march weeks of grinding out programmers and grinding out people, and part of the Agile Movement was saying, wait a minute, this isn't sustainable, and even the notion of what is a sustainable pace is really vital, but a company cannot sustain itself without a profit, and if we don't actually evolve the Agile community from value streams into profit streams, we can't help our businesses survive. I sometimes ask developers, I say, raise your hand if you're really embracing the idea that your job is to make more money for your company than they pay you, that's called a profit, and if that's not happening, your company's going to fail. Ula Ojiaku They'll be out of a job. Luke Hohmann You'll be out of a job. So if you want to be self-interested about your future, help your company be successful, help them make a profit, and so where I'm at right now is Applied Frameworks has, with my co-author, Jason Tanner, we have published a bold and breakthrough new book called Software Profit Streams, and it's a book that describes how to do pricing and packaging for software enabled solutions. When we say software enabled solution, we mean a solution that has software in it somehow, could be embedded software in your microwave oven, it could be a hosted solution, it could be an API for a payment processor, it could be the software in your car that I talked about earlier. So software enabled solutions are the foundation, the fabric of our modern lives. As Mark Andreessen says software is eating the world, software is going to be in everything, and we need to know how to take the value that we are creating as engineers, as developers, and convert that into pricing and licensing choices that create sustainable profits. Ula Ojiaku Wow. It's as if you read my mind because I was going to ask you about your book, Software Profit Streams, A Guide to Designing a Sustainably Profitable Business. I also noticed that, you know, there is the Profit Stream Canvas that you and your co-author created. So let's assume I am a Product Manager and I've used this, let's assume I went down the path of using the Business Model Canvas and there is the Customer Value Proposition. So how do they complement? Luke Hohmann How do they all work together? I'm glad you asked that, I think that's a very insightful question and the reason it's so helpful is because, well partly because I'm also friends with Alex Osterwalder, I think he's a dear, he's a wonderful human, he's a dear friend. So let's look at the different elements of the different canvases, if you will, and why we think that this is needed. The Business Model Canvas is kind of how am I structuring my business itself, like what are my partners, my suppliers, my relationships, my channel strategy, my brand strategy with respect to my customer segments, and it includes elements of cost, which we're pretty good at. We're pretty good at knowing our costs and elements of revenue, but the key assumption of revenue, of course, is the selling price and the number of units sold. So, but if you look at the book, Business Model Generation, where the Business Model Canvas comes from, it doesn't actually talk about how to set the price. Is the video game going to be $49? Is it going to be $59, or £49 or £59? Well, there's a lot of thought that goes into that. Then we have the Value Proposition Canvas, which highlights what are the pains the customer is facing? What are the gains that the customer is facing? What are the jobs to be done of the customer? How does my solution relate to the jobs? How does it help solve the pain the customer is feeling? How does it create gain for the customer? But if you read those books, and both of those books are on my shelf because they're fantastic books, it doesn't talk about pricing. So let's say I create a gain for you. Well, how much can I charge you for the gain that I've created? How do I structure that relationship? And how do I know, going back to my Business Model Canvas, that I've got the right market segment, I've got the right investment strategy, I might need to make an investment in the first one or two releases of my software or my product before I start to make a per unit profit because I'm evolving, it's called the J curve and the J curve is how much money am I investing before I well, I have to be able to forecast that, I have to be able to model that, but the key input to that is what is the price, what is the mechanism of packaging that you're using, is it, for example, is it per user in a SAS environment or is it per company in a SAS environment? Is it a meter? Is it like an API transaction using Stripe or a payment processor, Adyen or Stripe or Paypal or any of the others that are out there? Or is it an API call where I'm charging a fraction of a penny for any API call? All of those elements have to be put into an economic model and a forecast has to be created. Now, what's missing about this is that the Business Model Canvas and the Value Proposition Canvas don't give you the insight on how to set the price, they just say there is a price and we're going to use it in our equations. So what we've done is we've said, look, setting the price is itself a complex system, and what I mean by a complex system is that, let's say that I wanted to do an annual license for a new SAS offering, but I offer that in Europe and now my solution is influenced or governed by GDPR compliance, where I have data retention and data privacy laws. So my technical architecture that has to enforce the license, also has to comply with something in terms of the market in which I'm selling. This complex system needs to be organised, and so what canvases do is in all of these cases, they let us take a complex system and put some structure behind the choices that we're making in that complex system so that we can make better choices in terms of system design. I know how I want this to work, I know how I want this to be structured, and therefore I can make system choices so the system is working in a way that benefits the stakeholders. Not just me, right, I'm not the only stakeholder, my customers are in this system, my suppliers are in this system, society itself might be in the system, depending on the system I'm building or the solution I'm building. So the canvases enable us to make system level choices that are hopefully more effective in achieving our goals. And like I said, the Business Model Canvas, the Value Proposition Canvas are fantastic, highly recommended, but they don't cover pricing. So we needed something to cover the actual pricing and packaging and licensing. Ula Ojiaku Well, that's awesome. So it's really more about going, taking a deeper dive into thoughtfully and structurally, if I may use that word, assessing the pricing. Luke Hohmann Yeah, absolutely. Ula Ojiaku Would you say that in doing this there would be some elements of, you know, testing and getting feedback from actual customers to know what price point makes sense? Luke Hohmann Absolutely. There's a number of ways in which customer engagement or customer testing is involved. The very first step that we advocate is a Customer Benefit Analysis, which is what are the actual benefits you're creating and how are your customers experiencing those benefits. Those experiences are both tangible and intangible and that's another one of the challenges that we face in the Agile community. In general, the Agile community spends a little bit more time on tangible or functional value than intangible value. So we, in terms of if I were to look at it in terms of a computer, we used to say speeds and feeds. How fast is the processor? How fast is the network? How much storage is on my disk space? Those are all functional elements. Over time as our computers have become plenty fast or plenty storage wise for most of our personal computing needs, we see elements of design come into play, elements of usability, elements of brand, and we see this in other areas. Cars have improved in quality so much that many of us, the durability of the car is no longer a significant attribute because all cars are pretty durable, they're pretty good, they're pretty well made. So now we look at brand, we look at style, we look at aesthetics, we look at even paying more for a car that aligns with our values in terms of the environment. I want to get an EV, why, because I want to be more environmentally conscious. That's a value driven, that's an intangible factor. And so our first step starts with Customer Benefit Analysis looking at both functional or tangible value and intangible value, and you can't do that, as you can imagine, you can't do that without having customer interaction and awareness with your stakeholders and your customers, and that also feeds throughout the whole pricing process. Eventually, you're going to put your product in a market, and that's a form itself of market research. Did customers buy, and if they didn't buy, why did they not buy? Is it poorly packaged or is it poorly priced? These are all elements that involve customers throughout the process. Ula Ojiaku If I may, I know we've been on the topic of your latest book Software Profit Streams. I'm just wondering, because I can't help but try to connect the dots and I'm wondering if there might be a connection to one of your books, Innovation Games: Creating Breakthrough Products Through Collaborative Play, something like buy a feature in your book, that kind of came to mind, could there be a way of using that as part of the engagement with customers in setting a pricing strategy? I may be wrong, I'm just asking a question. Luke Hohmann I think you're making a great connection. There's two forms of relationship that Innovation Games and the Innovation Games book have with Software Profit Streams. One is, as you correctly noted, just the basics of market research, where do key people have pains or gains and what it might be worth. That work is also included in Alex Osterwalder's books, Value Proposition Design for example, when I've been doing Value Proposition Design and I'm trying to figure out the customer pains, you can use the Innovation Games Speed Boat. And when I want to figure out the gains, I can use the Innovation Game Product Box. Similarly, when I'm figuring out pricing and licensing, a way, and it's a very astute idea, a way to understand price points of individual features is to do certain kinds of market research. One form of market research you can do is Buy-a-Feature, which gives a gauge of what people are willing or might be willing to pay for a feature. It can be a little tricky because the normal construction of Buy-a-Feature is based on cost. However, your insight is correct, you can extend Buy-a-Feature such that you're testing value as opposed to cost, and seeing what, if you take a feature that costs X, but inflate that cost by Y and a Buy-a-Feature game, if people still buy it, it's a strong signal strength that first they want it, and second it may be a feature that you can, when delivered, would motivate you to raise the price of your offering and create a better profit for your company. Ula Ojiaku Okay, well, thank you. I wasn't sure if I was on the right lines. Luke Hohmann It's a great connection. Ula Ojiaku Thanks again. I mean, it's not original. I'm just piggybacking on your ideas. So with respect to, if we, if you don't mind, let's shift gears a bit because I know that, or I'm aware that whilst you were with Scaled Agile Incorporated, you know, you played a key part in developing some of their courses, like the Product POPM, and I think the Portfolio Management, and there was the concept about Participatory Budgeting. Can we talk about that, please? Luke Hohmann I'd love to talk about that, I mean it's a huge passion of mine, absolutely. So in February of 2018, I started working with the framework team and in December of 2018, we talked about the possibility of what an acquisition might look like and the benefits it would create, which would be many. That closed in May of 2019, and in that timeframe, we were working on SAFe 5.0 and so there were a couple of areas in which I was able to make some contributions. One was in Agile product delivery competency, the other was in lean portfolio management. I had a significant hand in restructuring or adding the POPM, APM, and LPM courses, adding things like solutions by horizons to SAFe, taking the existing content on guardrails, expanding it a little bit, and of course, adding Participatory Budgeting, which is just a huge passion of mine. I've done Participatory Budgeting now for 20 years, I've helped organisations make more than five billions of dollars of investment spending choices at all levels of companies, myself and my colleagues at Applied Frameworks, and it just is a better way to make a shared decision. If you think about one of the examples they use about Participatory Budgeting, is my preferred form of fitness is I'm a runner and so, and my wife is also a fit person. So if she goes and buys a new pair of shoes or trainers and I go and buy a new pair of trainers, we don't care, because it's a small purchase. It's frequently made and it's within the pattern of our normal behaviour. However, if I were to go out and buy a new car without involving her, that feels different, right, it's a significant purchase, it requires budgeting and care, and is this car going to meet our needs? Our kids are older than your kids, so we have different needs and different requirements, and so I would be losing trust in my pair bond with my wife if I made a substantial purchase without her involvement. Well, corporations work the same way, because we're still people. So if I'm funding a value stream, I'm funding the consistent and reliable flow of valuable items, that's what value stream funding is supposed to do. However, if there is a significant investment to be made, even if the value stream can afford it, it should be introduced to the portfolio for no other reason than the social structure of healthy organisations says that we do better when we're talking about these things, that we don't go off on our own and make significant decisions without the input of others. That lowers transparency, that lowers trust. So I am a huge advocate of Participatory Budgeting, I'm very happy that it's included in SAFe as a recommended practice, both for market research and Buy-a-Feature in APM, but also more significantly, if you will, at the portfolio level for making investment decisions. And I'm really excited to share that we've just published an article a few weeks ago about Participatory Budgeting and what's called The Color of Money, and The Color of Money is sometimes when you have constraints on how you can spend money, and an example of a constraint is let's say that a government raised taxes to improve transportation infrastructure. Well, the money that they took in is constrained in a certain way. You can't spend it, for example, on education, and so we have to show how Participatory Budgeting can be adapted to have relationships between items like this item requires this item as a precedent or The Color of Money, constraints of funding items, but I'm a big believer, we just published that article and you can get that at the Scaled Agile website, I'm a big believer in the social power of making these financial decisions and the benefits that accrue to people and organisations when they collaborate in this manner. Ula Ojiaku Thanks for going into that, Luke. So, would there be, in your experience, any type of organisation that's participatory? It's not a leading question, it's just genuine, there are typically outliers and I'm wondering in your experience, and in your opinion, if there would be organisations that it might not work for? Luke Hohmann Surprisingly, no, but I want to add a few qualifications to the effective design of a Participatory Budgeting session. When people hear Participatory Budgeting, there's different ways that you would apply Participatory Budgeting in the public and private sector. So I've done citywide Participatory Budgeting in cities and if you're a citizen of a city and you meet the qualifications for voting within that jurisdiction, in the United States, it's typically that you're 18 years old, in some places you have to be a little older, in some places you might have other qualifications, but if you're qualified to participate as a citizen in democratic processes, then you should be able to participate in Participatory Budgeting sessions that are associated with things like how do we spend taxes or how do we make certain investments. In corporations it's not quite the same way. Just because you work at a company doesn't mean you should be included in portfolio management decisions that affect the entire company. You may not have the background, you may not have the training, you may be what my friends sometimes call a fresher. So I do a lot of work overseas, so freshers, they just may not have the experience to participate. So one thing that we look at in Participatory Budgeting and SAFe is who should be involved in the sessions, and that doesn't mean that every single employee should always be included, because their background, I mean, they may be a technical topic and maybe they don't have the right technical background. So we work a little bit harder in corporations to make sure the right people are there. Now, of course, if we're going to make a mistake, we tend to make the mistake of including more people than excluding, partly because in SAFe Participatory Budgeting, it's a group of people who are making a decision, not a one person, one vote, and that's really profoundly important because in a corporation, just like in a para-bond, your opinion matters to me, I want to know what you're thinking. If I'm looking in, I'll use SAFe terminology, if I'm looking at three epics that could advance our portfolio, and I'm a little unsure about two of those epics, like one of those epics, I'm like, yeah, this is a really good thing, I know a little bit about it, this matters, I'm going to fund this, but the other two I'm not so sure about, well, there's no way I can learn through reading alone what the opinions of other people are, because, again, there's these intangible factors. There's these elements that may not be included in an ROI analysis, it's kind of hard to talk about brand and an ROI analysis - we can, but it's hard, so I want to listen to how other people are talking about things, and through that, I can go, yeah, I can see the value, I didn't see it before, I'm going to join you in funding this. So that's among the ways in which Participatory Budgeting is a little different within the private sector and the public sector and within a company. The only other element that I would add is that Participatory Budgeting gives people the permission to stop funding items that are no longer likely to meet the investment or objectives of the company, or to change minds, and so one of the, again, this is a bit of an overhang in the Agile community, Agile teams are optimised for doing things that are small, things that can fit within a two or three week Sprint. That's great, no criticism there, but our customers and our stakeholders want big things that move the market needle, and the big things that move the market needle don't get done in two or three weeks, in general, and they rarely, like they require multiple teams working multiple weeks to create a really profoundly new important thing. And so what happens though, is that we need to make in a sense funding commitments for these big things, but we also have to have a way to change our mind, and so traditional funding processes, they let us make this big commitment, but they're not good at letting us change our mind, meaning they're not Agile. Participatory Budgeting gives us the best of both worlds. I can sit at the table with you and with our colleagues, we can commit to funding something that's big, but six months later, which is the recommended cadence from SAFe, I can come back to that table and reassess and we can all look at each other, because you know those moments, right, you've had that experience in visiting, because you're like looking around the table and you're like, yeah, this isn't working. And then in traditional funding, we keep funding what's not working because there's no built-in mechanism to easily change it, but in SAFe Participatory Budgeting, you and I can sit at the table and we can look at each other with our colleagues and say, yeah, you know, that initiative just, it's not working, well, let's change our mind, okay, what is the new thing that we can fund? What is the new epic? And that permission is so powerful within a corporation. Ula Ojiaku Thanks for sharing that, and whilst you were speaking, because again, me trying to connect the dots and thinking, for an organisation that has adopted SAFe or it's trying to scale Agility, because like you mentioned, Agile teams are optimised to iteratively develop or deliver, you know, small chunks over time, usually two to three weeks, but, like you said, there is a longer time horizon spanning months, even years into the future, sometimes for those worthwhile, meaty things to be delivered that moves the strategic needle if I may use that buzzword. So, let's say we at that lean portfolio level, we're looking at epics, right, and Participatory Budgeting, we are looking at initiatives on an epic to epic basis per se, where would the Lean Startup Cycle come in here? So is it that Participatory Budgeting could be a mechanism that is used for assessing, okay, this is the MVP features that have been developed and all that, the leading indicators we've gotten, that's presented to the group, and on that basis, we make that pivot or persevere or stop decision, would that fit in? Luke Hohmann Yeah, so let's, I mean, you're close, but let me make a few turns and then it'll click better. First, let's acknowledge that the SAFe approach to the Lean Startup Cycle is not the Eric Ries approach, there are some differences, but let's separate how I fund something from how I evaluate something. So if I'm going to engage in the SAFe Lean Startup Cycle, part of that engagement is to fund an MVP, which is going to prove or disprove a given hypothesis. So that's an expenditure of money. Now there's, if you think about the expenditure of money, there's minimally two steps in this process - there's spending enough money to conduct the experiments, and if those experiments are true, making another commitment to spend money again, that I want to spend it. The reason this is important is, let's say I had three experiments running in parallel and I'm going to use easy round numbers for a large corporation. Let's say I want to run three experiments in parallel, and each experiment costs me a million pounds. Okay. So now let's say that the commercialisation of each of those is an additional amount of money. So the portfolio team sits around the table and says, we have the money, we're going to fund all three. Okay, great. Well, it's an unlikely circumstance, but let's say all three are successful. Well, this is like a venture capitalist, and I have a talk that I give that relates the funding cycle of a venture capitalist to the funding cycle of an LPM team. While it's unlikely, you could have all three become successful, and this is what I call an oversubscribed portfolio. I've got three great initiatives, but I can still only fund one or two of them, I still have to make the choice. Now, of course, I'm going to look at my economics and let's say out of the three initiatives that were successfully proven through their hypothesis, let's say one of them is just clearly not as economically attractive, for whatever reason. Okay, we get rid of that one, now, I've got two, and if I can only fund one of them, and the ROI, the hard ROI is roughly the same, that's when Participatory Budgeting really shines, because we can have those leaders come back into the room, and they can say, which choice do we want to make now? So the evaluative aspect of the MVP is the leading indicators and the results of the proving or disproving of the hypotheses. We separate that from the funding choices, which is where Participatory Budgeting and LPM kick in. Ula Ojiaku Okay. So you've separated the proving or disproving the hypothesis of the feature, some of the features that will probably make up an epic. And you're saying the funding, the decision to fund the epic in the first place is a different conversation. And you've likened it to Venture Capital funding rounds. Where do they connect? Because if they're separate, what's the connecting thread between the two? Luke Hohmann The connected thread is the portfolio process, right? The actual process is the mechanism where we're connecting these things. Ula Ojiaku OK, no, thanks for the portfolio process. But there is something you mentioned, ROI - Return On Investment. And sometimes when you're developing new products, you don't know, you have assumptions. And any ROI, sorry to put it this way, but you're really plucking figures from the air, you know, you're modelling, but there is no certainty because you could hit the mark or you could go way off the mark. So where does that innovation accounting coming into place, especially if it's a product that's yet to make contact with, you know, real life users, the customers. Luke Hohmann Well, let's go back to something you said earlier, and what you talked earlier about was the relationship that you have in market researching customer interaction. In making a forecast, let's go ahead and look at the notion of building a new product within a company, and this is again where the Agile community sometimes doesn't want to look at numbers or quote, unquote get dirty, but we have to, because if I'm going to look at building a new idea, or taking a new idea into a product, I have to have a forecast of its viability. Is it economically viable? Is it a good choice? So innovation accounting is a way to look at certain data, but before, I'm going to steal a page, a quote, from one of my friends, Jeff Patton. The most expensive way to figure this out is to actually build the product. So what can I do that's less expensive than building the product itself? I can still do market research, but maybe I wouldn't do an innovation game, maybe I'd do a formal survey and I use a price point testing mechanism like Van Westendorp Price Point Analysis, which is a series of questions that you ask to triangulate on acceptable price ranges. I can do competitive benchmarking for similar products and services. What are people offering right now in the market? Now that again, if the product is completely novel, doing competitive benchmarking can be really hard. Right now, there's so many people doing streaming that we look at the competitive market, but when Netflix first offered streaming and it was the first one, their best approach was what we call reference pricing, which is, I have a reference price for how much I pay for my DVDs that I'm getting in the mail, I'm going to base my streaming service kind of on the reference pricing of entertainment, although that's not entirely clear that that was the best way to go, because you could also base the reference price on what you're paying for a movie ticket and how many, but then you look at consumption, right, because movie tickets are expensive, so I only go to a movie maybe once every other month, whereas streaming is cheap and so I can change my demand curve by lowering my price. But this is why it's such a hard science is because we have this notion of these swirling factors. Getting specifically back to your question about the price point, I do have to do some market research before I go into the market to get some forecasting and some confidence, and research gives me more confidence, and of course, once I'm in the market, I'll know how effective my research matched the market reality. Maybe my research was misleading, and of course, there's some skill in designing research, as you know, to get answers that have high quality signal strength. Ula Ojiaku Thanks for clarifying. That makes perfect sense to me. Luke Hohmann It's kind of like a forecast saying, like there's a group of Agile people who will say, like, you shouldn't make forecasts. Well, I don't understand that because that's like saying, and people will say, well, I can't predict the future. Well, okay, I can't predict when I'm going to retire, but I'm planning to retire. I don't know the date of my exact retirement, but my wife and I are planning our retirement, and we're saving, we're making certain investment choices for our future, because we expect to have a future together. Now our kids are older than yours. My kids are now in university, and so we're closer to retirement. So what I dislike about the Agile community is people will sometimes say, well, I don't know the certainty of the event, therefore, I can't plan for it. But that's really daft, because there are many places in like, you may not for the listeners, her daughter is a little younger than my kids, but they will be going to university one day, and depending on where they go, that's a financial choice. So you could say, well, I don't know when she's going to university, and I can't predict what university she's going to go to, therefore I'm not going to save any money. Really? That doesn't make no sense. So I really get very upset when you have people in the agile community will say things like road mapping or forecasting is not Agile. It's entirely Agile. How you treat it is Agile or not Agile. Like when my child comes up to me and says, hey, you know about that going to university thing, I was thinking of taking a gap year. Okay, wait a minute, that's a change. That doesn't mean no, it means you're laughing, right? But that's a change. And so we respond to change, but we still have a plan. Ula Ojiaku It makes sense. So the reason, and I completely resonate with everything you said, the reason I raised that ROI and it not being known is that in some situations, people might be tempted to use it to game the budget allocation decision making process. That's why I said you would pluck the ROI. Luke Hohmann Okay, let's talk about that. We actually address this in our recent paper, but I'll give you my personal experience. You are vastly more likely to get bad behaviour on ROI analysis when you do not do Participatory Budgeting, because there's no social construct to prevent bad behaviour. If I'm sitting down at a table and that's virtual or physical, it doesn't matter, but let's take a perfect optimum size for a Participatory Budgeting group. Six people, let's say I'm a Director or a Senior Director in a company, and I'm sitting at a table and there's another Senior Director who's a peer, maybe there's a VP, maybe there's a person from engineering, maybe there's a person from sales and we've got this mix of people and I'm sitting at that table. I am not incented to come in with an inflated ROI because those people are really intelligent and given enough time, they're not going to support my initiative because I'm fibbing, I'm lying. And I have a phrase for this, it's when ROI becomes RO-lie that it's dangerous. And so when I'm sitting at that table, what we find consistently, and one of the clients that we did a fair amount of Participatory Budgeting for years ago with Cisco, what we found was the leaders at Cisco were creating tighter, more believable, and more defensible economic projections, precisely because they knew that they were going to be sitting with their peers, and it didn't matter. It can go both ways. Sometimes people will overestimate the ROI or they underestimate the cost. Same outcome, right? I'm going to overestimate the benefit, and people would be like, yeah, I don't think you can build that product with three teams. You're going to need five or six teams and people go, oh, I can get it done with, you know, 20 people. Yeah, I don't think so, because two years ago, we built this product. It's very similar, and, you know, we thought we could get it done with 20 people and we couldn't. We really needed, you know, a bigger group. So you see the social construct creating a more believable set of results because people come to the Participatory Budgeting session knowing that their peers are in the room. And of course, we think we're smart, so our peers are as smart as we are, we're all smart people, and therefore, the social construct of Participatory Budgeting quite literally creates a better input, which creates a better output. Ula Ojiaku That makes sense, definitely. Thanks for sharing that. I've found that very, very insightful and something I can easily apply. The reasoning behind it, the social pressure, quote unquote, knowing that you're not just going to put the paper forward but you'd have to defend it in a credible, believable way make sense. So just to wrap up now, what books have you found yourself recommending to people the most, and why? Luke Hohmann It's so funny, I get yelled at by my wife for how many books I buy. She'll go like “It's Amazon again. Another book. You know, there's this thing called the library.” Ula Ojiaku You should do Participatory Budgeting for your books then sounds like, sorry. Luke Hohmann No, no, I don't, I'd lose. Gosh, I love so many books. So there's a few books that I consider to be my go-to references and my go-to classics, but I also recommend that people re-read books and sometimes I recommend re-reading books is because you're a different person, and as you age and as you grow and you see things differently and in fact, I'm right now re-reading and of course it goes faster, but I'm re-reading the original Extreme Programming Explained by Kent Beck, a fantastic book. I just finished reading a few new books, but let me let me give you a couple of classics that I think everyone in our field should read and why they should read them. I think everyone should read The Mythical Man-Month by Fred Brooks because he really covers some very profound truths that haven't changed, things like Brooks Law, which is adding programmers to a late project, makes it later. He talks about the structure of teams and how to scale before scaling was big and important and cool. He talks about communication and conceptual integrity and the role of the architect. The other book that I'm going to give, which I hope is different than any book that anyone has ever given you, because it's one of my absolute favourite books and I give them away, is a book called Understanding Comics by Scott McCloud. Comics or graphic novels are an important medium for communication, and when we talk about storytelling and we talk about how to frame information and how to present information, understanding comics is profoundly insightful in terms of how to present, share, show information. A lot of times I think we make things harder than they should be. So when I'm working with executives and some of the clients that I work with personally, when we talk about our epics, we actually will tell stories about the hero's journey and we actually hire comic book artists to help the executives tell their story in a comic form or in a graphic novel form. So I absolutely love understanding comics. I think that that's really a profound book. Of course you mentioned Alex Osterwalder's books, Business Model Generation, Business Model Canvas. Those are fantastic books for Product Managers. I also, just looking at my own bookshelves, of course, Innovation Games for PMs, of course Software Profit Streams because we have to figure out how to create sustainability, but in reality there's so many books that we love and that we share and that we grow together when we're sharing books and I'll add one thing. Please don't only limit your books to technical books. We're humans too. I recently, this week and what I mean recent I mean literally this weekend I was visiting one of my kids in Vermont all the way across the country, and so on the plane ride I finished two books, one was a very profound and deeply written book called Ponyboy. And then another one was a very famous book on a woman protagonist who's successful in the 60s, Lessons in Chemistry, which is a new book that's out, and it was a super fun light read, some interesting lessons of course, because there's always lessons in books, and now if it's okay if I'm not overstepping my boundaries, what would be a book that you'd like me to read? I love to add books to my list. Ula Ojiaku Oh my gosh, I didn't know. You are the first guest ever who's twisted this on me, but I tend to read multiple books at a time. Luke Hohmann Only two. Ula Ojiaku Yeah, so, and I kind of switch, maybe put some on my bedside and you know there's some on my Kindle and in the car, just depending. So I'm reading multiple books at a time, but based on what you've said the one that comes to mind is the new book by Oprah Winfrey and it's titled What Happened to You? Understanding Trauma, because like you said, it's not just about reading technical books and we're human beings and we find out that people behave probably sometimes in ways that are different to us, and it's not about saying what's wrong with you, because there is a story that we might not have been privy to, you know, in terms of their childhood, how they grew up, which affected their worldview and how they are acting, so things don't just suddenly happen. And the question that we have been asked and we sometimes ask of people, and for me, I'm reading it from a parent's perspective because I understand that even more so that my actions, my choices, they play a huge, you know, part in shaping my children. So it's not saying what's wrong with you? You say, you know, what happened to you? And it traces back to, based on research, because she wrote it with a renowned psychologist, I don't know his field but a renowned psychologist, so neuroscience-based psychological research on human beings, attachment theory and all that, just showing how early childhood experiences, even as early as maybe a few months old, tend to affect people well into adulthood. So that would be my recommendation. Luke Hohmann Thank you so much. That's a gift. Ula Ojiaku Thank you. You're the first person to ask me. So, my pleasure. So, before we go to the final words, where can the audience find you, because you have a wealth of knowledge, a wealth of experience, and I am sure that people would want to get in touch with you, so how can they do this please? Luke Hohmann Yeah, well, they can get me on LinkedIn and they can find me at Applied Frameworks. I tell you, I teach classes that are known to be very profound because we always reserve, myself and the instructors at Applied Frameworks, we have very strong commitments to reserving class time for what we call the parking lot or the ask me anything question, which are many times after I've covered the core material in the class, having the opportunity to really frame how to apply something is really important. So I would definitely encourage people to take one of my classes because you'll not get the material, you'll get the reasons behind the material, which means you can apply it, but you'll also be able to ask us questions and our commitment as a company is you can ask us anything and if we don't know the answer, we'll help you find it. We'll help you find the expert or the person that you need talk to, to help you out and be successful. And then, and I think in terms of final words, I will simply ask people to remember that we get to work in the most amazing field building things for other people and it's joyful work, and we, one of my phrases is you're not doing Agile, if you're not having fun at work, there's something really wrong, there's something missing, yeah we need to retrospect and we need to improve and we need to reflect and all those important things, absolutely, but we should allow ourselves to experience the joy of serving others and being of service and building things that matter. Ula Ojiaku I love the concept of joyful Agile and getting joy in building things that matter, serving people and may I add also working together with amazing people, and for me it's been a joyful conversation with you, Luke, I really appreciate you making the time, I am definitely richer and more enlightened as a result of this conversation, so thank you so much once more. Luke Hohmann Thank you so much for having me here, thank you everyone for listening with us. Ula Ojiaku  My pleasure. That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com or your favourite podcast provider. Also share with friends and do leave a review on iTunes. This would help others find this show. I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com Take care and God bless!   

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 episode of the Engineering Room, Dave Farley and Kent Beck have a wide-ranging discussion about the return of waterfall development in software, TDD, Software Design and lots of other things along the way. Kent Beck is the first signatory of the Agile Manifesto. He is the author of the industry-changing book "Extreme Programming Explained". Kent popularised Continuous Integration and TDD and wrote the first version of xUnit, the unit testing framework that has informed the design of unit testing frameworks ever since. It is hard to imagine people who aren't familiar with Kent Beck's work, but even if that is the case, his work has had an impact on how you think about, and practice software development and software engineering.xx⭐ PATREON: Join the Continuous Delivery community and access extra perks & content! ➡️ https://bit.ly/ContinuousDeliveryPatreon

In 2002, Kent Beck released a book called  "Test Driven Development by Example".In December of 2023, Kent wrote an article called "Canon TDD".With Kent's permission, this episode contains the full content of the article.Brian's commentary is saved for a followup episode.Links:Canon TDDTest Driven Development by Example The Complete pytest CourseLevel up your testing skills and save time during coding and maintenance.Check out courses.pythontest.com

In this episode, Matt Swanson returns to discuss YAGNI (you ain't gonna need it),  Kent Beck's quote "make the change easy (warning: this may be hard) then make the easy change," why educational materials for beginners abound, but that's not the case for intermediate and advanced developers, what drives people to create educational materials, the purpose of testing, and being judicious in what you spend your time thinking about.Matt Swanson on TwitterMatt Swanson on GitHubMatt Swanson on DevTo

In this conversation live from RubyConf San Diego, Andrew and Julie sit down with Elise Shaffer, host of The Ruby on Rails Podcast. They kick things off with sharing conference experiences, the joy of reconnecting with friends, and the unique energy the in-person events bring. The discussion shifts to the concept and practice of Test Driven Development (TDD), its benefits, and how it aids in problem-solving during coding.  An interesting point is discussed about whether tests or code should be written first, and whether it's okay to write tests after the code.  They also dive into the handling of tests on legacy codes within Rails. The conversation wraps up with gratitude to the organizers, speakers, volunteers, and attendees at RubyConf. Press download now to hear more! [00:00:24] Elise shares her conference experience mentioning enjoying the sessions and seeing friends from previous conferences, and Julie and Andrew share their joy of being in the company of friends, the conference atmosphere, and food.  [00:01:39] Elise shares the number of Ruby and Rails conferences she's attended and her most memorable one which was Steel City Ruby, highlighting the value of smaller conferences and tight-knit communities. [00:02:45] They discuss the difference between in-person and online conferences, agreeing that in-person events offer more energy and interaction. [00:03:50] The conversation shifts to memorable conferences as Andrew reminisces about his first conference experience at RailsConf in Pittsburgh. Julie talks about her first conference, RailsConf 2022 in Portland, where she met Elise and Andrew and where Ruby for All was conceived.[00:06:12] Andrew asks Julie about her rise in popularity withing a year, moving from a newcomer toa recognized member of the community. The group jokes about autographs and fame within the Ruby community. Elise shares her role in the community, especially with the podcast she hosts. [00:09:33] Elise and Andrew discuss the technical aspects of testing and continuous integration within software development. She explains her background in Ruby and Rails, where she focused on testing and its challenges in larger applications, and she discusses strategies for testing and the importance of testing not every permutation but preventing major issues, [00:12:46] Julie asks Elise to explain parallelized testing.  Elise details using CircleCl or other runners to break up many tests across multiple workers to speed up the process.[00:13:56] Elise explains what Test Driven Development (TDD) means to her, and Julie asks whether TDD is always applicable, like when fixing a bug rather than creating a new feature. [00:15:30] Elise wishes TDD was still popular and stresses that TDD is a skill that must be developed. She describes the advantages of TDD, particularly in large applications, where having a robust test suite allows for faster development and less worry about breaking something inadvertently. [00:18:58] Andrew challenges the concept of TDD, suggesting that for a talented engineer, tests might seem like a waste of time.  Elise responds by emphasizing that TDD is a thinking tool that aids in understanding the problem. [00:20:59] The discussion turns to reviewing tests.  Elise explains her approach to reviewing pull requests by checking the problem solved, reviewing commits one at a time, and comparing her list of tests with the submitted ones, placing higher importance on the tests than the code itself. [00:24:02] Elise and Andrew compare their personal styles in reviewing code and the importance of preparing commit messages for review. Julie is curious how Elise and Andrew manage their commit history and whether they use the command line for combining commits. Andrew mentions using interactive rebase. [00:24:47] If you're interested in getting into TDD, Elise tells us she's working on a course about test driving in Rails applications coming out on early next year , but also recommends reading two great books: Test Driven Development: By Example by Kent Beck and 99 Bottles of OOP by Sandi Metz.[00:25:33] Julie questions how to handle TDD in a legacy codebase with complex and nested tests. Elise suggests pairing with someone more knowledgeable to break up the tests into smaller, more manageable files. Panelists:Andrew MasonJulie J.Guest:Elise ShafferSponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteElise Shaffer WebsiteElise Shaffer GitHubThe Ruby on Rails PodcastCircleCITest Driven Development: By Example by Kent Beck99 Bottles of OOP by Sandi Metz (00:24) - - Introduction and conference experience (01:39) - - Memorable conferences and tight-knit communities (02:45) - - In-person vs. online conferences (03:50) - - First conference experiences (06:12) - - Julie's rise in popularity and fame in the community (09:33) - - Testing and continuous integration in software development (12:46) - - Parallelized testing and speeding up test processes (13:56) - - Test Driven Development (TDD) and its applicability (15:30) - - Advantages of TDD and its role in understanding problems (18:58) - - Challenges to the concept of TDD (20:59) - - Reviewing tests and pull requests (24:02) - - Managing commit history and using interactive rebase (24:47) - - Recommendations for learning TDD (25:33) - - Handling TDD in legacy codebases

Suppose you believed that the ecological/embodied cognitive scientists of last episode had a better grasp on cognition than does our habitual position that the brain is a computer, passively perceiving the environment, then directing the body to perform steps in calculated plans. If so, technical practices like test-driven design, refactoring in response to "code smells," and the early-this-century fad for physical 3x5 cards might make more sense. I explain how. I also sketch how people might use such ideas when designing their workplace and workflow. Books I drew uponAndy Clark, Being There: Putting Brain, Body, and World Together Again, 1997Alva Noë, Action in Perception, 2005Also mentionedGary Klein, Sources of Power: How People Make Decisions, 1998I mentioned a session of the Simple Design and Test conference.The sociology book I contributed to: The Mangle in Practice: Science, Society, and Becoming, 2009, edited by Andrew Pickering and Keith Guzik. My chapter, "A Manglish Way of Working: Agile Software Development", is inexplicably available without a paywall.The MIT AI Lab Jargon FileI believe the original publication about CRC cards is Kent Beck and Ward Cunningham, "A laboratory for teaching object oriented thinking", 1989. I also believe the first book-type description was in Rebecca Wirfs-Brock et. al., Designing Object-Oriented Software, 1990. The idea of "flow" was first popularized in Mihály Csíkszentmihályi's 1990 Flow: The Psychology of Optimal Experience. The idea of the hedgehog and the fox was popularized by Isaiah Berlin in his 1953 book The Hedgehog and the Fox (a wikipedia link).The original developer of the Pomodoro technique describes it here. There was a book about it, but Goodreads has been sufficiently enshittified that I can't find it. Perhaps you might be interested in Reduce PTSD and Depression Symptoms in 21 Days Using the Pomodoro Method instead? Because Goodreads prefers that.The Boy Who Cried World (wikipedia)CreditsI was helped by Steve Doubleday, Ron Jeffries, and Ted M. Young. I took the picture of Dawn in the tango close embrace.

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. 

Can you measure developer productivity? Prompted by an article by McKinsey and already reacted to by many, we ask if McKinsey is telling us to measure something that is at all useful, how to think about the problem McKinsey raises, and what you, as a technical leader, can do to address that problem better than what McKinsey suggests. Opening quote from The Psychology of Computer Programming by Gerald M. Weinberg. References: Mckinsey article - https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity Kent Beck's response part 1 - https://tidyfirst.substack.com/p/measuring-developer-productivity Kent Beck's response part 2 - https://tidyfirst.substack.com/p/measuring-developer-productivity-440 Dave Farley's response - https://www.youtube.com/watch?v=yuUBZ1pByzM Dan North's response - published after we recorded - https://dannorth.net/mckinsey-review/ Untangling the metrics request - https://podcasters.spotify.com/pod/show/tactics-tech-leadership/episodes/Untangling-the-Metrics-Request-e27906b --- Send in a voice message: https://podcasters.spotify.com/pod/show/tactics-tech-leadership/message

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.

The debate on measuring developer productivity has arrived - and it's here to stay. On this week's episode of Dev Interrupted, cohost Conor Bronsdon welcomes LinearB cofounder & CEO Ori Keren and Kelly Vaughn, Director of Engineering at Spot AI, to offer their critiques of a debate that has captured the attention of the engineering community: can you measure developer productivity?Consulting giant McKinsey published an article that ignited a firestorm, prompting industry leaders Kent Beck and Gergely Orosz to counter with a detailed 2-part response via the Pragmatic Engineer.Believing the industry to be at a crossroads, Ori and Kelly combine forces to offer their perspective on the debate, sharing why it's an opportunity for dev teams everywhere to “roll out metrics the right way.”Show Notes:The McKinsey article: Yes, you can measure software developer productivityOrosz & Beck 1: Measuring developer productivity? A response to McKinsey, Part 1Orosz & Beck 2: Measuring developer productivity? A response to McKinsey, Part 2CTO Board SlidesKelly's newsletter: Lessons in Engineering LeadershipRegister for the 2023 Engineering Benchmarks Report Release WebinarSupport the show: Subscribe to our Substack Leave us a review Subscribe on YouTube Follow us on Twitter or LinkedIn Offers: Learn about Continuous Merge with gitStream Want to try LinearB? Book a Demo & use discount code "Dev Interrupted Podcast"

  Dans cet épisode de rentrée, Antonio et Arnaud ont le plaisir d'accueillir Katia Aresti dans l'équipe. Ils passent en revue les dernières nouveautés et sujets chauds de cette rentrée, notamment la sortie de Java 21, les nouvelles versions de Quarkus, Micronaut, Hibernate, NodeJS, Redis, et bien d'autres encore. Ils discutent de sujets plus généraux tels que l'observabilité, la nouvelle tendance “Platform Engineering”, et la productivité des développeurs. Ils abordent aussi les sujets sur la sécurité, tels que les failles sur les CPUs Intel et AMD, ainsi que la vie privée, avec les Tracking APIs de Chrome, Firefox et le projet de loi SREN. Le tout est agrémenté de sa dose d'IA, avec des librairies telles que Semantic Kernel, ainsi que des sujets plus haut niveau tels que Google Gemini, Meta GPT, LLama 2, et les biais et la consommation énergétique de l'IA. Enregistré le 8 septembre 2023 Téléchargement de l'épisode LesCastCodeurs-Episode–299.mp3 News Langages Apache Groovy a 20 ans! https://twitter.com/ApacheGroovy/status/1695388098950217909 L'annonce du lancement du projet par James Strachan https://web.archive.org/web/20030901064404/http://radio.weblogs.com/0112098/2003/08/29.html Le projet a depuis énormément évolué et après plusieurs vies a été adopté par la fondation Apache en 2015 Java 21 arrive le 19 septembre https://www.infoworld.com/article/3689880/jdk–21-the-new-features-in-java–21.html. C'est la nouvelle LTS Pas mal de nouvelles fonctionnalités comme les virtual threads, le pattern matching sur les switch, sequenced collections … Retrouvez le 19 septembre une interview de Jean-Michel Doudoux par Charles Sabourdin pour l'épisode 300 des castcodeurs! Librairies Semantic Kernel pour Java est (en train de) sorti: https://devblogs.microsoft.com/semantic-kernel/introducing-semantic-kernel-for-java/ Framework OSS pour faire de l'IA .Net et Python Java 0.2.7 Alpha est publié Kernel car il est tout petit Se connecte à plusieurs fournisseurs (aujourd'hui OpenAI, Azure AI, Hugging Face), plusieurs DB vectorielles, plusieurs template de prompt (suit la specification de OpenAI) OpenSSL qui committe https://www.openssl.org/blog/blog/2023/07/17/who-writes-openssl/ en majorité des OSS payés puis des gens payés par leur boite et enfi des contributeurs non payés c'est ne passant rapide mais ca montre que depuis heartbleed, ca a changé Micronaut 4.1.0 https://micronaut.io/2023/09/01/micronaut-framework–4–1–0-released/ Bean Mappers pour créer automatiquement une correspondance entre un type et un autre un Introspection Builder l'annotation @Introspected pour générer un builder dynamique si un type ne peut être construit que via un modèle builder améliorations pour les développeurs utilisant Kotlin Symbol Processing (KSP) Quarkus 3.3.1 / 3.3.2 https://quarkus.io/blog/quarkus–3–3–1-released/ https://quarkus.io/blog/quarkus–3–3–2-released/ Pas mal de fixes https://github.com/quarkusio/quarkus/releases/tag/3.3.1 https://github.com/quarkusio/quarkus/releases/tag/3.3.2 Il est important de noter qu'un problème de dégradation des performances et de la mémoire a été introduit dans Quarkus 3.3. Ce problème est corrigé dans Quarkus 3.3.2. Hibernate ORM 6.3.0 et 6.2.8 https://hibernate.org/orm/ et Hibernate Reactive 2.0.5 un support initial de la spécification Jakarta Persistence 3.2 Un nouveau guide d'introduction Hibernate 6, un nouveau guide de syntaxe et de fonctionnalités pour le langage de requête Hibernate (Hibernate Query Language) Annotation @Find sur des méthodes -> créer des méthodes de recherche similaires aux méthodes de requête Reactive compatible avec Hibernate ORM 6.2.8.Final, certains changements d'api Infrastructure Une série d'articles sur l'observabilité par Mathieu Corbin Observability: tout ce que vous avez toujours voulu savoir sur les métriques: https://www.mcorbin.fr/posts/2023–07–04-metriques/ Tracing avec Opentelemetry: pourquoi c'est le futur (et pourquoi ça remplacera les logs): https://www.mcorbin.fr/posts/2023–08–20-traces/ L'auteur reprend les bases sur l'observabilité. Qu'est ce qu'une métrique ? Les labels, les cardinalités Les types de métriques (Compteurs, jauges, quantiles et histogrammes) C'est quoi le tracing ? Traces, Spans, Resources, Scopes qu'est ce que c'est? Les Events pour remplacer les logs? Web NodeJS 20.6.0 est disponible et ajoute le support des fichiers .env https://philna.sh/blog/2023/09/05/nodejs-supports-dotenv/ Configurable avec l'option --env-file Le fichier .env peut contenir des variables d'environnement et commentaires # Attention par contre: pas de lignes multiples ni d'extension de variables Vous pouvez par exemple configurer NODE_OPTIONS avec ce système Data Redis 7.2 est sorti ! https://redis.com/blog/introducing-redis–7–2/ Auto-tiering : cette nouvelle fonctionnalité permet de stocker les données sur des supports de stockage différents, en fonction de leur importance et de leur fréquence d'accès. Cela permet d'améliorer les performances et la scalabilité de Redis. RESP3 : cette nouvelle version du protocole RESP permet une communication plus efficace entre Redis et les clients. Improvements to performance : de nombreuses améliorations de performances ont été apportées à Redis 7.2, notamment pour les opérations de lecture et d'écriture. New commands : plusieurs nouvelles commandes ont été ajoutées à Redis 7.2, notamment : CLIENT NO-TOUCH : cette commande permet d'empêcher un client d'être touché par une opération AOF ou RDB. WAITAOF : cette commande permet d'attendre que l'AOF soit écrite avant de poursuivre l'exécution. Dans le podcast sont cités les hot replacement des Redis, comme https://www.dragonflydb.io/ Architecture Article sur Google Gemini et sa capacité a battre ChatGPT https://www.semianalysis.com/p/google-gemini-eats-the-world-gemini Google a raté les premiers pas (ils avient le meilleur LLM public avant ChatGPT 3) ET les chercheurs qui invente le champs des LLMs Google va 5x ChatGPT–4 avant al fin de l'année, mais vont-il les publier les chercheurs se tirent la bourre sur le nombre de GPU (H100) auxquels ils ont accès ; ce sont lers grosses orga comme Meta OpenAI Google et les autres qui lutent avec des GPU qui n'ont pas assez de VRAM et ce qu'ils vont faire c'est de la merde et sans consequence le peuple utilise le modele dense de LLAMA mais pour les environnements contraints ca serait mieux des sparse models et du speculative decoding. ils devraient se concentre sur la performance de modele qui utilise plus de compute et memoire en evitant de consommer de la bande passante de memoire, c'est ce que l'edge a besoin les benchmarks public ne mesurent pas des choses utiles meme hugging faces est dans la category des pauvres de GPU Nvidia est entrain de se construire une machine de guerre (service) la chine et les us vont etre en competition mais l'europe qui fait du GPU pauvre ne va pas s'en sortir les startups ne peuvent pas payer les GPU en actiosn, il faut du cash Tout le monde rempli les poches de NVidia, sand Google Gogole grossi exponentiellement ses propres GPUs Meta GPT https://www.infoq.com/news/2023/08/metagpt-agent-collaboration/ IA: les biais et énergie qui consomme par Leslie Miley tech advisor du CTO de Microsoft https://www.infoq.com/presentations/ai-bias-sustainability nouvels infranstructures consommation énergétique et d'eau des data center pour IA est terriblement coûteuse l'impact des infrastructures sur les comunautés (bruit) explique bien son point de vu sur les problèmes d'amplification des biais du IA propose des stratégies pour mitiger l'impact negatif Kubeflow toolkit pour deployer machine learning (ML) workflow en Kubernetes est accepté par la CNCF (Cloud Native Computing Foundation) https://www.infoq.com/news/2023/08/kubeflow-cncf-project Méthodologies Measuring developer productivity? A response to McKinsey by Kent Beck and Gergely Orosz (pragmaticengineer.com) https://tidyfirst.substack.com/p/measuring-developer-productivity McKinsey a sorti un article où ils expliquent la recette miracle recherchée par tous les managers comme le graal: Comment mesurer la productivité des développeurs? (faut bien vendre du conseil) Kent et Gergely partent d'un model mental de description de la création de valeur par le développeur pour ensuite voir quels sont les besoins de mesurer la productivité et comparent cela avec d'autres secteurs (la vente, le support, le recrutement). Ils concluent cette première partie avec les compromis à faire pour que ce type de mesures ait un intérêt sans impacter trop négativement les développeurs un autre article dans la même lignée de Martin Fowler https://martinfowler.com/bliki/CannotMeasureProductivity.html Et si on parlait de Platform Engineering ? DevOps vs. SRE vs. Platform Engineering (humanitec.com) What is platform engineering? (gartner.com) / What is platform engineering? (platformengineering.org) Internal Developer Platform Cognitive load Team topologies Engineering Effectiveness (thoughtworks.com) and Maximize your tech investments with Engineering Effectiveness (thoughtworks.com) Ces différents articles retracent la génèse du concept de Platform Engineering L'activité de Platform Engineering vient en réponse à la charge cognitive rajoutée aux équipes techs dans des transitions DevOps loupées (You build it, you run it … et vous vous débrouillez). Cela conduit à la création de golden paths et d'une Internal Developers Platform qui doit proposer en interne les services nécessaires aux équipes pour livrer leurs produits le lus efficacement possible tout en suivant les critères de qualité, de compliance de l'entreprise. Pour en savoir plus, une table ronde à laquelle Arnaud a participé en Juillet : https://youtu.be/N-tN7HUA4No?si=2P0wSqG32MLWUlGq On call Process (Astreinte) , startup TinyBird par VP Engineering Félix López (ex google, ex eventbrite) https://thenewstack.io/keeping-the-lights-on-the-on-call-process-that-works/ Si votre produit est SAAS, on doit avoir des astreintes. Cela impose un lourd fardeau à ceux qui doivent être en astreinte,, surtout en petite entreprise Petites entreprises évitent avoir un processus d'astreinte formel pour éviter le stress. Cela crée dans la pratique plus de stress: Si personne n'est responsable, tout le monde est responsable. Tinybird est la plateforme de données en temps réel pour les développeurs et les équipes de données. Pré création du process formel chez Tinybird: désorganisé, non structuré et stressant Mise en place: Principes fondamentaux d'un processus d'astreinte: L'astreinte n'est pas obligatoire, minimiser le bruit, pas seulement pour les SRE, alert = runbook, avoir des backups pour la personne en astreinte, appeler quelqu'un devrait être la dernière solution, minimiser le temps en astreinte L'article explique comment ils sont passé regarder chaque alerte (comprehensible?, exploitable?), puis avoir un board grafana pour chacune et plan spécifique. Une fois le tri fait, tout migré vers un seul channel de com, et manuel d'astreinte pour chaque alerte. Itérer. Multiples benefices sur le long terme: rapports d'incident ouvert, atténuer les problèmes futurs, renforcement la propriété et les connaissances du code et systèmes au sein de toute l'équipe etc. Sécurité Downfall, une nouvelle faille de sécurité sur les processeurs intel ( https://www.lemondeinformatique.fr/actualites/lire-la-faille-downfall-met-a-mal-des-milliards-de-processeurs-intel–91247.html ) et AMD ne fait pas mieux avec une faille nommée Inception (https://www.lemondeinformatique.fr/actualites/lire-les-puces-amd-vulnerables-a-la-faille-inception–91273.html) Downfall, La vulnérabilité est due à des fonctions d'optimisation de la mémoire dans les processeurs Intel qui révèlent involontairement les registres matériels internes aux logiciels. Cela permet à des logiciels non-fiables d'accéder à des données stockées par d'autres programmes, qui ne devraient normalement pas être accessibles. Tous les PC ou ordinateurs portables équipés de processeurs Intel Core de la 6e génération Skylake jusqu'aux puces Tiger Lake de 11e génération incluses contiennent cette faille. Les derniers processeurs Core 12e et 13e génération d'Intel ne sont pas concernés. Inception, nécessite un accès local au système pour être potentiellement exploité ce qui en limite de fait la portée. Tous les processeurs AMD depuis 2017 sont touchés, incluant les derniers modèles Zen 4 Epyc et Ryzen Comment désactiver le nouveau tracking publicitaire ciblé sur Chrome https://www.blogdumoderateur.com/chrome-comment-desactiver-tracking-publicitaire-cible/ Google a annoncé en juillet le déploiement de sa nouvelle API Topics, permettant « à un navigateur de partager des informations avec des tiers sur les intérêts d'un utilisateur tout en préservant la confidentialité ». C'est cette API, incluse dans la version Chrome 115 de juillet 2023, qui est censée remplacer les cookies tiers. Loi, société et organisation Une nouvelle definition d'open pour Llama 2? https://opensourceconnections.com/blog/2023/07/19/is-llama–2-open-source-no-and-perhaps-we-need-a-new-definition-of-open/ c'est relativement “open” mais il y a des restrictions donc pas open source pas plus de 700 M d'utilisateurs par mois pas le droit d'utiliser Llama pour améliorer d'autres modèles autres que dse dérivés de Llama et c'est le modele final qui est ouvert, pas la sauce pour le construire, donc pas de maven build ni le “source code” pour y arriver “from scratch” attention au risuqe de sacrivier open source pour avoir l'IA plus vite, plus facile HashiCorp passe tous ses projets open source en BSL, comme Confluent, Mongo, Redis, Elastic, etc https://thenewstack.io/hashicorp-abandons-open-source-for-business-source-license/ Couverture par InfoQ https://www.infoq.com/news/2023/08/hashicorp-adopts-bsl/ Fork de Terraform : OpenTF, avec pour objectif de rejoindre la CNCF https://opentf.org/announcement Stack overflow annonce Overflow AI https://www.infoq.com/news/2023/09/stackoverflow-overflowai/ l'intégration de l'IA générative dans leur plateforme publique, Stack Overflow for Teams, ainsi que de nouveaux domaines de produits IA/ML aident à générer des balises initiales et à suggérer des paires question-réponse, permettant aux développeurs de se concentrer sur l'amélioration et la précision Amélioration des Capacités de Recherche Les forums de questions-réponses basés sur la communauté sont le cœur battant de Stack Overflow. Selon Prashanth Chandrasekar, PDG de Stack Overflow, l'objectif d'OverflowAI est d'améliorer la communauté de diverses manières plutôt que de la remplacer complètement. Vous avez entendu parler du projet de loi SREN ? http://share.mozilla.org/817319645t Le gouvernement français prépare une loi qui pourrait menacer la liberté sur Internet. Le projet de loi visant à sécuriser et réguler l'espace numérique (SREN) obligerait les navigateurs web, comme Mozilla Firefox, à bloquer des sites web directement au niveau du navigateur. Mozilla lance une pétition pour retirer cette n-ieme solution stupide pour censurer Internet Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 8 septembre 2023 : JUG Summer Camp - La Rochelle (France) 14 septembre 2023 : Cloud Sud - Toulouse (France) & Online 18 septembre 2023 : Agile Tour Montpellier - Montpellier (France) 19 septembre 2023 : Salon de la Data Nantes - Nantes (France) & Online 19–20 septembre 2023 : Agile en Seine - Paris (France) 21–22 septembre 2023 : API Platform Conference - Lille (France) & Online 22 septembre 2023 : Agile Tour Sophia Antipolis - Valbonne (France) 25–26 septembre 2023 : BIG DATA & AI PARIS 2023 - Paris (France) 28–30 septembre 2023 : Paris Web - Paris (France) 2–6 octobre 2023 : Devoxx Belgium - Antwerp (Belgium) 6 octobre 2023 : DevFest Perros-Guirec - Perros-Guirec (France) 10 octobre 2023 : ParisTestConf - Paris (France) 11–13 octobre 2023 : Devoxx Morocco - Agadir (Morocco) 12 octobre 2023 : Cloud Nord - Lille (France) 12–13 octobre 2023 : Volcamp 2023 - Clermont-Ferrand (France) 12–13 octobre 2023 : Forum PHP 2023 - Marne-la-Vallée (France) 13–14 octobre 2023 : SecSea 2K23 - La Ciotat (France) 17–20 octobre 2023 : DrupalCon Lille - Lille (France) 19–20 octobre 2023 : DevFest Nantes - Nantes (France) 19–20 octobre 2023 : Agile Tour Rennes - Rennes (France) 26 octobre 2023 : Codeurs en Seine - Rouen (France) 30 septembre 2023 : ScalaIO - Paris (France) 26–27 octobre 2023 : Agile Tour Bordeaux - Bordeaux (France) 26–29 octobre 2023 : SoCraTes-FR - Orange (France) 10 novembre 2023 : BDX I/O - Bordeaux (France) 15 novembre 2023 : DevFest Strasbourg - Strasbourg (France) 16 novembre 2023 : DevFest Toulouse - Toulouse (France) 18–19 novembre 2023 : Capitole du Libre - Toulouse (France) 23 novembre 2023 : DevOps D-Day #8 - Marseille (France) 23 novembre 2023 : Agile Grenoble - Grenoble (France) 30 novembre 2023 : PrestaShop Developer Conference - Paris (France) 30 novembre 2023 : WHO run the Tech - Rennes (France) 6–7 décembre 2023 : Open Source Experience - Paris (France) 7 décembre 2023 : Agile Tour Aix-Marseille - Gardanne (France) 7–8 décembre 2023 : TechRocks Summit - Paris (France) 8 décembre 2023 : DevFest Dijon - Dijon (France) 31 janvier 2024–3 février 2024 : SnowCamp - Grenoble (France) 6–7 mars 2024 : FlowCon 2024 - Paris (France) 19–22 mars 2024 : KubeCon + CloudNativeCon Europe 2024 - Paris (France) 28–29 mars 2024 : SymfonyLive Paris 2024 - Paris (France) 17–19 avril 2024 : Devoxx France - Paris (France) 25–26 avril 2024 : MiXiT - Lyon (France) 25–26 avril 2024 : Android Makers - Paris (France) 6–7 juin 2024 : DevFest Lille - Lille (France) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

An airhacks.fm conversation with Ceki Guelcue (@ceki) about: previously Ceki on airhacks.fm: "#241 Simplicity is a Good Incentive", Log4j was used inside a 2FA application, Zurich Research Lab Log (ZRL) became Log4j, Log4j was published at IBM developer works, Kent Beck on unit testing, the purpose of unit testing, the hierarchical filtering in Log4j, mapping log levels to exceptions, business logs and system logs, ndc, Logback markers, selling a self-published Log4j book, Log4j and LMAX Disruptor, Log4j 2 is only loosely related to Log4j v1, Jakarta Commons Logging is a logging facade, Log4j 2 is the successor of Logback, Logback is the native implementation of slf4j, SLF4j provides a narrow Logging API, reload4j is a forked and maintained version of Log4j v1, using jelly to program XML Ceki Guelcue on twitter: @ceki

René is a Principal Cloud Solution Architect - Engineering (CSA-E) and technical lead for Azure DevOps and software development processes at Microsoft in Germany. In his role as CE, he helps customers adopt good development practices and processes as well as understanding the principles of DevOps. As an Azure DevOps expert, René trains customers in using the DevOps toolchain and shows ways to integrate Azure DevOps into existing heterogeneous environments.   Before his start at Microsoft in late 2008, René had been working as a developer of enterprise logistic systems for almost ten years.   Topics of Discussion: [3:05] René's start of his career and how he got into programming. [5:20] How does René define the real difference between the 1990s waterfall mindset and the agile mindset, just from a process perspective? [7:49] How DevOps is an evolution of Agile. [9:13] What is DevOps all about? [11:29] The three ways of DevOps as described in The Phoenix Project: Maximize flow or system thinking. Amplify feedback loops. The culture of continuous experimentation and learning. [16:52] The importance of creating a natural cadence in your iteration. [17:16] What's the best way to standardize across different teams? [21:13] Choosing the right tool at the right point in time. [24:10] What type of test automation does René find himself recommending? [27:50] To René, the most important thing is to get your code right. In addition, unit testing also has a very positive impact on your architecture and design because you're building a testable product. [28:50] What is Rene's view on open telemetry in a DevOps mindset?   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us programming@palermo.network 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! Architect Tips — Video podcast! Azure DevOps .NET Clear Measure Architect Forum The Phoenix Project book: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford Test-driven development: By Example, by Kent Beck Extreme Programming Explained: Embrace Change, by Kent Beck and Cynthia Andres The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data, by Gene Kim The Mythical Man-Month: Essays on Software Engineering, by Frederick Brooks Jr. The Art of Unit Testing: With examples in JavaScript, by Roy Osherove Site Reliability Engineering: How Google Runs Production Systems, by Jennifer Petoff, Niall Murphy, Betsy Beyer, and Chris Jones   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Transcript: Joe Krebs 0:10 Agile FM radio for the Agile community. www agile.fm. Thank you for tuning in to another episode of agile FM today. I have Jim Highsmith here. Jim Highsmith just released a book called Wild West to Agile the adventures in software development, evolution and revolution. And it came out by Pearson as a publisher. Well, before we get started taking the book apart, welcome to the podcast. Jim, I'm so happy you're here. Thanks. SoJim Highsmith 0:46 I'm glad to be Joe Krebs 0:47 A lot of people know, Jim for one of the 17 signatories of the Agile Manifesto. And so this is, this is a very interesting book you wrote, because it's about a time period of 60 years of software development, software engineering, but also management leadership topics, and you group them into four eras. And we'll talk a little bit about those, obviously, and discuss if that's if that's possible. But you did write a book in 1999, or something. And the book was called adaptive software development. And without that, without that book, our entire industry would have been possibly called adaptive instead of Agile.Jim Highsmith 1:36 Yeah, it's interesting, you know, before the Agile Manifesto meeting, Kent Beck and I swapped books, or manuscripts before they were published, I read XP, for it was published, and he read my adaptive book for it was published. And so we, we had those went into the Agile Manifesto meeting. And it was it was, is I remember, we had like, 20 words up on the board. And we whittled them down to agile, but adaptive was one of them until the board and I made the point that I didn't think that the name ought to be something that one of us already had.Joe Krebs 2:15 Yeah. And and then we you guys chose the word agile became the Agile Manifesto. And, you know, and that was just the starting point of the fourth out of your four areas you are highlighting in your book. There's three before that, right. And this is this is this is the, this is the interesting piece here is did you take journal, did you write journal for those last 60 years? Or how do you remember, going all the way back when I looked at your book is fascinating to see all of those topics? But by no way? Could I remember all of those things, how you wrote them down? How did you do that? Well,Jim Highsmith 2:54 it's interesting, because the things that I had to look at changed abruptly in the mid 90s, when I started having emails and computerized documents. And the other parts of it, particularly the early years, was basically from memory. It's interesting, as I, as I looked at things as I began to remember, other things came to me. So it was it was interesting how one memory led to another memory.Joe Krebs 3:26 Wow, that's amazing. Yeah. So even Nike made it into the book, right? Yeah. Nice. So what's interesting about this book is I looked at the title. And obviously, it's about a reflection on 60 years of software engineering, from Apollo to SpaceX, if you want to see that. Right. I think that was one of those subtitles. What's interesting is when I first picked it up, I thought it was a book about that wasn't sure let's put it this way, if it's about you, or is it about a historical book about all of what's going on? And then when I started reading it, I was like, Oh, my God, this is fascinating, I's both. It's, it's a reflection on the the eras ors of what was happening in the last six years of software engineering, plus a personal touch from you, and how everything came together. Why did you decide off of putting this together, like your personal experience? And, you know, what do you what do you think is benefiting from the historical aspect of the book?Jim Highsmith 4:32 Well, one of the things about the history that I think is important is that it helped by understanding some of the history, it helps us prepare for the future. I don't try to predict the future in the book. And I say this is, you know, part of being ready for the future is preparation. And it's interesting how this book got started, and why the personal is in there, because it actually started out as a family oriented memoir to my grandkids. And as I, as I developed that and tried to figure out how to make something that would be interesting to teenagers, because they're in their mid teens now, I decided on this kind of scope of 60 years and breaking it into arrows. And once I did that, I realized that a lot of it was my personal stories. And I kept, I kept asking people, which do I emphasize? Do I emphasize historic history? Or do I emphasize the personal and people like Martin Fowler, who was a reader of the manuscript and had a lot of great information and feedback for me? Yeah, pushing me to do more personal or like a memoir. So it is kind of a historical memoir. And I think that it also helped me reduce the scope of the book. As I tell people, it's not the history of software development, it's a history of software development, it's really important, because there are a whole lot of areas that I never really got into. And so they're not in the book. So for example, I worked with people who did object oriented programming, but that was sort of different from what I did. So there's not a lot of history in there about object oriented programming. There's nothing about aerospace, there's nothing about Unix, there's nothing about a whole range of topics that I didn't have any interaction with. And by doing it like that, I was able to scope the book to something reasonable. Yeah.Joe Krebs 6:35 Well, I it's, it's fascinating, right, so you just mentioned those four areas, just to give readers or listeners a little bit context, here is the Wild West. In the beginning, this is how it all started. We got structured, and we got the roots. And obviously, then the Agile space. Now, you just mentioned that a little bit in how it could be helpful for for anybody who to look back into history to make, you know, not predictions, but to learn from history for future events, possibly reflect on it. Now, if somebody and because the Agile era itself is already quite long, at this point, we're recording this in 2023. So some of the listeners right now might only have experience in that era. Right? So what do you think if somebody who is relatively new into software engineering, possibly coming out of college right now, and this is like, this is all I know, this is the way of how I have learned and worked in this is the only thing I know, what are the aspects you feel like you would like to point people back to until I get this, this is interesting stuff, and you should be aware of it.Jim Highsmith 7:45 Um, I had a colleague at ThoughtWorks, who is in her late 20s, she read some of the manuscript help some with it. And it was really interesting talking to her, because in college and and her work, work environment, she had never done anything except that. And so looking back at the history of things, she, she really enjoyed it. And she thought it was very helpful to her to kind of understand, for example, what was the conditions in the world that made agile, kind of take hold in the early 2000s? Was it just because it was a better way to do software, because people really liked it. There were business conditions, technological conditions, that kind of came together at that point in time to make a pivot point. And I think people need to understand these things didn't just grow. Boom, but, they had some background and the other background background, I thought was important was to bring out some of the individuals, some of the people who were pioneers of those different eras, who really contributed to the evolution of software development. I asked people if they did they know who Tom DeMarco can or or Larry Constantine do they know that these people were and most didn't? So I wanted to bring those people forward in people's mind. It'sJoe Krebs 9:32 interesting yeah, no, I and it's nicely written beautiful graphics. And in there too you see like the the era and you saw like with, you know, where technology was produced with the mainframe computers, and you see people like interacting with the machine and you see today are people enjoying technology in their living rooms. So a lot of these kinds of visuals that go in, there's also a visual and that was striking to me that was interesting because you always have like these comparisons in your book where you would say the "then", right? And the "now" piece where you you highlight the different windows here in terms of time. And what's interesting about several times the org charts of organizations comes up. And and then poor was like a hierarchy of organization and the now part is very different. I don't and this is this is something I noticed in the book is that I definitely see that there is a trend towards that. But when I read that, I was like, there are a lot of organizations still out there that are having an old org chart kind of thing they are, they're still today operating in an agile era, with the org chart of, you know, the structured, maybe right kind of approach. What's your advice to them? I mean, there's there seems to be like a less of learning in terms of adaptation?Jim Highsmith 10:56 Well, I think that this is, you know, a big topic now is digital transformation, becoming a digital organism. And I think there are multiple different parts of it. And I think until, well, for example, if you really want to be a digital organization, you're going to have to think about how you measure success, with different measures of success. And then you have now, just like in project management, we had to move from the Agile triangle to something I call the Agile triangle, from the iron triangle to the Agile. And in business, I think you've got to do some work. And so I think organization structure is another one of those things that become digital, and become fast acting and innovating. You've got to look at the organization structure, and have it malleable. meet the needs of a growing company, or of a company that's moving into making some major changes. I think there's there's some people doing that. But it's one of those areas. That's it's just emerging, and I don't think the right model are there yet other than other than Germany and Apple whose unfix model, which I talked about in the book, and it's just getting started, but it's seems to be really taking hold in europe.Joe Krebs 12:23 Yeah, it's interesting. Like, we'll get definitely get there. You just mentioned business one more time, right? So the agile movement is a reaction to the business needs, right? It's not just like you guys thought about, hey, let's work differently. Right? It was business needs that require that. And I think that need is still obviously here. So how did the like, because 95 somewhere in that neighborhood? That would be in your roots era? That was the significant event of the.com bubble burst? How did that influence like business and that era? Do you see like, historically, while you were working on the book, and you're just on the material? Did you see any correlation? Like what happened was that like, also like a massive impact on the way of how people worked? Jim Highsmith 13:16 Well, I think the thing that was the massive impact on how people work was really not connected to the.com bubble. But it was connected to something else. And this is the transition from automating interim systems. Automating customer facing system. I think that was a that was one of the impacts of the internet. And that was a major transition. So for example, there was a late 1980s, my wife and I went together, my chair, and we went to this place. And I finally picked out the right chair and hook it up to the counter, or took the slip up to the counter, wrote the guy check. Now those checks are those little small pieces of paper that we used to use. And said, we helped me put the chair in the car. And he said, Well, you have to come back tomorrow. And I said, well, the chair is right there. My car is over here. Why can't we put it in the car today? He said, Well, our computer system prints out picking tickets overnight. And I can't give you the chair without picking. That's the sort of computer interfaces that we were dealing with in the late 80s, early 90s. And so that move from internal facing systems to external facing system was a big movement and to me that was a bigger thing than the.com.com bust was a temporary reaction, the moving too fast. You can anticipate the same thing for AI now.Joe Krebs 14:59 Maybe Yeah, yeah. That's a wonderful example of how you connect the paths to possibly future events. So I was like, Well, are we possibly going into first year too? Well, that would be for a totally different recording here. Right? That would be awesome to catch up on that as well. Now, I do when I was going through this material in your book, that was also obviously, you know, I have lived through professionally, almost three, I touched on the second one, but then the the roots in an agile myself. What's interesting is there's several topics where you look back, and you're like, oh, wow, I totally forgot about this, right? We did exactly what you did too right. It's like, there are certain steps where you find yourself in your personal story, I found myself, for example, in domain modeling, for example, right? technique I find very useful. Still, today, sometimes I scribble a little bit on a napkin and do these kinds of things. Obviously, Martin Fowler follow, which you mentioned before, right analysis pattern, huge book and everything, but you don't see these things necessarily anymore. I just want to use that as an example. Right? Not necessarily make this a conversation about analysis, patterns ones. But is there anything where you would look back and say like, Okay, we are in the Agile era, but there is something in those previous three eras, we would say that's a shame that they went away, there wasn't useful techniques. They are always like, Oh, why we're not doing this anymore. It might be still a good idea. IsJim Highsmith 16:29 it true? Interesting, as I began looking at some of the stuff that was used, for example, in the structured era, I found out that people are still using data flow diagrams, maybe not to the extent they were before, but there's still a useful tool. So there's some of the diagramming methods that people are still using. And I'm sure some of the diagramming methods in UML are still being used. One of the interesting things that's still being used today, I think a lot of people don't know the origin of it. Was the idea of coupling and cohesion. Yeah, that actually, Larry Constantine, developed those in the 1960s. And so, one of the interviews that I have in the book is with Larry Constantine. Another one is with Tom DeMarco, who, those two people and a few other really kind of started the structured methods movement in the 1980s.Joe Krebs 17:33 Yeah, if I remember correctly, even Larry Constantine even went to the started initiating use case driven approach why and so there was certain I think there was part of that, and that popularized this technique, among others.Jim Highsmith 17:47 I'm not sure he was involved in use cases, but he may have been,Joe Krebs 17:52 yeah, there was there was definitely a ton of movement here. That very interesting, you just mentioned the the unfixed model. And maybe that is something I actually do want to ask you about that. So we have these four eras, which is great material. But there's also topics like unfix, for example, right? You have mentioned in your book, and that's a little bit forward thinking. Now, I myself, I'm a little biased here, because I'm writing about agile kata. But there's also lean change management, flight levels, there's evidence based management is beyond budgeting. There's agenda shift as fast goals, I mean, there's topic after topic after topic. And if I, when I came to reading about the Agile era, I was also like, fascinated about all of those things. Again, I'm a little focused on one of them myself with the Agile Kata. But what I noticed is, are we right now with business agility, the digital transformation you mentioned, are we entering? are we approaching a fifth era right now? Because there is a diversity of techniques right now. It feels like very energetic right now. There's a lot of things that are happening right now. And like in islands, and we're trying to put things together into this business agility right now. Do you feel like we're in the beginning of a new era? Something business?Jim Highsmith 19:17 I think it could be a new era, people have asked me about that quite a bit. I don't know if agile methodologies per se, will continue there as they are today. I think there's a lot of stuff happening and people going in different directions. And somebody asked me the other day, if I thought the 17 would get back together and rewrite the manifesto. And I said no, we're in a completely different era. You know, and and agile is now been spread kind of worldwide. And back then, in 2001, there was a very small contingent that was working in what was then called lightweight methodologies. Right? And so the times are very Very different. So I think that for the future, I think the important things are how do we build agility and adaptive leadership into our organizations? That's the real challenge. And I think agile can be a part of that. I think what we have to do is we have to look at, what do we keep from agile? And what do we change? Yeah. What is it that persists? And one of the things that I think the manifesto did, it was both inspirational and aspirational. I think in some of the newer things that we're seeing, they've lost that inspiration part of it, got some new new project, new principles or new processes, or new names, but it doesn't have the inspiration. The original manifesto. I think that's one of the things may be modified a little bit. But keep Yeah. And then we need to figure out what what goes on beyond that. And whether it's a new methodology called Excalibur doesn't matter to me, as long as it keeps on focus on Agility and adaptively leadership.Joe Krebs 21:15 Yeah, well, I do think like, from from whatever I noticed is I think we're moving forward with the, with the ideas in mind, right, I think, I don't think there's any kind of dead end or anything in terms of the journey. I think this is going to continue. I think it's an expansion right on. Where do we go with this topic in general. And I see like, somewhere in your, in your work, I see parts within the evolution where there's a high increase of new ideas, and then there's a new arrow coming out of it. And I was just wondering if you with all the oversight and things you see and read and hear about, if you feel like and this might my stuff I just mentioned is probably not even a complete list? Definitely not. If there is anything where you would say there is a big, big pool in arsenal of ideas right now, for how do we approach the problems of the future?Jim Highsmith 22:12 Well, I think that there's a lot of new stuff coming down. And both in management, organizational design, software development, and I think you it's going to require integration, we've got to, you've got to be able to use all those different topical areas, and somehow integrate them into something that an organization can use. And I think it's going to be different for every organization. You know, I think that this idea of one methodology fits a lot of different companies, I think one methodology to one company that everybody has to have sort of their role their own, appropriate for them. And I think that's actually the more difficult part. And the difficult part that I've seen all through the eras, which is, there's, there's a number of people who take whatever methodology and say, This is it, we're gonna follow these steps, and we're gonna do these processes, we're gonna fill out these documents. And that's the way we're going to do things. Yeah. As opposed to this is a framework, a guide a guidelines need to be adapted to every different project or every different organization. I think that's the, that continues to be one of the more difficult things to do for organizations is to allow them enough flexibility in how they approach. Yeah.Joe Krebs 23:44 I couldn't agree more with you. And this is you just make me think about all of those things that are ahead of us. As a as a community as a as an industry. When you just mentioned earlier in your book that you had the intent of writing this book for your grandchildren in the beginning, and then add a little bit more other things to it. And the book grew in both sides. It still both it's still personal as well, a historic document you put together. Is it any point that you like, because it we've been up? It's going public, right? In Pearson in here as a book? It's not just for your grandchildren? Did you soften your tone a little bit your when you did this were like, because some of the experience you had you were like, you could read between the lines that it was not necessarily easy. There was some frustration, right? Did you so it's a littleJim Highsmith 24:41 bit so maybe a little bit and you'll notice that with organizations where things went pretty well attended to use the name of the organization, but it didn't go so well. tended to use pseudo name Yeah, yeah. And one of the things that that happened during a book is, you know, I had been used to in my previous books, writing stuff, writing about engineering methods, writing about management methods. And here I was faced with writing about myself. And that's a very different perspective to write from. And luckily, I had a number of people that pushed me to do more and more of that, I think it was the right direction. But it was difficult, but I really challenge other people in our industry do more of that write about themselves and what they're doing, not just write about stone.Joe Krebs 25:43 Yeah. That's, that's interesting. Why because it's the personal touch and the struggles. It's also like, you know, it's not like polished in a way where you would say, that doesn't sound like reality, you can really feel with you in some of the situations, you know, you know, some of them were further back where I can picture like a cubicle or something like that, like, you know, like, all these kinds of things. And it's like, oh, he's going through this, but you see the path of where this is going and how you found your path. So I read by or any kind of personal story that goes along with it. It's, it's makes it more real. Jim, this is a great conversation. Thank you. And I do want to say everyone who is listening to this and has an appetite for hearing more about this and obviously going into those four eras of Wild West structure routes and agile as you grouped them and labelled them. I can only recommend to pick up the book wild west to Agile by Jim Highsmith. Thank you so much, Jim, for your time.Jim Highsmith 26:45 Thank you Joe, I enjoyed it.,Joe Krebs 26:48 Same here., thank you. Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www agile.fm. Talk to you soon.

In today's episode I'm joined by J. B. Rainsberger for an assessment of what value can be derived from using ChatGPT as a programming tool. We also discuss why you should write your tests backwards, using ChatGPT to make tests pass, and J. B.'s philosophy and approach as a consultant.  Finally, we get into the benefits of joining J. B.'s JBrains Experience mentoring group.Extreme Programming Explained by Kent BeckExtreme Programming Installed by Ron Jeffries, Ann Anderson, and Chet HendricksonPlanning Extreme Programming by Kent Beck and Martin FowlerSwitch by Chip and Dan HeathTest Driven Development at Wiki.C2.comJBrains.ca - J.B. Rainsberger's SiteThe JBrains ExperienceThe Code WhispererBlog.JBrains.caThe World's Best Intro to TDD, Level 1J. B. Rainsberger on Twitter

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.

The dataset wars are heating up, Bark is a transformer-based text-to-audio model that can generate highly realistic, multilingual speech as well as other audio, Kent Beck needs to recalibrate after using ChatGPT, the team behind Stable Diffusion release a new open source language model & Mitchel Hashimoto weighs in on prompt engineering.

The dataset wars are heating up, Bark is a transformer-based text-to-audio model that can generate highly realistic, multilingual speech as well as other audio, Kent Beck needs to recalibrate after using ChatGPT, the team behind Stable Diffusion release a new open source language model & Mitchel Hashimoto weighs in on prompt engineering.

According to the book Extreme Programming Explained: Embrace Change by Kent Beck, “The basic problem of software development is risk.” One of these risks is that of the schedule slip. In this episode, we discuss how to use XP to prevent schedule slips when developing software. Tuning in, you'll hear about how XP addresses the problem of schedule slips through short-release cycles, what a Big Bang release is and why you want to avoid this, and the value of prioritizing the most important features in your schedule first.

“Respecto a tu código: hazlo funcionar, hazlo bien y hazlo para que se ejecute rápido.” Kent Beck. Los invitados en este episodio de Conceptos son Ileana Méndez Ruiz y Jose Botran, fundadores Codifica. Algunos de los Conceptos que exploramos hoy: - Diferencias entre el uso pasivo y el uso activo de la tecnología en los niños - Cómo los niños vencen el miedo al fracaso por medio de la programación - La importancia de construir distintos proyectos en un mismo lugar - Lo bello de aprender sin saber que se está aprendiendo - Qué es Codifica y porque su existencia es tan importante para futuras generaciones --- Send in a voice message: https://anchor.fm/conceptospod/message

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

Gergely Orosz writes the #1 technology newsletter at Substack, called The Pragmatic Engineer. He started his career as a software developer in the U.K., spent three years at Skype, and followed that role with four years as an engineering manager at Uber before deciding to leave big tech and work for himself. Gergely began pursuing his newsletter full-time in September 2021 and in just one year has amassed 200,000 subscribers. He now makes more money than he did at his salaried tech job, and with freedom and flexibility. In today's podcast, Gergely shares why he left his well-paying job at Uber, how he got his first 1,000 subscribers, why this kind of work can be stressful and lonely (but ultimately rewarding), and why it takes hard work to build authority and become a great writer. Working solo can be challenging, and in this episode, both Lenny and Gergely offer tips for structuring your unstructured time and finding your focus.—Find the full transcript here: https://www.lennyspodcast.com/leaving-big-tech-to-build-the-1-technology-newsletter-gergely-orosz-the-pragmatic-engineer/#transcript—Where to find Gergely Orosz:• Website: https://www.pragmaticengineer.com/• Newsletter: https://newsletter.pragmaticengineer.com• Twitter: https://twitter.com/GergelyOrosz• LinkedIn: https://www.linkedin.com/in/gergelyorosz/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• Twitter: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—Thank you to our wonderful sponsors for making this episode possible:• Lemon.io: https://lemon.io/lenny• Eppo: https://www.geteppo.com/• Vanta: https://vanta.com/lenny—Referenced:• Gergely's books: https://blog.pragmaticengineer.com/books/• Centered: https://www.centered.app/• The Pomodoro technique: https://www.forbes.com/sites/bryancollinseurope/2020/03/03/the-pomodoro-technique/• Coding Horror: https://blog.codinghorror.com/• How to Achieve Ultimate Blog Success in One Easy Step: https://blog.codinghorror.com/how-to-achieve-ultimate-blog-success-in-one-easy-step/• A Comment Is an Invitation for Refactoring: https://blog.pragmaticengineer.com/a-comment-is-an-invitation-for-refactoring/• Kent Beck's website: https://www.kentbeck.com/• Steve Yegge's famous rant on Google vs. Amazon: https://www.alexanderjarvis.com/steve-yegges-famous-rant-on-google-vs-amazon/• Stevey's Tech Talk: https://www.youtube.com/playlist?list=PLZfuUWMTtMcC1DZF6HxJhqsGrBXu8Jzi7—In this episode, we cover:(04:32) Gergely's background(07:19) The Pragmatic Engineer, growth and current subscribers (08:59) Compensation with a subscription-based newsletter vs. his salaried position at Uber(10:55) How the onset of Covid and layoffs at Uber prompted Gergely to start his newsletter(23:10) What he did immediately after leaving Uber(25:41) The day-to-day of writing a newsletter(35:08) Tips for productivity(41:19) Gergely's favorite parts of entrepreneurship (43:15) The downsides of solo work(50:39) Why Gergely stopped making long-term plans(54:30) How to get started writing a newsletter(1:04:48) Key advice on building a successful newsletter—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. When we work with teams that are under pressure of a tight deadline, it's not so easy to find the right level of transparency with the clients and stakeholders. On one side we should protect the team, on the other side, the team needs to be open with the stakeholders to be able to find a solution when it seems the projects are going over the schedule and budget! In this episode, we explore some of the lessons Bert learned about finding the right level of transparency between the team and the clients and stakeholders. In this episode, we refer to XP Explained by Kent Beck, and the concept of Single Piece Flow, a key part of Lean Thinking.   About Bert Heymans Bert is a long time Lean Management aficionado and project management tool specialist, along the way he fell in love with business analysis and teaching business analysis techniques. In 2016 he founded Lean Coffee Ghent and has been at it since. You can link with Bert Heymans on LinkedIn and connect with Bert Heymans on Twitter. 

In this episode of The Rabbit Hole, we're talking about The Rules of Simplicity and why you should be following them when building software. We break down the four Rules of Simplicity first laid out in the book Extreme Programming Explained: Embrace Change by Kent Beck and discuss how they relate to other rules and principles that we've discussed on this podcast in the past. For a quick crash course on The Rules of Simplicity, why you should be practicing them, and how to go about applying them today, don't miss this episode!

Mental models are metaphors that help us understand complex problems we work on. They can be a simplified roadmap over an infinite area of complexity. How does one come up with mental models? How are they useful? Are they primarily a solo thing, or can they be used to communicate with the team? What happens when your model is inaccurate? Today, Joël is joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget, to discuss. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Eebs on Twitter (https://twitter.com/EebsKobeissi) You Need a Budget (https://www.youneedabudget.com/) Skill floors and skill ceilings (https://thoughtbot.com/blog/who-is-empowered-by-your-design) Transcript: 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. And today, I'm joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget. EEBS: Hi, Joël. It's really good to be here. JOËL: And together, we're here to share a little bit about what we've learned along the way. So, Eebs, what's new in your world? EEBS: Oh, a whole lot. I'm a new dad, so I'm getting to experience all those things. But in the developer world, I've recently picked up programming on an ESP32, which controls LED lights. And so I'm having fun lighting up my office. JOËL: Is that like one of those little microboards, kind of like a Raspberry Pi? EEBS: Yeah, exactly. It's a little board that's compatible with the Arduino IDE. And I literally only played with it last weekend, so it's still very new to me. JOËL: Nice. Have you done any Arduino development or Raspberry Pi or anything like that before? EEBS: No, I have a Raspberry Pi that I run like a DNS server on, but I haven't done any actual programming. I did make an LED blink, which is pretty cool. JOËL: What kind of programming is required for a board like that? EEBS: From my understanding, it's either in Python or C. Those are, I think, the two languages that you can program on it. I definitely do not know C. And so I'm just going through a bunch of tutorials and reading some sample code. But I think if I ever end up trying to implement something more complex, I'll probably switch over to Python because that's a little more familiar. JOËL: So the coding feels fairly high level even though you're writing controller code for LEDs. EEBS: I hope so. I'd love to be able to take advantage of whatever abstractions I can. JOËL: Do you have any fun goals you're trying to do with this? Or is this just for the fun of trying a completely different environment than web development? EEBS: No, it's actually rooted in something visual. So I have these shelves behind me that are in my webcam when I'm in meetings or whatever. And so I want to be able to put a light strip across these shelves and have some sort of visual thing in the background. JOËL: Like LED mood ring? EEBS: Yeah, kind of. My eventual goal would be that as I'm talking, a little equalizer display pops up behind me. I thought that would be pretty neat. JOËL: That is amazing. That will give you all of the cred in the meetings. EEBS: Right? I thought that'd be pretty cool. What have you been thinking about recently, Joël? JOËL: I've been submitting to the RubyConf call for proposals which, as of the recording of this episode, has just closed this week. And like many people, I submitted on the last day. EEBS: [laughs] JOËL: And it was really fun trying to take some ideas that I'm excited about and then turn them into a proposal that is accessible to other people. EEBS: Nice. Do you want to share a little bit about what the talk is, or is it under wraps for now? JOËL: I don't know if anyone on the committee will listen to this before the review goes out. This might break the anonymity of the proposal. EEBS: Oh, right, right. JOËL: One thing I will share that's interesting is that there are topics that I'm excited about. It's like, oh, here are a bunch of cool things about something, some technical topic. But talks that are just ten cool things about X are not that great. And so I needed to find some sort of unifying idea that I could use to share that. And that generally is in the form of trying to find a story that I can tell. What unifies all of these things together? What tells a compelling story? Is there some metaphor I can lean into? EEBS: Nice. I think that's a really powerful way of communicating something deeper is through telling something that people can relate to. JOËL: One way that thinking about metaphors has been really impactful for me recently is the idea of mental models and how those can help us in development. I'm curious; we've thrown around the phrase a little bit you and I in past conversations; what does a mental model mean to you? EEBS: I tend to be a visual thinker. And from talking to others, I've heard similar statements. So for me, a mental model is how I think about a particular domain or how I think about code flow or structure. And for me, it's usually either as two-dimensional objects or occasionally three-dimensional objects that I have floating in my visual space. So, for example, if we had two classes that are collaborators in some way, I often think of them maybe as two rectangles that are side by side. And when they interact, there's some little amorphous blob from one of those rectangles that reaches out into the other one or passes a message from one to the other. And I sort of have this idea of how many connections are there between these two physical things. Or, if I'm thinking about code flow and the path of execution that code might take, sometimes I visualize it as maybe a tree or potentially loops if there are such cases. JOËL: So when you think of these concepts, just in general, you're seeing in your mind's eye squares and rectangles floating in the air. EEBS: Yeah, pretty often. Sometimes it takes those shapes, and as I build up a mental model of some code, I'm usually adding new shapes into that picture I have in my mind. I tend to view things sort of top-down. So like, the start of code or the start of execution is usually at the top or maybe the far left or far right. And as execution happens, I usually view that as moving in towards the middle and potentially going back out when a response is returned. If it's a web request, something like that, I view it as this sort of outside in. And there's a bunch of pieces in there that are all talking to each other. JOËL: That's really cool. So not only is there a geometric aspect to it, but there's a spatial aspect to it as well. EEBS: Yeah. And it's interesting, like, I haven't actually thought about it [laughs] in this level of detail before. But yeah, there certainly is a spatial aspect to it. And I have this idea in my mind of like things and domain objects kind of belong at the bottom, and they should have well-defined boundaries. But the pieces that are a little bit towards the outer edges may be a little more fuzzy and may have less definition around them. JOËL: That's really interesting because I also have this sort of in my mind's eye see these things when I'm thinking about concepts like that. But I've talked to other people, and some people don't even have much of a mind's eye at all. They don't tend to visualize things in their mind in that way. EEBS: Yeah, it's really interesting how different people approach this thinking about code. A lot of people write things down. And I write things down, too, and draw little arrows that don't really make any sense. But it helps me do something physically sometimes as well as just thinking about it. JOËL: Have you ever tried to convert these pictures you see in your mind and actually draw them on paper? EEBS: Occasionally. And for the most part, that usually takes the form of some kind of domain modeling, whether it's based on database tables or just domain objects. And sometimes I will try and draw them out and then specify the relationships between them like, oh, you know, this one model talks to this other model in this particular way. And I'll define a relationship between them, which helps me think about them and how they interact. JOËL: I've found that even though for some things I can see it very vividly in my mind's eye, I struggle to then concretely translate that onto paper or digital paper if you will. It's almost like trying to, say, translate an emotion into words and that even though I feel like I see a visual picture, I can't reproduce it by drawing necessarily. EEBS: It's interesting you brought up feeling because a lot of the times, I have this gut feeling about a mental model, like whether I think it is correct or not. And sometimes I have this uneasy feeling of, like, that doesn't feel right to me, but it's hard to articulate why. And I think sometimes that's when I have to pull out something physical, start making those relations, start connecting things. And that's when I might uncover, like, oh, this feels odd because I have a circle here or a cycle or something. Or I've sort of represented the truth of something in two different places. Do you have any techniques for getting it out of your head and into something physical that you could share with someone else, maybe it's text or a picture? JOËL: I think I do struggle with that conversion sometimes. Practice definitely helps. I think maybe there is a metaphor here between converting these, let's call them, pictures that I see in my mind's eye and then drawing diagrams with trying to take feelings and expressing them in words. In the same way that, maybe I might have some feelings, and then I want to journal how I feel, and I struggle to express that. But finding a way to express that gives me a certain amount of precision and a more concrete thing. In the same way, these things that flash in front of my mind's eye, if I can take the time to put them on paper, they're now more real. They're more concrete. I think you can probe the edges, the ways that it kind of falls apart more easily. EEBS: Yeah, that makes a lot of sense. There's a lot of value in writing that down and going through those details in a methodical way because oftentimes, you'll catch inconsistencies, or you'll find better ways to describe it. And being able to share your mental model with someone else is often...well, it can be really tricky. And I think that's why it's important to go through and maybe find a common medium that you can share because I can't see into your brain. You can't see into mine. But if we can share our mental models, then hopefully, we have a better chance of agreeing on the solution or finding inconsistencies. JOËL: Exactly. I think, in many ways, there are almost multiple layers of mental models and that you might have an abstraction or a metaphor for a concept that you're working with separate from the diagram. And then the diagram is yet another metaphor, but now we're going geometric to represent a broader idea. EEBS: Yeah. Are there any other ways that you take that picture from your mind's eye besides written documents or conversations? Do you use any diagramming tools that specifically help with that? Or is it just kind of free-form? JOËL: I do a mix. I am a big fan of draw.io, which allows you to just free-hand or pull shapes together, things like that. There are some more structured tools that I will use. I'll use Mermaid.js. EEBS: Yeah, I've been using that a lot too. JOËL: Yeah, that's great. I've been digging into more structured diagrams recently, particularly the idea of graphs, directed graphs. And those have interesting properties. EEBS: Can you share a little more detail about what you mean? JOËL: So a graph in the computer science sense is a bunch of nodes. They are typically represented as circles and then edges which are the connections between them. A directed graph is now there's an arrow pointing in a particular direction. A really interesting property that you can have with directed graphs is whether or not they include cycles. So can you only by following the arrows effectively create a loop? Or will the arrows always lead you to some kind of terminal node? EEBS: Gotcha. Is that a directed acyclic graph? JOËL: If there are no cycles, yes, it is a directed acyclic graph or DAG, as you'll often see it abbreviated. EEBS: [laughs] How do you relate that graph to code? And what benefits do you get from expressing it that way? JOËL: So this shows up in a lot of places. And I'd even say that thinking of certain aspects of my code as a graph and a potentially directed acyclic graph is itself a mental model or a metaphor that helps bring clarity to the way I think about things. So, for example, code, you know, you invoke some main function at some point to call the code, and then that's going to call out some other functions, which call out some other functions, and so on. You may have heard that referred to as a call graph. But that is a graph of calls. There might be cycles in there for co-recursive functions and things like that. But that is one way you can then sift through and analyze how control flow or how logic flows through your application is through a function graph. You mentioned earlier the idea of objects and how they're connected to each other. That's an object graph. EEBS: Right. Recently, I had to work through a state transition problem where a customer has some billing, and they can go through many different states, whether it's active, or canceled, or past due, those sorts of things. And so actually, I reached for Mermaid.js and built a graph of, okay, they start here in this empty state. And then they subscribe, which then they become active. They might cancel their subscription, which moves them to a different state. And by listing out all the states and the transitions between them, it helped me to understand what methods I might need to define on which objects in order to allow those transitions to happen and what checks I might need to make before allowing those transitions depending on the state of the system. JOËL: I'm hearing the keywords states and transitions. And that's making me think of finite-state machines. Are you drawing a finite-state machine graph or something a bit more free-handed? EEBS: It's a bit more of free-handed. I don't think I've actually drawn out a state machine since college but just representing the different states as different boxes and the transitions that are possible from those states. I mean, I guess that kind of is a state machine in some way. So graphs are great visual approaches. Are there any non-visual approaches that you take? JOËL: That's a great question because not all mental models have to be visual. I think the power of a mental model exists in a metaphor. And one that's kind of broad but that I've applied to a lot of different areas is the general idea of something being parallel or in series. I think I first came across this concept talking about electric circuits. And are we talking about two little light bulbs that are in parallel, and if the electricity to one is cut, the other one still lights up? Or are they chained together in series? EEBS: Yeah, like my LEDs. JOËL: Exactly, going back to Arduino, but it can also be applied to a bunch of other things. We can talk about code being in parallel or in series. We can talk about work being in parallel or in series. Interestingly, I took that mental model as a sort of quick shortcut when I was digging into some functional programming ideas. Monads and applicatives are the fancy terms here. EEBS: Oh boy, I'm ready. JOËL: In general, and there's a hefty asterisk here, I think of monads as being serial, so you're chaining something; one thing happens, then another. So you can think of, for example, chaining promises in JavaScript, promise one, then promise two, as opposed to applicatives which are parallel. So you might think of maybe zipping two lists or two arrays in Ruby. The two arrays, there are no dependencies between the two of them. They get processed side by side as you're traversing both of them together. EEBS: Interesting. I've heard the term monad a lot, but I haven't heard the term applicative. Are there any other details you can share about them and what makes them different or how they might be seen in our code? JOËL: I think that the key difference is that distinction in how they're processed. Applicatives are a way of combining two independent, let's call them data sources, and then you find a way to combine them together. So it could be two independent arrays, and you're zipping through them. It might be two independent HTTP requests, and they can both fire in parallel. But then you want to combine their outputs. So you say wait until both are successful and then combine their output. EEBS: Oh, okay, gotcha. JOËL: It could even be nullable values. So you say do this thing if both values are present. But you're not...the value of one or the fact that one is null or not is not dependent on whether the other one is null or not. They're independently null or not as opposed to something...Monads are, again, a different way of combining. You might call them data sources or operations. But in this case, there is a clear dependency one, and then its output influences the next one. You might say check the value is null or present or not. And then, if it is present, take that value and then put it as the input of my next operation. And then, if it is null or not, do another thing. See, now you have a sort of chain. EEBS: Where do you see these chains happening in code? Or is it everywhere? JOËL: Once you know that pattern which, again, could be thought of as another mental model, you start seeing it everywhere. So promises in JavaScript chaining together that's effectively monads. Don't @ me, all the functional programming people. EEBS: [laughs] JOËL: I know that's not quite true. Anything dealing with multiple operations that could succeed or fail depending on, again, whether you're treating them as dependent or independent, that's probably going to look very similar to either monad or applicative. EEBS: So the first thing that actually comes to mind here is things like background jobs. Using Sidekiq or Resque or other job processors, you can have a queue of jobs that need to be executed, and they might need to run in serial, or potentially you have multiple workers pulling from a single queue, and thus the work is happening in parallel. Is that a reasonable analogy? JOËL: I think it's good for the serial versus parallel, but it's not necessarily a good analogy for understanding monads and applicatives. EEBS: Gotcha. JOËL: So with two workers, you can process a queue in parallel, and a bunch of things happen. EEBS: But there's not necessarily anything that is bringing those two workers together to produce a single output. JOËL: Yes. And there's no dependency between the tasks in the queue. EEBS: Right, right, gotcha. JOËL: So if you have a task that says execute this task and then only if this task succeeds, then do the second task, now you've created a dependency. And you couldn't process that in parallel because if task one, which has to be executed first, is executed by worker one, task two should not get processed unless task one is successful. You can't just say, oh, I've got another worker free. I haven't processed task two because it's waiting to know does task one succeed. EEBS: Right. So an example in code would be a user creates a new order. And when they create a new order, we send them a confirmation email. That would be an example of that happening in serial or a monad-like thing. [chuckle] JOËL: Yes, I found that thinking of things as serial or parallel is a good shortcut for thinking about monads and applicatives. I don't know that the reverse is necessarily true. They don't necessarily transfer one-to-one with each other. And maybe that's a danger of mental models, right? You find a mental model that describes a situation, and then you try to reverse it, and then you make false assumptions about the world. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: Another mental model that is not necessarily visual that I like actually comes from the video game community, and that's thinking of skill ceilings and skill floors. So in, I think, particularly the MOBA Community, that's a Multiplayer Online Battle Arena, they'll talk about characters as having a high skill floor or a low skill ceiling. And generally, what that means, and again, the meaning varies a little bit by community, is that a character with a low-skill floor is an easily accessible character. They might not have a lot of skill shots, like, you press a button, and things happen around your character. You don't need to aim, things like that. A high skill ceiling means that there's a lot of room for you to grow, and as you get more skilled, you can get significantly better with that character. EEBS: Gotcha. So the opportunity is greater with a higher skill ceiling. JOËL: Correct. And depending on how the character is set up, you might have a very narrow range that could be in the low range where it has a low skill floor and a low skill ceiling, which means that the character is easy to learn. But once you've learned it, there's not really a lot you can do with it. It's a fairly basic character. So getting better at the game is not necessarily going to make you that much more impactful. And then you could have one that's the opposite that is high both skill floor and skill ceiling where a character is very hard to learn. But once you learn it, that's kind of all there is to it. And then you might have one that has a large range somewhere; maybe it's easy to learn, but it's hard to master, or there's a lot of room for growth. And so, taking this framework for analyzing characters and video games, I think we can apply that to technology in general. This could be language design. This could be just API design. And you might say, well, I want this to be very accessible. People can jump in very easily. You might say I want this to be very powerful and have a lot of high-end features that make your power users very happy and very productive. EEBS: That's interesting. When you first were talking about it, I was actually less thinking about it from a user's perspective of what maybe they could do in the application but potentially from the standpoint of a developer writing the system itself. One of the pieces I always come back to in software development is that change is inevitable. And so, making something easy to change often pays great benefits down the road. And so I wonder how that fits into this idea of a low skill ceiling or a high skill ceiling in terms of perhaps flexibility or being decoupled such that you can take one idea and easily extend it or easily get more from it than you originally set out to build. JOËL: There's often a trade-off. So you make something easy to change. It's highly decoupled. But you maybe introduce more indirection to the system. So while it's easier to change one single piece, it's harder to understand the system as a whole. EEBS: Yeah, that's true. And sometimes, you bake in assumptions that you make about the future, which turn out not to be true. JOËL: [laughs] Yes, that is definitely something I'm guilty of. EEBS: I think we all are. JOËL: One thing that I find interesting is as you evolve the design of an architecture pattern, a system, a whole language, you might want to move one of those if I think of them like two independent sliders on a one-dimensional scale. So maybe you want to move the upper boundary a little bit and say I want a higher skill ceiling for this, but they don't actually move completely independently. So introducing some advanced features might inadvertently also raise the skill floor. And conversely, making the language super accessible so that it has a low-skill floor, you might have to decide I will not introduce certain features. EEBS: One thing I wanted to ask you about is, do you view different languages as having different skill floors and ceilings? And, you know, I love Ruby. I know you love Element. I've played with Element. It's been a great learning tool for me. How do you view those two languages in terms of skill ceilings and skill floors in terms of, I guess, what you can do with them? JOËL: That's a great question. And I think you can definitely apply that to languages. Admittedly, I think you could probably start a lot of flame wars with that. EEBS: [chuckles] Let's not do that. JOËL: I wrote an article a while back where I applied that mental model to look at the F# programming language. And there was a debate in that community about certain features to add and whether they would allow advanced programming but potentially at the cost of accessibility to newer members of the community and how to balance those. And so I thought, hey, let's throw this video game metaphor at the problem and talk about it through that lens. EEBS: That's really cool. Did you draw any conclusions, or was it as a way to start a conversation? JOËL: It is a way to start a conversation. I don't think there is a single correct or best distribution of your skill, ceiling, and floor. It has to match the goals you set out for your project. Just like in games, people love to rank which characters are best and not. And sometimes you can show that, in general, this character is better. But oftentimes, in a balanced game, you can talk about this character being easier to get started with or this character working very well if you're a pro. But the fact that you have a higher or lower skill ceiling or floor doesn't necessarily make the character better or worse. EEBS: So, this conversation about differing mental models, I think I hadn't realized that there can be so many different types of mental models. And some things that I do in my thinking I haven't classified as a mental model. But now that you bring it up, I think one that I think about fairly often is this idea of two objects that are collaborators and reaching into the internals of one of those objects from the other object. So A and B are two separate things. And if A reaches into B's bucket and messes with the state of B, I view that as sort of a bad practice. You're not really adhering to maybe the public API that that object is exposing. You're kind of reaching in and going around behind its back and changing some stuff that it may not expect. JOËL: Would you refer to that maybe as tight coupling? EEBS: Yeah, it's definitely tight coupling. It's not just tightly coupled; it's almost worse than that. It's almost like going behind somebody's back and making a change without them knowing. And so when I see that in code or when I write code that does that, I have this really intense desire to separate that and to say, no, no, you can't go in and update this record directly in the database. You have to send it a message and say, "Hey, I would like you to be aware of something," and then it goes and changes its own internal state as a response to that. And so I have this very vivid sort of mental feeling of it being wrong, of it being like, I'm being sneaky, or I'm not being gracious to the person I'm interacting with as though I were one of these objects. JOËL: That's fascinating. You've practically anthropomorphized these objects. EEBS: I do. I view them as little people. JOËL: You describe this interaction as going behind someone's back. That is the thing that I, a person, do to someone else. It's not a function making a direct call. And yet, it's such a strong...we use a social mental model to talk about objects and interactions. EEBS: Yeah, I almost want them to be friends. And I think that applies to real-life relationships, right? If you have a nice dialogue back and forth, there's an understanding. There's commonality that you can find. But if I were to go do something behind your back without chatting with you about it first, you might not be so happy with me. JOËL: I'd feel betrayed. EEBS: Right. JOËL: I feel like there's probably a really fun conference talk to be done about that. We often use that metaphor; I think when talking about objects sort of subconsciously but making it explicit and just being, hey, let's talk about these objects as if they were people. Why don't we want to do this? Because this one here is betraying the other object there. This one here is being impolite. EEBS: We could have two people get on stage and talk to each other. And I might then go and reach in your pocket and pull out some change without you knowing, and you might be upset with me. JOËL: That would be great. Get a little skit going up on stage. Or even if you're artistically inclined, you could probably draw some really fun little characters to illustrate this. EEBS: That would be really cool. I, unfortunately, don't have the artistic talent to do that. JOËL: Well, free conference talk idea to all listeners of the podcast. I expect to see this for RailsConf 2023, maybe. EEBS: I'll be looking for it. So I've shared a mental model that I didn't really know was a mental model. Are there other mental models that you want to share that I may not be thinking of? JOËL: Here's one that I've just come to realize recently that I'm actually quite excited about: when you think about the word refactoring, how would you describe that idea? EEBS: Well, refactoring to me is changing the implementation without changing the behavior. JOËL: Yes, I think that is the classical definition. You should be able to change the implementation of a method, and the tests without changing are still green after you've done that. EEBS: I guess, mentally, I think about that as perhaps drawing a box around some of the objects that are floating in my mind's eye, rearranging how they exist within that box, and then the box dissolves. And the tests still pass, but the structure of the objects or the code has changed in my mind. JOËL: I love that you immediately went to a visual approach there. And I think I have something similar, but I'm coming at it from a slightly more domain modeling perspective. So thinking maybe less from an individual method approach but looking at maybe a larger system, what you're trying to do is use code to describe some version of reality. So it might be a business process that you have. It might be trying to describe some aspect of your customer's life that you're trying to automate for them. Oftentimes, this thing you're trying to describe in code terms is going to be a simplification because life has a ton of edge cases, and many of them we don't care about. So if we go with a visual metaphor here, you're trying to draw some kind of shape using only straight lines to approximate some weird curve. And so, let's say you draw something with only four lines. It's really simple, how you have a diamond. That's the shape you're trying to create. And then you're going to fill it in with little other shapes that approximate a diamond. And those are your different models and functions and all the other components that we use to build software. At some point, your understanding of the underlying reality might change. Maybe you need more precision, or maybe the actual feature requirements have changed. The thing you're trying to approximate with your code is not a diamond. Maybe you've added a few more sides to it. It's a pentagon. So we've gone from four sides to five. And the little components, and modules, and things that you have there approximate that diamond work. They still mostly approximate your pentagon, but it's really clunky because the initial design was to approximate something else. They were really good for fitting in really tightly and being very loosely coupled to each other when we were trying to do a diamond, but then they don't work as well in the pentagon. EEBS: So maybe some of the internal shapes need to change or adjust to fill the space that the pentagon has now created. JOËL: To fill the space or maybe even just to fill it in a way that's less clunky. And so the idea here in this metaphor is that the reality we're targeting in software is always changing. And so the underlying reality changes, and so we're changing that shape that we're creating all the time. But also, we're getting more precision as we decide; oh, we care about this edge case now. We didn't in version one, and so as part of that, we're constantly having to take the modules that maybe were very well designed initially but then restructure them to fit the new requirements because now there's a fourth object coming in, and it's kind of clunky with our current configuration. EEBS: That's interesting. One of the first things that jumps to mind is that maybe there are better ways or worse ways to do that refactoring to fit that new shape. Do you think there's any truth to that in the sense that you might initially design a system that perfectly fits that diamond or very closely fits that diamond but then as it changes to a pentagon, do you need to simply add a new piece to fill in that empty space? Or do you need to restructure everything within the diamond now to fit the shape of the pentagon? JOËL: Oftentimes, you do need to restructure. And I think there's this wonderful little phrase from; I believe it's Kent Beck that says, "Make the change easy, and then make the easy change." EEBS: Yep. JOËL: And so, to me, that makes the change easy is that initial restructuring that you need to do of those first shapes so that you can finally bring in the new one. EEBS: Oh, that's a cool visual. I immediately can imagine the pieces in the pentagon moving around to make space for a new piece that you need to now bring in. And that movement of all those pieces can be really difficult. Have you ever played that game where it's a square, and you're trying to get a ship out of a port, but there's a whole bunch of other ships, and you can only move them left and right and up and down? And you can do that. And that's what I'm picturing right now is moving shapes within that pentagon to then make space for either a new shape or to allow a shape to escape that is no longer relevant. JOËL: I played a version of that that had cars, cars, and trucks. EEBS: Gotcha. Yeah, I think I played that too. JOËL: That would also be a fun conference talk, right? Like, start with that game as your initial metaphor. And then you use that as a way to talk about refactoring. EEBS: That would be really cool. JOËL: I would watch that talk. To anybody listening who wants to give that talk, I want to see you at RailsConf 2023. EEBS: [laughs] Are we just a talk factory now? [laughter] JOËL: I love talk ideas. Maybe this should become a segment. Just have Eebs come in for five minutes once a month and give us a talk idea. It could even be fun to see a talk idea that multiple people implemented differently. EEBS: That would be really cool, actually. I always get nervous about giving talks or being on podcasts like this one. I would love to be the person that gets to sit there and throw out random ideas and have other people fulfill my dreams. JOËL: Well, thank you so much, Eebs, for joining us to talk about mental models. And to all of our listeners, I'd love to hear about what mental models you find are helpful, and so please share them with us. On Twitter, you can reach us at @_bikeshed. EEBS: Thanks for having me, JOËL. This has been super fun. JOËL: And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. 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. If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.