Podcasts about Lean software development

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.

BONUS: Rediscovering Agile's Roots, What We Can Learn From Lean Manufacturing with Doug Rabow In this BONUS episode, we reconnect with Doug Rabow, a previous guest and an expert in Lean-Agile strategic management known for his dedication to fostering empowered teams and enhancing processes through Lean principles. This discussion dives into the foundations of Lean, its evolution from manufacturing, and how software development can benefit from these time-tested methodologies. Join us as we uncover how adopting Lean can transform software practices and culture to align more closely with the true spirit of Agile. Introduction to Lean and the Toyota Production System (TPS) "Lean isn't just a methodology; it's an ongoing journey of learning and problem-solving." Doug begins by mapping out the origins of Lean and its cornerstone, the Toyota Production System (TPS) (Wikipedia article on TPS). Initially crafted to solve operational challenges in manufacturing, TPS introduced principles aimed at efficiency and continual improvement. Doug underscores that while Agile has gained broader recognition, Lean provides an essential, often overlooked foundation that extends beyond frameworks like Lean Six Sigma or isolated process improvements. "Lean isn't a set-and-forget solution; it's about cultivating an evolving culture of problem-solving." Cultural Foundations of Lean: Adapting for Software Teams "Respect for people and a culture of continuous improvement form the heartbeat of Lean." Transitioning to software development, Doug highlights the core cultural tenets that empower teams to excel. He points out that scaling these principles—such as fostering a culture where problem-solving is embedded in daily practices—is vital due to the complexities of software as a people-driven process. Referencing Conway's Law, Doug illustrates how the structure of teams directly impacts code and workflow. "Developing software is as much about building teams as it is about building products. Lean teaches us that these are inseparable." The Toyota Way: A Blueprint for Excellence "Applying Lean is about chasing excellence, not just managing tasks." Jeffrey Liker's The Toyota Way introduces 14 principles that Doug relates to software environments, emphasizing the value of discipline and respect for people. He discusses the importance of aligning processes with long-term strategies and ensuring that these processes are designed to foster continuous learning. Doug reiterates that truly understanding and integrating Lean requires more than surface-level adoption. "Respect for people isn't an add-on in Lean; it's the root of a thriving, innovative team culture." Waste in Software Development: Insights from the Poppendiecks "Work in progress is not an asset; it's a liability." Doug shares insights from Mary and Tom Poppendieck's (Mary and Tom have been on our podcast here) pioneering work on Lean Software Development, particularly their adaptation of waste types from manufacturing to software. These include partially done work, extra features, relearning, handoffs, and task switching. Doug points out that waste reduction strategies—such as Kanban and pull systems—help teams minimize bottlenecks and optimize flow. "Software development, like manufacturing, benefits from visualizing value streams and focusing on reducing waste." Metrics and Measurement in Lean "The right process will create the right results—focus on process metrics, not individual metrics." In Lean, metrics are crucial for assessing and refining processes. Doug advocates for using metrics like cycle time and throughput to provide teams with insights into system efficiency. He explains how focusing on process metrics rather than individual productivity helps sustain a culture that prioritizes team learning and growth. "When we measure what truly matters—the process—we empower teams to solve problems collectively and improve outcomes." About Doug Rabow Doug Rabow is a dedicated practitioner of Lean-Agile strategic management with an emphasis on building empowered teams and optimizing processes through Lean methodologies. His extensive experience in applying Lean principles in software development has made him a trusted voice in the Agile and Lean community. You can link with https://www.linkedin.com/in/dougrabow.

Agile in Hardware: Agile Transformation in a Hardware Organization, Wärtsilä Case Study with Henna Torkkola nd Maarit Laanti In this Agile in Hardware episode, Henna Torkkola and Maarit Laanti share the pioneering journey of integrating Agile practices into Wärtsilä's Marine R&D, particularly within the ambitious New Product Development (NPD) program for advanced engine technology. From fostering collaboration across the value stream to embracing simulation and hybrid Agile approaches, they offer insights into how Agile has reshaped R&D processes. Henna and Maarit explain how bringing Agile to hardware isn't about imposing frameworks but adopting a collaborative, flexible mindset that inspires productivity and innovation across teams. Starting with a Vision for Agile in Product Development Henna and Maarit delve into the origins of Wärtsilä's Agile journey, recounting how the NPD program, initiated in 2018, was envisioned to deliver faster releases, co-create with stakeholders, and establish a more satisfying work culture for program teams. Moving beyond traditional project stages, the company embraced Agile methods to accommodate real-time adjustments and maintain a competitive edge. “Agile success in hardware starts when you focus on the values behind the practices—not just calling it Agile.” Expanding the Agile Mindset Across the Value Stream Originally designed as an R&D initiative, the program expanded to engage the entire value stream, including sourcing and manufacturing. Henna explains how cross-departmental collaboration was achieved through inclusive events and ceremonies, bringing in diverse stakeholders from the start. This broad integration marked a shift from isolated R&D to a holistic approach involving the entire value chain, creating a product developed with inputs from every angle. “Cross-functional collaboration is crucial; bring everyone to the table early and celebrate wins together.” Integrating Manufacturing for a Smooth NPD Transition To bridge the gap between R&D and manufacturing, the team included design-for-manufacturing experts from the outset, ensuring seamless transitions and early feedback. The addition of quick real-world testing strategies like using a single-cylinder prototype and rolling-wave planning enabled the NPD program to adapt plans incrementally while collecting feedback earlier in the process compared to previous programs. “Invite manufacturing to R&D's early stages—you'll tackle issues before they escalate.” Blending Traditional and Agile Models for Hardware Innovation The team adopted a hybrid model that merges Agile's flexibility with traditional gate-check models, evolving over time as teams moved away from rigid milestones. By focusing on early feedback and iterative adjustments, they avoided process bottlenecks and fostered a product-centric mindset. “Don't get stuck on milestones; prioritize feedback loops to keep product goals aligned with real-world needs.” Simulation and Small-Scale Testing: Essential Tools for Fast Feedback Both simulation and small-scale testing proved essential to the program's agility, facilitating rapid feedback and enabling team alignment. With testing and simulation experts working alongside designers, the process quickly highlighted practical improvements, creating a more effective pathway from R&D concepts to production-ready components. “Invest in simulations—they give you insights much faster, aligning design with manufacturing realities.” Synchronization and Common Planning: Enabling Transparency and Efficiency Henna and Maarit underscore the benefits of synchronization and common planning cadences across the R&D teams, enhancing transparency and team spirit. These synchronizations empowered teams to independently manage priorities while aligning with organizational goals, creating an ecosystem where collaboration and autonomy coexist. “A synchronized cadence empowers teams, letting them take charge of plans within a unified vision.” Pivoting to Sustainable Fuel: Adapting Agile to Changing Requirements As the market focus shifted towards sustainability, the NPD program swiftly integrated sustainable fuels like ammonia into development. Thanks to the Agile-inspired adaptability, the program adjusted its trajectory, positioning Wärtsilä to lead in environmentally conscious engine development with a product-first mindset that welcomed change. “With Agile, your process adapts to change—making room for innovations like sustainable fuel in real-time.” Resources for Agile Enthusiasts in Hardware and Product Development For listeners eager to dive deeper, Henna and Maarit recommend: Flexible Product Development: Agile Hardware Development to Liberate Innovation by Preston Smith White papers on Agile in hardware, particularly those available on WikiAgile About Henna Torkkola and Maarit Laanti Henna Torkkola is an Agile coach at Wärtsilä's Marine R&D, focusing on Future Fuels and New Product Development. With expertise in banking and Agile transformations, she holds a Master's in Human Resource Management and is passionate about the cultural impact of Agile. You can link with Henna Torkkola on LinkedIn. Maarit Laanti, a pioneering Agile coach and co-founder of WikiAgile, is the author of the first PhD on Agile in a scaled environment. She has led transformative Agile initiatives at Nokia and contributed to the SAFe framework. A global authority on Lean and Agile, she is recognized for advancing Agile scaling in hardware. You can link with Maarit Laanti on LinkedIn.

BONUS: Unlocking the Secrets to Thriving Workplaces and Agile Leadership with Vasco Duarte In this insightful BONUS episode, Vasco Duarte is interviewed by Bill Fox for an episode on the Forward Thinking Workplaces Podcast. Vasco is a visionary leader in agile and lean software development. Vasco shares his revolutionary approach to fostering innovation, creating dynamic workplaces, and leading teams to success. His strategies are designed for leaders looking to elevate their organizations by focusing on people, purpose, and efficient work processes. Tune in for practical advice on how to unlock your team's full potential and thrive in today's fast-paced work environment. Creating Environments for Natural Innovation “Innovation is a natural human quality; it flourishes when you don't make an effort to prevent it.” Vasco emphasizes that innovation isn't something leaders need to force. Instead, it happens organically when the right environment is in place. He encourages leaders to shift away from rigid structures and towards creating motivating spaces where creativity can thrive. By doing this, teams naturally become more innovative and solutions-driven. “The only way innovation does not happen naturally is if we make an effort to prevent it from happening.” Motivated Individuals: The Key to Project Success “Build your projects around motivated individuals and trust them to deliver their best.” Vasco highlights the importance of centering projects around motivated individuals, giving them the trust and support they need to succeed. According to him, leaders should focus on empowering people, unleashing their full potential. When teams feel trusted and valued, they bring more energy and creativity to their work. “If you trust people and give them the space to perform, they will achieve things you didn't expect.” The Power of Community and Purpose “Aligning purpose with autonomy and mastery leads to engaged and high-performing teams.” Drawing from Dan Pink's model of autonomy, mastery, and purpose, Vasco stresses the role of community and clear purpose in building engaged teams. He explains how people are naturally motivated when they understand the purpose of their work and have the freedom to master their skills. This alignment creates a strong sense of belonging and shared goals within the team. “When people have a sense of community and purpose, they bring their best selves to work.” Defining Boundaries to Foster Innovation “Clear boundaries create a flexible framework where innovation can thrive.” Vasco believes that well-defined boundaries are essential to encouraging innovation. Far from being restrictive, these boundaries offer a structured yet flexible framework that helps teams feel secure while exploring new ideas. When teams know the limits but also have room to experiment, they perform better and innovate faster. “Boundaries are not barriers; they provide the structure that allows innovation to flow freely.” Streamlining Processes with "#NoEstimates" “Focus on delivering value efficiently by reducing waste in your processes.” One of Vasco's most transformative ideas is his “No Estimates” approach to software development, which encourages focusing on value and reducing waste. This method ensures that teams spend their time wisely, enhancing productivity without the guesswork of traditional estimations. It's all about respecting everyone's time and effort while delivering maximum value. “Stop wasting time on estimates and start focusing on delivering real value to your customers.” Leadership Aligned with Employee Purpose “Leaders must understand and align with the purposes of their employees to drive team success.” Vasco shares valuable leadership advice, urging leaders to connect with their team members on a deeper level. By understanding employees' individual purposes and goals, leaders can foster more meaningful and productive collaborations. Open communication is key to building cohesive, high-performing teams that are aligned with the organization's vision. “When leaders align with their team's personal goals, they unlock higher levels of performance and engagement.” Real-World Insights from Industry Practitioners “Learning from practitioners in the field brings fresh, actionable insights.” Through his podcast, Vasco shares real-world insights from a wide range of industry practitioners. These stories highlight different approaches and solutions that have been successfully applied in various sectors, providing listeners with diverse perspectives on innovation and agile leadership. “Every practitioner I speak with offers a unique lens on solving the challenges of modern work environments.” About Vasco Duarte Vasco Duarte is an agile thought leader, podcast host, and one of the pioneers behind the “#NoEstimates” movement. With years of experience in lean and agile software development, Vasco helps teams and organizations improve productivity, efficiency, and innovation through dynamic leadership and strategic processes. He is also the host of the Scrum Master Toolbox podcast, where he shares insights from industry practitioners on agile leadership, team dynamics, and efficient workflows. You can link with Vasco Duarte on LinkedIn.

Join us in this thoughtful episode of the Mob Mentality Show as we explore the world of Lean Software Development with Dave Adsit. Titled "Crafting Lean Software: Dave Adsit on Small Batches and Short Lead Times," this episode provides valuable insights for those looking to enhance their software development values and practices. Dave Adsit shares his experiences on how to effectively implement lean principles to achieve small batches, short lead times, and frequent releases. ### Key Discussion Points: #### **Lean Software Development** - **Craft vs. Engineering** - **Principles of Flow** - **Waterfall vs. "Agile" vs. Lean** - **Timeboxes vs. Scope-Boxes** - **Resource vs. Flow Efficiency** - **Prioritization, Prototyping, and Lean Investment Bets** - **Single Piece Flow, Feature Flags, Continuous Delivery** - **Maximal Learning through Experimentation and a 50% Product Bet Success Rate** #### **Collaboration** - **Integration with Lean** - **"All Hands on Deck" Mindset** - **Relation to WIP Limits** - **Pair and Mob Programming** - **Failures and Lessons** - **Rules, Why, and Learning Paths** - **Utilization and Person vs. Team vs. System Value** #### **Continuous Improvement** - **Core Value** - **Innovative vs. Inert Practices** - **Deep vs. Shallow Learning** - **Leading Learning Opportunities** - **Knowing Enough to Make Informed Decisions** - **What If Some Do Not Want to Learn?** - **Rock Star vs. Super-Star** Video and Show Notes: https://youtu.be/LgAMUGtdXGA  

In this conversation, Etienne and Dave reminisce about their early experiences with computers and programming. They discuss the different computer models they had, the challenges of typing in code from magazines, and the evolution of technology. They then shift the conversation to their roles as VP of Engineering and CTO, and the differences between the two positions. They talk about the importance of product management and design in software development, and the value of delivering in small batches. They also discuss the concept of lean software development and the economic mindset behind it. The conversation explores the conundrum of developers being resistant to working on new features and instead over-engineering existing ones. The fear of the unknown and the comfort of familiarity play a role in this resistance. The conversation also delves into the importance of prototyping and experimentation in the development process. The concept of failure and its relationship to learning and psychological safety is discussed. The impact of different communication mediums, such as texting and video calls, on team culture and effectiveness is explored. The conversation concludes with a discussion on measuring team productivity and effectiveness through inputs, outputs, outcomes, and impact.Time Stamps00:00 - Reminiscing about Early Computers and Programming13:16 - The Differences Between VP of Engineering and CTO24:23 - Delivering in Small Batches for Faster Feedback26:47 - Embracing the Economic Mindset in Lean Software Development 35:50 - Developers' Resistance to New Features38:10 - Prototyping and Experimentation44:33 - Failure and Learning51:20 - Impact of Communication Mediums01:04:53 - Measuring Team Productivity and EffectivenessThe CTO Podcast is honored to be featured among Feedspot's top 45 C-suite podcasts.We have 200+ CTOs in peer groups: Quick Testimonials VideoContact Etienne: Website / YouTube / LinkedIn / X / Instagram / The CTO Podcast WebsiteContact Dave: LinkedIn / Website Get full access to CTO Podcast at www.ctopod.com/subscribe

