Podcast appearances and mentions of woody zuill

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.

In this Mob Mentality Show episode, we dive into the journey of Jeff “Cheezy” Morgan, a coach in Continuous Delivery (CD) and lean thinking. Known for his role in advocating for CD within companies, Jeff shares how his experiences with software development and his recent shift into the café business have shaped his philosophy on people and just-in-time. This discussion explores how Jeff's approach to Agile and CD evolved, his journey into Extreme Programming (XP), and how mob programming impacted his perspective on teamwork and Continuous Integration (CI).  **Jeff's Agile and CD Journey** We start with Jeff's introduction to Agile, discussing the early days of his career when dev practices didn't include CD and the impact of adopting CD in high-stakes projects like Y2K. Jeff describes how learning from Thoughtworks influenced his views on XP and CD, and how he became an advocate, eventually taking CD to different organizations. He also shares what it was like discussing with Woody Zuill and Llewellyn Falco and reflects on the transformative role mob programming has played in his career. **From Pairing to Mobbing**   For Jeff, mob programming was not initially appealing, but over time it became his preferred approach for helping teams. We explore how mobbing enhances CI, tightens communication, and fosters collective learning. Jeff explains how mobbing enables "just-in-time" discussions that align teams on what to build and how it allows real-time feedback on other team members' learning. Jeff also examines the transition from pairing to mobbing, the challenges of mob programming with CI/CD, and why mobbing helps him “get the whole system in the room” for tackling complex problems. **Quality Without QA?**   We dive into the controversial idea of achieving high quality without traditional Quality Assurance (QA). Jeff opens up about years spent wrestling with the role of QA in Agile/CD environments and shares experiments with “test-infected” developers—who took full ownership of quality. He reflects on the pitfalls of relying on “heavyweight” traditional QA processes and automated tests, which often create lean waste, add handoffs, and introduce brittle, flakey tests. Jeff and hosts Austin and Chris discuss whether “shift left” is merely a shift away from QA, the Deming Red Bead experiment's relevance, and whether there's a happy journey for QA professionals on CD teams. **Applying Lean to Cafés**   Outside the tech world, Jeff has found a second passion—running cafés. We discuss how owning two cafés influenced Jeff's perspective on Lean thinking and Agile principles. From supply chain issues during COVID to needing backup suppliers, Jeff discusses if “just-in-time” challenges in the café world mirror software development. He shares valuable insights about hiring, managing consistent delivery, and applying Lean principles to run a resilient business. Additionally, Jeff and Chris exchange stories on chip shortages and if Lean can help address real-world supply chain issues. **More from Jeff**   Finally, we tackle some big questions: What does DevOps mean in today's Agile world? Should “DevOps” be responsible for shielding organizations from developers? How does Test-Driven Development (TDD) factor into DevOps scripts, and can mobbing help break down silos that traditionally separated devs, ops, and QA? Join us for this wide-ranging conversation with Jeff “Cheezy” Morgan to uncover actionable insights for anyone involved in Agile, CD, DevOps, or Lean. Whether you're in software, QA, or running a small business, this episode is packed with valuable takeaways on quality, learning, and resilience.  Video and Show Notes: https://youtu.be/OJ5d6qLIQRY   

BONUS: What the UK COVID App Project Taught Us About Remote Agile Collaboration: A Conversation with Giovanni Asproni NOTE: We want to thank the folks at Tuple.app for being so generous with their stories, and supporting the podcast. Visit tuple.app/scrum and share them if you find the app useful! Remember, sharing is caring!   In this special BONUS episode, Giovanni Asproni, CTO and co-founder of Launch Ventures, takes us behind the scenes of his work on the UK government's COVID-19 app project. Giovanni shares insights into the rapid development process, the adoption of remote pairing and ensemble programming, and valuable lessons on leadership in large-scale, high-stakes projects. Giovanni also offers practical advice for teams embracing remote collaboration and agile methodologies. The Start of a Crucial Project "When we got the call from the UK government, we knew this was a mission to help stop the spread of the virus." Giovanni kicks off the episode by recounting how his team at Zühlke Engineering got involved in the development of the UK's COVID-19 app. Tasked with the challenge of building a solution that could help prevent the spread of the virus, they were under immense pressure to deliver quickly. Giovanni explains how they tackled technical hurdles, such as using Bluetooth technology to assess contagion risks, despite the lack of existing APIs on iOS and Android at the time. "Speed was essential, but we also needed a robust design—Bluetooth was key to evaluating contagion risks, even though we didn't have the APIs we needed." Overcoming Rapid Release Challenges "We had to move fast, but accessibility and coordination were non-negotiable." Giovanni discusses how the team, which consisted of around 60-70 members spread across the globe, used agile methodologies to stay organized and on schedule. By fostering open communication and using a clear team structure, they were able to streamline development. Agile planning and strong leadership, including cross-team coordination, were crucial to staying on track. "Agile was our backbone—every team knew their responsibility, and clear communication meant we could deploy with confidence." The Power of Remote Pairing and Ensemble Programming "Pairing allowed us to maintain quality under immense pressure." Giovanni dives deep into the practices of remote pairing and ensemble programming (or mobbing), which were introduced to enhance code quality and resilience during the project. With team members working remotely and under heavy scrutiny, mobbing provided a social outlet and improved problem-solving, while tools like Tuple made remote collaboration seamless. He reflects on the success of these practices, highlighting their impact on efficiency and team morale. "We embraced mobbing not just for resilience, but to stay connected in a time when social contact was scarce." Advice for Remote Pairing Beginners "Don't overthink it—just start and take breaks!" For teams new to remote pairing or ensemble programming, Giovanni offers simple but effective advice: give it a serious try, take breaks to avoid burnout, and don't overcomplicate the process. He emphasizes that these practices can dramatically improve productivity and team cohesion if executed well. "Take the plunge—remote pairing can feel awkward at first, but the benefits are worth it." Key Lessons on Remote Work and Collaboration "Don't try to recreate the office—remote work offers unique advantages." Reflecting on the lessons from the COVID-19 app project, Giovanni explains how remote work is not just a substitute for office work but an entirely different mode of collaboration. He warns against trying to replicate office dynamics remotely, and instead, encourages teams to embrace the benefits of remote settings, such as easier scheduling and fewer distractions from management oversight. "Remote work isn't about replicating the office—when done right, it's a whole new way to collaborate." Resources for Learning More "Explore the power of mob programming with these great resources." To wrap up, Giovanni shares a few key resources for listeners who want to dive deeper into remote pairing, ensemble programming, or leadership in software engineering. He recommends "Software Teaming" by Woody Zuill and the Remote Mob Programming website, which offers comprehensive guides and tools. You can also find out more about Giovanni's work at his company website: https://www.asprotunity.com. During the episode, Giovanni mentions a network of consultants, which you can access at: https://www.clockwork.ing. And the podcast Giovanni hosts is the Software Engineering Radio podcast. About Giovanni Asproni Giovanni Asproni is a consultant, CTO, and co-founder of Launch Ventures. He is an expert in agile development, software design, and modern software engineering practices. Giovanni is a host for the Software Engineering Radio podcast and a frequent speaker at international conferences. You can link with Giovanni Asproni on LinkedIn.

Fredrik får besök av Daniel Nilsson som berättar om hur han och Hogia jobbar med att ta in nyanställda och LIA-studenter. Daniels viktigaste tips: ta med de nya som vanliga medlemmar i teamet på de vanliga arbetsuppgifterna. Fördelar med att vara produktbolag snarare än konsultbolag. Låt LIA ta tid, det ger mest för alla då. Daniel berättar också hur man intervjuar och tar in nyutexaminerade, med en månads introduktion där man lär sig hela Hogias stack och bygga en applikation i stacken. Skillnaden mot LIA är egentligen att man får en större introduktion till företaget som helhet, medan LIA kanske handlar mer om att komma in i ett team. Konsultbolag är fegare med att ta in studenter och nya än vad de borde vara? Stereotypen om utvecklare stämmer inte längre - det handlar mycket mer om kommunikation idag. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Daniel Nilsson Tidigare avsnitt med Daniel Hogia På meetupen spelades också snacket med Woody Zuill in LIA - lärande i arbete Mobbande - mobbprogrammering, ett arbetssätt i grupp som används ganska mycket på Hogia Parprogrammering Stöd oss på Ko-fi! VB6 - en klassisk version av Microsofts Visual basic Nösnäs teknikcollege Titlar Vi jobbar ju så fort vi hinner Hyfsad korvstoppning Superdjupa i backend En liten tunn grund Han är på fyra bolag Hela poängen med LIA Det är okej att göra fel Som vem som helst i teamet Kravlöst Jag har inga förväntningar Det får ta tid

In this episode of the Mob Mentality Show, we explore the profound impact of mob programming from a management perspective with our special guest, Rickard Westman. With a diverse background in sports and news software products, Rickard transitioned from a traditional solo work environment to embracing mobbing—a journey that radically transformed how teams communicate, collaborate, and deliver value. Rickard opens up about his early experiences in the industry, where he witnessed the drawbacks of isolated work patterns—particularly the delays and inefficiencies caused by waiting on pull requests. His initial encounter with mob programming was anything but smooth. The concept felt awkward and unnatural, but after Woody Zuill's workshops and after experimenting with mobbing, Rickard and his teams discovered its potential to revolutionize their workflows. In this episode, we dive into Rickard's journey from skepticism to advocacy for mob programming. He shares how mobbing helped increase production release frequency and enhance safety within his teams. By exposing communication breakdowns and dependency issues during scaling, mob programming brought to light the hidden challenges that were stalling progress. With the introduction of multiple mob teams, these issues began to dissipate as team members naturally shared knowledge and collaborated across different areas. One of the key insights Rickard offers is the importance of slack in the system, generated through effective teaming. This slack led to greater autonomy, smoother flow, and quicker resolution of bottlenecks. Rickard recounts a compelling story where a bug fix, which would have taken six weeks in the traditional setup, was resolved in just one day through mobbing. This rapid turnaround is a testament to the power of collective problem-solving and the deep, holistic understanding of the product that mobbing fosters among team members. Rickard also touches on the shift in management responsibilities as a result of mob programming. With teams becoming more self-organizing, managers found themselves spending less time overseeing individual tasks and more time empowering their teams to make decisions. This distributed decision-making model, contrasted with the traditional command-and-control approach, aligns with principles from the book *Turn The Ship Around.* Throughout the episode, we discuss the benefits and potential pitfalls of mob programming from a management perspective. Rickard emphasizes the importance of coaching mob members to understand their contributions, especially when not working solo. He also explores how successful mob teams can serve as models for new teams, highlighting different interaction patterns for product owners, analysts, and even sports writers. Finally, we examine the meta-level impact of mob programming at the C-suite level and how it influences broader organizational decision-making. Whether you're a manager, developer, or team member, this episode provides valuable insights into how mob programming can unlock potential, foster collaboration, and drive continuous improvement in your organization. Video and Show Notes: https://youtu.be/hLN2iCBdYac  

Fredrik paid a visit to Hogia and got the opportunity to talk to Woody Zuill and Martin Lassbo about mob programming, innovation, and keeping an open and curious mind. Mob programming is still new. Every time you say “that can't work”, you tend to be proven wrong eventually. Try it, for a year or two. You can't evaluate things after trying it for just an hour or two, some things take much longer. But do steer and adjust often. How frequently do you want to steer? Short iterations are valuable in that they give us more opportunities to steer work in a good direction. Standardization stifles innovation. Sometimes you do want it, but it depends on which space you're in. We had a process, but we still succeeded! Where did the thought I have originate? All your thoughts started somewhere else. The things we most believe can hide our biggest mistakes. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Hogia Woody Zuill Martin Lassbo Mob programming Episode 218 (in Swedish) covers working in a mob in depth Other episodes with Woody Support us on Ko-fi! Øredev Woody's Øredev talk 2018, Beginner's mind Pair programming Turn up the good Cynefin - the decision framework you can never spell after hearing the word spoken Systems thinking - looking at systems as a whole, rather than in parts Kahnemann Thinking, fast and slow The drunkard's walk by Leonard Mlodinow Rational irrationality Survivorship bias Confirmation bias * Desirability bias Max Planck Russell Ackoff Deming Chaos theory Feynman - you are the easiest person to fool Dave Farley Titles There's always a lot to talk about The continuation My best thinking time The beginner's mind We just work together Maintain curiosity Steer towards better Turn up the good Getting a thing we thought we wanted How frequently could we steer? We think we know what we want Not a systems thinker Talent plus luck A higher level than the work itself A little more talent and a lot more luck I'll misquote it but I'm close Re-think the things we already believe Stay open-minded Something else could eat us A student of the biases Walk down a different path

Fredrik paid a visit to Hogia and got the opportunity to talk to Woody Zuill and Martin Lassbo about mob programming, innovation, and keeping an open and curious mind. Mob programming is still new. Every time you say “that can’t work”, you tend to be proven wrong eventually. Try it, for a year or two. You can’t evaluate things after trying it for just an hour or two, some things take much longer. But do steer and adjust often. How frequently do you want to steer? Short iterations are valuable in that they give us more opportunities to steer work in a good direction. Standardization stifles innovation. Sometimes you do want it, but it depends on which space you’re in. We had a process, but we still succeeded! Where did the thought I have originate? All your thoughts started somewhere else. The things we most believe can hide our biggest mistakes. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Hogia Woody Zuill Martin Lassbo Mob programming Episode 218 (in Swedish) covers working in a mob in depth Other episodes with Woody Support us on Ko-fi! Øredev Woody’s Øredev talk 2018, Beginner’s mind Pair programming Turn up the good Cynefin - the decision framework you can never spell after hearing the word spoken Systems thinking - looking at systems as a whole, rather than in parts Kahnemann Thinking, fast and slow The drunkard’s walk by Leonard Mlodinow Rational irrationality Survivorship bias Confirmation bias * Desirability bias Max Planck Russell Ackoff Deming Chaos theory Feynman - you are the easiest person to fool Dave Farley Titles There’s always a lot to talk about The continuation My best thinking time The beginner’s mind We just work together Maintain curiosity Steer towards better Turn up the good Getting a thing we thought we wanted How frequently could we steer? We think we know what we want Not a systems thinker Talent plus luck A higher level than the work itself A little more talent and a lot more luck I’ll misquote it but I’m close Re-think the things we already believe Stay open-minded Something else could eat us A student of the biases Walk down a different path

Join Murray Robinson and Shane Gibson as they chat with with Woody Zuill about mob programming. Woody explains the concept of mob programming where a cross-functional software development team focuses on completing one feature at a time. Woody describes how mobbing has increased the effectiveness of development teams he's worked with by 10 times while rapidly increasing team learning, capability and skills. Tune in to learn about the practical implementation of mobbing techniques to improve your product development.   Listen to the podcast on your favourite podcast app: | Spotify | Apple Podcasts | Google Podcasts | iHeart Radio | PlayerFM | Amazon Music | Listen Notes | TuneIn | Audible | Podchaser |  Deezer | Podcast Addict | Connect with Woody via LinkedIn or over at https://woodyzuill.com/   Contact Murray via email or Shane on LinkedIn shagility. You can read the podcast transcript at: https://agiledata.io/podcast/mob-programming-and-software-teaming-with-woody-zuill/#read   The No Nonsense Agile Podcast is sponsored by: Simply Magical Data

Welcome to another episode of the Mob Mentality Show! In this episode, we dig into the essential 7th Habit of Highly Effective People: "Sharpen the Saw." Join us as we explore the concept's vital role in Mob Programming. **In This Episode, We Discuss:** - The significance of "Sharpen the Saw" in the Genesis of Mob Programming with Woody Zuill. - The repercussions of neglecting to "Sharpen the Saw" and its impact on team efficiency and personal growth. - Strategies for integrating "Sharpen the Saw" into your workday versus outside of work hours. - The importance of dedicated learning time for continuous improvement. - Comparing ad-hoc and scheduled approaches to sharpening the saw. - Using learning sessions to enhance team skill diversity and foster a culture of growth. - When to use kanban cards for "sharpen the saw" activities - Creating a well-ordered life with scheduled habits for consistent personal and professional development. - Insights from "The Power of Habit" and "Atomic Habits" on stacking habits for maximum impact. - Transforming real knowledge and belief into action through proper identity and motivations. Tune in to discover practical tips and strategies to keep your team sharp, focused, and continuously improving. Whether you're a seasoned mobber or new to the practice, this episode offers valuable takeaways to enhance your team's productivity and collaboration. **Don't miss this dive into the 7th Habit!** **Join the Conversation:** Share your thoughts and experiences with us in the comments! How do you incorporate "Sharpen the Saw" in your daily routine? Let's learn and grow together! Video and Show Notes: https://youtu.be/_Uu0EXhV8oY  

In this episode of #AgileWay podcast I have a conversation with Woody Zuill about challenging the dogma, enhancing the collaboration by building credibility, relationship, influence. #agile #businessagility #change #collaboration #relationships #teaming

Luis Garcia: Forecast Over Estimation, How To Transform Your Approach To Project Management, NoEstimates Unplugged Week This is one of a series of episodes where Product Owners explain how they used, and benefited from #NoEstimates in their work with teams.  To know more about #NoEstimates, sign-up to get the first 3 chapters of the book here. Introduction to #NoEstimates Luis Garcia, transitioning from estimation discomfort to a #NoEstimates approach as a product owner, discovered its benefits after attending a workshop by Woody Zuill. Faced with the challenges of hard commitments in government projects, he sought to shift focus from when to what and why in project discussions. A Transformative Project Example  Implementing #NoEstimates in a kanban team, Luis emphasized work breakdown and comfortable task sizing. This method facilitated stakeholder communication, improved expectation management, and enabled precise progress measurement through metrics like cycle time and using techniques like Monte Carlo forecasting. Overcoming Implementation Challenges  When Luis tried to introduce #NoEstimates, he originally faced skepticism, misconceptions about planning, and stakeholder resistance. In those cases, Luis advises focusing on forecasting based on available data, ensuring team stability, and managing expectations effectively. And focusing on progress transparency, instead of trying to change people's minds. Strategic Stakeholder Management  Successfully integrating #NoEstimates involved fostering team accountability and ownership over the refinement process, thereby enhancing stakeholder dialogue and planning efficiency. For example, Luis shares that #NoEstimates shifted the team's focus to identifying and preparing the most valuable tasks, leveraging data for all planning and prioritization decisions. This focus helped to keep stakeholders informed, and improved transparency. Measuring Success and Communicating Progress  Without traditional estimates, Luis's team adopted a probabilistic approach to measure and communicate progress, supported by insights from the book "Thinking in Bets" by Annie Duke. When it came to adopting a different way to measure and communicate progress, practicality was key; even simple tools like Excel were effective for data management in the #NoEstimates process, emphasizing simplicity and scalability. Advice for #NoEstimates Adopters  Luis recommends low-change experimentation with #NoEstimates to experience its benefits firsthand and stresses the importance of informative discussions over rigid planning. Resource Recommendation  For those considering #NoEstimates, Luis suggests starting with the "NoEstimates" book and following thought leaders like Vasco Duarte, Woody Zuill, and Allen Holub on social media. About Luis Garcia Luis is a Program Manager at Formula.Monks, specializes in developing impactful digital products. Luis has over 10 years of experience and several Agile certifications, he adeptly applies Agile frameworks to meet client needs. His background includes a Master's in Computer Engineering and an Executive MBA. He is also fluent in English, Spanish, and French, he values diverse work environments and continuous learning. You can link with Luis Garcia on LinkedIn.

