Podcast appearances and mentions of arlo belshee

Seye Kuyinu: Shared Ownership of Change, Strategies for Effective Agile Transformation Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Seye delves into change leadership within an organization facing team cohesion challenges. He highlights the initial step of process assessment and the impact of conflicting factions within a team. The breakdown of processes led to differing interpretations of the team's goals. Seye references Arlo Belshee's work in Agile Engineering Fluency (detailed map here), and suggests establishing work agreements, visualizing the change process, and securing buy-in for effective change. He underscores the importance of collective ownership of change and introduces the idea of a team coaching canvas to facilitate progress. The episode emphasizes collaborative change leadership to address team dynamics and process issues.   [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Seye Kuyinu Seye has been a Scrum Master for about a decade now. He first connected to Agile, frustrated with the lack of adequate communication that plagues traditional complex projects. He finds People and Interactions over Processes & Tools cannot be overstated, while seeing that everything is a fractal- our individual, team, organization and societal challenges are the very same. The solution in every layer is the same- an understanding of ONENESS! You can link with Seye Kuyinu on LinkedIn and connect with Seye Kuyinu on Twitter. 

What happens when companies go from a single small team of developers to tenfold their size as a result of becoming market fit? Could it be that the same patterns that once helped them grow will now halt their progress? Developer and Agile Consultant Arlo Belshee will teach us about the patterns behind inefficient teams, illegible code, and —of course— bugs, and how to spot these patterns and fix them. Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

Incremental Steps episodeBuilt-in quality (from Lean principles)Tiny commitsKent Beck's book TDD by exampleDead Code episodeClose open loopsGetting Things Done (GTD) methodologyCapturingProcessingPomodoro Methodrainymood.comCentered AppTrunk-based developmentelm-review template flag (preview folder)sparksp/elm-review-no-forbidden-wordsSelf-documenting codeSelf-documenting code tweet and blog postelm-verify-examplesAPI Design Lessons episodeHammock-Driven DevelopmentReleasing vs. shippingContinuous DeliveryNaming as a Process article by Arlo Belshee

In this episode Arlo Belshee, Aaron Coville and Marc Denman discuss how small changes in our coding behaviors can lead to incredible results. Arlo believes we can achieve a bug-free world, Aaron agrees with him on some points of that... Listen to hear the debate and more:Imagining a bug free worldWhy we waste so much time making and dealing with bugsThe average developer creates 3 bugs a day (even Senior Devs)What is “The insight loop” (16:36)Teaches you how to see code differently and How to refactor legacy code safelyYour engineering culture will create habits, some good some bad.Naming as a process (27:11): using nonsensical names for methods, like Applesauce, forces a habit of refactoring and naming with intentionality, but does it come at a cost?

As menders working with legacy code, we are focused on identifying and reducing technical debt. But how much easier this task would be if the creator of the code or the previous maintainer left us some breadcrumbs to follow? A simple note on the rationale for a particular decision they have made or a warning about interconnected lines of code would take us a long way! Today we talk with Andrea Goulet, co-founder and Chief Strategy Officer of Corgibytes. Her empathy-driven approach to software development earned her recognition as one of the Top Ten Professionals in Software Under 35 by LinkedIn. She tells us about this lack of communication in software development, the phenomenon she calls the communication debt, and how its reduction can make the software more robust and its maintenance more efficient. When you finish listening to the episode, connect with Andrea via LinkedIn, contact her via Corgibytes' website, and check out her LinkedIn courses: Agile Software Development: Remote Teams and Creating an Agile Culture.  Mentioned in this episode: Andrea on LinkedIn at https://www.linkedin.com/in/andreamgoulet/  Andrea on Twitter at https://twitter.com/andreagoulet  Corgibytes website at https://corgibytes.com  Andrea Goulet, Agile Software Development: Remote Teams at https://www.linkedin.com/learning/agile-software-development-remote-teams  Andrea Goulet, Creating an Agile Culture at https://www.linkedin.com/learning/agile-software-development-creating-an-agile-culture    Changelog podcast with Katrina Owen at https://changelog.com/podcast/108  Katrina Owen, Exorcism.io at https://exercism.io  Indi Young, Practical Empathy at https://amzn.to/3jkDlLH* Legacy Code Rocks with Indi Young at https://www.legacycode.rocks/podcast-1/episode/270edc0e/practical-empathy-with-indi-young Ward Cunningham on technical debt at https://youtu.be/pqeJFYwnkjE Legacy Code Rocks with Arlo Belshee at https://www.legacycode.rocks/podcast-1/episode/c240c45d/naming-with-arlo-belshee Daniel Kahneman, Thinking Fast and Slow at https://amzn.to/3kceRW3* Legacy Code Rocks with Cyrille Martraire at https://www.legacycode.rocks/podcast-1/episode/2fd0fdeb/living-documentation-with-cyrille-martraire  Cyrille Martraire, Living Documentation at https://amzn.to/3kd2J7e* * Heads up! If you purchase a book through the links above, we will get a small commission which helps us continue to bring quality content to our Legacy Code Rocks! community. You won’t pay a penny more, we receive a small kickback, and you’re supporting our friends who wrote them. Everybody wins!

In this Episode, Diana joined Shahin to talk about Agile Fluency and other related topics. We conversed about and around the following topics: Agile Fluency® Model (Resources, Community & Game); and it's reference Language Fluency  Group coaching compared to Individual coaching Retrospective Facilitator Gathering & Open Space Technology Continuous Learning & Continuous Improvement; Advice and Tools for newer people to Agile Coaching in the Zones & Improvement Kata We referred to and/or mentioned the following people: Rebecca Wirfs-Brock - Linda Rising - Esther Derby - Klaus Leopold (LeanOnAgile Show with Klaus) - Joshua Kerievsky - Ward Cunningham - Norman Kerth - Allison Pollard - Alistair Cockburn - Ron Jeffries - Arlo Belshee - Martin Fowler - James Shore We cited the following resources: By Diana & Co-Authors: Agile Retrospectives: Making Good Teams Great (Amazon US - Amazon CA) Liftoff: Start and Sustain Successful Agile Teams (Amazon US - Amazon CA) The Five Rules of Accelerated Learning (LeanPub) By Other Authors: Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy: Survive & Thrive on Disruption - Jutta Eckstein & John Buck (Amazon US - Amazon CA) Project Retrospective: A Handbook for Team Reviews - Norman Kerth (Amazon US - Amazon CA) Love is Letting Go of Fear - Gerald Jamposky (Amazon US - Amazon CA) Checklist Manifesto - Atul Gawande (Amazon US - Amazon CA) For more details please visit http://podcast.leanonagile.com. Twitter: twitter.com/LeanOnAgileShow  LinkedIn: linkedin.com/company/lean-on-agile

Richard interviews Arlo Belshee. Arlo is a well-known legacy code consultant, a team-building leader, and one of the inventors of promiscuous pair programming. Arlo currently serves as CTO at Deep Roots. As we chat about our favorite teams, Arlo shares with us what he considers to be the three most important things for a successful team-building. When you finish listening to the episode, make sure to visit Arlo's blog at http://arlobelshee.com and to connect with him on Twitter at https://twitter.com/arlobelshee and LinkedIn at https://www.linkedin.com/in/arlobelshee/. Read the full transcript at kasperowski.com/podcast-38-arlo-belshee/.

We discuss with Arlo Belshee (https://twitter.com/arlobelshee) and Marian Willeke (https://twitter.com/mhwilleke) from DigDeepRoots (https://twitter.com/digdeeproots) how to prevent bugs (#BugsZero) and ship faster. Video and show notes: https://youtu.be/Pn_xpaf2Jzk 

In this SoundNotes live talk, we discuss technical debt with Arlo Belshee and Marian Willeke. We’ll specifically delve into why technical debt is a very common problem, why it's often not solved, and how it can be.

Technical debt can cause critical issues for organizations. Every year an organization does not address these issues brings them closer to ruin. Some businesses even have to shut their doors due to irreconcilable technical debt that conventional solutions alone cannot address. Arlo Belshee, full-stack Agile developer and technical coach, shares insightful knowledge on building better software, specifically as it pertains to what he calls safeguarding: “a simple, 22-minute practice that allows you to find, fund, and then execute real changes to your process and product.” One of the things that makes fixing technical debt so difficult is that “there is no one problem of technical debt.” Belshee advocates for empowering teams to own problems, to know what’s going on in their part of the system and to work quickly to address these problems. Accenture | SolutionsIQ’s Stas Zvinyatskovsky hosts at the Deliver: Agile Conference in Nashville, Tennessee. 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 Connect with us on social media!  Twitter: twitter.com/AgileAmped  Facebook: www.facebook.com/agileamped  Instagram: www.instagram.com/agileamped/

After coding live at Lean+Agile DC 2018, Ben Scott of Ippon Technologies joins Bob Payne to talk code craftsmanship and getting proper feedback from the business side.  Ben explains a way to quickly build a quality demo from scratch – creating the first demonstrable piece of value.  Bob and Scott walk through their opinions on (shudder) best practices, living in ambiguity in agile methods, and bridging the gap between IT and business. Bob Payne: [00:00:03] Hi I'm your host Bob Payne. I'm here at Lean+Agile D.C.. I'm here with Ben Scott and we're listening to "Stand in the Place Where You are" by RBM played on the music fiddle version which is really disconcerting for me. It's like Fugazi. You know elevator music which is definitely elevator music. But country elevator music. So Ben we were talking earlier about lots and lots of things but you were talking about sort of your experience here trying to do live coding and talk. What was your what was the gist of your talk? What were you talking about with. Ben Scott: [00:00:56] So, let's start with the problem statement: Whenever you start a project from scratch mainly it's really hard to get good business demos and keep the business interactive with getting proper feedback. You'll see a lot of demos with terminals. Hey let's see what my code can do and you have to look at log statements or use post postman to demonstrate APIs. And then the business kind of glazes over it. And I think a lot of issues stem from developers trying to recreate everything internally. Someone has to provide a demo that even started a presentation with zero code I could provide a business level demo with a front end application backend with database usage deployed to the cloud. All within the same presentation within 45 minutes. So that was kind of the gist, some people really liked the felt it really demonstrated well what could be done now. They're probably unsure how to adopt down to their own organization but it's mostly a show that it is able to do that and you don't have to buy it. It's FREE.  Ben Scott: [00:02:14] It's opensource a tool that I use is called J Hipster and I think overall great.  Bob Payne: [00:02:23] Yeah I mean for those of us who've been familiar with play or Rails or any of the generative frameworks you know that it was not should not have been surprising but I realized how how painful it is for most organizations to get to that first demonstrable piece of value.  Ben Scott: [00:02:50] Yes.  Bob Payne: [00:02:51] It is a little a little insane.  Ben Scott: [00:02:53] It is. The key differences are with J hipster is it really tries to adopt the enterprise level technology. Bob Payne: [00:03:00] You see the full stack you've got full size containerized deployments.  Ben Scott: [00:03:05] You can you don't have to but it sure does generate Docker containers. I use the docker file to let you generate a Docker container from your code. It will generate your CD pipeline script. It supports multiple privacy circles C.I. Jenkins obviously and a few other really really kind of handhold you through the whole process of getting a code from scratch all the way to diploid and ready. It can't do anything about your business level code that's on you right. But all the bootstrapping and plumbing it generates according to best practices of the time with us.  Bob Payne: [00:03:45] I winced on the inside. I don't like the phrase best practices but best that I'm okay with. Ben Scott: [00:03:54] Yes well it's always a big debate. What is best practice. Like for depending on where you are which technology you're using and your opinion because it's a hotly debated topic Your Domain Driven Design or you don't. Some people really love it some people hate it. Yeah that type of thing.  Bob Payne: [00:04:12] Yeah I try to stay away because people always ask us for as consultants are always asking for the answer and there really only is know fee here given your situation. Here are a few options that we've seen people be successful. Yes you know and you know I always sort of try to steer people away from that. Like calling people resources. There's a few you like hot button words that I can't make can move resources around us our projects exactly rituals and scroll to find that I hate things that that pull it out of the somewhat grey world that we actually live in.  Ben Scott: [00:05:05] Yes I actually like to prefer I prefer to live in this ambiguity. I don't like to define what scrum is definitely. I don't like too dear to a Agile philosophy per se or implementation whenever somebody dresses. Hey what is ads out to you. To me it's you delivered a piece of software that was correct at the right time and how you got there might differ based on the people working in your company. Yes we might use Scrum or not. It depends if it's a good fit with that place and sometimes it's now or sometimes they just decide as long as we do what scrum says we are agile and we just get away from what they really mean.  Bob Payne: [00:05:50] Yeah. Defer to authority. There is a good strategy.  Ben Scott: [00:05:55] So I don't like to prescribe things.  Bob Payne:[00:05:57] Yeah.  Ben Scott: [00:05:58] When we hire Scrum Masters always ask me what's your process. What tool to use. You know you use Jira. I don't prescribe - you use what you like to use right.  Ben Scott: [00:06:07] Well your client will let you use yes whatever you is best for your situation which will change.  Bob Payne: [00:06:15] So how do you so I know you've been doing a lot of technical coaching coaching. What do you what do you find most rewarding. Because sometimes it's it's you know it's it's a tough slog sometimes and there are always those little nuggets that just say yeah you know that will keep me going for a few months banging my head against this team or this wall or whatever. Ben Scott: [00:06:43] So I really enjoy bringing upskilling developers on where they lack and I'm not a awesome developer. I'm a very niche developer who understand the agile practices so I can do their job testing frameworks Cucumber, or perform sensing as a Gatling I know how to do them and the basic forms right and the tools to know how to use them. Eventually it clicks at first like I don't want it. It is what QA is for but eventually it clicks and it's really fun to see a click. Likewise I work a lot with the business side on bridging the gap between developers and the business we actually start working together instead of the whole campus. This is the business that we need to take to go on like what we need is. Of course we do to this refactoring. We need to adopt this technology or just trying to bring them together so they actually work as a team and we'll stack clicks which is much harder than it was going developers. Bob Payne: [00:07:40] Yeah. Ben Scott: [00:07:41] That's that's really fun.  Bob Payne: [00:07:42] Yeah that is. Yeah. We like speed we have that sort of mission of making people's lives more valued fulfilling and productive. It's kind of our or our mission if we can do that on an individual basis or you know we health and organization so that it helps the folks. But it all fundamentally comes down to you know people people in interactions and you know hopefully making a you know a decent world for them to sort of grind away at the code code is an unforgiving.  Ben Scott: [00:08:21] Yes we'll spend days looking for that tiny little mistake.  Bob Payne: [00:08:27] Yeah yeah. So what's the other big dogmatic thing you're railing against. I don't know that you're actually railing against any big dogmatic things but you seem like the sort of person that might. Ben Scott: [00:08:41] There are some things I'm very strict on and it's is code craftsmanship to the detriment of sometimes I'm actually delivering value and I understand that. But there are times to be fast and dirty. You have a production bug.  Bob Payne: [00:08:55] Yep. Ben Scott: [00:08:56] There's a feature that needs to go to the market right away. OK we can do that fast and dirty. But if that's every time there's a problem.  Bob Payne: [00:09:06] Right.  Ben Scott: [00:09:06] And at that point I don't have any issues slowing everything down and I guess focus on craftsmanship. Let's focus on actually teaching what solid principles mean because over time you're going into being faster more maintainable code. The sustainable pace and that takes time to learn. It might take six months a year to really get there. It's a huge investment and it's the responsibility of the entire organization to to foster that. So just like we have the Center for agile excellence or you go to an agile coach organization talk about processes.  Ben Scott: [00:09:39] You should have a software craftsmanship as well a new way to mentor the developers. And that practice that's probably where I'm the most strict on.  Bob Payne: [00:09:51] OK yeah no that's ... Yeah. That's a good place to be strict I think. I often think of the three things that can make a great team. It's discipline, continuous improvement, and play the long game you know not the short term gain necessarily but product delivery is is not project right now. Ben Scott: [00:10:16] And I completely understand there's times we have to go really fast for whatever reason it is. Maybe there's a bug that's costing thousands of dollars. When it's in production.  Bob Payne: [00:10:23] Yeah. Ben Scott: [00:10:24] And yes. Quick and dirty fix but then think about it and fix it again the right way. Bob Payne: [00:10:30] Yeah. Well everybody. It's interesting because that the current understanding where the current sort of popular understanding of technical debt is that it is a bad thing and you know when they first started talking about it Ward Cunningham and and you know some of the folks on the first XP team actually used it in more the financial term debt. Sometimes you do take down. You know you go fast to be quick and you might incur some debt. You got to pay it down. Always cost a little bit more to pay it down. But sometimes that's the right decision. But when you're paying off the credit card with another credit card you're in drips.  Ben Scott: [00:11:20] That compounds quickly. Bob Payne: [00:11:21] Then You need to re platform the whole thing. Ben Scott: [00:11:26] And then it just never ends.  Bob Payne: [00:11:27] Yeah. Bob Payne: [00:11:28] And that's what the craftsmanship comes in play because if you instill those values when you build a new software and maybe you'll be a little bit better and last longer.  Bob Payne: [00:11:36] Yeah. So is IPPON primarily you know do you or most of the folks steeped in XP stream programming and.  Ben Scott: [00:11:47] So I would say most of us are what I would consider like Premier consultants as far as developers. Most of us are developers. So in that sense we're a bit different from most agile consulting companies. We focus a lot on the engineering aspect of agile versus the process and most of our developers don't always subscribe to Agile values. They like to get their stuff done and they're like good code and beautiful aspects that don't always adhere to delivering to agile way which is fine. But you couple that wish people would truly understand agile and you've just multiplied yet the actual value of it. It's like the cross-functional needed agile deep expertise to guide the ship but you still need a technical deep expertise on what good coding practices look like. Yeah and we also like to embed with our clients. We don't always like to take the whole project and then deliver at the end. We like to develop right and while we could develop we'll pair with them or we'll teach developed practices how to test and how to automate the whole thing and the whole the whole package. I think that's where our values will be different than other places. Bob Payne: [00:13:07] Yes. And we've you know at LitheSpeed we've been happy to be able to partner with the guys periodically because we focus primarily on the people in the process and you guys can focus on the technical chops.  Ben Scott: [00:13:25] Yes. Bob Payne: [00:13:25] Yeah. I'm primarily a PowerPoint engineer and there is no PPT unit.  Ben Scott: [00:13:34] No I'm really bad at PowerPoint.  Bob Payne: [00:13:39] I wouldn't say I'm good. But the reason I'm not very good is because there's no there's no unit test framework to how to get good. I was talking to somebody earlier because I I was when I was developing you know I got immediately test infected like TTD like real TDD not the ATDD or BDD. Not that those things are bad but that thinking and design process of TDD was an amazing force multiplier for me as not a terribly great developer. It allowed me to focus know where I was know that I hadn't broken something else because I couldn't keep every esoteric detail from the entire system. Ben Scott: [00:14:38] Yes.  Bob Payne: [00:14:39] In my head some people love that they loved the challenge of I've got every single detail in my head. But that doesn't scale. It does and test.  Ben Scott: [00:14:52] It's a good thing you brought TDD like I have my own opinions about it. And you're right. Some people love us some people hate it. And to me there's a lot of focus from the process scores to do TDD when developers aren't ready for it. Bob Payne: [00:15:06] Yeah yeah yeah.  Ben Scott: [00:15:07] Just like everything will be fine if you just do TDD.  Bob Payne: [00:15:11] Yeah I don't believe that to be true. Everything will be fine if you have engineers that are that are that really you know there I sort of look at the code and you can see the thought process of the developer in the code and that is much easier for me to read to read tested code than it is to to create an elegant you know you start throwing in some Lambda's there and we're we're we're parked. I mean because I struck part of my psychosis if you will. And I think it's reasonable to call it that around TDD as I started in Lisp and I don't know if you've ever tried to debug lisp or scala. It's probably easier now and in scala but there's just the interpreter. Back when I was doing this so you had a command line and you read in a file and something pops out and it is the most amazing black box in the world because it's just it's interpreted. It's a functional language and 42 is the answer, right? I forgot the question we asked in end. So unless you knew that those little pieces worked. Yes pull that out throw it into an interpreter and see if it give it some some values in and see if it makes sense because all it takes is a misplaced pen. It could be anywhere and it will usually evolve out to something that still works.  Ben Scott: [00:17:04] And I guess where I differ what it is like or I'm strict on tests in the same commit as the code.  Bob Payne: [00:17:11] Yeah.  Ben Scott: [00:17:12] I don't prescribe to. You must write a test first. Bob Payne: [00:17:15] Sure.  Ben Scott: [00:17:16] But it must be in the same commit. Yeah that's that's kind of where I differ. And some people are really good at writing tests first. Some are not. Bob Payne: [00:17:24] Yeah. Ben Scott: [00:17:24] But everybody should be able to write before or after, there's not. Never does ..That's Not allowed. Bob Payne: [00:17:31] Yeah I think it's a reasonable place to be strict. I think for me just I. Bob Payne: [00:17:39] I loved Arlo Belshee. I think it was our Arlo Belshee that coined the term test infected because some people either are or are not. And it's like you know that zombie strain virus. And I don't know which side is the zombie in which is the not here but I think the TTD folks are probably the zombies. But if you were when you find yourself on one side of that divide I think that the folks that actually like TTD and I know it is not universal. It's it's one of the more powerful and least used agile engineering practices.  Ben Scott: [00:18:15] Yes. Bob Payne: [00:18:16] I mean Pairing, people say they pair, but nobody pairs. I mean not like. Ben Scott: [00:18:21] Well not like extreme program where you must pair. Right. We like to pair for occasions like right. Here's a difficult piece of code. Let's work on it together or for mentoring. We'll pair for code reviews the type of thing we'll do some pairing for writing prose not so much right. How hard is it to write Pojos. You know it's so many people go down this rabbit hole to we test the setters and getters like I don't care. Like ok. Probably not. I'm OK. But really how long would it take you to actually do it if you said if everybody said we need to.  Ben Scott: [00:19:09] So. So interesting thing. So the debate by just writing a piece of code using reflection finds a perjures sets the value gets the value a certain done. So all my pages are tested automatically. Bob Payne: [00:19:25] Yeah. and now with generative frameworks it is it is relatively easy. I was cured of that debate because I'm not a great programmer. When I misformatted the way I created a Java date. And so when I made and I always know how to make your assertion not against the same constructor that you used. So I use distracted at this other date class add some other stuff in and misuse the constructor and when I assert it against the string format it value, i'm like "Well that's not right." And I don't know that I would have found that regular regular test or I would have I would have found like f'd up dates in the database or in the persistence layer or in the front end and I'm like I might not know. Then I've got a whole different problem but because I knew it I found out early that it didn't work like the debugging. For me it was just so much so much easier. Ben Scott: [00:20:36] And eventually you have to use common sense. You look at your POJO like well maybe I don't need to test every single one of them. But if you're serializing a date you should test that because for whatever reason it's so strict that the date format it will kill you application is different for might just use a whole AI behind it to be able to extract data and decide what date it is.  Bob Payne: [00:21:00] You guys likes you know you guys like screw up the order of the month and the day like what is this? Ben Scott: [00:21:05] It has Slashes no slashes. Bob Payne: [00:21:07] Dashes no dashes, dots..  Ben Scott: [00:21:10] Or you add milliseconds and you expect no milliseconds and it still won't truncate it'll just die right there. Bob Payne: [00:21:17] Yeah. Ben Scott: [00:21:17] So testing that. That's a good test. Typically also have a serialization test if it's data layer i'll serialize or deserialize back to the object, validate, but I might not validate.  Bob Payne: [00:21:30] You know that was that it was more important when he had to write her own serializer. Ben Scott: [00:21:37] Well I don't write my own serializer but I do write my own test for the annotations like for date format for example did you do the right format right. Does the precision matter or those type of things you have and I'm working on a project right now that for whatever reason the order matters. The order should not matter but whoever was sending it to they got that code where the order of your serialization matters and they can't just construct the object they actually validate it in its raw format first.  Bob Payne: [00:22:05] Okay. Ben Scott: [00:22:06] So then we have to validate that we send in the right Json format but in the right order each field. It shouldn't matter. At least in my opinion it should not matter.  Bob Payne: [00:22:15] No. But yeah well unless you want strong coupling in implementations which I'm shocked at how many are organizations really like strong coupling. Ben Scott: [00:22:33] I'm not sure they like it or just live with it. Bob Payne: [00:22:36] Yeah it's Like oh my god. It's like it's like the old Korbo or SOAP. Oh man. Ben Scott: [00:22:42] This is how we've always done it so we will continue. Bob Payne: [00:22:44] Yeah. Yep. So what else would do you. What's interesting to you in what hobbies do you have besides like? Ben Scott: [00:22:56] Kids.. Does that count as Hobbies? Bob Payne: [00:22:58] Yeah. Ben Scott: [00:22:59] It takes a lot of my time - it's fun time, it's really interesting and enjoyable to watch and grow. But I did find my most of my hobbies dropped away little by little. Bob Payne: [00:23:10] Yeah. Ben Scott: [00:23:13] When I did become a parent. Bob Payne: [00:23:16] I picked up new hobbies like I had never watched soccer before because I didn't like sports because those were the people that beat up the geeks. And now I'm doing like Magic the Gathering which I avoided in college like the plague. Ben Scott: [00:23:43] I never got into that. Bob Payne: [00:23:43] Because I was more of a punk than a D&D. There's a reasonable Venn diagram there. But but. Now I'm going to Friday Night Magic with my son. Ben Scott: [00:23:55] So that's a very fun but very expensive game. Bob Payne: [00:23:59] It is. Like you know a lot of people like do sports gambling. I think that's even worse. You know. Ben Scott: [00:24:06] Yes. Bob Payne: [00:24:07] Liaisons in a Russian hotel. Let it get very expensive very quickly depending on what you're doing. Ben Scott: [00:24:17] And I also do gaming video games typically do single player story type games. Bob Payne: [00:24:23] Oh really? given your military background. You've had enough First Person Shooter.. Ben Scott: [00:24:31] We'll it's more that to play online takes dedicated time whereas a single player. I can stop anytime. Pause and walk away. Bob Payne: [00:24:39] Yeah. Ben Scott: [00:24:40] I find that sometimes as a parent it's really hard to get an hour dedicated time. Bob Payne: [00:24:43] Oh yeah yeah. Ben Scott: [00:24:44] straight to play, it's like no I cannot help you to do anything because I'm in my game. If I'm doing single player I can quickly pause and do something else. That's how I mostly got into it. Ben Scott: [00:24:54] Before kids I was mostly into Dota. Bob Payne: [00:24:59] sorry? Ben Scott: [00:24:59] Dota Which is a different type of game. Bob Payne: [00:25:02] OK. Ben Scott: [00:25:03] League of Legends. Very similar as the birth of League of Legends. Was one of the first of those types of games.  Bob Payne: [00:25:11] Okay. But that's when I decided it would be hard for me to play because it requires 1 hour blocks.  Bob Payne: [00:25:19] Oh yeah. Yeah. Ben Scott: [00:25:22] Couldn't dedicate that anymore.  Bob Payne: [00:25:23] I know, yeah. So there's there's probably a game waiting for me this evening when I go home. So let's see. But. Ben Scott: [00:25:35] Let's see what else now spend time with family. Every Wednesday we have. Bob Payne: [00:25:42] Long walks on the beach and. Ben Scott: [00:25:43] Ah.. Not that, Just cook and eat and and drink and be merry. Revolves around food, and every Wednesday we have big family dinner.  Bob Payne: [00:25:55] Wednesday? Ben Scott:[00:25:55] Yeah Wednesday just because weekends are crazy. We also do on weekends. But we found that doing it in the middle of the week it kind of cuts the week and half. Bob Payne: [00:26:04] Yeah. You talk about work a little bit the stress and excuse to escape the daily grind of get up go to work. Come back do homework or other things. It's another event middle of the week that's a bit unusual but yeah it works for us. Bob Payne: [00:26:22] Yeah Wednesdays are not that exciting, it's dessert day. So. Ben Scott: [00:26:26] I like family Wednesdays. It's fun. Bob Payne: [00:26:29] Ok cool. We'll have to we'll have to do dessert/Dota/. Ben Scott: [00:26:37] Well I haven't played that game in so long i'd probably be terrible at it now. Bob Payne: [00:26:41] It's ok. You're better than I am  Ben Scott: [00:26:44] Probably. Bob Payne: [00:26:48] Thanks a lot, Ben Really appreciate it.  

Episode 28 of the Modern Agile Show features an interview with Arlo Belshee, a pioneering agilest who is constantly pushing the boundaries of agility, from planning to programming. Arlo was at the deliver:Agile conference in Austin, Texas to talk about mastering legacy code via ultra-safe refactorings. Arlo describes “recipes” that people can execute manually on languages that have lacked automated refactoring tools (like C++). Together with his colleagues at Tableaux software, Arlo has helped to find a way to solve the classic chicken-and-egg problem of not being able to refactor because you lack tests and not being able to test code without first refactoring. The safe recipes use the type system and rely on the compiler to ensure that you can indeed refactor without automated tests and that the design transformations you make are perfectly safe. Each recipe involves micro-changes that together help you safely make important design changes. Arlo explains how his approach to ultra safe refactoring helped him and his colleagues make design changes in legacy Microsoft products, like Foxpro. This is the essence of the Modern Agile principle, Make Safety A Prerequisite. Also also mentions a practice called “safeguarding”, a practice of analyzing a defect stream after an incident occurs. His teams performs RCA (root cause analysis) to identify the hazards that were present when an incident occurred, followed by “remediation”, which is a small, time-boxed fix to make the code less hazardous.

Arlo Belshee is a Team Craftsman and Legacy Code Wrangler who combines systems thinking, Lean systems, Extreme Programming, and changing culture experience to build high-quality teams at large companies. In this episode, we discuss naming as a process and its various steps to increase accuracy and efficiency.

Arlo Belshee spends all of his time working in "legacy" organizations: "legacy code, legacy culture, legacy team practices".   In software, "legacy" generally means "full of bugs". But Arlo has an interesting concept: what if creating buggy code, we didn't. Arlo's topic at the Agile Alliance Technical Conference concerns eliminating bugs by not creating them in the first place, because, after all, bugs are optional and there are ways to develop without creating this. Arlo has lots of passion around this and has even created a new initiative with a nifty hashtag: #BugZero. Similar to the concept of "inbox zero" (zeroing out your email inbox to improve your efficacy), bug zero means "get the bugs out of your code and keep it that way." 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

Guest: Arlo Belshee @arlobelshee Full show notes are at https://developeronfire.com/podcast/episode-073-arlo-belshee-refactoring-humanity

Hosts Ryan Ripley, Amitai Schlair, Arlo Belshee Discussion Ryan Ripley (@RyanRipley) Amitai Schlair (@schmonz) and Arlo Belshee (@arlobelshee) covered one of the most diverse agendas ever covered on the podcast. We started with a discussion about scaling agile, the limitations of frameworks like SAFe, LeSS, and DaD. We then moved on to the limits that consistency puts on innovation and how tuning consistency can be a serious competitive advantage. However, this is complicated task because “anytime we are going for consistency we are necessarily hurting innovation in that same space.” Next we discussed the controversial topic of refactoring vs test driven development (TDD). Arlo described his views on the differences between the two skills and ways that teams can work to refactor their designs safely – with tools – so that the code can then be come testable using TDD practices. On the TDD side of the discussion the group agreed that “a unit test that uses mocks is not a unit test.” Mocks are a smell that can reveal design issues within your code. Arlo also provided ideas about how to work without mocks and improve designs. Finally, we covered hiring people for emotional intelligence instead of skills. If smart, inquisitive people can be taught programming and other related skills quickly (~6 months) then what advantage does hiring for skills really bring to a team? Couldn't it be better to hire for empathy and culture first if skill are cheap to grow…especially in a pair/mob-programming environments? The answers to these questions and how this mindset shifts hiring led to an interesting conversation about how such thinking can help companies build innovative and effective teams. Empathy and Emotional Intelligence are skills worth hiring for.Tweet This And then…we called it a night. 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 – https://ryanripley.com No plugs from me this week. Just a big thank you to the listeners for your feedback and support! Amitai – http://www.schmonz.com/ Agile in 3 Minutes Podcast What's there to be afraid of? Approval Tests via Llewellyn Falco Arlo – http://arlobelshee.com/ Industrial Logic Blog 7 Languages in 7 Weeks by Bruce Tate The Language of Emotions: What Your Feelings Are Trying to Tell You by Karla McLaren The Art of Empathy: A Complete Guide to Life’s Most Essential Skill by Karla McLaren The post AFH 016: Are You Mocking My Unit Tests? [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

I always enjoy talking with Arlo about his open data work and the strange coincidence that he and Ward Cunningham are both working on this problem.  He chats about his work with big data, his penchant for starting with XP as the initial set of agile practices for teams to allow tight feedback and real agility. This interview has been on disk for a while but I hope you enjoy.  As you can tell he is an angry, angry, bitter man. Bob Payne

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I'm Clayton Lengel‑Zigich.

Here's the link to the pledgie where you can help me get to RubyConf. This week's episode is an interview with Corey Haines. He's pretty well known as the Software Journeyman and his coding tours where he traded time pairing on code for room and board. You can keep up with him at http://coreyhaines.com. You can also check out the following links for other things he's doing: http://www.katacasts.com/ http://www.coderetreat.com/ Here's a link to the Software Craftsmanship Manifesto which is tied a lot to the discussion we had on Software Craftsmanship. Corey mentioned the Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science) book, which is a mind-blowing set of instruction and exercises for computer programmers. We also discussed pairing in relation to the code retreats. Corey mentioned the paper by Arlo Belshee called “Promiscuous Pairing and the Beginner's Mind” You can reach Corey on twitter as @coreyhaines and by email at coreyhaines@gmail.com Finally, checkout the latest news on the XP Universe conference. Download this Episode

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

Welcome to the Arlo Belshee experience. Promiscuous Pairing, Least Qualified Implementer and a whole lot of energy. I spoke to Arlo at the Agile 2005 Conference in Denver.