 Namaste, I'm Johannes Braunwald and I'm here at Agile India with Arlo Belschi so Arlo is a very experienced trainer in extreme programming and Agile practices and he gave some really interesting insights into How to train teams on becoming Agile at the conference So Arlo, how do you get started with getting teams to be Agile? Well, so the first step is cultural team has to own its destiny And so for that there needs to be a team I find usually the the main obstacle is that we don't actually have a team people call it a team it consists of 60 or 80 or 150 people That each one is allocated to multiple feature crews working on each a different crew for each feature that they're working on four or five in flight per developer at a time and it's a horrible mess There is no team, right? So the first step is to actually just get teams to exist I usually do that by using the power of the hierarchy and The last authoritarian decision that will be made is to create the teams that will take over It's sort of the opposite of, you know, voting yourself as a democracy Right, right. First the Queen says that we will have Parliament and parliamentary rules established So yeah, do that and then once we've got teams and real teams single assignment like we need Then it's about getting those teams to own their destiny And getting them to own their destiny. They need to start controlling their code. They need to start controlling their process their practices Their interactions with each other with their customers everything And so that's where we start with refactoring and teach people to do little changes to their their culture little changes to their process and little changes to their code and That's the that's the so there's just two steps Well, okay, so that's day one, right? Yeah, so day one it's Teams gonna get together. We're gonna talk about retrospectives. They're gonna have a little bit of a mini-chartering. They're gonna start doing some retrospectives They're gonna start pair programming for a couple hours a day. They're going to Do some refactoring probably on some legacy code But it's not, you know, full in-depth on all of these I want to teach people extract method and And introduce parameter and introduce variables so that we just get started and no further than that, right? So With each one of these things it's get started on a set of things that support each other And start to see some results fairly quickly But then once we've got that there will be thousands of days of one more new Improvement every day on until they finally learn, you know, everything there is to learn All right So if we go back to the first step to actually get a team getting a team, yeah So and you say that you have lots of people and there's better cross features. Yeah mess. Yeah So and then you say you by management degree we now have teams. How does that work? I mean, it seems magic. Oh, well, yeah, okay. That's a little magic So Typically when I'm going into an engagement the first thing that I need to establish is are they actually going to be capable of change? And so I go in and I talk to the champions of the engagement whoever those are which typically include management But it's on entirely management And establish, you know, what is the compelling business reason that is sufficient that you're actually going to make a change and For many businesses, they don't know that but they can identify one or two pain points And so I have a process to work through once we've established a compelling business reason Then all of those champions are fully aligned that yeah, we have to solve this problem So they're willing to start executing changes and as soon as they're willing to start executing changes I can just say okay. Well, then here's the engagement that we that we offer and here's the pre-rex And one of those pre-rex is single assignment teams with the cross-functional of about eight people That's that's the definition of a team that you can start work with right and do they accept that. Yeah. Yeah, and At that point, they know they know what they want to get out of it. They know they need to get it And that's a pre-rex to getting there and they can see why it's a pre-rex. So all right, they'll do it All right, and then you come to the you go on and you teach them some technical practices start the tech Yep, so you start with the tech. Yeah, and you said you start with the four basic mechanisms Yeah, and you said you start with the four basic refactoring. Yeah, four basic refactorings Extract method introduce variable introduce parameter and rename The goal is with just those four you can start introducing names and we can start teaching the great names. So Those Are kind of the things that you want developers to have in their fingers Do you work on any particular platforms or tools that support refactoring or do you teach manual refactoring? Well, whenever possible C-Sharp Life is easy and fun And otherwise. Yeah, when I'm in JavaScript or C++ then I have to teach the manual process I keep hoping that someday someone will finish a tool that does refactoring in C++ So you do find that the tool support there is important for teams to get. Oh, it's a huge difference. Yeah I find that speed of uptake the probability of success the degree of productivity the Decrease in bug rate all of these are dramatically determined by whether there's a refactoring tool and You only need to really know those four refactorings to start getting better right you need those four for day one Yeah, I mean the first set of things that I'm teaching people are local refactoring and it's starting to be able to take chunks of code that are messy and nasty and legacy bad legacy And get them a little more intelligible and a little lower complexity And so those four the first four once people have that they can handle many problems and then one at a time You know one or two days between they'll run into a problem They can't be solved with a refactoring they know and they have the cheat sheet and they go look it up Right, so then it becomes self-directed right and so after a while by focusing on refactoring You said that the team will master their destiny was that carry on their destiny. Yes with refactoring on the code and with pairing and retrospectives for team formation So how do you introduce pairing? It's another prereq So we talk about the value of the various things And we actually have multiple different engagement styles So the one that I'm talking about is the full-on immersion one There are lesser ones that if people aren't going to do the things they're gonna make work Well, we will do a much lesser investment and they will get a less much lesser result That's okay, that's their choice right but if people are gonna do the work then then we ask you know So pairing is an interesting part of it and you know, do you have problems with or want to control the rate of learning on the team? the rate of you know discipline and productivity and Habit formation habits formation formation. Yeah, so how long does it take me to change a habit if we decide that we're going to now Always write the tests first how long until we always do right if we're pairing all day Then it doesn't take very long and if we're not pairing it takes a really long time So so it is an enabling practice in lesson It's all an enabling practice and I talked about why you use it and that it enables and then People sign up for it. They usually sign up for two hours a day. Some of them will sign up for all day So you ask the developers on the team to sign up for how much they want to pair Usually I ask again that that starting group. That's the champions And so that consists of a bunch of IC developers and some leads and some managers And that group makes the call it Since those people are representative of pretty much all of the voices in the group Most people then say all right, whatever. We'll join on him So we've talked about a refactoring and test room. I'm sorry about pairing but we haven't talked much about test room development So there was a statement. I don't remember who said it, but in ten years a developer who doesn't know TDD will be Unemployable, how do you what do you think about that statement? um, I Think it's you know, that's likely true in much the way that a developer who all they know is cobalt Is no longer employable. That's not to say that you can't write good programs in cobalt, right? You can write just fine without TDD TDD is It's going to become a you know, sort of a baseline It's not what actually drives bugs out of the system or results in quality refactoring is what does that? TDD is the stand-in that has gotten the credit and that's the easy one to point to I can easily identify whether someone is unit testing It's much harder to test to look at their code and say did they refactor? But aren't refactoring is very dangerous if you don't test No, as long as you're using the rigorous approaches The point of refactoring is that you can statically analyze and Demonstrate that you know it is bug for bug compatible in the code It doesn't matter whether there's a test there or not now if what you're doing is local rewrites Instead of refactoring then yeah, that's dangerous as hell. You can't do that without test coverage But you don't do that right? I don't rewrite my code. I mechanically refactor it I mean mechanical refactoring are how you get legacy code to the point where you can put tests around it Well, I can't afford to introduce a bug during that process So I have to do something that's completely safe in the nastiest gnarliest code that we have Then you know what it's also safe in the not so nasty gnarly code that you get later. I That said I do still teach unit testing. I do still teach test first But I teach it later and for a different purpose right test first is to start learning to use test suspect And the whole point of that is to teach people vertical decomposition and to break the the spec down into a smaller chunk and Now we're getting into requirement space I think We're not now now we're moving into sort of a user engagement or customer engagement part of it It's a little bit people draw more distinctions in these than I do Yes, so first of all, I'm assuming pairing right so it might be that the paired that's doing the the tests is a PM and a dev or a tester in a dev or whatever And it's a little more spec-like, but I mean really it's that as you're going You're recording one little more goal that you want to achieve or one little piece of thinking you want to try out And then you go and meet it and that's not necessarily about requirements. It's not necessarily about tech It could be about anything. It's just one more thing. I want to try right So what you're saying is that when you're get that basic fluency, so you're no longer afraid of your code, right? Then you can start doing experiments and then then You can decide where those experiments will take you based on your context Yeah, and and some of the tests become the recording of experiments that I've run But the experiments are primarily actually I'm doing refactoring so I'm learning stuff there And then I'm just recording things out into the tests All right, so what's so when we got that covered? What's the next step for a team? Well, so So the thing is that many people talk about Bringing on the practices, you know a practice at a time or do you do it all at once? My perspective is each one of these practices actually longitudinal in nature They are It takes you 20 minutes to learn to do the basics of it and it's it's because it's actually a thousand different practices Yeah, you know and so it takes you 20 minutes to learn the first case All right, and then you will learn those cases over forever So I'm bringing in all the practices at once the first couple of cases of each and then the next two years are Learning all the other cases of every single one of those practices And so it takes about three to six months to the point where you're really pretty confident at development and are able to start driving the Tech debt down and then takes about another 18 months while you're paying off the accrued debt from before And that's the first two years or so right Now all of the stuff that we've been talking about is focusing on the engineering practice is how to get that better And that that that takes a while especially if you want to move your existing code base to a better place When when you go to an agile conference these days, it seems like most of the talks are not about engineering They're about strategy or Product management or discovery and the sort of stuff. How does that play? Yeah, so if we look at the fluency model We see You know, there's a bunch of one-star talks. They're talking about scrum primarily They're talking about how we do the management of our team and how we get to align teams It's where I think that it's one star is an aligned team So I recommend talking in terms of stories and great that helps get alignment and alignment with the customer goal You know fine good stuff, whatever then two star Everyone ignores and forgets about being effective at actually executing and delivering And the reason is because the people who haven't figured that out yet We're seeing that it is important are talking about one-star stuff the people who have seen it is important mostly have figured it out and they're now talking about three-star stuff and so three-star and we're starting to look at Building the right thing and learning customer need and Discovering strategies and all that sort of stuff and that's where people are playing so in the conferences right now We see a split where the community that is able to execute Assumes execution and is building on it and that the group that is not able to get execute Assumes that execution is just like traditional with similar bug rates and whatever and so they're talking about how you build Systems that can account for the failures that are a necessary part of software development So there's a whole life There's a big hole there where people have moved on and and we've got half of the people still believe that bugs are normal Half the believe that people believe that bugs are an option and they've chosen not to have them But isn't it very important to do the right thing than to do the thing right Let's look at the risk of software development, right? so if you look at a given feature teams that are picking them by the usual which is opinion of the most highly-paid person in the room When you do that that person usually has a fairly good clue and and as a result They're right about a third of the time and it adds positive value And it loses value about a third of the time and it has no change about a third of the time and a given feature So it's you know, it's evenly spread However, when you look at execution The number of projects which are which are able to make it to their market window With the features that they needed in order to be successful in the market is about a third And the other ones are either they miss the market window or they miss the execution so it seems like risk is about the same between execution and Build the right thing except the first one was per feature when you add more features you get regression to the mean and It tends to be that the high-value features have Super linear Exponential, right? Yes So you get a preponderance of those also at the low end you have exponential decay But they're so bad they're freaking obvious So you know them in beta and you remove them and the result is that over time as you have a large number of features You do have positive value So even if you go with the opinion of the highest paid person in the room your product will have positive value Not as good as it could but it will have positive value, right? Whereas No matter how you go only a third of your projects are even going to make it off the springboard So your biggest risk to software development is actually shipping the product at all If you ship it it will have some value now Once you have eliminated the risk of execution and paid that down Then now you're at a state where you've got about a hundred percent chance of hitting the market window with your with what you want Yeah, but you've still got this random distribution of features now. I see where to make my next improvement, right? Your biggest risk is actually in Shipping it right. Yeah. Yeah, and that also gives you the opportunity to gather the feedback. Yeah. Yeah, all right Are you ready for the lightning round? All right, so what's your favorite programming language? Minions I'm writing it What's the first step that I should take to become a better developer refactor more And what's the first refactoring I should work on extract method What's your favorite? Cotter coding cutter gilded rose Yeah, and What is gilded rose? It's a refactoring Cota It's a Cota it's about three screens long of text is all that has most of the traits of legacy code system in those three screens and your job is to just add one more little feature That will require you to either do a whole lot of special casing and get things under a tremendous manner test or refactor it to a Same point and then you can move on Thank you very much. Thank you