EPISODE DESCRIPTION:In this Dev Life edition of the Angular Plus Show, we talk with Agile coach and author Woody Zuill all about Software Teaming or Mob Programming. We explore the unique aspects of this approach, the benefits, challenges, considerations, and then Woody addresses common barriers & concerns to adopting Software Teaming before sharing practical steps for how you can incorporate this collaborative approach into your workflow to really maximize productivity. Grab your coding crew, rally around the keyboard, and turn your development process into a coding flash mob! This is… The Dev Life!LINKS:https://woodyzuill.com/https://twitter.com/woodyzuillhttps://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/https://www.youtube.com/watch?v=SHOVVnRB4h0https://www.youtube.com/watch?v=s4Eg-mnx9zgCONNECT WITH US:Woody Zuill - @woodyzuillBrooke Avery - @jediBraveryPreston Lamb - @PrestonJLamb

Embark on a captivating journey through the Agile Mentors Podcast in 2023 with Brian Milner. Explore a spectrum of Agile topics, from Scrum Master challenges to leadership insights. Join Brian for insightful summaries, memorable moments, and a walk through the rich tapestry of Agile wisdom on the show. Overview In this episode of the Agile Mentors Podcast, Brian embarks on a retrospective journey through the standout moments of the podcast in 2023. Explore carefully curated episodes, offering solutions to the common challenges and then delving into the world of Agile beyond software development. Listen in as Brian shares insightful summaries featuring memorable moments and a diverse landscape of Agile wisdom shared by his esteemed guests. Categorized into topics like Scrum Masters, Product Owners, Developers, Agile’s use beyond software, general career advice, and leadership and coaching, this retrospective is a treasure trove of practical advice, actionable insights, and real-world experiences. Tune in for an inspiring tour through the rich tapestry of the Agile Mentors Podcast 2023 episodes. Listen Now to Discover: [01:16] - Brian introduces the episode and invites listeners to join him in a retrospective of the year's episodes, highlighting ones that may have been missed or are hidden gems worth revisiting, which he will group by listener preferences and areas of interest. [02:39] - For Scrum Masters: Brian begins discussing the first episodes tailored for Scrum Masters, kicking things off with #47, "Exploring Lean Thinking and Agile Development," featuring guest Bob Payne, who shares insights into lean thinking, a foundational principle in agile development. Brian recommends this episode for Scrum Masters aiming to enhance their understanding of Agile's fundamentals. [03:34] - Episode #52, "The Birth of Agile: How 17 Adventurous Techies Changed the World," features Agile icon Mr. Jim Highsmith, one of the authors of the Agile Manifesto. Jim provides a glimpse into the past and offers insights into the future of Agile. [04:06] - Episode #59, "Revising the Scrum Guide," features Don McGreal, who played a key role in the guide's revision, shedding light on the thinking behind the revisions. [05:31] - In Episode #62, "Effective Sprint Goals," Maarten Dalmijn delves into effective crafting techniques and the finer details of achieving success with Sprint Goals. [06:12] - In Episode #69, "Should Scrum Masters Be Technical with Allison Pollard," Allison and Brian explore the question of whether Scrum Masters should possess technical skills. If you grapple with how technical a Scrum Master should be, this episode provides valuable insights and perspectives. [06:51] - In Episode #39, Mike Cohn, an authority on user stories, shares valuable insights into the art of crafting effective user stories. [07:15] - In Episode #65 with Randy Hale titled "Unlocking Lean Portfolio Management," Brian and Randy explore the concept of moving beyond a single-team focus as a product owner, delving into the realm of lean portfolio management building upon insights shared by Bob in episode #47. [07:50] - For Product Owners: Must listen bonus from last year, Episode #22, with Roman Pichler, who shares his insights on "How to Create Helpful Product Roadmaps," addressing challenges commonly faced by product owners in dealing with the nuanced aspects of their role. The episode covers strategies to avoid pitfalls, especially the dangers of rigidly locking into scope and schedule timelines. [08:54] - For Developers: Episode #33, "Mob Programming with Woody Zuill," introduces developers to the transformative practice of mob programming. Woody Zuill, a pioneer in this way of working, shares insights and a practical and thoughtful approach that makes it worth exploring. [10:00] - In Episode #48, Brian hosts a unique episode featuring the renowned Lisa Crispin and Janet Gregory, experts in Agile testing, in a show called "Holistic Agile Testing." This episode is particularly recommended for developers specializing in testing or involved in testing within a Scrum team. [11:00] - In Episode #54, "Unlocking Agile's Power in the World of Data Science," Brian and Lance Dacy explore the intersection of Agile methodologies and data science. The popularity of this episode prompted a sequel, Episode #63, on the fusion of Agile and data science. [11:58] - In the final developer-focused episode, Carlos Nunez joins Brian to delve into the world of DevOps. Carlos, a speaker at Agile 2023, shares insights on the significance of DevOps in today's Agile landscape, emphasizing DevOps as a means of empowerment rather than gatekeeping. [12:38] - Agile Outside of Software: Episode #32 with Cort Sharp focuses on Scrum in High School Sports—specifically high school swimming. Cort shares his experience applying Scrum principles to create practice schedules and routines for the swim team he coaches, providing valuable insights for those interested in using Agile beyond the software realm. [13:24] - In #38: "Using Agile for Social and Societal Transformation with Kubair Shirazee," Kubair walks listeners through how his nonprofit employs Agile methodologies to empower micro-entrepreneurs in developing countries. The episode highlights success stories, such as a barber's journey from a rented spot to owning a professional store, demonstrating Agile's transformative impact beyond the tech industry. [14:40] - Episode #45 with Scott Dunn explores "Overcoming Agile Challenges in Regulatory Environments." This crucial topic addresses the unique challenges faced in tightly regulated sectors like government, legal, and medical professions, offering a compelling dialogue on navigating regulatory hurdles within an agile framework. [16:00] - Episode #64 features John Grant discussing "How Agile Methodologies Reshape Legal Practices." This episode reveals the transformative impact of Agile in the legal profession and offers a unique perspective on Agile as a philosophy rather than just a practice, illustrating its broader applicability beyond the software realm. [17:00] - Today's episode is brought to you by Mountain Goat Software's Certified Scrum Product Owner (CSPO) course. This is a two-day training course taught by one of our certified Scrum trainers that teaches you how to use the product backlog as a tool for project success and how to respond to changes in business conditions by restructuring the product backlog. For the schedule, visit the Mountain Goat Training Schedule. [17:27] - General Career Advice: #34: "I'm Trained, Now What? with Julie Chickering" addresses the post-training phase for Scrum Masters and Product Owners. Julie shares insights on taking the next steps, implementing knowledge, and finding opportunities to build a resume in Agile roles. [18:29] - In #40: "Is it Time to Go Out on Your Own? Tips and Insights with Chris Li" Brian and Chris Li discuss considerations for those at later stages of their careers contemplating the transition to independent consulting. If you're pondering whether it's time to establish your consultancy, this episode provides valuable insights and considerations to guide your decision-making process. [19:00] - In #42: "The Importance of Self-Mastery with Bob Galen," Bob emphasizes the value of constant learning, even after years of experience, highlighting the importance of staying open to new discoveries and others' experiences. This episode serves as a compelling guide for personal growth and continuous improvement. [20:28] - Episode #46 with Christina Ambers: In this episode, Christina shares insights on "How to Assess Company Culture Before Accepting a Job Offer." As the year closes and people consider new job opportunities, Christina guides listeners through the crucial step of evaluating company culture and the importance of understanding if a company truly embraces Agile values or merely pays lip service to them. [21:14] - Episode #50 celebrated the milestone of the 50th episode. Lance Dacy was on the show to discuss "Choosing Your Path: Exploring the Roles of Scrum Master and Product Owner." The episode offers guidance for individuals at crossroads, helping them decide between Scrum Master and Product Owner roles. It serves as a valuable resource for those navigating career decisions in the Agile landscape. [22:13] - Leadership and Coaching: In the Leadership and Coaching category, Episode #37 features Brad Swanson discussing "Servant Leadership, Not Spineless Leadership." Brad dispels misconceptions and offers valuable insights into the essence of servant leadership, making it a compelling resource for those interested in effective leadership approaches. [23:28] - In Episode 41, Karim Harbott explores "Cultural Transformations in Organizations." The episode delves into the challenges of changing organizational culture, emphasizing the time and effort required beyond implementing specific practices. [24:00] - In "#44: Transformations Take People with Anu Smalley", Anu highlights the often-overlooked aspect of involving people in organizational transformations, shedding light on the human dynamics that can either support or hinder the process. [24:35] - In Episode #53, "Debunking Myths in Agile Coaching with Lucy O'Keefe," we tackle the common myths surrounding Agile coaching and provide insights on unlocking excellence in Agile coaching practices. [25:01] - Episode #66 is a solo episode where Brian shares his insights into navigating team conflicts, laying the foundation for understanding and mastering the essential skill of conflict navigation. [26:00] - In Episode #68, Brian hosts Mike Hall for a discussion of "The Pros and Cons and Real-World Applications of SAFe." Whether you're new to SAFe or deeply involved, Mike's expertise provides valuable perspectives and tips for navigating this framework. [26:42] - In Episode #70, Mike Cohn joins Brian to explore "The Role of a Leader in Agile." Here, Mike shares valuable insights based on his extensive experience, offering sound advice and perspective on the crucial role of leaders in self-organizing teams. [28:10] - Brian encourages listeners, especially newcomers, to explore relevant episodes based on their roles, with the goal being to offer practical advice and solutions on specific issues rather than lengthy discussions. All episodes are available in the show notes for convenient access. [29:33] - Brian expresses gratitude to listeners for the past year, reflecting on the unique nature of podcasting and letting listeners know he cherishes the encouragement and connections made, especially at events like Agile 2023. [31:00] - What do you want to hear in 2024? What are some of the hot-button topics that haven’t been covered on the show or guests you want to hear from? Send Brian an email with your ideas. [32:28] - And don’t forget to share and subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. [33:00] - We also have our Agile Mentors Community, where we have discussions about every podcast [33:24] - Wishing you a Happy Holiday Season! We'll see you early again in 2024. References and resources mentioned in the show: #47: Exploring Lean Thinking in Agile Development with Bob Payne #52: The Birth of Agile: How 17 Adventurous Techies Changed the World with Jim Highsmith #59: Revising the Scrum Guide with Don McGreal #62: Effective Sprint Goals with Maarten Dalmijn #69: Should Scrum Masters Be Technical with Allison Pollard #39: The Art of Writing User Stories with Mike Cohn #65: Unlocking Lean Portfolio Management with Randy Hale #22: How to Create Helpful Product Roadmaps with Roman Pichler #33 Mob Programming with Woody Zuill #48: Holistic Agile Testing with Lisa Crispin and Janet Gregory #54 Unlocking Agile's Power in the World of Data Science #63: The Interplay Between Data Science and Agile with Lance Dacy #71: The World of DevOps with Carlos Nunez #32: Scrum in High School Sports with Cort Sharp #38: Using Agile for Social and Societal Transformation with Kubair Shirazee #45: Overcoming the Challenges of Agile in Regulatory Environments with Scott Dunn #64: How Agile Methodologies are Reshaping Legal Practices with John Grant #34: I'm Trained, Now What? with Julie Chickering #40: Is it Time to Go Out on Your Own? Tips and Insights with Chris Li #42: The Importance of Self-Mastery with Bob Galen #46: How to Assess Company Culture Before Accepting a Job Offer with Christina Ambers #50: Choosing Your Path: Exploring the Roles of Scrum Master and Product Owner with Lance Dacy #37: Servant Leadership, Not Spineless Leadership with Brad Swanson #41: Cultural Transformation in Organizations with Karim Harbott #53: Agile Coaching: Debunking Myths and Unlocking Excellence with Lucy O'Keefe #66: Successful Strategies for Navigating Team Conflicts #68: The Pros and Cons and Real World Applications of SAFe with Mike Hall #70: The Role of a Leader in Agile with Mike Cohn #49: Celebrating One Year: A Look Back at 50 Episodes of the Agile Mentor Podcast Certified Scrum Master Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified ScrumMaster® Advanced Certified Scrum Product Owner® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

In the second part of the podcast episode, Gayatri Kalyanaraman is in conversation with Woody Zuill, Expert Coach and co-author of Mob Programming, shares his career journeyBalancing the speeches and consulting with consulting engagementsWoody shares tips and tricks of being in the speaking networksWoody talks about joy of creating his own businesses - Almost 16 of them is creating Woody shares early experiments on signs and making new thingsHe shares his passion of making his day productive by avoiding repeated steps and automateWoody shares his deep inflection points in his career that has positioned him today Woody also shares his ideal places to work and attracting like minded people to work Instead of Doing what others are expecting of us and always uplifting to oneself alsoWoody also shares deep views on how one needs to contribute for a better tomorrowWoody has been programming computers for almost 40 years, and have 20+ years of experience as an Extreme Programmer, and 15+ years as an Agile Guide of some sort. He truly believes that code must be simple, clean, and maintainable so that we can realize the Agile promise of Responding to Change, and that we must constantly "Inspect and Adapt".Woody is a co-author with Kevin Meadows of the book "Mob Programming, A Whole Team Approach". He's a prolific speaker on this topic at conferences, user groups, and meet-ups all over the world.More generally, I've delivered workshops, trainings, and coaching sessions on Agile Software Development, Mob Programming, and Software Development Practices for a number of firms including Ericsson, Schneider Electric, Qualcomm, Intel, H & M, King Games, Capital One, Twitter, and Spotify.Woody can be connected at https://www.linkedin.com/in/woodyzuill/ 

In the first part of the podcast episode, Gayatri Kalyanaraman is in conversation with Woody Zuill, Expert Coach and co-author of Mob Programming, shares his career journeyShares how he joined software development after he created tools to improve his day-to-day lifeJokingly Woody mentions how he didn't have to clean up(unlike doing carpentry) after a hard day at writing codeEarly experimentation on pair programming and having fun and how he found that explaining ideas, listening each other and accepting each others opinions - most importantly stop interrupting othersTalks about the story of using pair programming for knowledge transfer in a rapid mannerShares his principle on how experimenting is the fastest way to build cultural nuancesPaying attention to others emotions and deeply listening enables - Listen as if the next sentence is the most important thing we are going to listenHis motto - Be the best team member that you can be Woody shares tips and tricks on deep listening skill and staying curiousAha moments Woody has had how “Teams” have evolvedHow can you lead from without any of the influence and how that led him to become a speaker and teacherWoody has been programming computers for almost 40 years, and have 20+ years of experience as an Extreme Programmer, and 15+ years as an Agile Guide of some sort. He truly believes that code must be simple, clean, and maintainable so that we can realize the Agile promise of Responding to Change, and that we must constantly "Inspect and Adapt".Woody is a co-author with Kevin Meadows of the book "Mob Programming, A Whole Team Approach". He's a prolific speaker on this topic at conferences, user groups, and meet-ups all over the world.More generally, I've delivered workshops, trainings, and coaching sessions on Agile Software Development, Mob Programming, and Software Development Practices for a number of firms including Ericsson, Schneider Electric, Qualcomm, Intel, H & M, King Games, Capital One, Twitter, and Spotify.Woody can be connected at https://www.linkedin.com/in/woodyzuill/ 

Join Brian as he rediscovers and relives the most captivating topics, memorable guests, and impactful topics from the first year of the “Agile Mentors” podcast. Overview From deep dives into Agile methodologies and practical tips for using your knowledge to benefit others and foster change, the first 50 episodes of the “Agile Mentor” podcast have been filled with fascinating topics and memorable guests. In this episode, Brian Milner embarks on a retrospective journey through the inaugural year of the show. Listen in as he shares the real stars of the podcast, the moments that surprised him, those that took him out of his comfort zone, and the ones that inspired him to push to be better every day! Plus, what’s next for the show. Listen Now to Discover: [00:45] - Brian introduces the retrospective episode to celebrate one year and 50 episodes of the "Agile Mentors" podcast and share what's next. [01:54] - A thank you for YOUR role in the show. [02:17] - The role of marrying the right topic to the right guest. [02:56] - The format that allows listeners to choose the episodes that interest them the most. [04:03] - Pointing you toward the best of the best. Our first several episodes were focused on the Agile Framework and some core topics, including having Mike Cohn on to talk about the different roles and generally accepted practices. [05:13] - Sending out thanks to a few of our guests, including the trainers at Mountain Goat Software, including Lance Dacy. [05:45] - Kert Peterson joined us to share his knowledge, and Scott Dunn shared his insight from the product owner's perspective. [06:05] - On episode 16, Mitch Lacey joined us to discuss The Hidden Secret Ingredient And Julie Chickering brought a great perspective from a project management background and applying that to some of the stuff we've discussed here on the show. [06:39] - The time when one of my mentors joined us on the show to discuss transformation. [07:08] - Learning about coaching and marketing from the best! [07:27] - Roman Pitchler joined us to discuss product roadmaps and planning things from a product owner perspective. And John Miller shared about using Scrum in the education environment. [07:46] - On EP25, Henrik Nieberg came on and talked to us about scaling, and on EP27, Tricia Broderick walked us through leadership without blame. [08:18] - How Scrum can be applied outside of software development and mob programming. [08:42] - The key to working with humans. [09:03] - The episode that surprised Brian a little bit. [09:34] - Three episodes all about change: The first one was about how one organization uses Scrum to help impoverished micro-entrepreneurs succeed (and change their lives). The second featured Chris Li sharing his insight on how to know when it’s time to strike out on your own, and Karim Harbott walked us through the difficulty of transforming an organization's culture. [10:25] - The episode that inspired Brian to try to push in different ways to get better. And how to cultivate an Agile culture in a virtual world. [10:53] - Why transformations take people, how to assess a company’s culture before you accept their job offer, and lean thinking in Agile with Bob Payne. [11:49] - The real stars of the podcast. [12:30] - What’s ahead for the podcast? [13:02] - Stepping off the gas a bit. [13:45] - Virtual dial—targeted tips. [14:32] - The lifeblood of the “Agile Mentors” podcast. [15:06] - Mike Cohn and Brian are both presenting at Agile2023 in Orlando, July 24 through 28th. [15:39] - The most significant benefit of BIG conferences. [16:41] - Thank you for getting us to a year and 50 episodes! Join the Agile Mentors Community to continue the discussion. If you have topics for future episodes, email us by clicking here. And don’t forget to subscribe to the “Agile Mentors” Podcast on Apple Podcasts so you never miss an episode. References and resources mentioned in the show: Agile2023 | Orlando, Florida | Agile Alliance #1: Scrum vs Agile & Keys to Success with Mike Cohn #3: What Makes a Great Product Owner? With Lance Dacy #9: Scrum Artifacts with Kert Peterson #10: Why User Stories are the Best Way to Capture Requirements with Mike Cohn #17: Getting There From Here: Agile Transformations with David Hawks #18 Coaching in an Agile World with Lyssa Adkins #21: Agile Marketing Teams with Stacey Ackerman #22: How to Create Helpful Product Roadmaps with Roman Pichler #23 How Agile Works in Education with John Miller #25: Scaling with Henrik Kniberg #27: Leading Without Blame with Tricia Broderick #29: Influencing Up with Scott Dunn #32: Scrum in High School Sports with Cort Sharp #33 Mob Programming with Woody Zuill #34: I'm Trained, Now What? with Julie Chickering #37: Servant Leadership, Not Spineless Leadership with Brad Swanson #38: Using Agile for Social and Societal Transformation with Kubair Shirazee #40: Is it Time to Go Out on Your Own? Tips and Insights with Chris Li #41: Cultural Transformation in Organizations with Karim Harbott #42: The Importance of Self-Mastery with Bob Galen #43: Cultivating Agile Team Culture in a Virtual World with Richard Cheng #44: Transformations Take People with Anu Smalley #46: How to Assess Company Culture Before Accepting a Job Offer with Christina Ambers #47: Exploring Lean Thinking in Agile Development with Bob Payne Mountain Good Software's Certified Product Owner course Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