Rebecca Cyr: The Penny Game Debacle, A Collaboration Change Gone Wrong And Other Lessons For Scrum Masters   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, Rebecca shares a story about working with a high-profile team struggling to finish their work within the sprint boundaries. Rebecca found out that the company had not provided sufficient agile training for the teams, which ultimately resulted in too much work-in-process, and other anti-patterns. Rebecca discusses her efforts to help the team focus and collaborate better, only to face resistance from the team's manager. She shares a failed attempt to use the Penny Game to help the team understand flow and collaboration, but this only resulted in conflict. Rebecca emphasizes the importance of understanding team dynamics and gaining consent before trying to build trust. Listen to this episode, and learn how you can navigate similar challenges and foster better team engagement.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Rebecca Cyr Rebecca Cyr is an experienced agile coach and scrum master, passionate about helping teams deliver value through agile principles and practices while learning, growing, and having fun together. Connecting people through deft facilitation is her superpower, as is storytelling as the language of learning. You can link with https://www.linkedin.com/in/rebeccacyr/.

BONUS: Mastering Work Intake For Agile Teams with Tom Cagley and Jeremy Willets 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 BONUS episode, Tom and Jeremy discuss the main ideas from their latest book on agile transformation and work intake management: Mastering Work Intake: From Chaos to Predictable Delivery. They share some of the main the challenges teams face when trying to adopt agile practices and offer practical strategies for improving work intake processes. The Trigger for the Book "Most people who try to transform and be agile don't do it well. They fail multiple times because they say 'yes' to everything, which is a lack of control on work intake." Tom emphasizes that many teams struggle with agile transformation, often due to poor management of work intake. He has built a career helping teams that have attempted and failed at this multiple times. The main issue is that they end up saying "yes" to every request, leading to a chaotic work environment, lots of work started, and very little finished. "We got started during the pandemic. We looked at many books on the topic and saw that it wasn't tackled very well. 'Actionable Agile' and 'Why Limit WIP' by Jim Benson inspired us." Defining Work Intake and avoiding common mistakes "We are drowning in work. We use metaphors to define work intake and see that work always finds a way to get done. Initially, we titled this book 'Work Entry' because of the idea that work is pushed to people, who naturally say 'yes' because they want to help." "Work has a way of getting started. Recently, I had water in my basement. I didn't know where it came from, but the water found a way in. We see this over and over at work. Work just gets in, often because saying 'no' feels career-limiting." Tom likens unmanaged work intake to water leaking into a basement—inevitable and hard to control. This analogy underscores how work finds its way into a team's backlog, often because rejecting tasks seems risky. "Jumping the queue is a very common mistake. Important work always gets done, but we don't always go through the process of identifying what's truly important. This leads to 'fast switching' between tasks and 'neglected WIP.'" Tom highlights the mistake of allowing work to bypass proper prioritization, leading to constant context switching, which makes teams slow, and neglected tasks which rarely or never get completed. "The goal conflict anti-pattern is another issue. Much of work intake is about the relationships that lead to decision-making." Jeremy discusses how conflicting goals and poor relationship management can lead to self-defeating work intake processes. Key Strategies for Managing Work Intake, and Avoiding the Over-Planning Anti-pattern "In the book, we present patterns to handle intake management and discuss the Product Owner's (PO) role. The PO is critical for managing work intake in Scrum, requiring discipline from both the PO and the team." Jeremy outlines the importance of having a disciplined Product Owner to manage work intake effectively. "The problem of team design often causes issues. Many teams work on features while supporting systems that deliver value to customers. This lack of focus is problematic. Building a solid DevOps framework is crucial." "Agility means flexibility. We need to prioritize and select work more frequently, getting feedback often to determine if the work is necessary. Refer to 'Lean Startup' for more insights." Jeremy advocates for flexibility and frequent prioritization over rigid, upfront planning. "Mapping who is involved in work intake decisions is key. Understanding the feedback loop and how it's integrated into decision-making helps manage work intake better." Tom emphasizes the importance of understanding decision-making processes and who are the stakeholders, to be able to improve those processes through collaboration. Different Types of Work Mean Different Decision Making! "People work on features, defects, support, etc. Each requires different management patterns. Recognizing team constraints is crucial for effective work intake." Tom explains the need for tailored strategies for different types of work, based on team constraints. Only this “whitebox” approach to work management can help us build a work intake process that helps us manage the work in a way that leads to faster deliveries and more productivity. As an example, Tom and Jeremy share a story about a company wanting to move to the cloud. Unfortunately, the CEO's decision overlooked the engineers' lack of skills, which led to big problems. This story puts emphasis on the importance of aligning work intake with team capabilities. A Top Tip: Be Mindful and Deliberate About Accepting Work Into Your Backlog! "We help teams be deliberate about work acceptance by emphasizing relationships and decision-making processes. Effective work intake management reduces disruptions." Tips For Product Owners  "Manage work intake across the entire product. It's more than just planning."  "PO is an active role. Help the team make decisions and sequence work." Tips For Scrum Masters "Don't overlook work intake. Involvement in this aspect is crucial to avoid anti-patterns." "Defend team boundaries to control work intake." The Impact of Applying These Ideas "It would be a lot calmer and more orderly." "We would get a lot more things done, avoiding the anti-pattern of rewarding work starts over finishes." About Tom and Jeremy Tom Cagley is an experienced agile coach and consultant specializing in helping teams manage work intake and improve their agile practices. You can link with Tom Cagley on LinkedIn. You can also listen to Tom's podcast, the SPAMCast. Jeremy Willets is a seasoned agile practitioner and author who has collaborated with Tom on numerous projects, including this book. You can link with Jeremy Willets on LinkedIn.