François-Guillaume Ribreau est CTO as a service. Mais aussi entrepreneur, développeur. Détecteur de points de douleurs et militant pour la résolution de problèmes informatiques. Dans cet épisode, François-Guillaume évoque les sujets clefs pour un développeur : - Comment s'assurer qu'un outil SaaS est utile et monétisable (exemple de Redsmin.com) - Comment prioriser les fonctionnalités en fonction des douleurs de l'utilisateur final - Comment travailler sur une approche mixant Lean + Extreme programming = eXtreme Lean - Comment travailler en tant que CTO as a service - Comment faire monter en compétences les jeunes ingénieurs - Comment travailler en pair programming - Pourquoi l'open source gagne toujours (surtout en BtoB) Donc beaucoup d'éléments autour du savoir-faire des développeurs, autour de la méthodologie eXtrem Lean et des tests utilisateurs. Mais aussi sur une question brûlante dans l'univers des logiciels en SaaS : comment créer un logiciel opérationnel tout en validant le besoin réel côté utilisateurs ? Prêt à booster vos perfs ? C'est parti pour un épisode MasterClass ! ▬▬▬▬▬▬▬▬▬▬ Les informations mentionnées dans cet épisode - Chart API as a service : https://www.image-charts.com/ - Keycloak IAM as a Service : https://www.cloud-iam.com/ - REX qui partage la manière dont a été construit le SaaS Cloud IAM en eXtreme Lean : https://www.youtube.com/watch?v=5gZYU56q4No - OSS Webhook as a Service : https://www.hook0.com/ - Mob Programming chez Ouest France, conférence https://www.youtube.com/watch?v=nTR7AxqI9WQ - Pour suivre vos films et vos séries : https://www.captainwatch.com/ - Film Le Menu : https://www.captainwatch.com/film/593643/le-menu - The Witcher : https://www.captainwatch.com/serie/71912/the-witcher - Les Anneaux de pouvoir : https://www.captainwatch.com/serie/84773/le-seigneur-des-anneaux-les-anneaux-de-pouvoir Recommandations de François-Guillaume - Livre NoBullshit Tech-Lead : https://www.getnobullshit.com/ - Code with the Wisdom of the Crowd : https://www.amazon.fr/Code-Wisdom-Crowd-Together-Programming/dp/1680506153 (mais le "créateur du mob" c'est plutôt Woody Zuill, François-Guillaume cherchais le nom !) - Le rapport La Tombe 2021 : https://www.assemblee-nationale.fr/dyn/15/rapports/souvnum/l15b4299-t1_rapport-information#_Toc256000000 - Bullshit Jobs : https://www.fnac.com/a12303134/David-Graeber-Bullshit-Jobs - Strange Loop Conference : https://www.youtube.com/@strangeloopconf   - Conference Devoxx : https://www.youtube.com/@devoxxfrvideos   Pour suivre l'actualité de François-Guillaume - Twitter : https://twitter.com/FGRibreau - LinkedIn : https://www.linkedin.com/in/francoisguillaumeribreau/ - Malt : https://www.malt.fr/profile/francoisguillaumeribreau ▬▬▬▬▬▬▬▬▬▬ Postproduction Audio : Guillaume Lefebvre (https://www.linkedin.com/in/guillaume-lefebvre-760381239/) Music by MADiRFAN from Pixabay

Join Woody Zuill and Brian Milner as they discuss the benefits of teams working together through Mob Programming. Overview In this episode of the Agile Mentors podcast, Woody Zuill, a 40-year veteran software developer specializing in team interaction, joins Brian to explore the concept of Mob Programming. Woody shares the benefits of working together rather than separating tasks in software development and how removing things like queuing, multitasking, and context switching can actually make teams more effective. Listen in as he walks us through the collaborative software development approach's perks. Listen now to discover: [02:22] - Brian introduces Woody Zuill, a 40-year veteran software developer specializing in team interaction. [02:51] - Woody explains how he discovered the term Mob Programming. [04:56] - Where the idea of Teaming came from. [06:20] - Woody explains why he's changing the name from mob programming to teaming. [07:23] - Teaming = collaboration brought to software development, where more than one brain connects to do the work that needs to be done. [11:11] - Painting the Mob Programming picture: it's when "all the brilliant minds work together on the same thing ‌in the same space, at the same computer." [13:40] - To work efficiently in software development, one team member acts as the driver at the keyboard while everyone else acts as the navigator. [16:41] - The drawbacks and disconnect of breaking software development down into smaller pieces. [18:34] - Isn't six people in one room working on one computer a waste of resources? [21:07] - Do you want to be productive or effective? Examining the Lean concept of flow. [24:57] - Enhancing the effectiveness of software development by removing the negative impact of waiting, queuing, multitasking, and context switching. [25:22] - The benefits of working together vs. separating tasks in software development. [26:53] - Team Flow: how collaboration adds to our ability to work in the zone. [28:38] - Working together is often more effective, so why have we gotten better at it? [31:25] - The strength of experimentation. [33:09] - Woody explains that since the software development process is a discovery process, innovations such as mob programming can benefit the process. [35:25] - Woody shares resources where you can find more information on Mob Programming (see the resources section below for more) and how you can contact him to schedule a workshop. References and resources mentioned in the show: Software Teaming: A Mob Programming, Whole-Team Approach by Woody Zuill Teaming by Amy C. Edmondson Code with the Wisdom of the Crowd: Get Better Together with Mob Programming by Mark Pearl The Mob Mentality Show on Apple Podcasts Diffusion of Innovations by Everett M. Rogers Online And In-Person Training To Help You Succeed With Agile Through Mountain Goat Software The Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left 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. Woody Zuill has been a software developer for over forty years. Woody is one of the pioneers of Mob Programming, a method of teamwork in software development that involves the entire team working together. Woody gives remote and in-person workshops on the topic. You can find out more about him on Twitter @WoodyZuill or on LinkedIn.

Join Woody Zuill and Brian Milner as they discuss the benefits of teams working together through Mob Programming. Overview In this episode of the Agile Mentors podcast, Woody Zuill, a 40-year veteran software developer specializing in team interaction, joins Brian to explore the concept of Mob Programming. Woody shares the benefits of working together rather than separating tasks in software development and how removing things like queuing, multitasking, and context switching can actually make teams more effective. Listen in as he walks us through the collaborative software development approach's perks. Listen now to discover: [02:22] - Brian introduces Woody Zuill, a 40-year veteran software developer specializing in team interaction. [02:51] - Woody explains how he discovered the term Mob Programming. [04:56] - Where the idea of Teaming came from. [06:20] - Woody explains why he's changing the name from mob programming to teaming. [07:23] - Teaming = collaboration brought to software development, where more than one brain connects to do the work that needs to be done. [11:11] - Painting the Mob Programming picture: it's when "all the brilliant minds work together on the same thing ‌in the same space, at the same computer." [13:40] - To work efficiently in software development, one team member acts as the driver at the keyboard while everyone else acts as the navigator. [16:41] - The drawbacks and disconnect of breaking software development down into smaller pieces. [18:34] - Isn't six people in one room working on one computer a waste of resources? [21:07] - Do you want to be productive or effective? Examining the Lean concept of flow. [24:57] - Enhancing the effectiveness of software development by removing the negative impact of waiting, queuing, multitasking, and context switching. [25:22] - The benefits of working together vs. separating tasks in software development. [26:53] - Team Flow: how collaboration adds to our ability to work in the zone. [28:38] - Working together is often more effective, so why have we gotten better at it? [31:25] - The strength of experimentation. [33:09] - Woody explains that since the software development process is a discovery process, innovations such as mob programming can benefit the process. [35:25] - Woody shares resources where you can find more information on Mob Programming (see the resources section below for more) and how you can contact him to schedule a workshop. References and resources mentioned in the show: Software Teaming: A Mob Programming, Whole-Team Approach by Woody Zuill Teaming by Amy C. Edmondson Code with the Wisdom of the Crowd: Get Better Together with Mob Programming by Mark Pearl The Mob Mentality Show on Apple Podcasts Diffusion of Innovations by Everett M. Rogers Online And In-Person Training To Help You Succeed With Agile Through Mountain Goat Software The Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left 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. Woody Zuill has been a software developer for over forty years. Woody is one of the pioneers of Mob Programming, a method of teamwork in software development that involves the entire team working together. Woody gives remote and in-person workshops on the topic. You can find out more about him on Twitter @WoodyZuill or on LinkedIn.

Ever been in a software group that was so effective that it truly lived up to the word "team"? If so, what was it like?  What was the differentiator that took it beyond the infamous office posters of so-called "teams" into the realm of actual teaming? Join Chris and Austin as they celebrate and discuss with Woody Zuill and Kevin Meadows the second edition of the Software Teaming Book that Woody and Kevin just published. Woody and Kevin not only explore the inspiring software teaming concept from Amy Edmondson's Teaming book but also they dive into the genesis of the first and second editions of their Software Teaming book. Woody and Kevin talk about what changes were made in the second edition and why. They share about how they collaborated to write the book and why Kent Beck was asked to write the foreword. Lastly, they riff on different analogies for teaming (e.g., Orchestra, Jazz Band, Improv Comedy Group) and on the unity and diversity they have experienced in mob/ensemble programming.  FYI: Video and show notes to be posted here in the next day or so. 

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 Paula joined this team, she noticed the team was not sharing the good (or bad) things that were happening. We discuss how teams in the new “remote world” become passive and do not follow-up on their agreements, and let things drop because the other person is not there, present by their side. In this segment, we talk about how important it is to work on the relationships between team members as well as between team members and stakeholders, especially in this remote work world! Featured Book of the Week: The Art of Being Brilliant by Cope and Whittaker In The Art of Being Brilliant: Transform Your Life by Doing What Works For You by Cope and Whittaker, is a book that helped Paula orient her career and learn about positive psychology which helped her feel and help others feel more confident in themselves. In this segment, we refer to Woody Zuill, a previous guest on the podcast and his mantra “turn up the good”. 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 Paula Dunne Paula is an Agile Coach with experience in large organization Agile adoption as well as in coaching product owners. You can link with Paula Dunne on LinkedIn. 

Getting Things Done methodologyElm Radio Developer Productivity episodeElm Radio Parse, Don't Validate episodeScaling Elm apps Elm Radio episodeRuby's method_missingRuby's Enumerble API methodsJoël Quenneville's recommendation to write functions at a single level of abstractionelm-pages v3 API makes HttpOnly cookies opt-out instead of opt-inLlewellyn Falco and Woody Zuill's video Practical Refactoring ("Understand the code so we can change it" vs. "change the code so we can understand it")Elm Radio Incremental Steps episodeElm Radio Opaque Types episode

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. This team did not feel that they could make their own decisions. When observing the team, Ziryan noticed that management was heavily involved with the team, and the team did not feel comfortable making decisions without management involvement. As he started working with the team members 1-on-1, Ziryan started to notice the patterns that had trapped this team. Listen in to learn about those anti-patterns, as well as what Ziryan did to help the team get out of that self-defeating pattern. Featured Book of the Week: Yes-but what if it all works out? By Berthold Gunster In Yes-but what if it all works out? By Berthold Gunster, Ziryan found an inspiring story of how to handle change with a “yes, and” rather than a “yes, but” attitude. The book helped Ziryan prepare for responding to, and harnessing change resistance. In this segment, we also talk about Scrum – A Pocket Guide by Gunther Verheyen, and the episode with Yves Hanoulle and Woody Zuill, where we discuss the heuristic: “Turn up the good”.  How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta! Abou Ziryan Salayi Ziryan is a Scrum Master, Professional Scrum Trainer, and organization coach with a passion for getting the most out of people and teams. His aim is to enable employees to be fully empowered and support self-organization in all areas within agile organizations You can link with Ziryan Salayi on LinkedIn and connect with Ziryan Salayi on Twitter.

Mob programming challenges the idea of developer teams as a group of individuals with a common goal yet who do most of the work separately. Hence, mob programming emphasizes the importance of collaboration, having faith that software development can benefit from it just as human enterprises have done throughout history. To teach us about the benefits of mob programming, we invited Agile coach Woody Zuill.You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

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.   About Woody Zuill and Yves Hanoulle Woody is the man behind Mob Programming, and he often talks and presents on agile topics, and coaches people interested in creating a wonderful workplace where people can excel in their work, and in their life. You can link with Woody Zuill on LinkedIn and connect with Woody Zuill on Twitter.    Yves is all about collaboration. His goal is to inspire people to create more collaborators.  Creating self-sustaining communities from home allows him to spend more time with his kids.  And to get a better work-life fusion. For him agile and communities share a common element called trust. With trust anything is possible, without trust, some things might be possible, yet very hard and expensive... You can link with Yves Hanoulle on LinkedIn and connect with Yves Hanoulle on Twitter. 

We're talking with Woody Zuill today about all things Mob Programming. Woody leads Mob Programming workshops, he's a speaker on agile related topics, and coaches and guides orgs interested in creating an environment where people can do their best work. We talk through it all and we even get some amazing advice from Woody's dad. We define what Mob Programming is and why it's so effective. Is it a rigid process or can teams flex to make it work for them? How to introduce mob programming to a team. What kind of groundwork is necessary? And of course, are mob programming's virtues diminished by remote teams in virtual-only settings?

We're talking with Woody Zuill today about all things Mob Programming. Woody leads Mob Programming workshops, he's a speaker on agile related topics, and coaches and guides orgs interested in creating an environment where people can do their best work. We talk through it all and we even get some amazing advice from Woody's dad. We define what Mob Programming is and why it's so effective. Is it a rigid process or can teams flex to make it work for them? How to introduce mob programming to a team. What kind of groundwork is necessary? And of course, are mob programming's virtues diminished by remote teams in virtual-only settings?

Woody Zuill on Turn Up the GoodMob ProgrammingWhere Could We Turn Up the Good?Pure FPElm 0.19 removing side effectsPurity is what makes elm-review interestingJeroen's post Safe dead code removal in a pure functional languageNo runtime exceptionsUseful Error MessagesUseful error messagesEvan's 2017 Deconstructconf talk Evan Czaplicki On StorytellingEvan's talk What is Success?Having a single language flavorIsomorphic codeMeta frameworks (elm-pages, Lamdera, elm-spa)Decoupled toolsThe community can iterate quickly and experiment with new changeselm-optimize-level-2 and elm-format are great exampleselm-optimize-level-2 can make their way upstream and don't break Elm's guarantees or assumptionsRobin Hansen's blog post series Successes, and failures, in optimizing Elm's runtime performanceExtensible Web ManifestoPlatform should provide building blocks, not solve every specific use caseStable CoreStable data layer, architecture allows ecosystem to evolve around it with less churnCommunity Members Working on What They're Passionate AboutPeople passionate about a problem working on it in the ecosystemPerformanceLeveraging Elm's unique characteristics for performance (immutability, static language, known types, etc.)Elm compiler performance - compiler speed mattersContent and ConferencesElm community content and conferencesElm Online meetdownThe Elm PhilosophyEvan's Elm philosophy tweetPhilosophy has influenced package design in the ecosystemElm Slack #api-design channel

In this episode, Richard interviews Woody Zuill, an Agile coach well known for popularizing mob programming and the No Estimates movement. In this first part of the interview with Woody, he tells us how kindness, consideration, and respect can transform any team into a fulfilling working experience. When you finish listening to the episode, connect with Woody on LinkedIn and Twitter, visit his website at www.woodyzuill.com, and check out his upcoming book No Estimates - How to Deliver Software Without Guesswork. You can read the transcript of the entire episode at https://kasperowski.com/podcast-73-woody-zuill/.

In this episode, Richard interviews Woody Zuill, an Agile coach well known for popularizing mob programming and the No Estimates movement. In this first part of the interview with Woody, he tells us how kindness, consideration, and respect can transform any team into a fulfilling working experience. When you finish listening to the episode, connect with Woody on LinkedIn and Twitter, visit his website at www.woodyzuill.com, and check out his upcoming book No Estimates - How to Deliver Software Without Guesswork. You can read the transcript of the entire episode at https://kasperowski.com/podcast-72-woody-zuill/.

In what context was mob programming discovered? What were tech practices like before and after the discovery? What was the biggest personal challenge in the new way of working? How did the collaboration patterns change?  Who better to answer these questions than members from the original #MobProgramming team on the 10 year anniversary of the practice

Undoubtedly the pandemic has caused us all to make adjustments to at least "get by". However, is there more than adapting to "survive"? How about adapting to "thrive"? Come join Chris and Austin as they discuss with Christopher Gallivan and James Simon who share the inspiring story of several teams adapting to a Global Pandemic with #Collaboration, #Community, and #Joy. In addition, they share about the insights they gained from #MobPrograming with Woody Zuill and how they are striving to build the developer community. Listen and come join in on the joy! Video and show notes: https://youtu.be/KxHdQIShh0k 

https://www.leanblog.org/393Joining me for Episode #393 of the podcast is Woody Zuill, who does "Mob Programming workshops, talks and presentations on agile topics," and "coaches and guides folks interested in creating a wonderful workplace where people can excel in their work, and in their life."I had a chance to meet Woody last year when I saw him speak at an Agile conference and I really enjoyed his perspectives. Woody has also participated quite a bit in a "Lean Consultants Stuck at Home" group that I had organized earlier in the pandemic times.Topics today include "flow" in software development, the difference between "mob programming" and "paired programming," and the "no estimates movement" and why that is important. I hope you'll find this interesting even if you don't work in software. 

Woody Zuill is an Agile consultant, public speaker, and probably best known for creating Mob Programing. Check out the full show notes at TheAgileWire.com YouTube: https://youtu.be/1ZZgP31I-R4

Podcast: Play in new window | Download Many websites these days have to deal with the reality of incorporating third-party scripts. These could be tracking scripts or analytics or monitoring, or even scripts that add explicit features to a site, such as chat. Regardless of the purpose, such scripts add complexity and overhead, and can interfere with the proper operation of the site. In this episode Ben Vinegar, VP of engineering at Sentry, joins the panel to discuss the complexities and implications of third-party scripts, both from the perspective of website developers, as well as from the perspective of the developers creating such scripts. Sponsors Faithlife | Now Hiring Software Developers Raygun | Click here to get started on your free 14-day trial Audible.com CacheFly Panel AJ ONeal Aimee Knight Dan Shappir Charles Max Wood Special Guest Ben Vinegar Links ETAG Cookies https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements Picks Aimee https://github.com/hwayne/awesome-cold-showers AJ AJQuery v2.0 https://webinstall.dev/sd Dropbox Paper Woody Zuill on Mob Programming and Influencing Change | Healthy Developer Interview #4 Charles Max Wood Scythe https://www.thecreepyline.com/ Ben Vinegar https://workers.cloudflare.com Follow JavaScript Jabber on Twitter: @JSJabber

Podcast: Play in new window | Download Many websites these days have to deal with the reality of incorporating third-party scripts. These could be tracking scripts or analytics or monitoring, or even scripts that add explicit features to a site, such as chat. Regardless of the purpose, such scripts add complexity and overhead, and can interfere with the proper operation of the site. In this episode Ben Vinegar, VP of engineering at Sentry, joins the panel to discuss the complexities and implications of third-party scripts, both from the perspective of website developers, as well as from the perspective of the developers creating such scripts. Sponsors Faithlife | Now Hiring Software Developers Raygun | Click here to get started on your free 14-day trial Audible.com CacheFly Panel AJ ONeal Aimee Knight Dan Shappir Charles Max Wood Special Guest Ben Vinegar Links ETAG Cookies https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements Picks Aimee https://github.com/hwayne/awesome-cold-showers AJ AJQuery v2.0 https://webinstall.dev/sd Dropbox Paper Woody Zuill on Mob Programming and Influencing Change | Healthy Developer Interview #4 Charles Max Wood Scythe https://www.thecreepyline.com/ Ben Vinegar https://workers.cloudflare.com Follow JavaScript Jabber on Twitter: @JSJabber

Podcast: Play in new window | Download Many websites these days have to deal with the reality of incorporating third-party scripts. These could be tracking scripts or analytics or monitoring, or even scripts that add explicit features to a site, such as chat. Regardless of the purpose, such scripts add complexity and overhead, and can interfere with the proper operation of the site. In this episode Ben Vinegar, VP of engineering at Sentry, joins the panel to discuss the complexities and implications of third-party scripts, both from the perspective of website developers, as well as from the perspective of the developers creating such scripts. Sponsors Faithlife | Now Hiring Software Developers Raygun | Click here to get started on your free 14-day trial Audible.com CacheFly Panel AJ ONeal Aimee Knight Dan Shappir Charles Max Wood Special Guest Ben Vinegar Links ETAG Cookies https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements Picks Aimee https://github.com/hwayne/awesome-cold-showers AJ AJQuery v2.0 https://webinstall.dev/sd Dropbox Paper Woody Zuill on Mob Programming and Influencing Change | Healthy Developer Interview #4 Charles Max Wood Scythe https://www.thecreepyline.com/ Ben Vinegar https://workers.cloudflare.com Follow JavaScript Jabber on Twitter: @JSJabber

Our Legacy Code Rocks community is turning five this year. To mark this exciting milestone, we decided to catch up with Woody Zuill, our frequent guest, and a person who always manages to teach us something new and exciting. Woody is best known for introducing mob programming to the world, and so we kick-off the show by discussing mob programming in the age of COVID-19. However, as it is always with Woody, he expands our horizons far beyond any single topic. If you get inspired by this chat as much as we did, make sure to register for the series of Woody's public workshops, which will take place online from 20th to 22nd October.  Mentioned in this episode: Woody on Twitter at https://twitter.com/woodyzuill  Woody on LinkedIn at https://www.linkedin.com/in/woodyzuill/  Woody’s website at https://woodyzuill.com  Woody Zuill and Kevin Meadows, Mob Programming: A Whole Team Approach at https://leanpub.com/mobprogramming  Mob Programming Workshop 20-22 October 2020 tickets at https://www.eventbrite.it/e/mob-programming-online-workshop-tickets-115876980167?aff=erelpanelorg or https://allevents.in/online/mob-programming-online-workshop/10000115876980167  Graham Wallas, The Art of Thought at https://archive.org/details/theartofthought  Winston Royce, Managing the Development of Large Software Systems (Waterfall Paper) at http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf  Zeigarnick Effect at https://en.wikipedia.org/wiki/Zeigarnik_effect

On this episode of DevTalk I speak to Stacy Cashmore about improving your team through pair programming. Links: How to get the most from pairing Woody Zuill on Twitte

The Software Process and Measurement Cast 612 features a conversation with Woody Zuill and Allan Kelly on the topic of being an agile guide. I have felt that the term coach was overused for more than a few years. Woody and Allan put a voice to a topic that I started writing about earlier this summer describing the term 'agile guide'. Over the past 14 years, there have been a number of conversations that changed how I think and work.  This is certainly one of those gestalt moments.   Bios: Allan has pioneered techniques such as Value Poker, Time-Value Profiles, and Retrospective Dialogue Sheets. He is the author of seven books including "Continuous Digital", "Little Book of Requirements and User Stories" and his latest book is "Art of Agile Product Ownership." When not writing, Allan consults and coaches, helping companies embrace the agile and digital world, and teams to improve their performance. Links: Me: www.allankelly.net Blog: www.allankelly.net/blogRetrospective cards: www.dialoguesheets.comTwitter: https://twitter.com/allankellynet Woody Zuill has been programming computers for 30+ years. Woody is an independent freelance agile guide! He believes code must be simple, clean, and maintainable to realize the Agile promise of Responding to Change.  Contact Information Mob Programming: http://mobprogramming.org/ Blog: http://zuill.us/WoodyZuill/ Twitter: https://twitter.com/woodyzuill Re-Read Saturday News  This week we tackle two chapters in Steve Tendon and Daniel Doiron’s  Tame your Work Flow. Chapters ten and eleven put our understanding of workflow and process-flow into action in more complex environments. Remember to buy a copy of Tame your Work Flow to support the authors and blog!   Week 1: Logistics and Front Matter – https://bit.ly/2LWJ3EY Week 2: Prologue (The Story of Herbie) – https://bit.ly/3h4zmTi Week 3: Explicit Mental Models – https://bit.ly/2UJUZyN  Week 4: Flow Efficiency, Little’s Law and Economic Impact – https://bit.ly/2VrIhoL  Week 5: Flawed Mental Models – https://bit.ly/3eqj70m   Week 6: Where To Focus Improvement Efforts – https://bit.ly/2DTvOUN  Week 7: Introduction to Throughput Accounting and Culture – https://bit.ly/2DbhfLT  Week 8: Accounting F(r)iction and  Show Me the Money – https://bit.ly/2XmDuWu  Week 9: Constraints in the Work Flow and in the Work Process - https://bit.ly/33Uukoz  Week 10: Understanding PEST Environments and Finding the Constraint in PEST Environments - https://bit.ly/3ga3ew9  Next SPaMCAST The Software Process and Measurement Cast 613 will feature our essay on directive and non-directive coaching. It is not as straightforward a dichotomy as you would expect, but as a coach, you do need to pick a position.    We will also have a visit to the QA Corner.   

The Software Process and Measurement Cast 611 features our conversation with Jeff Smith. Jeff and I talked about his new book, Operational Anti-Patterns with DevOps Solutions. Our conversation branched out to cover DevOps and how writing a book changes your perception of life. The conversation was the most clear-eyed and penetrating conversation on DevOps I have had on the podcast. Jeff challenged all of us to recognize that we can make a difference. Bio: Jeff Smith has been in the technology industry for over 20 years, oscillating between management and individual contributor. Jeff currently serves as the Director of Production Operations for Centro, an advertising software company headquartered in Chicago, Illinois. Before that he served as the Manager of Site Reliability Engineering at Grubhub. Jeff is passionate about DevOps transformations in organizations large and small, with a particular interest in the psychological aspects of problems in companies. He lives in Chicago with his wife Stephanie and their two kids Ella and Xander. Jeff is currently writing a book Operational Anti-Patterns with DevOps Solutions with Manning publishing due out in Spring of 2020, but available now via their early access program. He’s also the chapter president of Blacks in Technology where he strives to introduce the community to the different opportunities in the technology field. Contact Information for Jeff Smith: Web:  http://www.allthingsdork.com/ Email: jeffery.d.smith@gmail.com Twitter: @darkandnerdy Re-Read Saturday News  This week we transition to Part 4: Maximizing Business Value in Knowledge-Work in Steve Tendon and Daniel Doiron’s  Tame your Work Flow. We are approximately 40% through according to the Kindle App on my laptop.  (Side note: I would like to talk with anyone in the audience that uses a Kindle to read non-fiction books that they will later use for reference; I am working on a buying decision). Remember to buy a copy of Tame your Work Flow to support the authors and blog!   Week 1: Logistics and Front Matter – https://bit.ly/2LWJ3EY Week 2: Prologue (The Story of Herbie) – https://bit.ly/3h4zmTi Week 3: Explicit Mental Models – https://bit.ly/2UJUZyN  Week 4: Flow Efficiency, Little’s Law and Economic Impact – https://bit.ly/2VrIhoL  Week 5: Flawed Mental Models – https://bit.ly/3eqj70m   Week 6: Where To Focus Improvement Efforts – https://bit.ly/2DTvOUN  Week 7: Introduction to Throughput Accounting and Culture – https://bit.ly/2DbhfLT  Week 8: Accounting F(r)iction and  Show Me the Money – https://bit.ly/2XmDuWu  Week 9: Constraints in the Work Flow and in the Work Process - https://bit.ly/33Uukoz  Next SPaMCAST The Software Process and Measurement Cast 612 will break pattern -- again. Recently I had a conversation with Allan Kelly and Woody Zuill about the topic of coaching and how if you bring all of your capabilities to the table you have transitioned to a guide. Allan and Woody are agile guides.