Doug Rabow: Agile Governance, Creating Transparency and Overhauling Project Management to Fit Agile Product Development 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, Doug shares his strategies for improving visibility and governance in project management through tools like JIRA. He explains how creating transparency enhances governance and accountability in agile teams. This episode also offers a practical look at setting up light governance frameworks that enable real-time, pull-based reporting to facilitate better decision-making and project management.   [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Doug Rabow Doug is a passionate practitioner of Lean-Agile strategic management with a focus on developing empowered teams and Lean process improvement.   You can link with Doug Rabow on LinkedIn.  

Doug Rabow: Prioritize, Visualize, Execute, A Lean Approach to Work Management in Agile Teams 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. Doug explores some of the critical aspects of team management that ensure efficiency and clarity. Doug also shares how visual management is essential for maintaining focus on top priorities within teams. We learn about the Five S from Lean, and how simplifying and visually organizing work can prevent priority confusion and, in the end, improve productivity. Featured Book of the Week: The Toyota Way by Jeffrey Liker In this episode, we explore lessons from The Toyota Way by Jeffrey Liker beyond manufacturing. Doug describes how The Toyota Way applies to strategic management and software development, focusing on high-quality, small batches. Discover how continuous feedback drives continuous improvement, and what Agile learned from Lean Manufacturing.   [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 Doug Rabow Doug is a passionate practitioner of Lean-Agile strategic management with a focus on developing empowered teams and Lean process improvement.   You can link with Doug Rabow on LinkedIn.

Doug Rabow: The Delicate Dance of Driving Change, Learning How To Time Change Input in Agile Teams 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 facilitating change, jumping in too quickly can be problematic. Doug shares a story of his experience stepping into a less competitive industry, eager to implement numerous improvements. However, the existing team was content with their workflow, which created resistance to Doug's ideas. In this episode, we explore how Scrum Masters can help drive change without overwhelming their teams. And how facilitators can balance improvement enthusiasm with team readiness, and why involving the team in the change process is crucial.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Doug Rabow Doug is a passionate practitioner of Lean-Agile strategic management with a focus on developing empowered teams and Lean process improvement.   You can link with Doug Rabow on LinkedIn.

In Elixir Wizards Office Hours Episode 2, "Discovery Discoveries," SmartLogic's Project Manager Alicia Brindisi and VP of Delivery Bri LaVorgna join Elixir Wizards Sundi Myint and Owen Bickford on an exploratory journey through the discovery phase of the software development lifecycle. This episode highlights how collaboration and communication transform the client-project team dynamic into a customized expedition. The goal of discovery is to reveal clear business goals, understand the end user, pinpoint key project objectives, and meticulously document the path forward in a Product Requirements Document (PRD). The discussion emphasizes the importance of fostering transparency, trust, and open communication. Through a mutual exchange of ideas, we are able to create the most tailored, efficient solutions that meet the client's current goals and their vision for the future. Key topics discussed in this episode: Mastering the art of tailored, collaborative discovery Navigating business landscapes and user experiences with empathy Sculpting project objectives and architectural blueprints Continuously capturing discoveries and refining documentation Striking the perfect balance between flexibility and structured processes Steering clear of scope creep while managing expectations Tapping into collective wisdom for ongoing discovery Building and sustaining a foundation of trust and transparency Links mentioned in this episode: https://smartlogic.io/ Follow SmartLogic on social media: https://twitter.com/smartlogic Contact Bri: bri@smartlogic.io What is a PRD? https://en.wikipedia.org/wiki/Productrequirementsdocument Special Guests: Alicia Brindisi and Bri LaVorgna.

Link e riferimenti episodio:The Phoenix Project https://amzn.to/3Sx4AY5The Toyota Way https://amzn.to/499w9w1Lean Software Development https://amzn.to/3Okw0hfMio articolo su Codemotion Magazine: https://www.codemotion.com/magazine/it/devops-it/agile-xp-lean-devops/___________________________________________________________________Seguimi su LinkedIn: https://www.linkedin.com/in/daniele-scillia/Iscriviti alla mia newsletter (in inglese): https://learnagilepractices.substack.com/Vuoi accelerare la crescita della tua carriera? Scopri il mio servizio di Personal Coaching per Software Developers: https://learnagilepractices.gumroad.com/l/personal-coachingTutti i miei prodotti digitali dedicati alla crescita come programmatore: https://learnagilepractices.gumroad.com/

Phoenix core team members Chris McCord and Jason Stiebs join Elixir Wizards Sundi Myint and Owen Bickford the growth of Phoenix and LiveView, the latest updates, and what they're excited to see in the future. They express excitement for the possibilities of machine learning, AI, and distributed systems and how these emerging technologies will enhance the user experience of Elixir and LiveView applications in the next decade. Key Topics Discussed in this Episode: How community contributions and feedback help improve Phoenix LiveView The addition of function components, declarative assigns, HEEx, and streams Why Ecto changesets should be used as "fire and forget" data structures Excitement about machine learning and AI with libraries like NX The possibility of distributed systems and actors in the future Verifying and solving issues in the Phoenix and LiveView issue trackers Why marketing plays a part in the adoption and mindshare of Phoenix How streams provide a primitive for arbitrarily large dynamic lists Elixir VM's ability to scale to millions of connections A creative use of form inputs for associations with dynamic children Links Mentioned in this Episode: Fly Site https://fly.io/ Keynote: The Road To LiveView 1.0 by Chris McCord | ElixirConf EU 2023 (https://youtu.be/FADQAnq0RpA) Keynote: I Was Wrong About LiveView by Jason Stiebs | ElixirConf 2022 (https://youtu.be/INgpJ3eIKZY) Phoenix Site https://www.phoenixframework.org/ Phoenix Github https://github.com/phoenixframework Two-Story, 10-Room Purple Martin House (https://suncatcherstudio.com/uploads/birds/birdhouses/purple-martin-house-plans/images-large/purple-martin-birdhouse-plans-labeled.png) Blog: The Road to 2 Million Websocket Connections in Phoenix (https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections) Raxx Elixir Webserver Interface https://hexdocs.pm/raxx/0.4.1/readme.html Livebook Site https://livebook.dev/ Sundi's 6'x 6' Phoenix painting (https://twitter.com/sundikhin/status/1663930854928728064) Surface on Hex https://hex.pm/packages/surface Axon Deep Learning Framework https://hexdocs.pm/axon/Axon.html Nx Numerical Elixir https://hexdocs.pm/nx/intro-to-nx.html Phoenix PubSub https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html Jason Stiebs on Twitter https://twitter.com/peregrine Jason Stiebs on Mastodon https://merveilles.town/@peregrine Special Guests: Chris McCord and Jason Stiebs.

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

Join Murray Robinson and Shane Gibson in a conversation with Mary and Tom Poppendieck about Lean and Software Development. Organizations have queues because they don't care about the customer. The three rules of lean, customer focus, flow and highly efficient expert teams. Scale your organization like a micro services architecture. Its not about doing the work right its about doing the right work. Don't focus on utilization focus on the value we provide. Don't copy practices copy the principles behind the practices. Don't centralize processes. Set goals and let teams develop their own processes.   Listen to the podcast on your favourite podcast app: | Spotify | Apple Podcasts | Google Podcasts | iHeart Radio | PlayerFM | Amazon Music | Listen Notes | TuneIn | Audible | Podchaser |  Connect with Mary and Tom @ http://www.poppendieck.com/  or leanessays.com,  Murray via email or Shane in the Twitter-sphere  @shagility.   The No Nonsense Podcast is sponsored by: Simply Magical Data

"Pull, don't push. Don't tell people what to do. Tell them what results you want and let them figure out how best to achieve the outcome that's needed." Mary & Tom Poppendieck are the co-authors of several books related to Agile and Lean, including their award-winning book “Lean Software Development: An Agile Toolkit” published in 2003. In this episode, Mary & Tom shared about lean software development, its principles and mindset, and the concept of a pull system. Mary & Tom then pointed out the problems of having proxies in software development and how it is much better to manage by the outcomes by having the people directly figuring out the best way to achieve those outcomes. Later on, Mary & Tom talked about the concept of flow, why it is important to optimize flow, and how to optimize flow by analyzing the value stream map and minimizing approval process. Listen out for: Career Journey - [00:05:26] Lean Software Development - [00:18:50] Pull, Don't Push - [00:23:34] Proxies - [00:31:00] Managing by Outcome - [00:37:10] Optimizing Flow - [00:41:18] Value Stream Map & Approvals - [00:47:00] 3 Tech Lead Wisdom - [00:55:05] _____ Mary Poppendieck's Bio Mary wrote the now-classic book “Lean Software Development: an Agile Toolkit”, proposing an approach which focuses on customers, respects software engineers, concentrates on learning, and leverages flow. Mary is a popular writer and speaker. Sequels of her first book include “Implementing Lean Software Development: from Concept to Cash”, “Leading Lean Software Development: Results are Not the Point” and “The Lean Mindset: Ask the Right Questions”. Tom Poppendieck's Bio Tom has over three decades of experience in computing, including several years of work with object technology. Tom holds a PhD in Physics and has taught physics for ten years. He is the coauthor of four books: “Lean Software Development” (2003), “Implementing Lean Software Development” (2006), “Leading Lean Software Development” (2009) and “Lean Mindset” (2013). Follow Mary and Tom: Website – http://www.poppendieck.com/ Mary's blog – http://www.leanessays.com/ Mary's Twitter – @mpoppendieck Our Sponsor Today's episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals. Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/91.

Lean TDD is an attempt to reconcile some conflicting aspects of Test Driven Development and Lean Software Development. I've mentioned Lean TDD on the podcast a few times and even tried to do a quick outline at the end of episode 162 (https://testandcode.com/162). This episode is a more complete outline, or at least a first draft. If you feel you've got a good understanding of TDD, and it's working awesome for you, that's great. Keep doing what you're doing. There are no problems. For me, the normal way TDD is taught just doesn't work. So I'm trying to come up with a spin on some old ideas to make it work for me. I'm hoping it works for you as well. I'm calling the new thing Lean TDD. It's inspired by decades of experience writing software and influence from dozens of sources, including Pragmatic Programmer, Lean Software Development, Test-Driven Development by Example, and many blog posts and wiki articles. The main highlights, however, come from the collision of ideas between Lean and TDD and how I've tried to resolve the seemingly opposing processes.

Consejos para evitar uno de los problemas fundamentales de TDD. Intenta no caer en esta trampa!TDD is dead. Long live testing by David Heinemeier Hansson (creator of Ruby on Rails): https://dhh.dk/2014/tdd-is-dead-long-live-testing.htmlRIP TDD by Kent Beck (Author of "Extremme Programming Explained" and "inventor" of TDD): https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847Is TDD dead? by Martin Fowler (Famous by "Refactoring: Improving the Design of Existing Code" but many others contributions): https://martinfowler.com/articles/is-tdd-dead/Building features with Spike & Stabilise: https://medium.com/ingeniouslysimple/building-features-with-spike-stabilise-1906a9006a87What is programmer anarchy and does it have a future?: https://martinjeeblog.com/2012/11/20/What is Lean Software Development: https://www.productplan.com/glossary/lean-software-development/Extremme Programming Explained (Kent Beck): https://www.amazon.es/Extreme-Programming-Explained-Embrace-Embracing/dp/0321278658/ref=sr_1_1?__mk_es_ES=ÅMÅŽÕÑ&crid=1OGSUTQ998TZ0&dchild=1&keywords=extreme+programming+explained&qid=1615537489&sprefix=extreme+program%2Caps%2C179&sr=8-1Test Driven Development: By Example (Kent Beck): https://www.amazon.es/Driven-Development-Example-Addison-Wesley-Signature/dp/0321146530/ref=sr_1_1?__mk_es_ES=ÅMÅŽÕÑ&dchild=1&keywords=tdd+by+example&qid=1615536016&sr=8-1Refactoring: Improving the Design of Existing Code by Martin Fowler: https://www.amazon.es/Refactoring-Improving-Existing-Addison-wesley-Signature/dp/0134757599/ref=sr_1_4?__mk_es_ES=ÅMÅŽÕÑ&dchild=1&keywords=Refactoring+to+Patterns&qid=1615540711&sr=8-4Refactoring to patterns by  Kerievsky Joshua: https://www.amazon.es/Refactoring-Patterns-Addison-Wesley-Signature-Fowler-ebook/dp/B001TKD4RQ/ref=sr_1_1?__mk_es_ES=ÅMÅŽÕÑ&dchild=1&keywords=Refactoring+to+Patterns%3A+Kerievsky%2C+Joshua&qid=1615540653&sr=8-1mail: info@joantolos.comSwag: http://store.joantolos.comOfficial web: http://www.joantolos.comApple podcast: https://podcasts.apple.com/es/podcast/nada-nuevo-bajo-el-sol/id1563220961Spotify: https://open.spotify.com/show/6BcHhm3wO3cvSIMZL6ssG8

“Kanban is a flow strategy that helps you to optimize the flow of value through your value streams from ideation to customer." Dimitar Karaivanov is a Lean-thinker, a Kanban practitioner, and the CEO and co-founder of Kanbanize. In this episode, Dimitar shared his story on how he got fascinated by the simplicity and the effectiveness of Kanban, which then led him to start Kanbanize. He shared in-depth the concept of Kanban and why Kanban becomes one of the most popular Lean practices. Dimitar then shared about the principles, practices, and anti-patterns behind Kanban, as well as tips on how companies can improve their Kanban practices, including dealing with external dependencies. Listen out for: Career Journey - [00:05:06] Kanbanize Story - [00:07:05] Kanban - [00:10:25] Why Kanban Becomes Popular - [00:12:24] Kanban Principles - [00:14:53] Visualize the Workflow - [00:20:23] Limit Work in Progress - [00:23:11] Manage Flow - [00:28:26] Make Process Policies Explicit - [00:30:49] Feedback Loops and Improve Collaboratively - [00:31:43] Kanban Metrics - [00:33:52] Kanban Anti-patterns - [00:36:17] Handling External Dependencies - [00:40:39] Tips to Improve Your Kanban Practice - [00:42:01] 3 Tech Lead Wisdom - [00:43:40] _____ Dimitar's Bio Dimitar Karaivanov is a Lean-thinker and a Kanban practitioner with a solid background in the areas of software development and process improvement. Dimitar is also a keynote speaker and the author of ‘Lean Software Development with Kanban'. His expertise was gained through more than 15 years of career development at companies like Johnson Controls, SAP, and Software AG. Dimitar has envisioned and brought to life the idea of Kanbanize aimed at solving problems in the way companies manage big initiatives spread across multiple teams. Through the success of his company, he has proven that Kanban can be used not just for change management, but also for product development. He is passionate about achieving extreme performance at scale and applying Lean / Kanban outside IT, and is an active member, supporter and promoter of initiatives within these communities. Follow Dimitar: LinkedIn – https://www.linkedin.com/in/dimitar-karaivanov Twitter – https://twitter.com/dimitar_hk Kanbanize – https://kanbanize.com/ Our Sponsor Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags by visiting https://techleadjournal.dev/shop. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/49.

Guest Mr. Brian Tan Seng (98Labs, Inc) of YoungCTO Rafi Quisumbing Application Developer, Linux Systems Administrator, Software Architect, and Project Manager in a wide array of business applications. Particularly interested in systems optimization, and Agile software development. Also interested in conducting training and advising corporations in adopting Agile methodologies. https://www.linkedin.com/in/briantans... Specialties: Agile Software Development, Scrum, Extreme Programming (XP), Lean Software Development, Java (Spring Framework, Hibernate, Struts 2), Groovy & Grails

Get the book.Here's the song I mentioned, and missnamed.This is the company that makes the mystery game. If you sign up for notifications of new games, they give you a free mini game.Here is the one-page contract I used with companies of all sizes for projects up to a quarter of a million dollars.Support the show (http://patreon.com/agilebookclub)

În episodul 15 facem o trecere în revistă a principiilor ce stau la baza metodologiei Lean de dezvoltare a proiectelor software. Youtube: https://www.youtube.com/watch?v=8fZr8ptxel4 (Gestionarea Proiectelor Software | S1E15 | Lean Software Development)

Welcome to yet another episode on the Agile Atelier podcast! Today’s topic is Lean Software Development, I have the pleasure of chatting with two special guests – Mary and Tom Poppendieck. Mary and Tom are best known for their book Lean Software Development: An Agile Toolkit. Mary started her career as a process control programmer,…… Continue reading Episode 30: Lean Software Development with Mary and Tom Poppendieck

https://www.leanblog.org/391My guests for Episode #391 are Mary Poppendieck and Tom Poppendieck, the authors of books including Lean Software Development: An Agile Toolkit, Implementing Lean Software Development, and The Lean Mindset: Ask the Right Questions.In the episode, we'll hear their thoughts on Lean as "a way of thinking that values people" and how teamwork, problem solving, and customer focus are integral to Lean -- in software or otherwise. How can we build capabilities for problem solving ("producing people") and how can we "learn how to learn"?Questions, Links, and MoreHow did you first discover Lean? How did you come to see the potential applications to software development?You published Lean Software Development in 2003 -- how do you define that term “Lean” and what does it mean to you?How has your view of Lean evolved over those 17 years?What have you learned about Lean / TPS from visiting Japan?Your 2013 book is called "The Lean Mindset" -- as the subtitle says, asking the right questions is important... why so? How do we know what the right questions are?2009 -- Leading Lean Software Development -- another provocative subtitle... "results are not the point" -- what do you mean?LeanEssays.comTheir website: http://poppendieck.com/Mary on Twitter

Many agile concepts came from the manufacturing space. Mary and Tom share the decades of experience that brought them to define the term Lean Software Development. As always, they use the power of stories to talk about how organizations need to think differently about how they organize and optimize team flow. It was a joy listening to them and I hope you enjoy it as well. You can reach Mary at mary@poppendieck.com or follow her on Twitter @mpoppendieck.

Czy Metoda Kanban wpisuje się w podejście Lean? Czym różni się zarządzanie szczupłe (lean) w branży wytwórczej i pracy intelektualnej? Czym jest Lean Software Development i czy stosuje się jedynie do wytwarzania oprogramowania? O tym wszystkim w najnowszym odcinku podcastu "Kanban przy kawie". Ponadto od teraz możesz zostać sponsorem podcastu na platformie Patronite! Więcej na www.patronite.pl/kanban

A three minute talk on Understanding Lean Software Development. w: 2andh.com 

Joe Krebs speaks with Mary and Tom Poppendieck about Lean Software Development. Together they wrote a series of books: “Lean Software Development” “Implementing Lean Software Development”, “Leading Lean Software Development” and “The Lean Mindset” in chronological order. Mary and Tom talked about how Lean fits into the universe of processes, tools and techniques in regards to processes like Scrum or Kanban. They did that from a leaders point of view. We discussed the role of knowledge workers and how that relates to people for example in Lean Manufacturing. We also had a chance to touch on Kata practices as they gave feedback to the initial release of the Agile Kata.

In this episode, I speak with Mary and Tom Poppendieck about Lean Software Development. We talked about knowledge workers vs. manufacturing, scaling, kaizen and the kata. Mary and Tom also grouped the last 4 decades of software development and give a projection for the decade starting in 2020. I hope you enjoy the listen. If you like to meet Mary and Tom in person, join the Agile Power Week in New York on MAR 3-5. (www.incrementor.com/apwnyc).

Welcome to the History of Computing Podcast, where we explore the history of information technology. Because understanding the past prepares us for the innovations of the future! Todays episode is on Agile Software Development. Agile software development is a methodology, or anti-methodology, or approach to software development that evolves the requirements a team needs to fulfill and the solutions they need to build in a collaborative, self-organized, and cross-functional way. Boy, that's a lot to spit out there. I was in an elevator the other day and I heard someone say: “That's not very agile.” And at that moment, I knew that I just couldn't help but do an episode on agile. I've worked in a lot of teams that use a lot of variants of agile, scrum, Kanban, scrumban, Extreme Programing, Lean Software Development. Some of these are almost polar opposites and you still hear people talk about what is agile and if they want to make fun of people doing things an old way, they'll say something like waterfall. Nothing ever was waterfall, given that you learn on the fly, find re-usable bits or hit a place where you just say that's not possible. But that's another story. The point here is that agile is, well, weaponized to back up what a person wants someone to do. Or how they want a team to be run. And it isn't always done from an informed point of view. Why is Agile an anti-methodology? Think of it more like a classification maybe. There were a number of methodologies like Extreme Programming, Scrum, Kanban, Feature Driven Development, Adaptive Software Development, RAD, and Lean Software Development. These had come out to bring shape around a very similar idea. But over the course of 10-20 years, each had been developed in isolation. In college, I had a computer science professor who talked about “adaptive software development” from his days at a large power company in Georgia back in the 70s. Basically, you are always adapting what you're doing based on speculation of how long something will take, collaboration on that observation and what you learn while actually building. This shaped how I view software development for years to come. He was already making fun of Waterfall methodologies, or a cycle where you write a large set of requirements and stick to them. Waterfall worked well if you were building a computer to land people on the moon. It was a way of saying “we're not engineers, we're software developers.” Later in college, with the rapid proliferation of the Internet and computers into dorm rooms I watched the emergence of rapid application development, where you let the interface requirements determine how you build. But once someone weaponized that by putting a label on it, or worse forking the label into spiral and unified models, then they became much less useful and the next hot thing had to come along. Kent Beck built a methodology called Extreme Programming - or XP for short - in 1996 and that was the next hotness. Here, we release software in shorter development cycles and software developers, like police officers on patrol work in pairs, reviewing and testing code and not writing each feature until it's required. The idea of unit testing and rapid releasing really came out of the fact that the explosion of the Internet in the 90s meant people had to ship fast and this was also during the rise of really main-stream object-oriented programming languages. The nice thing about XP was that you could show a nice graph where you planned, managed, designed, coded, and tested your software. The rules of Extreme Programming included things like “Code the unit test first” - and “A stand up meeting starts each day.” Extreme Programming is one of these methodologies. Scrum is probably the one most commonly used today. But the rest, as well as the Crystal family of methodologies, are now classified as Agile software development methodologies. So it's like a parent. Is agile really just a classification then? No. So where did agile come from? By 2001, Kent Beck, who developed Extreme Programming met with Ward Cunningham (who built WikiWikiWeb, the first wiki), Dave Thomas, a programmer who has since written 11 books, Jeff Sutherland and Ken Schwaber, who designed Scrum. Jim Highsmith, who developed that Adaptive Software Development methodology, and many others were at the time involved in trying to align an organizational methodology that allowed software developers to stop acting like people that built bridges or large buildings. Most had day jobs but they were like-minded and decided to meet at a quaint resort in Snowbird, Utah. They might have all wanted to use the methodologies that each of them had developed. But if they had all been jerks then they might not have had a shift in how software would be written for the next 20+ years. They decided to start with something simple, a statement of values; instead of Instead of bickering and being dug into specific details, they were all able to agree that software development should not be managed in the same fashion as engineering projects are run. So they gave us the Manifesto for Agile Software Development… The Manifesto reads: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: * Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. But additionally, the principles dig into and expand upon some of that adjacently. The principles behind the Agile Manifesto: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Many of the words here are easily weaponized. For example, “satisfy the customer.” Who's the customer? The product manager? The end user? The person in an enterprise who actually buys the software? The person in that IT department that made the decision to buy the software? In the scrum methodology, the customer is not known. The product owner is their representative. But the principles should need to identify that, just use the word so each methodology makes sure to cover it. Now take “continuous delivery.” People frequently just lump CI in there with CD. I've heard continuous design, continuous improvement, continuous deployment, continuous podcasting. Wait, I made the last one up. We could spend hours going through each of these and identifying where they aren't specific enough. Or, again, we could revel in their lack of specificity by pointing us into the direction of a methodology where these words get much more specific meanings. Ironically, I know accounting teams at very large companies that have scrum masters, engineering teams for big projects with a project manager and a scrum master, and even a team of judges that use agile methodologies. There are now scrum masters embedded in most software teams of note. But once you see Agile on the cover of The Harvard Business Review, you hate to do this given all the classes in agile/XP/scrum - but you have to start wondering what's next? For 20 years, we've been saying “stop treating us like engineers” or “that's waterfall.” Every methodology seems to grow. Right after I finished my PMP I was on a project with someone else that had just finished theirs. I think they tried to implement the entire Project management Body of Knowledge. If you try to have every ceremony from Scrum, you're not likely to even have half a day left over to write any code. But you also don't want to be like the person on the elevator, weaponizing only small parts of a larger body of work, just to get your way. And more importantly, to admit that none of us have all the right answers and be ready to, as they say in Extreme Programming: Fix XP when it breaks - which is similar to Boyd's Destruction and Creation, or the sustenance and destruction in Lean Six-Sigma. Many of us forget that last part: be willing to walk away from the dogma and start over. Thomas Jefferson called for a revolution every 20 years. We have two years to come up with a replacement! And until you replace me, thank you so very much for tuning into another episode of the History of Computing Podcast. We're lucky to have you. Have a great day!

In the last couple of episodes I've introduced the concepts of Minimum Viable Product and Lean Software Development. In this episode I want to introduce Agile. Along with Minimum Viable Product & Lean Software Development - Agile - along with Cloud & DevOps which I'll pick up in the coming weeks - provides a great introduction on how to get the Better Return from your Software Development Investment.

Welcome to the History of Computing Podcast, where we explore the history of information technology. Because understanding the past prepares us for the innovations of the future! Todays episode is on Agile Software Development. Agile software development is a methodology, or anti-methodology, or approach to software development that evolves the requirements a team needs to fulfill and the solutions they need to build in a collaborative, self-organized, and cross-functional way. Boy, that's a lot to spit out there. I was in an elevator the other day and I heard someone say: “That's not very agile.” And at that moment, I knew that I just couldn't help but do an episode on agile. I've worked in a lot of teams that use a lot of variants of agile, scrum, Kanban, scrumban, Extreme Programing, Lean Software Development. Some of these are almost polar opposites and you still hear people talk about what is agile and if they want to make fun of people doing things an old way, they'll say something like waterfall. Nothing ever was waterfall, given that you learn on the fly, find re-usable bits or hit a place where you just say that's not possible. But that's another story. The point here is that agile is, well, weaponized to back up what a person wants someone to do. Or how they want a team to be run. And it isn't always done from an informed point of view. Why is Agile an anti-methodology? Think of it more like a classification maybe. There were a number of methodologies like Extreme Programming, Scrum, Kanban, Feature Driven Development, Adaptive Software Development, RAD, and Lean Software Development. These had come out to bring shape around a very similar idea. But over the course of 10-20 years, each had been developed in isolation. In college, I had a computer science professor who talked about “adaptive software development” from his days at a large power company in Georgia back in the 70s. Basically, you are always adapting what you're doing based on speculation of how long something will take, collaboration on that observation and what you learn while actually building. This shaped how I view software development for years to come. He was already making fun of Waterfall methodologies, or a cycle where you write a large set of requirements and stick to them. Waterfall worked well if you were building a computer to land people on the moon. It was a way of saying “we're not engineers, we're software developers.” Later in college, with the rapid proliferation of the Internet and computers into dorm rooms I watched the emergence of rapid application development, where you let the interface requirements determine how you build. But once someone weaponized that by putting a label on it, or worse forking the label into spiral and unified models, then they became much less useful and the next hot thing had to come along. Kent Beck built a methodology called Extreme Programming - or XP for short - in 1996 and that was the next hotness. Here, we release software in shorter development cycles and software developers, like police officers on patrol work in pairs, reviewing and testing code and not writing each feature until it's required. The idea of unit testing and rapid releasing really came out of the fact that the explosion of the Internet in the 90s meant people had to ship fast and this was also during the rise of really main-stream object-oriented programming languages. The nice thing about XP was that you could show a nice graph where you planned, managed, designed, coded, and tested your software. The rules of Extreme Programming included things like “Code the unit test first” - and “A stand up meeting starts each day.” Extreme Programming is one of these methodologies. Scrum is probably the one most commonly used today. But the rest, as well as the Crystal family of methodologies, are now classified as Agile software development methodologies. So it's like a parent. Is agile really just a classification then? No. So where did agile come from? By 2001, Kent Beck, who developed Extreme Programming met with Ward Cunningham (who built WikiWikiWeb, the first wiki), Dave Thomas, a programmer who has since written 11 books, Jeff Sutherland and Ken Schwaber, who designed Scrum. Jim Highsmith, who developed that Adaptive Software Development methodology, and many others were at the time involved in trying to align an organizational methodology that allowed software developers to stop acting like people that built bridges or large buildings. Most had day jobs but they were like-minded and decided to meet at a quaint resort in Snowbird, Utah. They might have all wanted to use the methodologies that each of them had developed. But if they had all been jerks then they might not have had a shift in how software would be written for the next 20+ years. They decided to start with something simple, a statement of values; instead of Instead of bickering and being dug into specific details, they were all able to agree that software development should not be managed in the same fashion as engineering projects are run. So they gave us the Manifesto for Agile Software Development… The Manifesto reads: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: * Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. But additionally, the principles dig into and expand upon some of that adjacently. The principles behind the Agile Manifesto: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Many of the words here are easily weaponized. For example, “satisfy the customer.” Who's the customer? The product manager? The end user? The person in an enterprise who actually buys the software? The person in that IT department that made the decision to buy the software? In the scrum methodology, the customer is not known. The product owner is their representative. But the principles should need to identify that, just use the word so each methodology makes sure to cover it. Now take “continuous delivery.” People frequently just lump CI in there with CD. I've heard continuous design, continuous improvement, continuous deployment, continuous podcasting. Wait, I made the last one up. We could spend hours going through each of these and identifying where they aren't specific enough. Or, again, we could revel in their lack of specificity by pointing us into the direction of a methodology where these words get much more specific meanings. Ironically, I know accounting teams at very large companies that have scrum masters, engineering teams for big projects with a project manager and a scrum master, and even a team of judges that use agile methodologies. There are now scrum masters embedded in most software teams of note. But once you see Agile on the cover of The Harvard Business Review, you hate to do this given all the classes in agile/XP/scrum - but you have to start wondering what's next? For 20 years, we've been saying “stop treating us like engineers” or “that's waterfall.” Every methodology seems to grow. Right after I finished my PMP I was on a project with someone else that had just finished theirs. I think they tried to implement the entire Project management Body of Knowledge. If you try to have every ceremony from Scrum, you're not likely to even have half a day left over to write any code. But you also don't want to be like the person on the elevator, weaponizing only small parts of a larger body of work, just to get your way. And more importantly, to admit that none of us have all the right answers and be ready to, as they say in Extreme Programming: Fix XP when it breaks - which is similar to Boyd's Destruction and Creation, or the sustenance and destruction in Lean Six-Sigma. Many of us forget that last part: be willing to walk away from the dogma and start over. Thomas Jefferson called for a revolution every 20 years. We have two years to come up with a replacement! And until you replace me, thank you so very much for tuning into another episode of the History of Computing Podcast. We're lucky to have you. Have a great day!

In the last episode I introduced the Minimum Viable Product. I personally see Minimum Viable Products being related to Lean Principals. I'll give you an introduction to Lean in this podcast - and where appropriate, tie it back to the Minimum Viable Product.

SPaMCAST 555 features our essay applying a simple filter to determine whether an interaction or event is collaborative. In this essay we put the simple four attribute model we introduced in SPaMCAST 554 to use.  Collaboration is an important tool, so let's recognize what is or isn’t collaboration and stop calling everything collaboration. We will also have a visit from the Software Sensei, Kim Pries. In this installment, Kim returns to the topic of lean software development.  In 2019, the concepts of lean and agile have become intertwined. Understanding concepts like waste is important for everyone involved in delivering value.   Re-Read Saturday News This week we dive into the availability heuristic.  The availability heuristic is useful for understanding what people believe and how they will act.  All leaders need to understand the impact of top of mind experiences on decision making and how to disrupt those biases; the availability heuristic is a tool for building that knowledge.  Remember, if you do not have a favorite, dog-eared copy of Thinking, Fast and Slow, please buy a copy.  Using the links in this blog entry helps support the blog and its alter-ego, The Software Process and Measurement Cast. Buy a copy on Amazon,  It’s time to get reading!   The installments: Week 1: Logistics and Introduction – http://bit.ly/2UL4D6h Week 2: The Characters Of The Story – http://bit.ly/2PwItyX Week 3: Attention and Effort – http://bit.ly/2H45x5A Week 4: The Lazy Controller – http://bit.ly/2LE3MQQ Week 5: The Associative Machine – http://bit.ly/2JQgp8I Week 6: Cognitive Ease – http://bit.ly/2VTuqVu Week 7: Norms, Surprises, and Causes – http://bit.ly/2Molok2 Week 8: A Machine for Jumping to Conclusions - http://bit.ly/2XOjOcx  Week 9: How Judgement Happens and Answering An Easier Question - http://bit.ly/2XBPaX3  Week 10:  Law of Small Numbers - http://bit.ly/2JcjxtI  Week 11: Anchors - http://bit.ly/30iMgUu  Week 12: The Science of Availability - http://bit.ly/30tW6TN    Next SPaMCAST SPaMCAST 556 will continue our essay and discussion extravaganza.  We will feature an essay on using questions to coach and teach. Asking questions is one way to get someone to own a change rather than use renting it from you. We will also have a visit from Susan Parente! 

Today we relate three great stories we heard or told at CITCON in Ghent, all starting with different answers to Jeffrey's question, "Why can't we ship that today?" The answers lead us to different suggestions for helping teams to move faster and get customer feedback. SHOW LINKS: - Value stream mapping: https://en.wikipedia.org/wiki/Value-stream_mapping - CITCON notes: https://citconf.com/wiki/index.php?title=WarStoriesAndSuccesses - Poppendieck and Poppendieck, Lean Software Development: https://www.amazon.co.uk/Lean-Software-Development-Agile-Toolkit/dp/0321150783 *** We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us: see link on troubleshootingagile.com Tweet us: twitter.com/TShootingAgile Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

GUEST BIO: David James is the founder of TotalCarCheck.co.uk, a vehicle background check website. David started this company as successful entrepreneurs do, by solving a problem he encountered. After his parents bought a stolen car and found themselves at a $5,000 loss, he created a website that wouldn't allow this to happen again. David's focused and realistic mindset has supported TotalCarCheck.co.uk in running background checks on almost two thirds of all the vehicles in the United Kingdom. The parallel app has become one of the top utility apps in the UK and David continues to use forward thinking, innovation, and his customers to grow his company and create transparency in the car buying process. SHOW SUMMARY: David James, founder of TotalCarCheck.co.uk, is an entrepreneur with a laser focus on simplicity and great results. His vehicle background check website has become the most successful website in the UK in his niche. David has built the foundation for his software based of seven lean principles, which he'll discuss during our conversation. In this episode, David explains how he runs his company with only two employees, his advice for new software entrepreneurs and the books that have given him the insight for this accolade of success. This is The Lean Commerce Podcast. TOPICS: How did you get started with your business? 0:57 I had a more normal career starting off, but I always had an entrepreneurial spirit. My parents accidentally bought a stolen car and I realized there was a problem that needed to be solved, people needed to be able to run a background check on a car. 4:17 Once you get the wheels rolling, you start to get momentum. Very quickly people started to realize what we were doing was different than what other vehicle background check websites were doing and business started to grow from there. 6:33 Even in darker times, there is opportunity. It sounds spiritual, but the experience of my parent's buying the stolen car was an epiphany for me. When I look back, it all seems kind of unbelievable that something so fortunate was built from such a negative experience. If you have a passion for something and genuinely enjoy doing it, it really helps you to become successful. 13:06 I think if you are consistent in what you want to do, you generally get results in the end. If you stay consistent in those principles and approach, you come out well in the end. You're checking two thirds of all of the vehicles in the UK, what does the backend of your business look like? 15:55 Pretty much from day one, we've done this with only two staff members (including myself). This works because of two rules. The first is, we automate ruthlessly. People tend to skip over this because the initial effort is difficult, but the cost saving over five years is incredible. The second is, outsource wherever you can. Our accounts, legal, HR, design and development are all outsourced. This gives you much more flexibility. What are your lean development principles? 20:22 My lean business strategy comes from the seven principles outlined in Lean Software Development by Mary Poppendieck. First, eliminate all waste. Second, amplify learning by teaching your entire team, not just yourself. Third, make decisions as late as possible. Fourth, deliver as quickly as possible. Fifth, empower the team. Sixth, build integrity. Seventh, see the whole picture. Marketing techniques that worked before, don't always work now. How do you work around this problem? 35:56 It's frustrating because you don't know if it's the market changing or if you did something wrong. But, that's the beauty of what we do. It was formulaic, it would be easy. That's how the best have their advantage because they are able to discover the variables to focus on and the variables to ignore. 38:40 Whenever I'm pouring over the numbers, I try to ground myself by asking, “What am I doing this for?” and remind myself that I'm doing this so I can

GUEST BIO: David James is the founder of TotalCarCheck.co.uk, a vehicle background check website. David started this company as successful entrepreneurs do, by solving a problem he encountered. After his parents bought a stolen car and found themselves at a $5,000 loss, he created a website that wouldn't allow this to happen again. David's focused and realistic mindset has supported TotalCarCheck.co.uk in running background checks on almost two thirds of all the vehicles in the United Kingdom. The parallel app has become one of the top utility apps in the UK and David continues to use forward thinking, innovation, and his customers to grow his company and create transparency in the car buying process. SHOW SUMMARY: David James, founder of TotalCarCheck.co.uk, is an entrepreneur with a laser focus on simplicity and great results. His vehicle background check website has become the most successful website in the UK in his niche. David has built the foundation for his software based of seven lean principles, which he'll discuss during our conversation. In this episode, David explains how he runs his company with only two employees, his advice for new software entrepreneurs and the books that have given him the insight for this accolade of success. This is The Lean Commerce Podcast. TOPICS: How did you get started with your business? 0:57 I had a more normal career starting off, but I always had an entrepreneurial spirit. My parents accidentally bought a stolen car and I realized there was a problem that needed to be solved, people needed to be able to run a background check on a car. 4:17 Once you get the wheels rolling, you start to get momentum. Very quickly people started to realize what we were doing was different than what other vehicle background check websites were doing and business started to grow from there. 6:33 Even in darker times, there is opportunity. It sounds spiritual, but the experience of my parent's buying the stolen car was an epiphany for me. When I look back, it all seems kind of unbelievable that something so fortunate was built from such a negative experience. If you have a passion for something and genuinely enjoy doing it, it really helps you to become successful. 13:06 I think if you are consistent in what you want to do, you generally get results in the end. If you stay consistent in those principles and approach, you come out well in the end. You're checking two thirds of all of the vehicles in the UK, what does the backend of your business look like? 15:55 Pretty much from day one, we've done this with only two staff members (including myself). This works because of two rules. The first is, we automate ruthlessly. People tend to skip over this because the initial effort is difficult, but the cost saving over five years is incredible. The second is, outsource wherever you can. Our accounts, legal, HR, design and development are all outsourced. This gives you much more flexibility. What are your lean development principles? 20:22 My lean business strategy comes from the seven principles outlined in Lean Software Development by Mary Poppendieck. First, eliminate all waste. Second, amplify learning by teaching your entire team, not just yourself. Third, make decisions as late as possible. Fourth, deliver as quickly as possible. Fifth, empower the team. Sixth, build integrity. Seventh, see the whole picture. Marketing techniques that worked before, don't always work now. How do you work around this problem? 35:56 It's frustrating because you don't know if it's the market changing or if you did something wrong. But, that's the beauty of what we do. It was formulaic, it would be easy. That's how the best have their advantage because they are able to discover the variables to focus on and the variables to ignore. 38:40 Whenever I'm pouring over the numbers, I try to ground myself by asking, “What am I doing this for?” and remind myself that I'm doing this so I can

GUEST BIO: David James is the founder of TotalCarCheck.co.uk, a vehicle background check website. David started this company as successful entrepreneurs do, by solving a problem he encountered. After his parents bought a stolen car and found themselves at a $5,000 loss, he created a website that wouldn’t allow this to happen again. David’s focused and realistic mindset has supported TotalCarCheck.co.uk in running background checks on almost two thirds of all the vehicles in the United Kingdom. The parallel app has become one of the top utility apps in the UK and David continues to use forward thinking, innovation, and his customers to grow his company and create transparency in the car buying process. SHOW SUMMARY: David James, founder of TotalCarCheck.co.uk, is an entrepreneur with a laser focus on simplicity and great results. His vehicle background check website has become the most successful website in the UK in his niche. David has built the foundation for his software based of seven lean principles, which he’ll discuss during our conversation. In this episode, David explains how he runs his company with only two employees, his advice for new software entrepreneurs and the books that have given him the insight for this accolade of success. This is The Lean Commerce Podcast. TOPICS: How did you get started with your business? 0:57 I had a more normal career starting off, but I always had an entrepreneurial spirit. My parents accidentally bought a stolen car and I realized there was a problem that needed to be solved, people needed to be able to run a background check on a car. 4:17 Once you get the wheels rolling, you start to get momentum. Very quickly people started to realize what we were doing was different than what other vehicle background check websites were doing and business started to grow from there. 6:33 Even in darker times, there is opportunity. It sounds spiritual, but the experience of my parent’s buying the stolen car was an epiphany for me. When I look back, it all seems kind of unbelievable that something so fortunate was built from such a negative experience. If you have a passion for something and genuinely enjoy doing it, it really helps you to become successful. 13:06 I think if you are consistent in what you want to do, you generally get results in the end. If you stay consistent in those principles and approach, you come out well in the end. You’re checking two thirds of all of the vehicles in the UK, what does the backend of your business look like? 15:55 Pretty much from day one, we’ve done this with only two staff members (including myself). This works because of two rules. The first is, we automate ruthlessly. People tend to skip over this because the initial effort is difficult, but the cost saving over five years is incredible. The second is, outsource wherever you can. Our accounts, legal, HR, design and development are all outsourced. This gives you much more flexibility. What are your lean development principles? 20:22 My lean business strategy comes from the seven principles outlined in Lean Software Development by Mary Poppendieck. First, eliminate all waste. Second, amplify learning by teaching your entire team, not just yourself. Third, make decisions as late as possible. Fourth, deliver as quickly as possible. Fifth, empower the team. Sixth, build integrity. Seventh, see the whole picture. Marketing techniques that worked before, don’t always work now. How do you work around this problem? 35:56 It’s frustrating because you don’t know if it’s the market changing or if you did something wrong. But, that’s the beauty of what we do. It was formulaic, it would be easy. That’s how the best have their advantage because they are able to discover the variables to focus on and the variables to ignore. 38:40 Whenever I’m pouring over the numbers, I try to ground myself by asking, “What am I doing this for?” and remind myself that I’m doing this so I can spend more time with my family. I don’t want to get lost in my work and have it be the center of everything that I do. This work has that effect on us and if we’re not careful, it can become addictive and habitual. 43:46 Throwing hours at a project doesn’t fix anything. It doesn’t achieve anything. You need to be creative and innovate. Spend your time wisely instead of in this false culture of hustle and working nine hours a day for six days a week. What tactics do you use to get reviews? 45:38 We incentive people to leave reviews by giving them a check voucher for $199, using copy that asks users to leave a review and we giveaway free information to users who create an account with us. Resources mentioned in the Podcast: Lean Software Development by Mary Poppendieck The Power of Persuasion: How We’re Bought and Sold Breakthrough Advertising by Eugene M. Schwartz The Four Hour Work Week: Escape 9-5, Live Anywhere and Join The New Rich Browser Stack Browser Shots Webpagetest.org Google Lighthouse Contact David: David on Twitter David on LinkedIN Total Car Check Total Car Check on Twitter

GUEST BIO: David James is the founder of TotalCarCheck.co.uk, a vehicle background check website. David started this company as successful entrepreneurs do, by solving a problem he encountered. After his parents bought a stolen car and found themselves at a $5,000 loss, he created a website that wouldn’t allow this to happen again. David’s focused and realistic mindset has supported TotalCarCheck.co.uk in running background checks on almost two thirds of all the vehicles in the United Kingdom. The parallel app has become one of the top utility apps in the UK and David continues to use forward thinking, innovation, and his customers to grow his company and create transparency in the car buying process. SHOW SUMMARY: David James, founder of TotalCarCheck.co.uk, is an entrepreneur with a laser focus on simplicity and great results. His vehicle background check website has become the most successful website in the UK in his niche. David has built the foundation for his software based of seven lean principles, which he’ll discuss during our conversation. In this episode, David explains how he runs his company with only two employees, his advice for new software entrepreneurs and the books that have given him the insight for this accolade of success. This is The Lean Commerce Podcast. TOPICS: How did you get started with your business? 0:57 I had a more normal career starting off, but I always had an entrepreneurial spirit. My parents accidentally bought a stolen car and I realized there was a problem that needed to be solved, people needed to be able to run a background check on a car. 4:17 Once you get the wheels rolling, you start to get momentum. Very quickly people started to realize what we were doing was different than what other vehicle background check websites were doing and business started to grow from there. 6:33 Even in darker times, there is opportunity. It sounds spiritual, but the experience of my parent’s buying the stolen car was an epiphany for me. When I look back, it all seems kind of unbelievable that something so fortunate was built from such a negative experience. If you have a passion for something and genuinely enjoy doing it, it really helps you to become successful. 13:06 I think if you are consistent in what you want to do, you generally get results in the end. If you stay consistent in those principles and approach, you come out well in the end. You’re checking two thirds of all of the vehicles in the UK, what does the backend of your business look like? 15:55 Pretty much from day one, we’ve done this with only two staff members (including myself). This works because of two rules. The first is, we automate ruthlessly. People tend to skip over this because the initial effort is difficult, but the cost saving over five years is incredible. The second is, outsource wherever you can. Our accounts, legal, HR, design and development are all outsourced. This gives you much more flexibility. What are your lean development principles? 20:22 My lean business strategy comes from the seven principles outlined in Lean Software Development by Mary Poppendieck. First, eliminate all waste. Second, amplify learning by teaching your entire team, not just yourself. Third, make decisions as late as possible. Fourth, deliver as quickly as possible. Fifth, empower the team. Sixth, build integrity. Seventh, see the whole picture. Marketing techniques that worked before, don’t always work now. How do you work around this problem? 35:56 It’s frustrating because you don’t know if it’s the market changing or if you did something wrong. But, that’s the beauty of what we do. It was formulaic, it would be easy. That’s how the best have their advantage because they are able to discover the variables to focus on and the variables to ignore. 38:40 Whenever I’m pouring over the numbers, I try to ground myself by asking, “What am I doing this for?” and remind myself that I’m doing this so I can spend more time with my family. I don’t want to get lost in my work and have it be the center of everything that I do. This work has that effect on us and if we’re not careful, it can become addictive and habitual. 43:46 Throwing hours at a project doesn’t fix anything. It doesn’t achieve anything. You need to be creative and innovate. Spend your time wisely instead of in this false culture of hustle and working nine hours a day for six days a week. What tactics do you use to get reviews? 45:38 We incentive people to leave reviews by giving them a check voucher for $199, using copy that asks users to leave a review and we giveaway free information to users who create an account with us. Resources mentioned in the Podcast: Lean Software Development by Mary Poppendieck The Power of Persuasion: How We’re Bought and Sold Breakthrough Advertising by Eugene M. Schwartz The Four Hour Work Week: Escape 9-5, Live Anywhere and Join The New Rich Browser Stack Browser Shots Webpagetest.org Google Lighthouse Contact David: David on Twitter David on LinkedIN Total Car Check Total Car Check on Twitter

Today’s episode of Agile Coaches’ Corner is all about full cycle development. Joining your host is Eric Landes — a colleague of Dan’s and a Scrum.org certified professional Scrum trainer.   Eric comes from a DevOps background, originally starting out as a developer. Currently, he serves as a Senior DevOps Consultant, ALM Director, and Solutions Architect. In his roles, he helps clients deliver value to customers in their software delivery pipeline, and has tons of experience leading organizations in adopting Agile and Lean frameworks, like Scrum and Kanban. His specialties are in Agile Project Management, Lean Software Development, Enterprise Project Management Implementation, and many more.   In this episode, Eric explains what a full cycle developer is, what a full cycle development team looks like, who he sees this model working for, how to take steps towards this model and improving your team, and where to get started. He also gives a ton of recommendations, valuable resources, and actionable tips and tricks you can begin using today.   Key Takeaways What is a full cycle developer? Your development team has all the skills needed to build, deploy, etc. Responsible for the full software lifecycle Your team owns it from beginning to end What to keep in mind when transitioning to Agile or full cycle development: The journey takes a long time and the company needs to support the workers through structure and community A good leader is crucial Who does full cycle development work for? It depends on the context — experiment to find out what works for your team Not everybody; different models for different organizations Identifying the problem you’re trying to solve can indicate which model you should use Steps to take towards improving your DevOps team: Measure to help drive improvement Monitor things in production so you can give feedback to the team on what’s working and what’s not Implement hypothesis-driven development Where to get started on your full cycle development journey: Start with Agile and XP principles if you haven’t already Check out the Netflix Tech Blog Understand the principles and practices of DevOps Be sure to experiment, experiment, experiment Key Learnings: A full cycle developer has a general skill set and is responsible for the whole software lifecycle The transition to Agile or full cycle development takes a long time — the company needs to support their workers in this transition through structure and community The full cycle developer model doesn’t work for all companies; you should experiment to see what works best for your team Drive improvement by measuring data and providing feedback   Mentioned in this Episode: DevOps Enterprise Summit Eric Landes’ LinkedIn Full Cycle Developers (Netflix Model) Woody Zuill’s LinkedIn “7 Habits of Successful DevOps” (with Sam Guckenheimer) Implementing Hypothesis-Driven Development XP Principles Netflix Tech Blog edX   Eric Landes’ Book Picks Turn the Ship Around!: A True Story of Turning Followers into Leaders, by L. David Marquet Training from the Back of the Room!, by Sharon L. Bowman   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

Episode 26 of the Modern Agile Show features an interview with Mary and Tom Poppendieck, co-authors of numerous excellent books, including Lean Software Development, Leading Lean Software Development and The Lean Mindset. Mary gave a wonderful keynote at the Scandinavian Agile conference (2018) called Proxies and Permissions. In that talk, Mary pointed out that she and Tom believe that “people ought to be able to figure things out for themselves” rather than being fed recipes. In Mary's talk she highlighted Bret Victor's (@worrydream) Designer's Principle (from his talk, Inventing on Principle: https://www.youtube.com/watch?v=EGqwX...) that “creators need an immediate connection with what they create.” Mary describes how important it is for people on agile teams to be "autonomous and asynchronous”, to get feedback rapidly from what they build instead of waiting a long time to see the impact of what you do. This is especially true if you are running experiments. Mary and Tom discuss a variety of “proxies” that stand in the way of fast feedback and autonomy. Mary explains how “speed and safety” go hand in hand. Mary believes that many agile scaling approaches are “a crutch” for organizations that have tight dependencies between people and architecture issues that require lots of people to talk, rather than being able to work autonomously, as they do at Amazon. Mary and Tom discuss how they see the four Modern Agile principles and how they relate to their Lean work. Finally, Mary describes how teams need a “concept of leadership”, someone who works as part of the team and helps teach the team how to work well, solve problems and learn.

Lean leaders let go of their certainty and discover successful products.

It's Episode 9 of the Troubleshooting Agile podcast! This week we're discussing Agile Principle 7: "Working software is the primary measure of progress." Some of the topics we cover are: -The importance of "moving past the 'phase model' or the 'percent-of-budget model'" in measuring progress. -How Burn-Up/Down Charts simplify and optimise the process of measuring progress by assigning value only to that which provides value to the customer. -And how they also build trust between the business and software development sides of a company by delivering regularly. -The dangerous pitfall of taking Agile Principal 7 too literally and finding yourself toiling away in a Feature Factory. -How to avoid this pitfall by motivating your team with Type Y Management - perhaps taking inspiration from Star Trek's Jean-Luc Picard - and focussing on Business Outcomes. -That an unexpected outcome of focussing on 'working software' is often less software. 'But the software you end with, you know works. And you know it matters.' ** LINKS: -The 12 Agile Principles - http://agilemanifesto.org/principles.html -An extract from Alistair Cockburn's brilliant Crystal Clear: A Human-Powered Methodology for Small Teams on Earned-Value and Burn-Charts - http://alistair.cockburn.us/Earned-value+and+burn+charts -Mary and Tom Poppendieck's brilliant book on Lean Software Development - https://www.amazon.co.uk/Lean-Software-Development-Agile-Toolkit/dp/0321150783 -John Cutler's blog on how to tell if you're working in a Feature Factory - https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2 *** We'd love to hear any thoughts, ideas or feedback you have regarding the episode. You can email us, here: agile@troubleshootingagile.com Tweet us, here: twitter.com/TShootingAgile Or find our website, here: troubleshootingagile.com/ Also, here is a link to our iTunes: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2 If you have a moment, please like, subscribe and share with your friends. We really appreciate it.

Are you trying to get other people to use agile or lean software development methods, but they can’t seem to break out of the mindset they’re stuck in? Today I’d like to offer some strategies to overcome attachment. Building What Customers Want Takes Failure And Learning Traditional management at many companies focus on predictability. They want to know how long things will take, and how much they will cost. Unfortunately if your software company wants to be innovative, you may already know that you can’t measure performance this way. If you want to deliver truly disruptive and valuable ideas to your customers, you need to experiment and make small investments to see how customers receive them. Establishing the Mindset for Failure and Learning I talk often about how important experiments are to the success of your software company, and how you can sell and introduce the changes needed to work this way to leadership and other stakeholders. Assume for a moment you’ve already convinced people of the benefits of lean software development methods that let your company experiment (DevOps, Continuous Delivery, Lean Startup techniques etc.). Yes, people now understand the mechanics of these approaches. But it can be frustrating at first to help others have the courage to take risks and actually experiment. This is because experimenting and then learning from the results, often requires failure. The Uncertainty of Innovation Can Cause Anxiety One of the technology capabilities I have said in other articles is crucial to a company sustainably releasing valuable software, is Continuous Delivery. This lets your team release your software to customers as frequently as multiple times per day. If you’re going to let the customer take a larger role in deciding what’s in your product, and release it multiple times per day — you’ll have an increased set of feedback. Also subject matter experts like Product Managers will find out their ideas aren’t as valuable as they’d hoped when trying new things. These two changes alone introduce  data-href="https://medium.com/jayme-edwards-mentoring/how-uncertainty-impacts-software-development-processes-9d7d7cefe5c6">uncertainty that needs to be handled with care. Without addressing this, your team will start blaming each other and going back to what they’re comfortable with when their first few experiments don’t produce the results they anticipated. Overcoming Attachment to Enable Learning If you celebrate Christmas or your Birthday, you’ve probably experienced being attached to a gift or outcome you wanted as a child. You and your team need to overcome these feelings of attachment at your company to use lean and agile methods for developing software. Without detaching from outcomes, people will feel threatened when things change. We Must Be Comfortable With Uncertainty to Take Risks The more comfortable you can be with trying things and not being able to guarantee that the outcome is something that you want, the more you can take risks. This is exactly the mindset needed to be more innovative with software development. Strategies for Practicing Detachment Since you know people need to be more comfortable with uncertainty, and they need to be less attached to outcomes — what are some strategies you can use to cope with this? Thinking About the Possibility of Other Outcomes Most people in corporate America don’t want to do this. Typical work structures are all about certainty and planning for outcomes we expect. Instead, thinking about the possibility that what you’ve planned might not work out ahead of time primes you for a healthy mindset for taking risk. When you’re working with a team to experiment, remind them at every opportunity that everyone is looking forward to seeing the data to help them steer the product in the right direction. If the data behind a release shows that a change wasn’t positive, that is not a failure. It must be clear that there will be no reprimanding for theories the team held about what would be valuable, as testing those theories will inherently prove when our ideas aren’t good. This is the nature of the scientific method! Beware of Catastrophizing Once you begin to allow yourself to entertain the possibility of uncertain outcomes, it’s tempting to think of the worst case scenario. This is known as catastrophizing, and creates anxiety by focusing your thoughts on negative situations that haven’t even happened yet! When I’ve caught myself catastrophizing, I often realize I’m tensing up and experiencing the same emotions as I would if the event happened — but it hasn’t. Spending significant time thinking about the worst possible outcome will cripple your team with fear, and cause them to lose the courage needed to present their best ideas to your customers. Yes, there is a time for risk management — but innovation is not that time. Overcoming Resentment to Past Failures If you hold on to negative feelings about what may have happened in the past, you won’t have the open mind necessary to try new things. Examples might be working with a person who made a mistake before, a business partner who didn’t hold up their end of the deal, or a software development task that was more complicated than first thought. Resentment is another form of attachment. You should consider practicing forgiveness and using whatever healing tools work for you or your team to let go of any resentment. These could be simple things like giving someone a personal apology if you played a part in the situation. Or something that lets you face the situation and let your feelings with it rest such as meditation. Whatever physical, emotional, or spiritual activity you can find that works to help you or others involved emotionally detach from the experience, use it. Let the past go so your team can try new things with a clean slate! Challenging Limiting Beliefs If someone told you something about yourself as a child, or perhaps a co-worker made a statement about your skills — you may be walking around carrying an inaccurate picture of yourself. You should challenge thoughts held about what is really true with respect to the limitations you or your team may perceive about their capabilities. I once worked with a Fortune 500 client who only released their product at night when no customers were using it. They were convinced it was impossible to release it during the day even though the technology needed to do so was common. Until I challenged this belief, and did not back down until I heard a logical answer for why it couldn’t be done — no one had considered it a possibility. Once everyone moved past this limitation in their thinking, they were easily on board and supportive of working with me to plan for the change. Separating Our Identity From Outcomes In most companies if someone makes a “bad” decision, they are held accountable. What this can do though is cause you to place your self-worth in your decisions and their outcomes. To have the courage to innovate, you need to separate these two. People on your teams should strive to treat each other kindly especially at the times when they make mistakes. But when they slip up and get upset at you or someone else for a decision that they didn’t like, it’s important to not take it personally. You can’t control how the other person will react — but you can control your reaction to their being upset. Practicing Delayed Gratification Your company may need to build and release five small versions of an idea to your customer before you hit the ideal solution, when delivering a product in a lean fashion. Because of this, the management team may be lacking in the necessary patience at first to see things unfold with the product this way. Delayed gratification is simply waiting longer to get something you want. This might sound like a silly thing to recommend, but you’d be surprised how many people I come across in leadership positions who are still very attached to immediacy. If you have people like this in key positions at your company, this may be the reason why you’re having a difficult time getting support for the changes you want made. Practice this yourself, and with your team, to relax your feelings of urgency so you have the patience to try several iterations of an idea before settling. Permitting Others to be Frustrated with Uncertainty It’s natural that when trying something new, such as to not be as attached to outcomes, you and others will make mistakes. It’s crucial that everyone be willing to forgive each other when unpredictable negative outcomes occur. Without this safety net, there can be no loyalty, transparency, or ability to take risks. These are the attributes of relationships at your company that can make or break the long term health of the software development culture. You can also watch this episode on YouTube.  Related resources: How Uncertainty Impacts Software Development Processes 5 Ways To Cope With The Anxiety Of Software Development How To A/B Software Development To Find What Customers Value Lean Software Development - It's About Uncertainty!   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

In the first video in my series on Sustainable Software Development, I explain how Lean Software Development avoids a company becoming irrelevant in today’s shifting technology market. If you’re looking for the reason why lean software development can be the difference between software projects being fun and innovative, or grueling and underwhelming – this video will provide you with some guidance. I discuss how the software development industry has focused on agile software development methodologies like Scrum, DevOps, and Continuous Delivery but that these don’t get the results companies are looking for if not used with a lean mindset. I discuss the fact that working in the industry continues to be highly uncertain, and so we need strategies that deal with anxiety and reduce pressure to help us sustain our careers. I mention how the industry’s focus on technologies and process distracts us from value. A business must always be profitable, and without a focus on customer value and a culture of learning – you’re dead in the water. I don’t want to see passionate technologists and successful companies fall into the trap of thinking they only need to add features to a technology product or service to sustain profitability and innovation. ​Lean software development will ensure that the way teams work, and the way changes are rolled out to customers, puts the market in the driver’s seat to direct us where we’re headed. Developing software is more like steering a ship than building a skyscraper. We chart a direction to go, but we ASSUME that the winds will blow us off course. So we need to use tools and techniques that let us steer quickly. As I share strategies for sustainable software development on this channel, we will choose tools and techniques that allow us to adapt and respond gracefully as things change. You can also watch this episode on YouTube.    Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

An introduction to Lean Software Development This is a quick intro to the concepts of Lean Software Development. I'm starting a journey of trying to figure out how to apply lean principles to software development in the context of 2016/2017. Links Lean Software Development (http://amzn.to/223fkLo) book by Mary & Tom Poppendieck wikipedia (https://en.wikipedia.org/wiki/Lean_software_development) entry for Lean Software Development Patreon supporters of the show (http://patreon.com/testpodcast) Talk Python to Me (https://talkpython.fm/) Podcast Python Jumpstart by Building 10 Apps - video course (https://www.kickstarter.com/projects/mikeckennedy/python-jumpstart-by-building-10-apps-video-course?ref=card) pytest sprint (http://pytest.org/latest/announce/sprint2016.html) pytest.org (http://pytest.org) pytest/tox indiegogo campaign (https://www.indiegogo.com/projects/python-testing-sprint-mid-2016#/)

Kanban setzt auf Transparenz durch Visualisierung der Arbeitsabläufe. Die Begrenzung angefangener Arbeit macht Engpässe sichtbar und bietet somit Ansätze zur kontinuierlichen Optimierung. Dabei fordert Kanban kaum Änderungen an den bestehenden Prozessen. Somit ist die Einführung von Kanban sehr einfach.

I am thrilled to present a wonderful interview with Mary and Tom Poppendieck.  They are true legends in the Agile and Lean Software Development movement.  Checkout today's episode where we discuss challenges facing many organizations such as: product vs. project mindset, globally distributed teams, and equipping teams for success. We also discuss their latest book, The Lean Mindset.  Please consider picking up the book to learn more about these topics in greater detail.Please check out their website: poppendieck.com to learn more about Mary & Tom and their insightful work.  Many thanks to Mary and Tom for investing their time for this podcast and for their contribution to our industry.All Things Agile - Episode 005 - Mary and Tom Poppendieck InterviewTranscript:Welcome to the All Things Agile Podcast. Your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.Ronnie: Hello everyone and welcome to the All Things Agile Podcast, Episode 5. I’m very excited to present to you a wonderful interview with lead software legends Mary and Tom Poppendieck. Before I begin, a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So let’s get started!One of the goals for this podcast is to interview and feature influential leaders in the Agile space. Today’s guests are just that – Mary and Tom pioneered the Lean Software development movement, with their groundbreaking book Lean Software Development and Agile Toolkit. It’s a classic among Agile literature. In 2013 they also released ‘The Lean Mindset – Ask the Right Questions’. Mary and Tom travel the globe, speaking at conferences and consulting with many of the world’s top companies. It’s an honor and a pleasure to have them on the All Things Agile Podcast. Without further ado, let’s welcome Mary and Tom!Well, thank you for joining me today Mary and Tom, I really appreciate it. Why don’t we go ahead and get started with a few questions. During my own career, I have worked at several Fortune 500 companies. And I’ve often found that large organizations tend to be project-focused, rather than product focused. For example, I have seen environments where software development is treated as a black box, and it can sometimes have a throw-it-over-the-fence mentality. I would love to hear your thoughts on integrating software development as part as a holistic product chain.Mary: If you look back to the early 90’s, I was a manager in the early 90’s and there were very few of my colleagues that could even type. Typing wasn’t something that you learned, unless you were going to be a secretary. The idea of doing email and stuff was so difficult that when the internet first came, many managers sat down their secretaries to do their email typing. Eventually that went away. But if you look at industries that were formed before technology was widespread, like banks and insurance companies and those kinds of industries, you’ll find that this technology area was separated out from the mainstream for two reasons: one reason is because the managers of the line businesses simply were not comfortable with technology; and another was that computer technology was considered something that was expensive and should be centralized in order to reduce costs.Well, today, computer technology is not the same. It is the fundamental basis for competition for almost every company that uses it. Thanks to the kinds of products that they offer, or the things that help them be competitive – if you take a look at the new companies like Google and Facebook and Amazon and those companies, computer technology is a fundamental competitive advantage. And if that’s true, then it needs to be manage, at least what’s done, in the line organization, rather than in some side-organization that is in side to the line organization. So if you look at the companies I’ve just mentioned, they don’t have a central IT department. They have the line organizations responsible. That doesn’t mean that they don’t think about IT costs, but they think about them as product development costs.So now, the things that people develop that are helping the company become more competitive and distinguish it from other companies, are things that need to happen with people who sit in the line organization and truly understand customers and are close to them and secondly, software technology today is much more thought of not as a black box, but as a constant feedback mechanism. So you do something, you see the results on customers and on the line business, you adapt to the results and you continue on.With those two things said, first of all it provides the competitive or strategic advantage to be thinking in line organization about technology. And secondly, technology is by and large best developed as a short feedback loop kind of a business; it makes very little sense to continue on with this black box concept that used to be a sensible idea. Tom, you have something to say?Tom: Yes, definitely. I’d like to address this from a little more abstract level and put projects in their proper place. The motivating aspects as identified by Simon Sinek is ‘always a purpose’, a reason for doing things, a difference that an organization is attempting to make in the world. It’s the reason why people come to work, why they think about a problem, why they devote a lot of energy to solving a problem. Now, ‘Why?’ is primary – nothing great happens without a great ‘Why?’ ‘How?’ is where the project sits; it’s one of the techniques for containing risk, for containing how much resources you’re going to devote to achieving your ‘Why?’. Agile is another collection of techniques that are ‘How?’s – ways of working strategies, tools.Engineering disciplines are another set of ‘How?’s. Automated testing and many others. But they’re all ways of working, ways of thinking to achieve a purpose. And neither of those are your product. Your product is ‘What?’ that’s Simon’s third level. Why, How and What? Now, whether you are successful is not so much a matter of did you sail this in the constraints, that your project imposes? It is ‘did you do the very best that you could in terms of achieving your purpose within the constraints of your available tools and skills, and risk management strategies?’I read a fascinating article in Harvard’s Business Review yesterday. And it was saying that the most important, the most powerful way of managing risk is to measure and analyze time to recover the something going wrong in any individual component of what you’re doing. This translates easily at least in my initial impression, into how fast is your feedback loop?If you try and do a ‘What?’ that doesn’t really contribute to achieving the purpose and find out about it until very much after it has been done, and after many things have been built on top of it, you have wasted all of the good skills, all of the good techniques and you have triggered away your ‘Why?’ But if you find out about it very quickly, and you haven’t placed practices and approaches that you can recover very quickly, then you have the very best that you can; you’ve delivered the best ‘What?’ that you can using your constraints to achieve your purpose. And I think that’s the framework for thinking about projects – it’s just a tool; they’re not the ‘What?’, they are not the ‘Why?’ – they’re just a way of containing risk. Ronnie: Right, that makes sense. I agree. Sometimes, people place more emphasis, if you will, on the success of the project rather than the success of the product. And for the customers, I agree. Excellent answers. The next question I was wanting to ask, kind in a similar note, I also worked on projects where everything was kind of guided by arbitrary dates if you will. And sometimes, the end customer and the product features were really not in focus. Have you seen this behavior before and if so, what advice do you have for our listeners on how to tackle this issue?Mary: Well, it’s interesting where the arbitrary dates come from, because I think that a business organization wants them to help them move forward with customers. They have some frame in mind about how much it’s worth to them to do that, how much money they can spend and what kind of deadlines are important, and those deadlines and those budget constraints should be honored as far as what are our constraints for meeting our overall objective? But then those get translated into somebody’s version of minor objectives and minor deadlines and if we don’t do this by this time, we can’t get to there by that time. Then those become completely arbitrary and basically unattached to the overall purpose. And those kinds of deadlines that are fake, are pretty easy to detect and what is the reason for them? That’s what you got to ask. Why do we have these strange deadlines? Why don’t we have, instead, a very tight feedback loop and a visibility of the progress we’re making towards the overall objective of what we’re trying to do and understand what part of the progress needs to happen at different times.Now, if the way that you do a project is you first do all of the design and then you do all of the next step and it isn’t until the end that you actually do the work, write the code, write the test, integrate the software, then those days are truly artificial. But if you strategy is to say ‘I am going to have a complete system in two months – it’s going to be a minimal system, but it will be workable and we can get feedback on it – and that two months is going to give us another 8 months to finish the whole thing and the feedback necessary to do that’ – that’s a much more viable deadline. So you have to say are the high level constraints appropriately applied as low-level constraints to get stuff done or are they artificial? Because if they’re artificial, smart people can figure that out and they will ignore them. Tom?Tom: Not all deadlines are arbitrary. Some are legal, some are annual rhythms of shows. There are some very legitimate deadlines. And a competent team with a competent manager that understands what it takes to do work will be able to achieve a real deadline. However, if a deadline is used as motivation, as a goad, as a way of avoiding waste, then it can be very ineffective and very destructive. It can lead to bad behavior. The use of a deadline that is not legitimate, that is not related to the ‘Why?’, to the work being done, is probably a symptom of lack of competence to measure what really matters about the progress of the work.Mary: I want to throw in one last little thing here, and that is that projects should have things called: cost, schedule and scope. And the thing that really should be flexible is neither, in most business’ cases cost, nor schedule. The thing that should be flexible is scope, because cost and schedule deadlines are typically driven by business constraints. But the scope should be the thing that is negotiable almost always and the reason for that is that, especially in a software environment, the thing that we’re putting together is a complex system. The more junk, features, capabilities or whatever that we throw into that massive software, the more complex it is, the more difficult it is and by and large, over time, the more stuff you have in software, the more crud you get in there, the more complexity you get in there, the harder it is to change, to manage and so on.So in software, you want to think of ‘stuff’ as bad. You don’t want to measure a team on how much junk can I put in, in a window of time? You want to say: How much business purpose can I achieve within as little code as possible? So you are looking for reduced feature set, reduced capabilities that get the job done. And so the thing you really want to reduce is not the budget or the schedule; it’s the amount of stuff that you try to squeeze into a business-driven budget and schedule. So typically in all projects – and this is not the way most project managers look at it – but a software project almost always bend on scope, rather than bend on deadline or on cost.Tom: It is impact. Did you achieve the impact that your work aimed to achieve? Did it achieve its purpose? If the impact can’t be measured, you have no guidance about what to include and what to leave out. You have no measure about when you’re done. If you have as much impact as your tools and skills and techniques permit, as the team was capable of and the project was a success…Ronnie: I definitely like that impact thing – that kind of really sums it up really well, thank you. If you don’t mind, I’ll ask the next questions which is: in my experience, I’ve seen senior exectutives get very excited about Agile and they decide to roll it out across the organization. However, sometimes the teams can be lacking in technical skills or tools to ensure success. For example, great Agile teams place a high value on quality and that usually will translate in frequent and rigorous testing. And if a team has, for example, automated tests in place that will result in the product being in good shape. However, there may be teams which have never worked, for example, with test automation and it can then be a real challenge. What are your thoughts regarding skills and technical preparation in relation to methodology adoption?Mary: Methodology is the result – it’s not the driving factor in a good Agile implementation. What you’re trying to do is create an environment with rapid feedback, so that you can do a better job of satisfying customers. And you should not be measuring ‘did I do this or that Agile practice’? You should be measuring ‘do I have greater impact in delivering what my customers really want?’ And that’s where you get to the quality, the test automation and that sort of thing.So let’s talk about a different objective for that executive, so that the executive have stuff that they can measure and put hands around. And that is, instead of working about a methodology called Agile, why not worry about what I’m going to call ‘The Software Development Process of the Future’ which is continuous delivery. So instead of saying that we have these meetings and we have these things, you should be saying ‘How fast, from the time I decide to do something, until the time I get it in production – how long does that take?’ And when you start looking at how far along am I on the path to continuous delivery - that is my executive goal. Those companies that do that have far more effective Agile implementations because it’s that one thing that you’re focusing on that continues delivery, that drives all the good technical behavior by the way of good practice behavior.Let me give you an example in Alcoa – once upon a time when he became CEO, decided that he wanted to focus on one single thing and it was going to be safety. And every single issue around any kind of safety incident was what the entire company focused on. And that became a lever to cause all kinds of additional good behavior and the company really took off, because you can’t have safety without quality, alert workers, really good, well-run equipment, all of that sorts of things. And similarly in Lean, the concept of flow is sort of that driving principle. So you try and just focus on flow, everything falls in place. All the technical things, all the quality things and so on. Similarly in software. Let’s not focus on process; let’s focus on continuous delivery. How far are we towards being able to deploy immediately? And if we make that the one principle of how we perceive, then what we have is a driving principle that will drive all the rest of the good behavior and certainly, all of the technical behavior.Ronnie: Excellent answer. A final question, if you will. There are many great sources of information on implementing Agile, but most are geared towards smaller organizations often. And for larger companies, it can be a hurdle if you will to implement new methodologies in a global workforce. For example, I’ve recently worked with teams that are split across India, Brazil, China, Mexico and of course here in the US. What insight can you provide on how to tackle teams that are globally distributed?Mary: There certainly are many big companies – we wrote in our new book about Ericson as an example – very large companies that are very effective in implementing Lean and Agile concepts. But they don’t hold a lot of stake in having ‘teams’ that are geographically distributed. Yes, organizations are geographically distributed – but why do teams need to be? So what I see large, effective organizations do when they think about distribution is to say what are the things that need to be communicated? And how can we effectively, at a single site, have communication among colleagues and think about communication across teams on a different scale? So the effective ones don’t try too hard to make individuals have to communicate across large distances. And if they do, they have people travel.However, there can definitely be reasons why people should – and really valid purpose-drive, business-driven reasons why people need to communicate across geographic boundaries. And there certainly are plenty of examples on how this is done effectively. If you look at the open source movement, none of the open source projects have people co-located. These ones work very well with the communications issues across countries and if you look at them for models on how to do it. So if teams do need to be distributed, then you want to think ‘Why?’ Okay? You do not want to have class A people figure out what to do and class B people are in another continent that actually implement it, because that gets us back to the first question. The people that are doing the implementation are divorced from the purpose. But if the teams are geographically distributed, you have to think hard about how can they all share a common purpose that they understand and believe in and commit to, and if they do that the communication issues will be solved. And if you can’t imagine teams across countries dedicated to a common purpose, then you should say: Why are our teams structured this way? So every company that has solved this problem, has solved it in a different way, depending upon their market and their structure and all of that sorts of things. But they do have a few things in common. One is, they think for themselves. They don’t take rule books. They try to make sure they honor the intelligence of every person on the team and make sure that they can participate fully their thoughts in thinking about it, and they don’t have these wall handover mechanisms because that’s not the right way to deal with this. Tom: All the teams we have seen around the world, and we’ve seen many, have one shared characteristic. And it’s not tools or techniques or methodologies – it’s they think for themselves. There are many examples, case studies about groups that have thought about their problem and their context and their challenges and they think for themselves and come up with a unique combination of tools and techniques and disciplines that make them highly effective in achieving their purpose. A team which is distributed and is simply doing what it’s told to do is not going to be very effective. A team which is distributed for a good reason who all believe in a purpose that they are trying to achieve and have adequate tools, handles and the like, that make it possible to communicate effectively, will figure out how to do it. They will think for themselves, if they have sufficient feedback about how they are doing, how things are working for them; they will figure out how to do it. And there are many, many ways that different teams figure out how to do this. But it’s not a recipe. It’s not a product that you buy; it’s how people think about what they are doing together. If they can’t think together, they can’t be very effective at working together. They can’t learn together. The product will reflect that lack of learning.Ronnie: I definitely agree. I definitely agree with you that having those teams be able to really understand it and what they’re trying to achieve and have those goals and have that thought in control is very key – it’s as you mentioned, if you kind of have a class A, class B type situation, then it can often result in micromanaging and diminish morale and sometimes poor quality – I’ve seen in the past the results in code. Great points, great points! And a lot of them are actually referencing some of your more recent work – if you don’t mind, I’d love to mention that briefly. You guys have put together a great book last year ‘The Lean Mindset’. Would you like to maybe highlight that a little bit more?Mary: Sure! I was just reading in an article that it used to be ‘share all their value’ was the thing that businesses thought they were in business for. But today, in today’s economy and today’s high-tech environment, what you really want to do in order to have a successful business is you need to have great people that use their minds for accomplishing the common purpose. And that purpose has to be something that these people believe in and you need to have an intense focus on delighting customers. And those three things: customers that you’re trying to delight, employees that are deeply engaged at trying to make something happen for those customers and an overriding purpose are the three sort of company drivers of the future.Our book has 5 chapters. One is on purpose and then the next one is on engaged workers and energized workers; the third one is about delighted customers. And then we talk about efficiency and what efficiency means in this context. Efficiency means, in the Lean context, flow efficiency rather than resource efficiency. Which is a whole other topic that we can talk about sometime. And lastly, we talked about innovation because today’s economy, today’s technology moves too fast to be comfortable that what worked 3 years ago is going to work 3 years from now, so constant innovation is another thing that companies need to have. That’s sort of, in a nutshell, what the book is about, those 5 chapters. And to sum it all up we have lots of case studies in there, as Tom said, and each case study shows how thinking for yourself in your context is important; which means it’s important to have people who care to think for themselves and who are allowed to think for themselves and who are inspired to help make the company successful. Ronnie: Excellent! I definitely encourage our listeners to pick up a copy of your latest book. Once again, it’s ‘The Lean Mindset’ and it’s available at book stores everywhere. I picked up my copy on Amazon, and I really just want to thank you both Mary and Tom for joining me today for this podcast episode. It’s been tremendous help to myself and I’m sure, to all of our listeners. I really thank you so much for your time Mary and Tom, you’ve been great! Thank you listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!

A discussion with Jim York and Elizabeth McQueen on the effectiveness of the agile software development approach at the Customs and Border Protection agency – what it takes to make it work, and what happens when it does! Do you have comments or thoughts about this episode? Join the discussion on our Facebook page at www.facebook.com/PMIWDC Project Management Point-of-View (PM-POV), a podcast series produced by the Washington DC Chapter of the Project Management Institute, allows our membership and the public at large to listen to brief and informative conversations with beltway area practioners and executives as they discuss various perspectives on project management-- its uses, its shortcomings, its changes, and its future. Listens can send comments and suggestions for topics and guests to: pm-pov@pmiwdc.org. PDU Information You can earn 0.25 Category "A" PDUs for each PM-POV podcast you listen to — up to 1.75 PDUs by listening to all 7! Use the following information in PMI's CCRS system to register the PDUs for this podcast: PDU Category: Cat A: Registered Education Provider/PMI Component Activity Type: "Find an Activity" Provider Number: C046 Activity Number: 08142014PC » More PM-POV Episodes About the Speakers Jim York   FoxHedge Ltd Co-owner       For more than 25 years, Jim York has led, trained, and coached individuals, teams, and organizations in the implementation of Lean and Agile ideas. He is a Certified Scrum Coach and Certified Scrum Trainer. His coaching and workshops blend his practical experience in Scrum, Lean Software Development, Extreme Programming, Product Management, and traditional project management. Jim shares his passion for teaching as a frequent presenter at conferences, users groups, public and onsite workshops, and as a business process coach. In 2007, he cofounded FoxHedge Ltd (http://foxhedgeltd.com) with his wife, Melissa York. Their mission is to coach leaders to build effective teams and products.   Elizabeth McQueen     Customs and Border Protection Branch Chief, International Trade Data System       Elizabeth McQueen is the Branch Chief, International Trade Data System, at Customs of Border Protections. She is also PMIWDC's 2014 Chapter Vice-Chair. Elizabeth was elected as a chapter Director at Large in 2012, but her involvement with PMI and volunteering began several years earlier. Elizabeth joined PMI and the Washington DC Chapter, and attained her PMP certification, in 2005. She started volunteering the following year with the Business Process Assessment committee, eventually managing the Business Process Definition project in 2008. In 2009, she accepted an appointment to the role of Assistant Vice President for Records Management. During her tenure as the AVP, and then the VP of Records Management, Elizabeth worked with each operational area to help define their processes and create reusable templates, and to clean up each area’s SharePoint site. Elizabeth served one term as the VP of Records Management before being elected as a Director-at-Large to the Governance Board beginning in January 2012. The Governance Board appointed her as Vice-Chair for 2014, switching her tenure with another DAL to allow her to subsequently serve as Chair in 2015. From a professional perspective, Elizabeth is currently Director of Program Control for Customs and Border Protection’s Cargo Systems Program Directorate, within the Department of Homeland Security. Prior to her work with DHS, she owned Process Evolution Group (PEG), a business process improvement and project / program management training corporation. Elizabeth graduated in 1988 from the University of Texas at Austin, with a BS degree in Advertising. She lives in Alexandria, VA with her husband Steve and their tri-color Shetland Sheepdog, Bella. Outside of her professional work and time spent volunteering with the Chapter, she enjoys cooking, yoga, and travel with her family.

Recording Venue: WebEx Guest: Christof Ebert Christof Ebert, managing director of Vector Consulting Services talks with Frances Paulisch on his insights to how lean applies to product development. The interview centers around five key principles of lean development, namely end-to-end focus on creating value for the customer, eliminating waste, optimizing value streams, empowering people, and […]

In this episode we interview Mary and Tom Poppendieck, authors of that great trilogy of books on Lean Software Development. Because of the lenght of the interview we decided to publish it in two parts, with the second half expected to be published in a week or so. In this first part we talk with Tom and Mary about Lean principles and how they apply to software development. We speak about Toyota, about innovation and startups, and Tom and Mary explain what is meant with set-based design. This interview was recorded in an Amsterdam hotel lobby on the 26th of September 2010. Interview by @freekl and @mamersfo. Audio post-production by @Mendelt. Links for this podcast: Lean Software Development: An Agile Toolkit (Mary and Tom Poppendieck) Published May 18, 2003 by Addison-Wesley Professional Implementing Lean Software Development: From Concept to Cash (Mary and Tom Poppendieck) Published September 17, 2006 by Addison-Wesley Professional Leading Lean Software Development: Results Are not the Point (Mary and Tom Poppendieck) First edition published October 31, 2009 by Addison-Wesley Professional Lean Thinking: Banish Waste and Create Wealth in Your Corporation (James P. Womack and Daniel T. Jones) Second edition published June 10, 2003 by Free Press Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Result (Mike Rother) Published August 4, 2009 by McGraw-Hill Switch: How to Change Things When Change Is Hard (Chip and Dan Heath) Published February 16, 2010 by Random House Canada Cracking the Code of Effective Innovation: Organizational Size and Style Is Driving Innovation success Published June 2007 by Future Think LLC Toyota’s Principles of Set-Based Concurrent Engineering (Durward K. Sobek II, Allen C. Ward and Jeffrey K. Liker) Published January 15, 1999 in MIT Sloan Management Review Survive to Make Money or Make Money to Survive? (John Shook) Published December 4, 2008 by Lean Enterprise Institute Drive: The Surprising Truth About What Motivates Us (Daniel H. Pink) Published December 29, 2009 by Riverhead Hardcover Hidden Value: How Great Companies Achieve Extraordinary Results with Ordinary People (Charles A. O'Reilly III and Jeffrey Pfeffer) Published August 2000 by Harvard Business Press Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management (Jeffrey Pfeffer and Robert I. Sutton) Published Marc 1, 2006 by Harvard Business Press Toyota’s Journey From Waterfall To Lean Software Development (Henrik Kniberg) Published 16 March, 2010 on Henrik Knibergs' blog The Team Handbook (Scholtes, Joiner & Streibel) Published march 24, 2003, by Joiner/Oriel Inc This podcast is in English - Deze podcast is in het Engels

SPaMCAST 100 . . . YES 100 features an interview with Chris Hefley  Chris and I discussed Kanban.  This is an interview that will help novices and those experienced with Kanban.  Paul Laberge asked for an interview on the nuts and bolts of Kanban and I think we have delivered. Chris Hefley is the CEO and co founder of Bandit Software. Bandit Software is a Nasvhille, TN based company that specializes in tools for Kanban and Lean Software Development, as well as training, coaching, consulting and lean outsourcing. Chris is a career software developer and aspiring craftsman, and has a deep interest in things that can help software developers be more productive, effective, and happy. Citrix GoToAssist Express is sponsoring SPaMCAST Solve technical issues faster with GoToAssist Express. Try it FREE for 30 days. Ad for my book! Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing has hit the bookshelves!  According to Robert C. Anderson, Director, Process Development and Quality Assurance, Computer Aid, Inc, "Mastering Software Project Management is a masterpiece of clarity, organization and depth of practical knowledge." If you a project manager or know project managers buy yourself a copy and a second to lend co-workers! Have you bought your copy? Contact information for the Software Process and Measurement CastEmail:  spamcastinfo@gmail.comVoicemail:  +1-206-888-6111Website: www.spamcast.netTwitter: www.twitter.com/tcagleyFacebook:  http://bit.ly/16fBWV Conferences and Speaking Engagements in 2010 (To Date) ISMA Cinco in Sao Paulo September 13-15.  I will be one of the featured speakers.  THe title of the presentation is Function Points:  Past, Present and Future.  The website to get more information is http://www.ifpug.org/conferences/  I hope to see you there! Next!SPaMCAST 101 will feature the second part of the Seven Deadly Sins essay.  We take on solth next!

Lecture 12: Agile and Lean Software Development

Lecture 12: Agile and Lean Software Development

NEOSA Developers SIG, Agile and Lean Software Development, February 10, 2010

Welcome to the Software Process and Measurement Cast 76!In the SPaMCAST 76 I interviewed Tom and Mary Poppendieck talking about lean and their new book "Leading Lean Software Development: Results Are not the Point".  Our interview covered the book, lean and leadership to just a few topics.Mary Poppendieck has been in the Information Technology industry for over thirty years. She has managed software development, supply chain management, manufacturing operations, and new product development. She spearheaded the implementation of a Just-in-Time system in a 3M video tape manufacturing plant and led new product development teams, commercializing products ranging from digital controllers to 3M Light Fiber™.  Mary is a popular writer and speaker, and coauthor of the book Lean Software Development, which was awarded the Software Development Productivity Award in 2004. A sequel, Implementing Lean Software Development, was published in 2006.  A third book, Leading Lean Software Development, was published in late 2009.Tom Poppendieck has over 25 years of experience in computing including eight years of work with object technology. His modeling and mentoring skills are rooted in his experience as a physics professor. His early work was in IT infrastructure, product development, and manufacturing support, and evolved to consulting project assignments in healthcare, logistics, mortgage banking, and travel services.Tom holds a PhD in Physics and has taught physics for ten years. He is coauthor of the book Lean Software Development, which was awarded the Software Development Productivity Award in 2004. A sequel, Implementing Lean Software Development, was published in 2006. A third book, Leading Lean Software Development, was published in late 2009.Website: http://www.poppendieck.com/Leading Lean Software Development:  Results Are not the Point http://www.amazon.com/exec/obidos/ASIN/0321620704/poppendieckco-20Contact Mary:Phone:  952-934-7998Email:  mary@poppendieck.com  Contact Tom:Phone:  612-804-7217Email:  tom@poppendieck.com  The essay in SPaMCAST 76 is titled "Walls".  In the essay, "Walls" I explore the impact of living in an echo chamber when it comes to the ideas and concpets you use to drive change.Conferences and Speaking Engagements in 2010 (To Date)Are Your Project Stakeholders Satisfied February 11, 2010 11:00 am - 12:30 pm Eastern Time Measuring customer satisfaction is more than just asking if your clients got what they wanted. Customer satisfaction is a messy mix of expectations, experiences, and perceptions - with maybe a hint of functionality. In this webinar, Tom Cagley will outline one method for measuring this mixture and for identifying what really matters in customer satisfaction.Learning Objectives: •    How to define customer satisfaction •    Strategies for identifying what really matters •    A practical framework for measuring customer satisfaction •    Not all attributes of customer satisfaction matter to the same level for all stakeholders Register at http://solutions.compaid.com/forms/WebinarA20100211?ProcessType=PreRegQuest Conference in Dallas April 21 - 23.  I will be talking on "Process Improvement in a Multi-Model World".  The conference includes two days of workshops.  The website to get more information is http://www.qaiquest.org/dallas/index.htmlNext!The next Software Process and Measurement Cast will feature an interview with . . . Me.  Pat Ferdinandi turns the tables to explore the origins of the SPaMCAST and plans for the future.  I had fun being interviewed and hope you will enjoy the disucssion.

What can I say about this secular messianic figure that is constantly challenging and stretching agile methods to suit his will. Must be the portland air. We talked about Naked Planning for quite a while. He has essentially taken many of the techniques from Lean Software Development and warped them to suit his particular organization. He has a penchant for experimenting with his team and with his mind and he shares the results of those experiments in this interview. Enjoy -bob payne

Show 37 is an interview with Kenji Hiranabe discussing using kanban in software development.   According to WIKIPEDIA, “Kanban is a signaling system to trigger action which in Toyota Production System leverages physical cards as the signal”.  In other words the signal is used to indicate when new tasks should start, and by inference, the status of current work.  Kenji does a great job at explaining how the kanban can be used in system development.    Kenji Hiranabe, CEO of Change Vision, Inc (http://www.change-vision.com/index_en.html).  Change Vision develops tools to help deliver effective projects.  He is a Japanese software development consultant and book translator of Extreme Programming Installed, Lean Software Development, Agile Project Management, and other Agile books. He's also an author of JUDE, a UML and MindMap editor software and TRICHORD, a kanban based agile project management tool.  He specializes in agile development, object-oriented software construction and project facilitation.    You can read his blog at http://jude-users.com/en/modules/weblog/index.php?user_id=5     Check out SPaMCAST’s New Facebook page!!!!   The essay for this cast is titled “Making Tangible The Intangible”.  The essay for this cast reflects concepts espoused by Phil Armour in SPaMCAST 36 and Kenji Hiranabe in SPaMCAST 37 (the current cast for those of you reading this on my blog).  The confluence of concepts that so moved me combines Kenji’s comments on the intangibility of both software and the processes and Phil’s on software as a container for knowledge.  There are a number of ways to share your thoughts: Email SPaMCAST at spamcastinfo@gmail.com Voice messages can be left at 1-206-888-6111 Twitter – www.twitter.com/tcagley BLOG – www.tcagley.wordpress.com FACEBOOK!!!! Software Process and Measurement   Future Events and the next . . . I will be speaking at IFPUG’s 3rd Annual ISMA Conference and Fall Workshops Sunday, September 14 – Friday, September 19, 2008 at the Westin Arlington Gateway Hotel information at www.ifpug.org.  The presentation is call “Counting Facebook” and will be on Friday September 19, 2008 at 10:25 AM - 11:25 AM. I am speaking at Quest Toronto 2008 Conference, September 22- 26, 2008, at the Hilton Hotel in Toronto, Canada.  I will be presenting “Good Numbers Go Bad” on Wed Sept 24th from 1:30 - 2:30 pm and also joining in as a subject matter expert in the end of day solutions workshop.  Information can be found at http://www.qaiquest.org/toronto/   Finally I will be speaking at the Northeast Quality Council 57th Conference.  The conference is scheduled for October 14 – 15 , 2008 in Marlborough, Massachusetts at Best Western Royal Plaza.   The presentation is titled “One Size Fits . . .Someone Other Than Me”.  Information can be found at http://www.neqc.org/conference.   Next Software Process and Measurement Cast:   On the next SPaMCAST we will feature an interview with Ed Yourdon discussing social media in the development process.  Talking to Ed was jam packed with information on using social media to foster collaboration.  If you don't know about how to use social media, its time to find out!

Scott sits down in Oslo, Norway with Tom and Mary Poppendieck to talk about Lean Software Development, the importance of The Business, and the real definition of success.

SPaMCAST Seven! Show Seven features an interview with Kenji Hiranabe on using mind mapping in agile projects.  Mind Mapping is a powerful technique to order information and concentrate communication.  The interview with Mr. Hiranabe includes a large number of practical applications of the method to agile and plan based projects.  Kenji Hiranabe, CEO of Change Vision, Inc (http://www.change-vision.com/index_en.html).  Change Vision develops tools to help deliver effective projects.  He is a Japanese software development consultant and book translator of Extreme Programming Installed, Lean Software Development, Agile Project Management, and other Agile books. He's also an author of JUDE, a UML and MindMap editor software and TRICHORD, an agile project management tool. You can read his blog at http://jude-users.com/en/modules/weblog/index.php?user_id=5.He specializes in agile development, object-oriented software construction and project facilitation.  The essay for this cast is titled, Why are requirements so hard to get right? Part 1.   The essay focuses on the people factors affecting the requirements process.  The people factors typically are the most volatile and a seemingly least controllable of the people, process and environment variables within the requirements process.  Process,  and environment will be discussed in subsequent essays.   Remember that  comments and feedback are welcome!  There are a number of ways to share your thoughts . . .  Email SPaMCAST at spamcastinfo@gmail.comVoice messages can be left at 1-206-888-6111It is my intent to share all emails and voice messages!   Future Events:  On June 21 at 3 PM  I will  be presenting "When Good Numbers Go Bad" at Better Software 2007 in Los Vegas.  The conference and workshops run from Monday June 18 though Thursday June 21 at the Venetian in Las Vegas.  Information is available at http://www.sqe.com/bettersoftwareconf/  If you are attending let me know.   Next Software Process and Measurement Cast:  The next Software Process and Measurement Cast features an important interview with Stephen Finegold of SFT Consulting, LLC.  The interview will cover the topic of build management.  The essay will be on the first of the deadly sins of metrics. 

Mary and I talk about her work in the area of Lean Software Development, new product development and the Agile 2005 Conference in Denver.