Chris and Austin celebrate the one year anniversary of The Mob Mentality Show with Woody Zuill (https://twitter.com/WoodyZuill) and discuss the essence of Mob Programming. Some including Austin have been confused about what people mean exactly when they say "Mob Programming?" Is it a set of practices? A set of values/principles? Something deeper? Something simpler? All of the above? Come join the discussion to find out! Video and show notes: https://youtu.be/OzGlpwPNv0Q  

Chris and Austin discuss "Facilitating Effective Remote Meetings" with Lynn Langit (https://twitter.com/lynnlangit), Paul Tevis (https://twitter.com/vigemus), Jason Kerney (https://twitter.com/JasonKerney), and Woody Zuill (https://twitter.com/WoodyZuill) using a lean coffee format (https://trello.com/c/zPLZ3YFq/128-lean-coffee). Topics in the lean coffee include "Ada roles," "why have meetings," "what is wrong with having meetings,"  "3 goal agenda," and "the importance of side conversations." Video and show notes: https://youtu.be/xr0STSbJ3PE 

We discuss with Woody Zuill (https://twitter.com/WoodyZuill) mob programming and what it takes to create an environment where great work is inevitable. Video and show notes: https://youtu.be/OpIa9liv3ew 

Five people at one computer? How can that possibly be productive? While this seems like a reasonable question, it's not easily answered - until we begin to understand the power of flow. In this episode, we talked with Woody Zuill about Mob Programming. Mob Programming grew from the quest of one team to learn how to work well together. Once started we almost immediately noticed that working this way provided better results in a variety of ways. Woody is being a programmer for the last 35 years and he is one of the originators of the Mob Programming. Accenture | SolutionsIQ’s Fabio Branquinho hosts this conversation with Woody at Agile Brazil 2019, in Belo Horizonte. The Agile Amped podcast is the shared voice of the Agile community, driven by compelling stories, passionate people, and innovative ideas. Together, we are advancing the impact of business agility. Podcast library: www.agileamped.com/br Connect with us on social media! 
 BR LinkedIn: linkedin.com/showcase/accenture-solutionsiq-brasil US Twitter: twitter.com/AgileAmped Facebook: facebook.com/agileamped Instagram: instagram.com/agileamped

Mob Programming with Chris S. Chris Spoehr, Performance Manager and Mob Programming Expert   Mob Programming Maxims The team I'm currently on has been trying mob programming for about 4 months now. Recently, I was privileged to attend the first Mob Programming Conference. At the conference, both Woody Zuill and Llewellyn Falco gave compelling keynotes. When I returned to work, my team and I wanted to get the most out of my insights and we quickly began talking about how to level up our mobbing. We came up with an idea to introduce a third designated, rotating role to our mob when it was large enough. (Our mob flexes in size from 3-6 people.) After driving, a mobster would take on the role of 'facilitator' to observe _how_ the mob was working, and coach the mob when needed. In order to define just what these collaborative ideals are, I compiled these Mob Programming Maxims from my conference notes and slides Woody and Llewellyn have posted online. There is some affinity grouping, but no importance in the ordering. The commentary under each maxim is my interpretation of the meaning and relevance of the maxim. * For an idea to go from someone’s head into the computer it must go through someone else’s hands. - Llewellyn Falco This critical mindset behind mob programming comes from Llwellyn's "Strong Style Pair Programming". Working this way forces us to communicate clearly and completely with our teammates. When we're doing this well, this communication is at an abstraction layer. It helps build a shared mental model of the code amongst everyone on the team. * Turn up the good – Woody Zuill This concept has such depth that it deserves blog posts of its own. The core idea is one of positivity: instead of potentially applying the wrong fix to the right problem or the right fix to the wrong problem, we take something we're doing well and focus on doing it even better. As we do this, a common side effect is removing base conditions that created an issue in the first place, and those issues 'fall away.' * Just try it. It’s in the doing that we learn. – Woody Zuill & Llewellyn Falco One of the strengths of the mob comes from the breadth of ideas that comes from having "all the brilliant people working on the same problem at the same time." Often we will need to discuss how to solve the next issue in front of us. When we do, we discuss it only long enough so everyone understands the different approaches we can take. We bias ourselves toward action. We stop short of debating the merits of each approach. Just code it. We see how each approach looks in code. Then, we decide on which approach to keep, or we may discover a third, better approach has emerged. * Ask for Trust – Llewellyn Falco We ask of each person in the mob that they trust we will try everyone's ideas in turn. This is especially vital in a newly formed mob where this trust hasn't been built through experience. Without this trust in place, thrashing can occur. This kind of trust is reinforced by following the "just try it" maxim. * Respect Each Other This is another way of saying we should treat each other with "kindness, consideration, and respect", as Woody and the team at Hunter agreed to do. We take the Retrospective Prime Directive to heart and assume our teammates are contributing their best. And we're also all people. Many of us developers might not consider ourselves great at soft-skills, but it doesn't take much to not be an asshole. * Respect The Code If we're working on existing code, we should apply the Retrospective Prime Directive to the code itself. It was the best code that could be written by those who wrote at the time they coded it. Even though we may know so much better now, belittling the code (and those who wrote it) doesn't move us forward. However, this doesn't mean not refactoring or rewriting the code. We do need to respect it enough to understand its intention. * Be prepared to contribute the right thing, at the right time, in the right way – Woody Zuill When we are in the mob, we should all be prepared to contribute. This may manifest through navigating or driving. It may also manifest through doing research as a navigator to look up the API documentation the mob needs. We are mobbing because we are all valuable to the work being done. We should commit our focus to that work. A key aspect of this maxim is to *resist over-contributing*. We must practice the art of not talking to allow space for others to contribute. Using the single-navigator style of mobbing, where only one team member at a time acts to navigate the driver, while the rest silently observe until their turn, helps to reinforce this skill. * Communicate so the driver understands * Intent * Location * Instruction As navigators, we want to communicate with our driver at the highest possible level of abstraction. We want to start by communicating the intent of what should be done next, "we need to call the backend to get a list of possible widgets." Only if the driver needs further explanation do we drop down to location, "On line 123 we have a service object that we can call." Lastly, we may sometimes need to give specific instructions to a particular driver, "On line 123, type: var widgets = service.getWidgets();." This may be needed for a new dev or even just new to the tech stack. * Once the driver understands intent, navigator(s) may move on. We trust that once our driver understands our intention, we as navigators can start talking about what's next. Getting good at working this way allows us to see the full benefits of the group's collective knowledge and collaboration. * Rotate as often as is beneficial We want to rotate often enough to keep everyone engaged in the work we're doing. We prefer shorter rotation times. In fact, the quicker the rotation time the better the mob has to be at switching. Short rotation times also encourage turning up the good on the other mob programming maxims. There is no one-size-fits-all rotation time. Through experimentation and talking to others at the Mob Programming Conference, our team has discovered that "everyone drives at least once per hour" is a fair heuristic. Our team even added to it to prefer 10 minutes or shorter rotations. * Take Breaks When mobbing its easy to not take breaks. We can get into a groove and lose track of time. Or we might think about taking a break but no one else seems to need one so we don't speak up. Part of keeping our workspace comfortable is making sure we take time to physically stretch and rest our minds. Don't be afraid to call for bio breaks. I hope having these Mob Programming Maxims consolidated in one place helps your mobbing. I look forward to continuing this conversation as we discover more about this new way of working.

Episódio especial do Agile Brazil! Hoje o agile guide e coaching Woody Zuil vai falar um pouco sobre a importância do lean! Confira agora! Mande a sua pergunta/dúvida por áudio ou escrito para o Whatsapp 31 996977104 ou no email osagilistas@dtidigital.com.br que responderemos no programa!

Woody took us all the way back to the 70s, when he started learning programming as a side activity. He described how he learned to scratch his own itch for almost 15 years before finally making the jump to become a "professional developer". We talked about the jump itself, the imposter syndrome attached and how he overcame it. We talked about how he discovered pair-programming and eXtreme Programming. We finally devised on improving programming practices, coaching and working on systems.Woody Zuill is an independent Agile and Lean Guide and has been programming computers for more than 35 years. He is an originator and pioneer of the Mob Programming approach to teamwork in software development, and is considered one of the founders of the "#NoEstimates" discussion on Twitter. His passion is to work with teams to create an environment where every one of us can excel in our work and life.Here are the links of the show:https://www.twitter.com/WoodyZuillwoody@woodyzuill.comhttps://woodyzuill.comGoto Berlin Conference: https://gotober.com"Nobody Ever Gets Credit for Fixing Problems that Never Happened" (Repenning, N. and J. Sterman): http://web.mit.edu/nelsonr/www/CMR_Getting_Quality_v1.0.htmlCreditsMusic Aye by Yung Kartz is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.Your hostSoftware Developer‘s Journey is hosted and produced by Timothée (Tim) Bourguignon, a crazy frenchman living in Germany who dedicated his life to helping others learn & grow. More about him at timbourguignon.fr.Want to be next?Do you know anyone who should be on the podcast? Do you want to be next? Drop me a line: info@devjourney.info or via Twitter @timothep.Gift the podcast a ratingPlease do me and your fellow listeners a favor by spreading the good word about this podcast. And please leave a rating (excellent of course) on the major podcasting platforms, this is the best way to increase the visibility of the podcast:Apple PodcastsStitcherGoogle PlayThanks!Support the show (http://bit.ly/2yBfySB)

話したこと Agile 2019 Conference Washington D.C. について @kawaguti @martin_lover_se に話していただきました 感想や 質問、こんな話をして欲しい、などをぜひ #omoiyarifm までお願いします！ Agile 2019 Conference - Washington D.C. Global Scrum Gathering Vienna 2019 周辺地理の話 流行っていたテーマがあった？ 印象に残っているセッションは？ How to facilitate a Mob Programming session as a coach? (Woody Zuill) The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done Mapping The Enterprise Agile Journey (Stephen Denning) How to Change the World 〜チェンジ・マネジメント3.0〜 HARADA Kiro (@haradakiro) / Twitter 非公式モブプロ David Bernstein (@ToBeAgile) / Twitter Llewellyn Falco (@LlewellynFalco) / Twitter クリス Chris Lucian (@ChristophLucian) / Twitter Mob Mentality Show - YouTube モブプロの聖地 Hunter Industries で学んだこと - kawaguti's diary How to Manage Your Attention in a World of Distraction ish: The Problem with our Pursuit for Perfection Playful Leadership: Enable Transformational Change Fun Done Learn at Agile 2019 Lightning Talks - Speaker Deck Scrum does not work here in Asia - Joshua 스크람 Partogi - Medium Running Mob Programming - How we made our team x 4 faster! - Speaker Deck Mobster Joshua Kerievsky (@JoshuaKerievsky) / Twitter Modern Agile 情熱を保つ Agile Conference に友達に会いに行く Regional Scrum Gathering Tokyo 2020 Agile Open Initiative - Agile Alliance 区切りに学校のチャイムを使う アギレルゴ　アジャイル研修 A Scrum Book: The Spirit of the Game スクラムフェス札幌 スクラムフェス大阪 - Scrum Fest Osaka 2019 Agile Leadership Summit 2019 サテライト｜AgileJapan2019 米Target社の受入型集合研修(Dojo)でのモブプログラミングとDevOps - kawaguti's diary

Last week, the biggest conference in the Agile industry took place in Washington DC at the Gaylord National Resort & Convention Center. We were proud to be a sponsor of this event and we were even more excited about catching up with friends—both old and new. For those of you who couldn't make it to the conference, we wanted to give you a little taste of what it's all about, so we decided to live-stream our podcast out of our booth in the Prince George Exhibitor Hall. We had a chance to talk to a lot of really smart and interesting people while we were there; some who were speaking at the conference, others who were simply attending, and even a few who were involved in turning this event into a reality. Here are some of the highlights from day two. In this live talk, we’re chatting with Woody Zuill about Mob programming. We’ll discuss the problems it solves, who can do it, and how it works.

Recorded at Øredev 2018, Fredrik talks to Judy Rees. We start from Judy’s presentation Getting them to get it and discuss the challenges of really listening, communication, and the how the clean language technique can help you both understand others better, and get your own ideas across better as well. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Øredev 2018 Judy Rees Judy’s presentations at Øredev 2018 - Getting them to get it, and Overcoming the difficulties of remote meetings Clean language Woody Zuill Judy on Youtube Olaf Lewitz Chris Voss Never split the difference - Chris' book David Grove - discoverer(?) of clean language Teletext Arrival Caitlin Walker Penny Tompkins and James Lawley cleanlanguage.co.uk learncleanlanguage.com Titles I would present you as a Jedi master Jedi mistress A master listener As a result of paying attention Listening has such a low status in the world Don’t talk and don’t think about talking It’s against our programming to pay complete attention Paying attention is an active pursuit A question is a much more precise tool The nearest thing the FBI have to a Jedi mind trick The tools to reason about conversation See through the leaves Enabling them to heal themselves It’s designed for use with humans People are really rubbish at saying what they want in all kinds of domains of their lives Humanity is currently the limit The modeling brain Their model of David’s model

Scott Nimrod is an experienced Software Consultant based out of Miami who specializes in Test Automation, WPF, Functional Programming, and a variety of other technologies.  In this interview, Scott and I discuss the balance between strengthening your reputation through your personal brand as a developer, and the teamwork necessary to be successful in your career.  We also touch on concepts in the interview with Woody Zuill about mob programming and the "noestimates" movement.  Scott also runs a YouTube channel with great interviews and live programming exercises.  You can also watch this episode on YouTube.  Related resources: Woody Zuill on Mob Programming and Influencing Change How Agile Teams Grow Toxic! Ep. 4 Commitments Scott Nimrod on Consulting and Software Craftsmanship How to Disagree With Your Manager Respectfully How Agile Teams Grow Toxic! Ep. 3 Forecasting   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Today I have a special guest, Woody Zuill, who's one of the leading voices in our industry around the concept of Mob Programming.  If this is the first time you've heard of it, Mob Programming is essentially an entire team working together with only one person's hands on the keyboard.  There are some surprising advantages to this approach that you may not have encountered before.  Follow Woody on twitter at https://twitter.com/woodyzuill. Watch the video and access resources related to this episode on my website: https://bit.ly/2RQLOeB

Fredrik talks to Woody Zuill, writer of the book on mob programming, facilitator of happy teams and thoughtful teller of stories. Woody talks about how he and his team discovered mob programming, how it is evolving, how focusing on the good is the way forward, and how he may have aquired his mindset. Recorded on-stage at Øredev 2018. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! Links Øredev 2018 Woody Zuill Mob programming Turn up the good - Woody’s presentation at Øredev 2018 No estimates Test-driven development Hunter industries Llewellyn Falco Pair programming Agile alliance George Dinwddie Ron Jeffries Repenning, N. and J. Sterman: Nobody ever gets credit for solving problems that didn’t happen Horticulture Titles I think of myself as a software developer Trying to make a better work environment I don’t believe we can manage people This time of year seven years ago Purely by accident Sitting and thinking at the keyboard alone One member who’s not there Five or six people programming Opening different doors If you open a door, there’s a good chance somebody will welcome you in Superconnectors One of those connector things Oddly, it is working for us Purposeful stumbling I stopped looking for solutions to problems A habit we need to build I just went ahead and did it I’ll discover stuff if I just try it We follow the path that develops in front of us Your job is very important He was extending trust to me These things are not related A gentle way to think about our lives

Fredrik talks to Woody Zuill, writer of the book on mob programming, facilitator of happy teams and thoughtful teller of stories. Woody talks about how he and his team discovered mob programming, how it is evolving, how focusing on the good is the way forward, and how he may have aquired his mindset. Recorded on-stage at Øredev 2018. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @iskrig and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! Links Øredev 2018 Woody Zuill Mob programming Turn up the good - Woody’s presentation at Øredev 2018 No estimates Test-driven development Hunter industries Llewellyn Falco Pair programming Agile alliance George Dinwddie Ron Jeffries Repenning, N. and J. Sterman: Nobody ever gets credit for solving problems that didn’t happen Horticulture Titles I think of myself as a software developer Trying to make a better work environment I don’t believe we can manage people This time of year seven years ago Purely by accident Sitting and thinking at the keyboard alone One member who’s not there Five or six people programming Opening different doors If you open a door, there’s a good chance somebody will welcome you in Superconnectors One of those connector things Oddly, it is working for us Purposeful stumbling I stopped looking for solutions to problems A habit we need to build I just went ahead and did it I’ll discover stuff if I just try it We follow the path that develops in front of us Your job is very important He was extending trust to me These things are not related A gentle way to think about our lives

In this episode of Tech Career Talk, we explore Mob Programming. We answer three questions. What is it? Why we should try it? How do we do it? Link to Woody Zuill's talk: https://www.youtube.com/watch?v=SHOVVnRB4h0 --- Support this podcast: https://anchor.fm/tom-henricksen/support

Craig and Tony are at YOW! Conference in Brisbane and wander around the hallways talking to different speakers and some attendees and volunteers: Woody Zuill and Paul Rayner – Beer Driven Development (the other BDD), Woody’s talk “Mob Programming, A Whole Team Approach” talk and Paul’s “EventStorming – Collaborative Learning for Complex Domains” talk, the … Continue reading →

Guest: Dillon Kearns: @dillontkearns | GitHub | Incremental Elm In this episode, Dillon Kearns joins the show to talk about techniques for experimentation with Elm, making those experiments safe, the concept of mob programming, why you would want to experiment with Elm in the first place, and how you too can begin to experiment with Elm. Resources: Grant Maki's talk on experimenting in your team "Types Without Borders" by Dillon Kearns @ Elm Conf 2018 Dillon's Elm GraphQL library How Elm Code Tends Towards Simplicity by Dillon Kearns The CSS as ByteCode Talk by Richard Feldman This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 114. My name is Charles Lowell. I'm a developer here at the Frontside. With me today as co-host on the show is David. Hello, David. DAVID: Hey, guys. CHARLES: David is also a developer here at Frontside and we are going to be talking about something that we've been talking, I guess a lot about recently and we're talking about Elm. I think we first started talking about this several years ago and then it kind of simmer down a little bit but recently, it's been top of tongue. With us to talk about Elm today is Dillon Kearns. Welcome Dillon. DILLON: Thank you so much for having me. CHARLES: I understand that you are a full time Elm consultant. You have a background as a Lean and Agile coach but have recently transitioned to doing Elm consulting full time. Now, what exactly does that mean in 2018 to be an Elm consultant. DILLON: Actually a lot of my motivation for getting into Elm consulting in the first place is I kind of realize that Elm to me is just an extension of the things that I was passionate about with Agile and software craftsmanship. I'm trying to help teams have a better experience with their code, make it more maintainable, make it easier to change, make it easier to drive things based on customer feedback and I really believe that Elm helps people do that. I used a lot of the background and experiences that I've had with Agile and Lean coaching and a lot of those same skills, in order to help organizations adopt Elm. One thing I've seen a lot of teams struggling with is trying out a lot of different frameworks. I've encountered teams that have spent months, very painfully trying out different frontend frameworks and having trouble coming to consensus about that. One of the things that I think really helps address that is having an experimental and iterative approach, that you can really use the scientific method to focus on learning, rather than getting it right the first time. I think that there's really a need to help teams through that process of introducing a new frontend framework like Elm, so that that's why I've gone into full time Elm consulting. CHARLES: That's an interesting process. It sounds like you really need to be constantly sending out spikes, doing research on whether it's Elm or some other technology to help you kind of bridge the chasm to the next generation. How do you actually do that as an organization? My guess, this kind of a question independent of Elm but maybe we can talk about how you see that play out in the context of Elm. DILLON: Right and actually, for any listeners interested in that question, I would really highly recommend Grant Maki's ElmConf talk from this year. He spoke about exactly that topic and it was at ElmConf that it's relevant whether your team is considering Elm or looking at other frameworks. I think that the key is you need to get good at experimenting in a way that's low risk and in a way that you can be constantly learning and seeing how these different technologies fit in your codebase and fit for your team. There's a quote that I really like from Woody Zuill. Have you guys heard of mob programming before? CHARLES: I heard of mob programming from a paper by Richard Garfield a long, long time ago, almost 20... I don't know if it's the same concept. DILLON: Yes. It gained a lot of momentum these days. Mob programming is essentially pair programming but with more people involved. I've really enjoyed that process actually. I think it's actually a great way to experiment with different technologies because you get all of the minds together and it's a very good way to kind of transfer knowledge and explore things together but Woody Zuill talks about mob programming and he likes to ask the question, "Why did we begin doing mob programming for the team at Hunter Industries that originally started mob programming?" People would give answers like, "Because it cuts out code review from the process because you have lots of eyeballs on it in real time," or, "Because it reduces bugs," or, "Because it gives you better quality code. It gives all the best ideas into the product in real time," and all those things are valid points that are really good benefits of mob programming. But he says those things may be true but actually, they're not why we tried mob programming. The reason we tried mob programming was because the team wanted to try it. That's a really important point. The team needs to be experimenting with things that they're passionate about and they need to be exploring things on their own terms. But with that said, another lesson from that story of kind of his team at Hunter Industries discovering mob programming is that the team didn't discover mob programming in a vacuum. Really, the team discovered mob programming because the team became really excellent at experimenting and evaluating those experiments and then, they like to talk about this phrase that Kent Beck coined, 'turn up the good.' When something is working well, we often focus on the negative things and trying to eliminate those things but what happens if we take the things that are working well and 'turn that dial up to 11.' CHARLES: Yeah, I love that. I remember in the kind of the original layout of extreme programming, talking about how I really just wanted to turn up all the things that were working for 11 or to 11, so testing, refactoring, incremental releases and things like that. DILLON: Exactly. CHARLES: I actually had one question that's maybe a little bit of a diversion. This is actually the first time I've heard of mob programming. It's definitely not the same sort of mob programming I learned about in Richard Garfield's paper. I think it was more referring to massively distributed open source in the form which is really kind of commonplace now that happens on GitHub. I think it's maybe, an obsolete definition of mob programming but how many people would be in a mob like two, three, four, five, six, seven, 10? DILLON: That's a great question. Really, the answer is of course, it depends. That's a consultant's favorite answer but it really does. My rule of thumb is I find it usually three people is a very nice size for a mob. I find that mobs tend towards around three or four people but that being said, it's important to note that mob programming is all about this idea that what is the true cost of programming. I think that often we look at programming as the act of writing code, initially and that's a very limited way of looking at coding. Because of course, 90% of our effort is spent maintaining code, making decisions around code, reproducing bugs, fixing bugs, communicating with customers about bugs -- bugs are extremely expensive -- the farther out they get, until eventually they get to the point of a customer discovering them, bugs are in extremely expensive part of software. If we can minimize bugs, that's very valuable. When you look at programming on this bigger scale and look at the bigger picture of programming, then you realize that you may be able to get one person to write the code faster but then, that person needs to code review it. That person needs to go and ask somebody question down the line when they don't have context because they weren't involved in the decision making. For example, maybe there's a UX person who doesn't have context on certain choices that were made, so there's a lot of churn, so you can kind of eliminate that churn by getting all the relevant people involved right away and that's the idea. In my experience with mob programming, it works really well to keep kind of a core of around three people. Sometimes, somebody goes up to have a conversation with somebody, take a break or answer somebody's question, maybe somebody from another team has a question that type of thing and so, the team can keep coding as a pair or whatever. But ultimately, the idea is that you get faster because you're building up this shared context and you're not spending as much time down the line answering questions, doing code reviews and things like that. CHARLES: Right. I see. DAVID: That kind of matches with my experience. Mob programming on previous teams, the way we had it set up is there was a regular mob programming chat session that the whole team was invited to but it was optional. You can just show up if you wanted to and really, that sort of made it so that there was a set of people who regularly attend -- three to five people in a session -- and they were the core group, essentially. DILLON: Right. That's another great point. Invitation is a powerful technique. If you're kind of mandating the people try an experiment or work in a certain way, ultimately it's much more powerful to let the team experiment on their own and follow their passion and they'll discover great things. It's about experimenting, rather than choosing specific experiments. While we're on this topic of kind of the real cost of coding, I think this is a good point to talk about this quality in Elm because, I think that this is one of the things that really motivates me to use Elm myself and introduce it to others is that, I think that Elm really get something about programming where there's a sort of superficial ease of certain techniques that Elm kind of goes beyond and says, "Actually, let's optimize for a different set of things that we think make code more maintainable and more delightful to work with in the long run." CHARLES: I wanted to also transition between, we were on a little diversions on mob programming but do you use mob programming as explicit technique for introducing Elm when a team is considering adopting it? DILLON: That's a fantastic question. I absolutely do. Of course, I honor the ways of working in a particular organization or team. I think that's important to do but I do strongly encourage using mobbing as a technique for knowledge sharing and when I'm on-site with a client, I find it extremely powerful as a technique for knowledge sharing and also, let's say you do an experiment, somebody is off in a corner and they're trying out Vue.js or they're trying out Elm or they're trying a particular coding technique. Then they come back to their team and they say, "Hey everybody, I tried this great thing," and now they have to spend this time convincing everybody and saying like, "Wait a minute. You didn't try this, you didn't try it that way. It wouldn't actually work in our context because of this." I think that it's very powerful to have everybody kind of involved in that process so that you can evaluate it together as a team. CHARLES: Because the thing is like, when you experience win or you experience fail, it's a very visceral feeling and that's the thing that sells you or turns you away. You can argue until you're blue in the face but words have a very limited capacity to convince, especially when compared with like physical and emotional feeling. It sounds like you can get everybody to have that shared experience, whether for the good or for the bad, you're going to arrive at a decision, orders of magnitude more quickly. They have to rely in conviction of that decision spread around the team. DILLON: Exactly. I think that hits the nail on the head and you say that we have this sort of skepticism of arguments from theoretical conversations, rather than 'show me the money,' but it's actually, try solving a real problem in this and that's exactly as it should be. I think that's one of the big antidote from this problem that I've seen in a lot of environments, where there's this analysis paralysis, especially with the state of the JavaScript ecosystem these days. I think that one of the keys to improving that situation is to get good at trying things, rather than theorizing about things. We have a tendency to want to theorize and when we do that, then we say, "Can it solve this problem? Can it solve this problem? Can it solve that problem?" You can talk about that until the cows come home but it doesn't get you anywhere and it doesn't really convince anybody of anything. The key is to find very small experiments and what I really recommend and what I'm dead focused on when I'm initially working with a client is getting something into production. Now, that doesn't mean that you need to have a road map for turning your entire application into Elm. In fact that's the whole point, is that you're not trying to do that. The point is you're trying to get as realistic of an experience as possible for what problems might occur if we do this? Will the team enjoy working with this language? Will it work well with our built pipeline? Will there be any unforeseen issues? You don't know until you actually try it, so you've got to try it and you've got to try it in tiny, tiny steps and low risk experiments. CHARLES: Right but you've got to try it for real. You don't want to try it with a TodoMVC. DILLON: Exactly. It needs to be meaningful, to really have a good understanding of what it's going to be like. CHARLES: I would say that I tend to agree but I've definitely encountered the counterargument and I also think this counterargument makes sense or perhaps where the pushback lies is if I'm constantly experimenting, then what I'm doing is I'm internally fragmenting my ecosystem and there is power in similarity. Any time you introduce something different, any time you introduce one fragment, you're introducing complexity -- a mental complexity -- like maybe I have to maintain my Elm app and I also have to have my Legacy... Or not Legacy, I've got my other JavaScript tool kit that does it in one way. Maybe I've got a couple of more because I've run these other experiments. I'm not saying that there is one way but there is power in uniformity. There is power in diversity. Where do you find the balance? DILLON: Those are all excellent points. To me, I think really the key is it's about the scientific method, you could say. The thing with the scientific method is that we often forget the last part. We get really good at hypothesizing about things. Sometimes people leave it at that, which we kind of just discussed. Sometimes, people go past the hypothesizing stage and they actually run the experiment and that's great. But then, the majority of people, if they get to that point, will forget to do the last step which is to evaluate the results. I think the key here is you need to be experimenting and this is what it means for it to be a low risk experiment. It means that you're not setting yourself off in a direction where you can't turn back. You want to set it up in such a way that you can turn away from it with minimal cost. One of the things that is really helpful for that is if you build a tiny, independent, little widget in your application, try building that in Elm. Some people will do that with a little sort of login badge in the corner of their application. One of the teams where I've introduced Elm at a Fortune 10 company, actually where we introduced Elm, we started out with just a tiny little table in one page and if we wanted to back that out, it would have been trivially easy but we decided that we wanted to go in further and invest more. CHARLES: That makes a lot of sense. Effectively, you need to have a Plan B. Don't sync all of the available time that you have to invest in an experiment. Make sure that you have a Plan B and if you need to do this widget or this table in Angular or React or Ember or whatever, you are thinking about that -- how would that work. DILLON: Exactly and the thing with experiments is the purpose of an experiment is not to build something. It's to learn. I really like this kind of ethos of lean startup, which I think is really getting much more into the mainstream in the software industry, which is a wonderful thing. The idea of lean startup, the kind of core concept is this idea of validated learning. Basically, in an environment where there's uncertainty, which is pretty much most of the things you're doing in software, the main goal is you're not shipping a product like you would be if you're trying to manufacture cars as quickly as possible. The main thing that you're producing is what they call 'validated learning' and so, you want to minimize the amount of time it takes to validate or invalidate your assumptions about something and then, you want to make it as cheap as possible to move on from that. CHARLES: I like that. So if you're going to organize your development process around this principle or maybe not organize it but integrate it into development process, how do you know that you're conducting a healthy number of experiments, versus I may be conducting too many experiments? Is there a metric that you can look at? We need to have this many experiments running at all times or this is just too many or something else. DILLON: That's a really interesting question. I think I would tend to think about that more again, as looking at the way the experiments are run, rather than 'are there too many experiments?' That's just not a problem that I've seen there being too many experiments. The pain that we tend to really see in environments where experiments are hurting teams is the way the experiments are being done. It's hard to backtrack from those experiments and as you were saying before, you kind of put yourself down this path where you can't walk it back and you create this sort of rift in the way the code is being written, which makes it more difficult to work in that codebase. The thing with experiments is they can have really big payoff. Now, you want to make sure that you're not just going in and picking up every shiny object that you see. One thing that can keep you honest with that is if you're kind of coming up with a hypothesis before you start. If you're saying, "This is the value to our business and to our team if we attempt this thing and this is what will prove that it seems to have that value and this is what will tell us, 'Actually, it doesn't have that value and we should drop it and cut our losses.'" CHARLES: That's a great heuristic. As you're saying and imagining how that might have saved my bacon in the past because I've definitely made the mistake of playing with too many shiny objects and picking things because I didn't fully evaluate what I thought the value. I was explicit with myself about what is the value that is going to bring to this project or this business. I have a theory about it but I am not thinking what is my hypothesis and how am I going to validate or invalidate? I'm thinking, I've got a short term pain that I'm experiencing and I'm grasping for this thing, which I think will solve it and I'm not properly evaluating how it's going to affect me long term. DILLON: Right and that could be a great team practice to play around with is often, teams will kind of come up with action items out of retrospectives. One thing that I think can be really beneficial for teams is to kind of flip that notion of doing action items which again, it's really just doing the middle part of the experiment where you're conducting the test but you cut out the hypothesis part and the evaluation part. Try to bring that into your team's retrospective and try to have explicit hypotheses in the retrospectives and then, in the next retrospective, evaluate the results. CHARLES: All right. I will definitely keep that in mind but this feels like a fresh take on kind of how you manage software development that I haven't encountered too much, being more scientific about it. It sounds like science-oriented development. DILLON: Right. DAVID: I like that. DILLON: There are a lot of buzzwords these days in software development, in general and it's really becoming a problem, I think in the Agile community but really, what it boils down to is these basic elements and basing decisions on feedback is one of those fundamental unit. You can call the scientific method, you can call it lean startup and validated learning, you can call it agile, you can call it whatever you want but ultimately, you need to be basing things on feedback. I think of it almost like our nerves. There's actually a disorder that some people have, which can be fatal, which is that their nerves don't tell them when they're feeling pain. I think this is a great analogy for software because that can happen to companies too. They don't feel the pain of certain decisions not landing well. Because they're not getting feedback from users, they're not getting feedback from metrics and recording, they're not getting feedback from doing that final evaluation step of their experiments, so when you fall on the ground, a small cut could be extremely harmful because you don't know the damage it's doing to you. CHARLES: I think that is a good analogy. One of the things that I'm curious about is we've been discussing a lot of techniques for experimentation and how you can integrate that into your process and how you can make your experiments safe, so let's talk a little bit about -- first of all, two things -- why would I want to experiment with Elm in the first place? Because ultimately, that's why we're here and why we're having this conversation. What's compelling about it that would make me want to experiment? And then how can I begin to experiment with Elm? DILLON: I actually just published a blog post yesterday. It's called 'How Elm Code Tends Towards Simplicity.' To your question of why would a team consider Elm, I kind of talk a little bit in this blog post about a case study at a Fortune 10 company where I introduced Elm to a few of the teams there. One of the teams there, we had actually seen an Angular project that they had worked on and often, in an enterprise environment, you have projects moving from one team to another. I actually had my hands on this Angular project. It kind of moved over to another team and we were experiencing some major pain trying to make changes in this codebase. Even making the simplest change, we were finding that there were a lot of bugs that would be introduced because there's some global variable. There's some implicit state. Sometimes, it was even reaching in and tweaking the DOM and really, the topic of conversation at our team lunches was how afraid we were to touch this codebase. Fast forward a few months and this team was asking my advice on picking a new frontend framework and I introduced them to Elm. They took a run with it and it was pretty remarkable to see this same team that had really struggled with AngularJS and they didn't really have a strong sense of what were the best practices. They weren't getting any guidance from the framework itself and the tooling around it and they actually loved the experience of working with Elm because they were saying, "This is amazing. Maybe it takes a little time to figure out how to solve a particular problem on Elm but once we do, we know that we've done it in a solid way." One of the things that I think is most powerful about Elm is that it keeps you from shooting yourself in the foot. I think that's a really good headline kind of summary of what I love about Elm. For example, tweaking the DOM. Now, it might seem like a pretty obvious thing that we just won't tweak the DOM and that's fair enough. That might not be a problem for a lot of teams. People wouldn't even reach for that technique because they're disciplined about it. But at a certain point, you start taking on enough things and then go from kind of those basic things that are going to make your code more unreliable and unsafe like tweaking the DOM and you start getting into the realm of best practices. There's so much discussion these days in the JavaScript community about best practices, which is great. It's great to discuss that but my concern is that there's a new best practice each week and the team has to agree on it, you have to find techniques for enforcing it, people have to make sure that these best practices are being followed in code reviews. Then when you look at a given piece of code, you have to trust that those best practices are being followed, so it requires a lot of work to make sure, in your reducers, in redux that you are not mutating anything. With Elm, data is just immutable. That's just how it is. There are a lot of these kind of things that are baked into the language and the expressivity of the type system allows you to bake in your own constraints. One of the things that I find really compelling about Elm is its design really prevents you from shooting yourself in the foot and it gives you tools for making sure that you take it even a step further and it helps you enforce these best practices at a compiler level. CHARLES: Now what's interesting here is it's almost like the opposite tension of experimentation is a work, right? like here, we have an example of uniformity being the more powerful track but then inside the actual macroscopic process, you want a lot of experimentation and diversity. But at the microscopic level, inside your application, it sounds like you want less experimentation and you derive a lot of strength from that but -- DILLON: That's a great point. CHARLES: -- Experiments that are possible, yeah. DILLON: I think that there is a lot of pain these days in the JavaScript community. We hear people talking often about JavaScript fatigue and it's a real thing. It takes a lot of work to stay on top of the latest best practices and frameworks and that can be a lot of fun. I love learning about the latest new frameworks and tooling but ultimately as you're saying, we don't want that experimentation so much about the fundamentals. We want some dependable, solid fundamentals and then we want the experimentation to happen within there. I think that's exactly what we see in the Elm ecosystem. We have a single kind of data store or way of managing state in Elm. It's called the Elm Architecture. In fact, it's what Redux is based on and it worked extremely well and you don't have to experiment with different data stores in Elm because that's just what Elm code looks like. Now, if you want to experiment in Elm, then there is a lot of innovation happening. One of my favorite things about Elm is that the compiler and its expressiveness has sparked a lot of creativity. One of my favorite things about Elm is the library called Elm UI. Actually, a client that I'm working with right now, it's a really interesting case study. They are kind of a very small startup. They just kind of branched off of a larger startup. They're building some tooling for this ecosystem. They were engineers at a company called Procore that does cloud document management for construction companies. They wanted to get a product-ready for a big conference for their potential clients. The reason they brought me in to help them was because they wanted to reach this ambitious target of being able to do a demo of this brand new product at this conference and they wanted to iterate very quickly. One of the things that really drew them into Elm in the first place is this library Elm UI. Elm UI essentially, Richard Feldman gives a talk on it, where he uses the analogy of it being treating CSS and HTML as bytecode for your views. I think that's a really apt way to put it. If you break down this idea of CSS -- Cascading Style Sheets, it removes the cascading part of CSS and it removes the sheets part of CSS. What you're left with is a way of expressing style and it's a way of expressing style that is able to part ways with all of the baggage of the entire history of backwards compatible decisions that CSS has ever made. If you want to vertically aligned something, then you just say, "Align vertically," you know, center vertically. If you want to center something horizontally, you say center X. It creates a high level language for expressing views. My experience with Elm UI, this may not be the right choice for every team but I love it. I use it on all of the projects that I maintain personally. I love using it because it gives you that same sense of invincibility refactoring that you get with Elm, which is remarkable that you could have that feeling with managing views. CHARLES: It's definitely something that feels like a dark art and it can't be called science. It's an art. It's a science for some people but it's historically been a dark art and something fiddly to work with. In terms of being able to make the experiment with Elm, when we talked a little bit about why you might want to experiment with it in the first place, what the business case is, I guess my next question is or a question that immediately comes to mind is supposing that we have decided to experiment with this, how do you mitigate that experiment? We talked about lowering the cost, having a way to turn away from it, having a way to make it inexpensive. For example, one of the things that I think of when evaluating a new technology is how well can I use it with old technologies. I have a lot about best practices in my tool bag. We all do. We got our all favorite libraries and pathways that are just familiar to us. One of the things that I've noticed is when adopting a new technology, one of the things that makes it easy to experiment with is how well it works with the existing technologies. I know that, we talked about Elm UI, kind of rethinking style in CSS and your views and Elm itself as a completely different language within JavaScript, that can be both liberating but it can also be limiting in the sense that I can't reach back for my existing tool if no tool exists in this new space. The kind of experience that I've had where this is really worked is systems like JRuby or Clojure, where there's a very clear pathway to be able to use Java libraries from those environments, so you always have kind of an escape hatch. What's that like in Elm? DILLON: This is a really interesting conversation because it highlights, in some ways some of the most defining features of Elm. In terms of how do you kind of pull Elm into an existing application, there are a lot of different techniques for that. It's pretty straightforward to create a little Elm app. We usually don't call them components for reasons that we can get into if we want to but that's a whole can of worms. But if you've got a little Elm application that you want to use to render a widget on your page, then it's as simple as just calling Elm.yourmodule.init and rendering it onto the page there. That's quite straightforward and if you want to interface with your existing code there are several ways to do that. There's something called port in Elm, which is how you kind of communicate by sending these messages and data back and forth between your Elm app and JavaScript. Now, this is one of the decisions, I think that defines Elm as the language and the reason this is important is because Elm decided not to make the choice that a lot of other compile to JS languages do. For example, if you look at ReasonML or PureScript or a more extreme example, TypeScript. TypeScript is a superset of JavaScript, so it's trying to allow you to gradually introduce this to get some incremental improvements for your JavaScript code, so it's extremely easy to experiment with it, which we've talked about the importance of experimentation. Now, the challenge with this technique, the tradeoff here is it's great, that it then becomes very easy to transition into it and that's an excellent strategy for the goals of TypeScript. Elm has a different set of goals, so the things that elm is focused on giving you is a truly type-safe experience. When you're working with Elm, if your Elm code says that this data is a float, then it is a float. Either, it is a float or that code is not being run and so, that's very different than the experience in TypeScript where you have these escape hatches. This is an inevitable choice for any compiled to JS language. Are you going to have escape hatches or not? Elm is really the only language out there, I think that chooses not to have escape hatches and that is actually the thing that that I love about the language because that's the only way you can truly have guarantees, rather than, "Yeah, I'm pretty sure that these type guarantees hold." DAVID: Yeah, wishes and dreams. DILLON: Yeah. CHARLES: What does it mean to have no escape hatches? because you talked about ports. Does it mean like it's impossible to use an external JavaScript library? DILLON: That's an excellent question. You absolutely can use JavaScript libraries. It means that it's being explicit and upfront about the fact that there's uncertainty in these areas. That's what it comes down to. Take for example dealing with JSON. In a JavaScript application, what we get when we're dealing with JSON is you make a request up to the server, you have some callback that passes in the data you get back and then you start pulling bits and pieces off of it and you say 'response.users subzero.firstname' and you hope that none of those things are null, none of those types are different than what you expected. In a way, it's kind of letting you pretend that you have certainty there when in fact, you don't and with Elm, the approach is quite different. You have to explicitly say, "I expect my response to have this shape. I expect it to be a list of things, which have a first name and last name which are strings," and then Elm says, "Okay, great. I'm going to check your assumptions," and if you're right, then here you go and you're in a well typed-space where you know exactly what the types are and if you're wrong, then that's just another type of data, so it's just a case statement where you say, "If my assumptions were correct, then do something and if my assumptions were incorrect, then you decide what to do from there." CHARLES: Right. For me, it sounds like there is some way because ultimately, I'm going to be getting unstructured but I'm going to be getting JSON back from the server and maybe, I have some library that's going to be doing that for me and enhancing it and adding value to that JSON in some way. But then at some point, I can present it to Elm but what you just saying is I need to be complete in making sure that I handle each case. I need to do or handle the case. Explicit about saying if the assumptions that Elm wants to make, turn out to not be true, Elm is going to make me handle the case where those assumptions were not true. DILLON: Exactly. I think that TypeScript of any type is the perfect illustration of the difference. TypeScript of any type is sort of allowing you to say, "Don't type check this. Trust me here," and Elm's approach is more kind of just be explicit about what you want me to do if your assumptions are incorrect. It doesn't let you kind of come in and say, "No, I know I'm going to be right here." CHARLES: Right but there is a way to pass data structures back and forth. DILLON: There absolutely is and actually, there's a technique that's starting to gain some traction now, which I'm really excited about, which is rather than using this sort of JavaScript interrupt technique we talked about, which is again, it's very much like communicating with a server where you're kind of sending messages and getting data back -- getting these messages with data back. But there's an alternative to that which is using web components. Actually, there's quite good support for assuming that you don't need to be compatible with Internet Explorer. Basically in a nutshell, if you can wrap a sort of declarative web component around anything, it could be a Google Maps API, it could be a syntax highlighting JavaScript library, something that you don't have an Elm library for but you want to use this JavaScript library, it's actually quite a nice experience. You just render that custom element using your Elm code just as you would any other HTML in Elm. CHARLES: Yeah I like that, so the HTML becomes the canvas or composition with other JavaScript and the semantics are very well-defined and that interface is actually pretty thin. DILLON: Exactly and the key again is that you wanted to find a declarative interface, rather than an imperative one where you're kind of just doing a series of statements where you say, "Do this and then set this value and then call this and then set this call back." Instead, you're saying, "Render this Google Maps custom element," which is centered around these coordinates and has this zoom level on. You declaratively give it the bit of information that it needs to render a particular view. CHARLES: Okay. Then I guess the final question that I have around this area is about being able to integrate existing tools and functions inside of an Elm application. Because it sounds like you could theoretically develop large parts of your application, is there a way that you can actually have other areas of your application that are not currently invested in Elm still benefit from it, in the sense for kind of need of JavaScript APIs that Elm can make available. DILLON: Right, so you're kind of talking about the reverse of that Elm reaching out to JavaScript. You're asking about, can JavaScript reach out to Elm and benefit from some of its ecosystem? CHARLES: Exactly. I say that is that another potential vector for experimentation. DILLON: It's a really interesting thought. I haven't given it too much thought, to be honest but I actually have heard it come up before and my gut feeling is that it's probably more fruitful to explore the inverse, reaching out to JavaScript from Elm and the reason is kind of the main appeal of Elm is that when you're operating within Elm, you have this sense that if it compiles, it works. Because again, this central decision to not allow escape hatches is what allows you to have that sort of robustness, so you have this feeling of bullet proof refactorings and adding new features seamlessly where you change your data modeling to say, "Here's this other case that can be represented," and then suddenly, the Elm compiler says, "Tell me what to do here, tell me what to do here and tell me what to do there," and you do it and your app is working. That's the real appeal of Elm, I think and you don't really get much of that by just calling out to an Elm library from within JavaScript. That's my gut feeling on it. CHARLES: Okay, that's fair enough. On the subject of interrupt and using tools like JSON, you actually maintain a GraphQL library for Elm. You probably have a lot of experience on this. Maybe we can talk about that as a concrete case that highlights the examples. DILLON: Yeah. I think to me this is one of the things that really highlights the power of Elm, to give you a really amazing refactoring and kind of feature creating experience. A lot of Elm libraries are prefaced by the author name, so it's still DillonKearns/ElmGraphQL. I spoke about it this year at ElmConf. In a nutshell, what it does is it actually generates code based on your GraphQL schema. For anyone who doesn't know, GraphQL is just kind of a language for expressing the shape of your API and what types of data can return. What DillonKearns on GraphQL does is it looks at your GraphQL schema and it generates an API that allows you to query that API. using this library, you can actually guarantee that you're making a valid query to your server. Again, you get this bulletproof experience of refactoring in Elm where you can do something like make a change in your API and recompile your Elm code and see whether you've made a backwards incompatible change. All of this effort of doing sort of this JSON decoding I was talking about earlier where you kind of have to explicitly say, "These are my assumptions about the shape of the JSON that I'm getting back." When you're using this library, you no longer need to make any assumptions because you're able to rely on this sort of schema of your API and so you know when you're requesting this data, you don't have to run it, see if it works and then tweak it and run it again -- this sort of cycle of checking your assumptions at runtime. It moves those assumptions that you're making from runtime to compile time and it can tell you when you compile your application, it can say, "Actually, this data you're requesting, it doesn't exist," or, "It's actually called this," or, "This is actually the type of the data." CHARLES: Right. I love that. How do you do that? Because it seems like you've got a little bit of a chicken and the egg problem because the schema is defined outside of Elm, so you have to be able to parse and understand the schema in order to generate the Elm types to be able to compile Elm code against them. Maybe I'm not -- DILLON: That's exactly right. That's exactly what it does. Now, the nice thing is that GraphQL is really designed for these types of use cases. It supports them in a first class way. If you have a GraphQL API, that means you have built into it whether you know about it or not, a way to introspect the schema. All of the queries for kind of interrogating that GraphQL server and asking what types of data does this return, what are all your queries that I can run, it's built into it by the framework, so that comes for free. Getting up and running with this package I built is as simple as running a little npm CLI, pointing it to either your URL for your server or the JSON form of your schema, if you prefer and then, it generates the code for you. CHARLES: Wow, that sounds fantastic. This is the exact kind of thing that feels like it would be cool if I could just start using this library to manage the GraphQL of my application but I'm consuming that GraphQL from other JavaScript but it's the Elm code that's managing it. Do you see what I mean? DILLON: I hadn't considered that. I guess you could. You're right. Maybe I'm so smitten with Elm that it's hard to see an in-between but I guess, you could get some benefits from that approach. CHARLES: Right and as an experiment of course. DILLON: There you go. There you go. CHARLES: All right. With that, I think we'll wrap it up. Thank you so much, Dillon for coming on and talking with us on the podcast. DILLON: My pleasure. I really enjoyed the conversation. CHARLES: I actually got so many great tidbits from so many different areas of software development in Elm but also, just in kind of other things that I'm interested in trying. It was a really great conversation. DILLON: I had a lot of fun and I love discussing these things. For any listeners who are interested in this stuff, feel free to reach out to me on the Elm Slack or on Twitter. I'm at @DillonTKearns. I'm also offering a free intro Elm talk for any companies that are kind of entertaining the idea of doing an experiment with Elm. If you go to IncrementalElm.com/Intro, you can find out about some of the talks that I'm offering. CHARLES: All right. Well, thank you very much and we, as always are the Frontside. We build software that you can stake your future on and you can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io on email. Please send us any questions you might have, any topics that you'd like to hear about and we look forward to hearing from you and we will see you next week.

One of the most important aspects of a company is its team and finding how teams can collaborate effectively. It’s a common approach to separate people into teams and tasks, but is that the most efficient way to accomplish your goals? Here to tell us is Woody Zuill. Woody is one of the original founders of Mob Programming, taking a “whole team” approach to teamwork in software development. He’s also been programming for 35+ years and has 15+ years as an Agile coach. He knows what constitutes an effective and collaborative team. Join us to hear him share his expertise on today’s CTO Studio.  In this episode, you’ll hear: Why the work of the software development team is more than just writing software. How is mob programming different than pair programming? Why is communication more than just someone expressing their idea? What is context switching and why is it so ineffective? Why it's better to work slowly on the right thing versus quickly on the wrong thing. And so much more! Woody helps teams to think differently about collaborating, efficacy, productivity and overall happiness in the software development process. In general, he is most interested in finding ways to make it easier for people to work well together. It's also important to him that we all question the things we do without questioning, the kinds of things we have a deep belief in because we tend to not question those things. This means even the traits of Agile are to be questioned - it's not the untouchable document that so many tech leaders make it out to be in my experience. It's about continuing to question the manifesto and why and how and how does this still apply. Woody says this is a brilliant place to start. The Agile Manifesto for him has done a really good job of saying here are some things that are really important to us as we explore better ways to manage the creation of software or to go about doing that work. Woody doesn't think it (the Agile Manifesto) was ever meant to be a be-all-end-all or some 10 commandments type of list! It's simply four things discovered to be important. He believes the people who put together the manifesto understood the massive importance of collaboration, and that we cannot collaborate on things if we aren't working on them at the same time or if we are working on different things or if we don't have enough time and space to do so.  His response led me to ask how much time do we waste when we collaborate? Woody quickly reframed the question: instead, he would ask how much time are we wasting when we separate people who should be collaborating?  That is primary to him, we make an assumption that separating people and then coordinating their communication and their type of collaboration is beneficial to us. But what is the advantage to doing this? Normally people tell him something like this: When we have 5 people working on 5 separate things we are getting 5 separate things done. But he says the reality is that we have 5 separate things that are crawling towards being done, and when we bring those people together to work on one thing at a time we will suddenly get things done very rapidly and in a more beneficial way. We are also getting more feedback sooner: we have 5 sets of eyes on the code at one time, we are sharing our ideas in real-time and we are coming to better decisions and we are able to unmake decisions. If we are integrating at certain points then when we do that we are going to find out where we differ, and then we have to have the same discussions anyway! We have to talk about why we thought something should be done a certain way (or another way), and by that time we've forgotten why we made so many of the decisions we made because we made them in tiny steps as we went. The issue I wanted to raise within this topic is how to ensure everyone is pulling their weight. If you have a group of 5 or 6 or 7 people working together there's a concern that one or two people may not contribute or be as efficient as they would've been if they had been knocking out code by themselves. Woody agrees, he says the idea of efficiency is the place to start here. Is being efficient actually useful to us? There are other considerations. Being effective is what he is after, and being productive might fall between efficient and effective as well. He explains that efficiency itself means (to some degree) that we have found a way to do something with as little motion waste as possible so to speak. So if we have a manufacturing device that is going to put two parts together and it has to reach a far distance to bring one part to the other part if we put the two parts really close to together then we've gotten rid of the inefficiencies of it. But we can be extremely busy without ever actually finishing any work, so productivity is the idea that we are actually producing something and there will be an end result. But productivity really is about the outputs divided by the inputs, in other words how much are we getting done for the time involved. Effectiveness is figuring out the right thing to be working on. So the problem is what is the right thing? Part of being effective is the process of discovery and learning what is the right thing to be working on. He likes to think we have to have a combination of being efficient and effective, but really the important thing is being effective. You'll also hear how that manifests and what it looks like in real-life mob programming, plus how we get good ideas, what makes some teams stronger than others and the importance of listening in team collaboration. Join us for those topics and more on today's CTO Studio.   Episode Resources: Woody Zuill’s blog Woody Zuill on Twitter Woody Zuill on LinkedIn

Craig is at Agile 2016 in Atlanta and catches up with his old friend Woody Zuill to talk about Mob Programming and #noestimates Craig’s InfoQ interview with Woody Zuill We need to work well together to get our work done Mob Programming originated at Hunter Industries, identified we can get a lot done if we … Continue reading →

Joe Krebs speaks with Woody Zuill, who coined the term “Mob Programming” and which he pioneered in from of blogging, conferences and speaking engagements. Today Mob Programming is a standard practice in agile teams around the world. In this episode he also shares insights into the “No Estimates” movement he created and why he applies this thinking to complex knowledge work in particular.

Woody Zuill coined the term "Mob Programming" which he also pioneered in from of blogging, conferences and speaking engagements. Today Mob Programming is a standard practice in agile teams around the world. In this episode he also shares insights into the No Estimates movement he created and why he applies this thinking to complex knowledge work in particular.

Vi har med Woody Zuill som är självaste grundaren till mob programming och #noestimates. Woody har 30 års erfarenhet av programmering och har senaste 15 åren arbetat som agile coach. Vi går igenom hur mob programmering och #noestimates kom till. Vi spanar även på framtiden och skapar #nomeetings.

Episode 22 of the Modern Agile Show features an interview with Woody Zuill, father of Mob Programming, a pioneer of #NoEstimates and an experienced Lean/Agile trainer and coach. Woody describes the early origins and influences of Mob Programming, including the study groups that he conducted at Hunter Industries. Woody describes the importance of daily Retrospectives in order to improve every day. He also explains how Mob Programming helps humans work well together and how the practice of mobbing helped him become a better person.

The history of testers and developers working together is a bumpy road. Throughout the evolution of software development, testers have struggled to be treated as equals and developers have lacked the understanding of why they should care. Yet some teams do it well - both roles have a good experience and the resulting software benefits from the different perspectives. In this podcast, Franziska and Maaret speak to Matt Wynne to share some tips on how to improve this in your team. Show notes: CukenFest London, April 19th-20th. Join us for our annual conference focused on building stronger ties between business and IT. Keynotes from Dan North and Ulrika Malmgren. More details on our event page - http://cukenfest.cucumber.io/. Book recommendation - Thanks for the feedback, Douglas Stone and Sheila Heen. Buy on Amazon - https://www.amazon.com/Thanks-Feedback-Science-Receiving-Well/dp/0670014664 Mob programming podcast w/ Woody Zuill. Listen - https://cucumber.io/blog/2016/04/19/mob-programming

Fredrik och Erik pratar mobbprogrammering - det relativt nya och trendiga steget upp från parprogrammering där hela teamet jobbar gemensamt med en enda uppgift i taget. Vi pratar om vad det är och vad de som provat på det tyckt, sagt och skrivit och givetvis vad vi själva tycker och tänker om det. Vi kommer också naturligt in på att världen inte innehåller några silverkulor, sund skepsis mot saker som sägs vara enbart fördelar och att fundera över vad som egentligen får trendiga lösningar att verka så bra. Kanske vårt mest skeptiska avsnitt hittills! Länkar Mobbprogrammering Ship it Lennart Fridén Parprogrammering A year of mob programming - erfarenheter från Mikael Sundberg som även berättat om upplevelsen i Kodsnack 218 From 12 to +50 tickets a month, lessons learnt Avsnitt 17 och framför allt 62 av podden Väg 74 diskuterar också mobbprogrammering. Woody Zuill och hans presentation Mob programming - a whole team approach TPS-report-mannen från Office space Avsnitt 5, om processer Avtagande avkastning - diminishing returns på svenska Partiskhet - bias på svenska Det finns inga silverkulor Go Anchoring Programming is terrible Under utveckling är en podd av och för utvecklare, skapad i soliga (nåja) Göteborg av oss som jobbar på TimeEdit. Vi vill väldigt gärna höra dina åsikter om det vi pratar om! Vi finns på Twitter som @uupodden och på Facebook som Under utveckling. Gillar du podden får du mer än gärna betygsätta oss i iTunes!

Woody Zuill (@WoodyZuill), Tim Ottinger (@tottinge), Zach Bonaker (@ZachBonaker) and Amitai Schleier (@schmonz) joined me (@RyanRipley) to discuss a wide range of agile topics and principles. [featured-image single_newwindow=”false”]Zach Bonaker Presenting ‘The Deception of Training' at Scrum Day San Diego 2016[/featured-image] Woody has been programming for over 35 years with 20 of those years as an Extreme Programmer (XP) and more than 15 of those years as an Agile Coach. He takes the “inspect and adapt” mantra to heart and through this type of inquiry has developed advanced agile concepts such as #NoEstimates and #MobProgramming. Woody is passionate about helping teams reinvent their workplace to make it possible for everyone to excel in their work and life. He published the Mob Programming book on Leanpub and provides his thoughts about many agile topics on his blog. Tim is committed to understanding and improving the art of software from the angle of “thinking for a living.” He is a programmer, author, trainer and globally recognized coach with over 35 years of real software development experience. His style is practical and hands-on, steeped in both Agile and classic traditions. Tim rapidly communicates concepts and practices, and is recognized for his compassionate and patient approach to working with individuals and has a sincere interest in helping people reach their goals. Zach is a self-described “benevolent trouble-maker” and seeks to foster servant leadership that cultivates growth, learning, and discovery. He is a systems thinker who shares his thoughts on his blog – Agile Out Loud. Zach is great at pushing agile thinking forward and has authored many popular posts on next generation agile theories and practices. Amitai is a software development coach, speaker, legacy code wrestler, non-award-winning musician, award winning bad poet, and the creator of the Agile in 3 Minutes podcast. He blogs at schmonz.com and is a frequent guest on Agile for Humans. Amitai has published many of his agile observations and musings in his new book – Agile in 3 Minutes on Lean Pub. In this episode you'll discover: How principles drive agile practices How turning up the good improves your team and your life Why principles trump practices Links from the show: Modern Agile Woody Zuill’s Blog Tim Ottinger’s Blog Amitai’s Blog [callout]This comprehensive set of cards is an indispensable resource for agile teams. The deck of Agile in a Flash cards teaches leadership, teamwork, clean programming, agile approaches to problem solving, and tips for coaching agile teams. Team members can use the cards as reference material, ice breakers for conversations, reminders (taped to a wall or monitor), and sources of useful tips and hard-won wisdom. Click here to purchase on Amazon.[/callout] [reminder]Which topic resonated with you? Please leave your thoughts in the comment section below.[/reminder] Want to hear another podcast about the life of an agile coach? — Listen to my conversation with Zach Bonaker, Diane Zajac-Woodie, and Amitai Schlair on episode 39. We discuss growing an agile practice and how coaches help create the environments where agile ideas can flourish. One tiny favor.  — Please take 30 seconds now and leave a review on iTunes. This helps others learn about the show and grows our audience. It will help the show tremendously, including my ability to bring on more great guests for all of us to learn from. Thanks! This podcast episode is brought to you by Techwell's Agile Dev West Conference. Techwell's Agile Dev West is *the* premier event that covers the latest advances in the agile community. Agile for Humans listeners can use the code AGILEDEV to receive $200 off their conference registration fee. Check out the entire program at adcwest.techwell.com. You'll notice that I'm speaking there this year. Attendees will have a chance to see my The #NoEstimates Movement presentation, along with my half day session on advanced scrum topics called Scrum: Answering the Tough Questions. I hope to see many Agile for Humans listeners in Las Vegas – June 4–9th, for this great event. The post AFH 065: Agile Open Forum with Woody Zuill, Tim Ottinger, Amitai Schleier, and Zach Bonaker [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

Returning guest Woody Zuill is a veteran programmer, sought-after consultant and international speaker, as well as credited with both the “no estimates” and the “mob programming” movements. In this episode, we discuss estimates, working on a problem versus working on a symptom, paradigm shifts, and much more!

Llewellyn Falco (@llewellynfalco) and Amitai Schleier (@schmonz) joined me (@RyanRipley) to discuss Agile Coaching, types of coaching, hiring coaches, and some #MobProgramming. [featured-image single_newwindow=”false”]Llewellyn Falco[/featured-image] Llewellyn is a professional teacher, speaker, agile programmer, and creator of the Approval Test project. He blogs here, appears on podcasts there, and helps make agile teams awesome everywhere. Llewellyn generously shares his insights on YouTube. Watch his videos, they are great. Seriously. Amitai is a software development coach, speaker, legacy code wrestler, non-award-winning musician, award winning bad poet, and the creator of the Agile in 3 Minutes podcast. He blogs at schmonz.com and is a frequent guest on Agile for Humans. Amitai has published many of his agile observations and musings in his new book – Agile in 3 Minutes on Lean Pub. In this episode you'll discover: How to hire an agile coach Different ways agile coaches work with teams Why you may want to get out to Boston on April 6th and 7th for the Mob Programming Conference Links from the show: Mob Programming Conference Agile in 3 Minutes #32 – Mob by Amitai Schleier The Beer Game AFH Episode 27 on #MobProgramming with Woody Zuill [callout]Written in a fast-paced thriller style, The Goal, a gripping novel, is transforming management thinking throughout the world. It is a book to recommend to your friends in industry – even to your bosses – but not to your competitors. Alex Rogo is a harried plant manager working ever more desperately to try improve performance. His factory is rapidly heading for disaster. So is his marriage. He has ninety days to save his plant – or it will be closed by corporate HQ, with hundreds of job losses. It takes a chance meeting with a professor from student days – Jonah – to help him break out of conventional ways of thinking to see what needs to be done. Click here to purchase on Amazon.[/callout] [reminder]What are your thoughts about this episode? Please leave them in the comments section below.[/reminder] Want to hear another podcast about the life of an agile coach? — Listen to my conversation with Zach Bonaker, Diane Zajac-Woodie, and Amitai Schlair on episode 39. We discuss growing an agile practice and how coaches help create the environments where agile ideas can flourish. One tiny favor.  — Please take 30 seconds now and leave a review on iTunes. This helps others learn about the show and grows our audience. It will help the show tremendously, including my ability to bring on more great guests for all of us to learn from. Thanks! This podcast is brought to you by Audible. I have used Audible for years, and I love audio books. I have three to recommend: Agile and Lean Program Management by Johanna Rothman Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland The Lean Startup by Eric Ries All you need to do to get your free 30-day Audible trial is go to Audibletrial.com/agile. Choose one of the above books, or choose between more than 180,000 audio programs. It's that easy. Go to Audibletrial.com/agile and get started today. Enjoy! The post AFH 058: Agile Coaching Strategies with Llewellyn Falco [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

Woody Zuill talks about Mob Programming and NoEstimates at Agile India 2017.

You've pair programmed but have you tried Mob Programming? Woody Zuill and his team "discovered" programming as a group and it changed their whole process. Woody joins Scott and explains how they stumbled on this, how they refined it, and how Mob Programming may make your programming life better.

Woody Zuill is a veteran programmer, software development project manager and creator of mob programming. In this episode, we discuss what mob programming entails and its value in terms of increased productivity.

Woody Zuill is an Agile coach working on the "original Mob programming team". As is befitting since Woody coined the term "mob programming"--which is, as he puts it "pair programming, except for everybody here is going to be involved." For him, mob programming is a natural evolution of pair programming. Like in pair programming where each pair helps problem-solve and vet the resulting code, in mob programming, "When you work with a whole group, you get the best of everybody... We're not looking into getting the most out of everybody... We're looking to get the best out of everybody into everything we do." That's why what began as informal or scheduled work sessions became the de facto programming style of Woody and his team. Woody Zuill has been a software developer for 30+ years and is an Agile enthusiast. He has been instrumental in promoting a "No Estimates" approach to Agile product delivery.  SolutionsIQ's Leslie Morse hosts. About Agile Amped The Agile Amped podcast series engages with industry thought leaders at Agile events across the country to bring valuable content to subscribers anytime, anywhere. To receive real-time updates, subscribe at YouTube, iTunes or SolutionsIQ.com. Subscribe: http://bit.ly/SIQYouTube, http://bit.ly/SIQiTunes, http://www.solutionsiq.com/agile-amped/ Follow: http://bit.ly/SIQTwitter Like: http://bit.ly/SIQFacebook

“All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.” That’s how Woody Zuill - who coined the term Mob Programming - describes it. He is our esteemed guest on the podcast, and we spend some time digging into his own experiences mobbing. This is a fun episode for folks looking for novel ways to improve the certainty of their software. Remember to like, share and subscribe on soundcloud or iTunes. It helps us reach more people! Show notes: The first Mob Programming Conference is happening May 1 & 2 at the Microsoft NERD Center at MIT in Cambridge MA. - http://mobprogramming.org/mob-programming-conference-may-1-and-2-2016/. Mob Programming: A Whole Team Approach (Book, work in progress) - https://leanpub.com/mobprogramming We’re mobbing daily at Cucumber HQ and our host Steve Tooke put a post together at the end of last year - https://cucumber.io/blog/2015/12/21/the-mob-rules-ok

Hosts Ryan Ripley, David Bernstein, Woody Zuill Discussion Ryan Ripley (@ryanripley), David Bernstein (@tobeagile) and Woody Zuill (@WoodyZuill) got together to discuss legacy code, what it means to be a great programmer, test driven development, and how the principles that we adopt drive our practices. Software development is one of the few activities that requires us to use both halves of our…Tweet This At the center of our discussion was David's new book: Beyond Legacy Code This book now has a prominent place on my desk next to Uncle Bob Martin's classic book  Clean Code. David starts the reader off with the current state of software development and why many of the problems that we observe and experience still persist today. He calls this “The Legacy Code Crisis” and does a brilliant job of making the case for agile software development practices. Legacy code is code without confidence. @tobeagileTweet This The second part of the book covers 9 practices that “extend the life and value of your software”. The 9 practices are: Say What, Why, and for Whom Before How Build in Small Batches Integrate Continuously Collaborate Create Clean Code Write the Test First Specify Behaviors with Tests Implement the Design Last Refactor Legacy Code Each practice is explained clearly along with why each practice is important. The “why” is critical. It's easy to explain the mechanics of TDD, but also showing the value that the practice provides makes the book appropriate for programmers, managers, and executives alike. My favorite aspect of this book is that David's explanations and insights are infused with the values and principles of the agile manifesto. His prose is engaging and feels conversational. It’s a pleasure to read David’s thoughts on these topics as he is clearly knowledgeable and passionate about agility and creating humane systems of work. I love this book and cannot recommend it highly enough. As Woody Zuill noted on the podcast: “If I had what it takes to write a book, I would like to have written this book.” And then…we called it a night. Will you help the Agile for Humans podcast grow? Please review Agile for Humans on iTunes or Stitcher and leave your comments on the blog site. Help your friends and co-workers find Agile for Humans by sharing your favorite episodes with them. Thanks for you do to support the show. Agile for Humans is brought to you by audible.com – get one FREE audiobook download and 30 day free trial at http://www.audibletrial.com/agile Resources, Plugs, and More Ryan – https://ryanripley.com AgileIndy 2016 – April 12 in Indianapolis, IN Path to Agility Conference – May 25 & 26 in Columbus, OH David – http://www.tobeagile.com/ Beyond Legacy Code: Nine Practices to Extend the Life and Value of Your Software by David Scott Bernstein Woody – http://zuill.us/WoodyZuill/ Mob Programming Conference – May 1 & 2 in Cambridge, MA The post AFH 029: Beyond Legacy Code with David Bernstein and Woody Zuill [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

Hosts Ryan Ripley, Amitai Schlair, Woody Zuill Discussion Ryan Ripley (@ryanripley), Amitai Schlair (@schmonz) and Woody Zuill (@WoodyZuill) got together to discuss Mob Programming (#MobProgramming). Mob programming involves the whole team working on the same thing, at the same time, in the same space, and at the same computer. You can think of it as pair programming turned up to eleven. We talked about the benefits that mob programming can bring to a team, how it can simplify the hiring and on-boarding process, and what to do when the mob needs some alone time. We have to pay attention to what’s working and continually turn up the good!Tweet This We also learned about the Mob Programming Conference coming to Cambridge, Mass on May 1st and 2nd. Hosted by Agile New England and organized by Nancy Van Schooenderwoert, Llewellyn Falco, Woody Zuill, Kurt Kilpela, and Peter Carmichael this is shaping up to be the event to attend if you are interested in learning about and seeing Mob Programming in action. And then…we called it a night. Will you help the Agile for Humans podcast grow? Please review Agile for Humans on iTunes and leave your comments on the blog site. Help your friends and co-workers find Agile for Humans by sharing your favorite episodes with them. Thanks for all you do to support the show. Agile for Humans is brought to you by audible.com – get one FREE audiobook download and 30 day free trial at http://www.audibletrial.com/agile Resources, Plugs, and More Ryan – https://ryanripley.com AgileIndy 2016 – April 12 in Indianapolis, IN Path to Agility Conference – May 25 & 26 in Columbus, OH Amitai – http://www.schmonz.com/ Agile in 3 Minutes on LeanPub.com Agile in 3 Minutes Episode #32 – Mob How to Develop Humans Mr. Bunny’s Big Cup o’ Java by Carlton Egremont III Woody – http://zuill.us/WoodyZuill/ Beyond Legacy Code by David Scott Bernstein Mob Programming Conference – May 1 & 2 in Cambridge, MA The post AFH 027: Mob Programming with Woody Zuill [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

In this episode Adam talks to Woody Zuill about software project estimation. They talk about the #NoEstimates hash tag, and what it means and where it came from. They also talk about ways to manage software projects without worrying about estimation, and alternative ways to make the decisions that estimates are usually used for. This episode is brought to you by Laracasts. Woody's #NoEstimates blog posts "What price estimation?" by Neil Killick "What is software design?" by Jack Reeves The Mob Programming Conference MobProgramming.org Sponsored by Laracasts

Guest: Woody Zuill @WoodyZuill Full show notes are at https://developeronfire.com/podcast/episode-054-woody-zuill-turn-up-the-good

Woody Zuill likes to share his experiences of software development. You'll find his blog at zuill.us/WoodyZuill/ or connect directly on Twitter twitter.com/WoodyZuill Greger Wikstrand also has a blog at gregerwikstrand.com/ and can be found on Twitter as twitter.com/GregerWikstrand Links 1) Photo: Ivan sutherland, Sketchpad This episode was recorded at Capgemini office in Helsingborg Architecture Corner is a part of Disruptive Architecture - disruptivearchitecture.info Published by Artmann Media, Höganäs, Sweden, October 2015. artmann.co.uk Copyright: Creative Commons License, Attribution Share Alike

Listen to this podcast to learn: How can a whole team of about five people be programming together when there is only one person actually typing? And why isn't it exhausting to work together like that all day, every day. How can mob programming possibly work? Perhaps that is the wrong question to ask, responds Woody. We started with this model because we liked working together. Only later did we realize that we were also more efficient. What does a mob programming team look like? It is a mix of roles and competencies and it shifts during the day and the project dependent on needs. What is the difference between mob programming and #pairprogramming? Can you get into "the zone" when working together as a team? Woody Zuill likes to share his experiences with Mob Programming. You'll find his blog at http://zuill.us/WoodyZuill/ or connect directly on Twitter https://twitter.com/WoodyZuill Greger Wikstrand also has a blog at http://www.gregerwikstrand.com/ and can be found on Twitter as https://twitter.com/GregerWikstrand This episode was recorded at Capgemini office in Helsingborg Architecture Corner is a part of Disruptive Architecture - http://disruptivearchitecture.info Published by Artmann Media, Höganäs, Sweden, September 2015. http://www.artmann.co.uk Copyright: Creative Commons License, Attribution Share Alike

[featured-image single_newwindow=”false”] Hosts Ryan Ripley, Aaron Griffith Discussion Aaron Griffith (@aaron_griffith) is a member of the Hunter #mobprogramming team, agile speaker, and #NoEstimates enthusiast. He joined Ryan Ripley (@ryanripley) to talk about agile in a galaxy far far away, agile coach camp (#accus) experiences, and a bonus topic from the Agile Coaching Cards Lean Coffee volume 1 deck. We started with Aaron's talk about agile and Star Wars. During this talk, Aaron compares and contrast the Republic and the Galactic Empire to an agile team. Using movie quotes and scenes he brings to life agile concepts and practices in ways that newcomers to agile can relate with and understand. He's received great feedback on this talk and will be giving it again at Agile Testing Days in Potsdam, Germany – November 9th-12th. We then moved on to our time at Agile Coach Camp 2015. We were both able to attend some interesting sessions. Ryan shared his experiences discussing the business side of agile and telling stories with Woody Zuill. Aaron explained insights learned in #MobProgramming sessions and gave his overall thoughts on his first visit to a coach camp. Finally, we wrapped up by doing a quick Lean Coffee session using Victor Bonacci's (@agilecoffee) new agile coaching cards deck. We pulled the “Dealing with bullies, naysayers, and other bad apples” card and shared stories and insights from past experiences with difficult agile team members. And then…we called it a night. If you would like to continue the conversation, please visit www.agileanswerman.com/ask-a-question. You can record a message that could end up on the show or send us an email with your feedback, topics, and questions. We hope to hear from you soon. Agile for Humans is brought to you by audible.com – get one FREE audiobook download and 30 day free trial at www.audibletrial.com/agile Resources, Plugs, and More Ryan – http://agileanswerman.com Agile Coaching Cards – These are the Lean Coffee decks that were mentioned on the show. The Art of Thought by Graham Wallas Slack by Tom Demarco The Star Wars Saga Aaron – https://twitter.com/Aaron_Griffith Agile Testing Days – Potsdam, Germany – 11/9-11/12 Agile Open SoCal The Hunter Mob is hiring! mobprogramming.org teachingkidsprogramming.org The post AFH 014: Agile in a Galaxy Far Far Away [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

Hosts Ryan Ripley, Zach Bonaker, Woody Zuill Discussion Woody Zuill (@WoodyZuill) joined Zach and Ryan to talk about experimentation in Agile. Woody talked about his early experiences in the workforce and the need to investigate. These experiences taught him to never take anything for granted and to be inquisitive about all things. This lead to one of his key mantras: Question the things that you have the most faith in. We then moved on to The Pattern of Continuous No Improvement. This phenomenon occurs when teams set out to correct the same issue sprint over sprint but cannot seem to make progress. Often this pattern is caused by not addressing the root cause of the issue. We talked about 5 why's as one means to discovering the root cause. We also talked about the team's need to recognize this pattern and to confront it head on. #NoEstimates was born from this insight as a team tried repeatedly to improve their estimates but continued to miss that goal. Finally the team decided to work without task estimates and found some improvement and later on, success. #MobProgramming is another idea brought to the agile world by Woody. He described its origin as an impromptu presentation during Agile 2012. Fortunately, that open jam session was popular and an important conversation about how teams get their work done was born. Asking the inverse of a question was highlighted as a powerful probing technique, especially during retrospectives. We all agreed that frequent retros bring valuable insights to the team and that effective mob programming is fueled by effective retrospectives. The discussion then shifted to how teams can measure their agility and the renaissance of craftsmanship in the software development world. And then…we called it a night. Resources, Plugs, and More Ryan – http://agileanswerman.com No Estimates Book by Vasco Duarte Agile for Humans EP 7 – #NoEstimates “War of Words Is Goofy” Zach – https://www.linkedin.com/in/zachbonaker The Subversion of Agile: Agile is a Cancer Woody – http://zuill.us/WoodyZuill/ Mob Programming Introduction A Day of Mob Programming – Time Lapse Video No Estimates: Let’s Explore the Possibilities Wiki Management by Rod Collins The post AFH 012: Agile Experiments with Woody Zuill [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

Ben and Samir Talwar of Codurance discuss the appeal of functional programming, mob programming, and a different take on conferences. This episode of Giant Robots is sponsored by: Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account. Links & Show Notes Codurance What is Go? (the game, not the language) Mob Programming, and the Importance of Fun at Work Mob Programming- A Whole Team Approach- Woody Zuill SoCraTes UK Hound What Is An OpenSpace Conference? Werewolf / Mafia (Party Game) London Software Craftsmanship Community Samir on Twitter

How do you estimate your projects? While at NDC, Carl and Richard talk to Woody Zuill about delivering software WITHOUT estimates. Woody starts out with a clarification - it's not zero estimates, just no estimates around particular features for an application. But how? Your customers want estimates, the trick is to deliver so quickly that there isn't time to estimate before you've delivered code. And does it have to be code? Isn't our goal to solve problems, and code is only one possible solution? Lots of great thinking about how you provide value to your customers!Support this podcast at — https://redcircle.com/net-rocks/donations

How do you estimate your projects? While at NDC, Carl and Richard talk to Woody Zuill about delivering software WITHOUT estimates. Woody starts out with a clarification - it's not zero estimates, just no estimates around particular features for an application. But how? Your customers want estimates, the trick is to deliver so quickly that there isn't time to estimate before you've delivered code. And does it have to be code? Isn't our goal to solve problems, and code is only one possible solution? Lots of great thinking about how you provide value to your customers!Support this podcast at — https://redcircle.com/net-rocks/donations

The Software Process and Measurement Cast features our interview with Woody Zuill.  We talked about the concept and controversy swirling around #NoEstimates. Even if the concept is a bridge too far for you, the conversation is important because we talked about why thinking and questioning is a critical survival technique. As Woody points out, it is important to peer past the “thou musts” to gain greater understanding of what you should be doing! Woody Zuill has been programming computers for 30+ years. Over the last 15+ years he has worked as an Agile Coach, Trainer, and Extreme Programmer and now works with Industrial Logic as a Trainer/Coach/Consultant for Agile and Lean software development. He believes code must be simple, clean, and maintainable to realize the Agile promise of Responding to Change.  Contact InformationMob Programming: http://mobprogramming.org/Blog: http://zuill.us/WoodyZuill/Twitter: https://twitter.com/woodyzuill Call to action! I have a challenge for the Software Process and Measurement Cast listeners for the next few weeks.  I would like you find one person that you think would like the podcast and introduce them to the cast.  This might mean sending them the URL or teaching how to download podcasts.  If you like the podcast and think it is valuable they will be thankful to you for introducing them to the Software Process and Measurement Cast! Thank you in advance! Re-Read Saturday News We have just begun the Re-Read Saturday of The Mythical Man-Month. We are off to a rousing start beginning with the Tar Pit.   Get a copy now and start reading! The Re-Read Saturday and other great articles can be found on the Software Process and Measurement Blog. Remember: We just completed the Re-Read Saturday of Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement, which began on February 21nd. What did you think?  Did the re-read cause you to read The Goal back up for a refresher? Visit the Software Process and Measurement Blog and review the whole re-read. Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version  Upcoming Events Software Quality and Test Management  September 13 – 18, 2015 San Diego, California http://qualitymanagementconference.com/ I will be speaking on the impact of cognitive biases on teams!  Let me know if you are attending! More on other great conferences soon! Next SPaMCast The next Software Process and Measurement Cast is a magazine installment.  We will feature our essay on Agile Testing. The flow of testing is different in an Agile project.  In many cases, organizations have either not recognized the change in flow, or have created Agile/waterfall hybrids with test groups holding onto waterfall patterns.  While some of the hybrids are driven by mandated contractual relationships, the majority are driven by lack of understanding or fear of how testing should flow in Agile projects. We will also have new installments from Jeremy Berriault’s QA Corner.  Jeremy, is a leader in the world of quality assurance and testing and was originally interviewed on the Software Process and Measurement Cast 274. The third column features Steve Tendon discussing more of his great new book, Hyper-Productive Knowledge Work Performance.  Shameless 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. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Hosts Ryan Ripley, George Dinwiddie, Neil Killick, JB Rainsberger Discussion #NoEstimates means many different things to many different people. The group defined #NoEstimates as a conversation around when estimates are appropriate and to which level of precision teams should target. We noted that the hashtag can lead to more “heat than light”, but also acknowledged that a rich conversation has formed around the questions that #NoEstimates poses. We moved on to discussing estimates being useful at a portfolio level for deciding which projects to do and to forecast budgets. To some this did not go far enough and we continued to highlight other benefits of estimating such as: Conversations that occur when estimating Shared understand of programming activities Enabling decision making at the executive level Validating project/program/product assumptions Indication of possible issues when reality and the estimate do not match When discussing when estimates are needed, there are no stock answers. George highlighted the need to meet the expressed needs of those seeking estimates. Once that is understood, we can determine an appropriate level of precision and act accordingly. JB cautioned against the mindless use of estimates, but everyone agreed that estimates created with a goal of “making good decisions” are useful. We turned to real world examples where burn-up charts are used to estimate the delivery of programs. This revealed some important considerations about estimates like the need to build uncertainty in to your estimates, while removing inappropriate levels of precision. We also covered situations with mandates and fixed dates where estimates may not be as critical as focusing on delivering the software frequently. Part of improving estimates requires improving software engineering practices. If the team can deliver consistently sprint over the sprint, the creation of estimates can move be performed by the stakeholders. While this type of improvement is difficult, George reminded us that focusing on the little things can have a great impact of making delivery more predictable. To wrap up, we circled back to the idea that we should focus on meeting needs. This aligns well with “individuals and interactions over process and tools”, but is also more difficult to do. Exploring how to meet needs requires soft skills, trust, and good relationships to succeed. Resources, Plugs, and More Ryan – http://agileanswerman.com #NoEstimates Does Not Stop Agile Metric Abuse The Product Owner Says #NoEstimates. Now What? Woody Zuill’s Blog George – http://blog.gdinwiddie.com/ Estimation as Hypothesis George’s post on Estimation Neil – http://neilkillick.com/ Interview about #NoEstimates with Chris Chapman and Neil The Requestimator’s Intent Babies, Bathwater, and #NoEstimates JB – http://www.jbrains.ca/ One Practical Alternative to Estimates The Trouble with #NoEstimates Those #NoEstimate People! The post AFH 005: A Panel Discussion on #NoEstimates [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

The Software Process and Measurement Cast includes three columns.  The first is our essay on managing Agile projects and teams. I often say project management is dead. That does not mean that the pressures that drive the need to manage work have gone away. In the end the “what” of project management is important because control, discipline and coordination are needed tools to deliver value; the journey toward Agile is the reframing of the “how” of project management. This week Gene Hughson returns with an entry from his Form Follows Function column.  Gene tackles the topic of whether the application of Conway’s Law makes microservices more of an organizational approach than an architecture.   After listening, check out Gene’s Form Follows Function blog! The third column in this SPaMCAST magazine is from the Software Sensei, Kim Pries.  Kim tackles hardcore testing.  Kim discusses the implications and uses of this aggressive type of testing in hardware, software and wetware. A great line up! Call to action! Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance! Re-Read Saturday News We just completed the Re-Read Saturday of Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement which began on February 21nd. What did you think?  Did the re-read cause you to pick  The Goal back up for a refresher? Visit the Software Process and Measurement Blog and review the whole re-read. Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version  Next week we will begin re-reading The Mythical Man-Month. Get a copy now and start reading! Upcoming Events Software Quality and Test Management  September 13 – 18, 2015 San Diego, California http://qualitymanagementconference.com/ I will be speaking on the impact of cognitive biases on teams!  Let me know if you are attending!   More on other great conferences next week.   Next SPaMCast The next Software Process and Measurement Cast will feature our interview with Woody Zuill.  Some people might think “that there is no Woody only Zuul” (apologies to the Ghostbusters) when it comes to topics like #NoEstimates.  However as Woody points out, it is important to peer past the “thou musts” to gain greater understanding of what you should be doing! Shameless 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. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

No Estimates with Woody Zuill (https://twitter.com/woodyzuill)

Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is a “Whole Team” approach to doing all the work the team does – including coding, designing, testing, and working with the “customer” (partner, Product Owner, user, etc). We'll take a look at the practice and explore the benefits and some ideas you can try on your own team. Woody Zuill has been programming computers for 30 years, and works as an Agile Coach/Development Manager. Over the last 15 years he has worked as an Agile Coach, Trainer, and Extreme Programmer. He believes code must be simple, clean, and maintainable to realize the Agile promise of Responding to Change. He spent many years as an artist/designer/manufacturer of graphics for televised sporting events where deadlines are for real. Loves Mob Programming. Resources: http://bit.ly/1hafo4r

Roy vandeWater: Hello, and welcome to another episode of the Agile Weekly podcast. I'm Roy vandeWater.