 All right, so this is a talk in which I am bringing intentionally very little prepared content It's much more of a discussion than than a speaking at you sort of talk. So I'm going to talk a little bit about fluency Agile fluency and fluency models and then particular Apply that to engineering And then we're going to go through this particular model that I have this big graph Which is I'll zoom in as we start to look at various pieces of it But it's this massive dependency chart that's sort of based off of my experience with a number of different teams the various practices and techniques that people use in engineering across the couple of three years as they go two to three years as they go from Basically scrumish working as teams or individuals, but often component teams and that sort of thing to Getting ready and doing continuous delivery and lean startup and data-driven decision-making and prepared to go into the organizational changes The the real change in power and dynamics that happen in a company So this is basically everything that leads to being able to ship it will And not have any bugs So what we're going to do in this talk is I'll talk a little bit about fluency and some of the overall model And then we're just going to go in and explore a lot of parts of this graph And we're going to explore whatever parts of you guys find interesting. So although Nominally, this is a talk followed by questions at the end If you wait to the end to give the questions that it will be a 10-minute talk a silent bit and then a five-minute hurry. So Hopefully the questions will come a little earlier so Let's first talk about fluency and And this is actually one of the more important aspects here. This is a fluency model. This isn't a proficiency model What I mean by that is a Lot of ways that we talk about Becoming more effective at software development our maturity or proficiency models. Do you do X? You know, are you a team that regularly inspects and adapts or not? Right and those sorts of things and CMMI levels and all of those sorts of things The problem with those is that Well, there are a lot of problems. They're not context sensitive They tend to rate that certain things are better than others and your goal is to get to the end of the model and a bunch of those sorts of things A fluency model is different A fluency model says there are proficiencies There are a lot of different proficiencies in different practices in different way of doing things And in fact, there are dependencies among those. You're going to have a lot of trouble doing Automated deploy verification if you don't have any form of automated developer tests Right because there's a pretty hard dependency there and there are a lot of other more subtle dependencies as well But with a fluency model, we're looking not just at do you do this thing, but we're looking at when and how So there's basically three levels of fluency at a practice So if we take the practice of red green refactor, so I'm going to just zoom in If I can find it There we are Red green refactor. Okay, so rapid conic inner inner loop and that that practice of I'll make some code red You know, I'll make the system red by making a test fail or something like that Then I'll make it green then I'll refactor and I'll go through that loop every Well, how long? All right, so how long should you go through that loop or how long should it take you to do one cycle of that loop? ideas thoughts minute other ideas How long does it take you today to do that? You on your team or to borrow a phrase that buddy you have at totally not your company How long does it take him to do that? Four days Yeah, okay, and probably a wide range of times between those two All right between a minute and four days and this is what we're talking about with fluency So there are things that you're doing aspiration only, you know We understand what red green and refactor are and we go through those things in a sequence at The best of times it takes us a long time when the moon lines when our manager lets us All right, we're aspiring to do it There's a level below that Where people say a red green refactor and you say huh? right, so so getting to the level of of aspiring is an important step, right and Then there's another Significant level and that's fluency and that's where you practice whatever practice it is Transparenly without thought and it's what you revert to under times of stress So I might not always red green refactor, but When the build is down and I'm in a rush and I've got a manager bringing breathing down my neck I always do All right, I might not always pair program I do a little bit of code just exploratory or whatever, but system downtime. We're pairing 100% absolutely without thought. We don't even consider doing otherwise. That's a team that's fluent at those practices So the interesting thing is the results that you get Depend on the outcomes of the practices that you're fluent at not the ones you're aspiring to You get what you do in your in the worst case when the chips are down because it doesn't take that long of Reverting away from TDD before your code acts as if You didn't really TDD it So if you want to focus on the outcomes you need to focus on what you're fluent at not what you're aspiring at and yet What most teams and people and managers reward and look at is what are we aspiring to do? What do we understand? What do we do? Most of the time when things are good, etc. All right So what I often find one of the uses of this particular model is it identifies a bunch of different practices I mentioned red-greener factor, you know done definition having a clear definition of what does it mean to complete a piece of work? whether that's a story or a particular commit that you're doing or a organizational change that you're making or a management task or you know Bothering to have a definition of done that you state in advance, right? That is a practice and Again, some teams are aspiring to it. Some teams are fluent at it Some people some teams don't really think about doing it at all right So what I find is that a lot of teams typically start out desiring To do all these things over on the right They want to do lead startup and hypothesis driven development and they want to do continuous deployment they want to do evolutionary design and All of these great wonderful things and bug zero not have bugs And they figure that it's not actually that far away They just need to do a little bit of CI and and a couple of tests and they can see you know Automated rollback as a thing that oh, yeah, we're gonna we're gonna have to do that But then they have no real visibility because they're aspiring to do all of these things They feel like they're pretty close But then when you ask them what they do when the chips are down what they do by habit They're over here Like do you have a single assignment team that every team all the time has only one assignment? And it would be absolutely mental for anyone in your organization to ever give a team two different jobs If it would be seen as absolutely crazy and the manager who tried to do that would not so much be fired It's just kind of looked at funny Then you probably have single assignment teams if not you might be aspiring to them But you're not fluent at it yet All right, and so I see a lot of companies out there that are Aspiring to all of the things on here, but are actually fluent at none of them And that's what the two to three years of technical evolution really looks like It's taking all the things that you've heard of all the things you aspire to do all the things that you do some of The time and actually becoming completely fluent at them Having it be so that all of your systems just support them as the normal way of doing all of your culture Supports them as the normal way of doing all right that it would be that when someone new comes into the organization In the first couple of weeks that where they're just sitting there They're just you know joining the team and sort of following along They naturally and immediately start exhibiting the behaviors of doing these things because it's just the way you do things all right, so What we're going to look at Starting basically now is what does it look like to attain real fluency at each of these things that you do all of them without thought and What's the ordering that matters and You'll note as I had this thing zoomed out There is not a linear sequence This part's sort of a mess There are a whole lot of things that all sort of depend on each other I know you can't read them at this we'll have to zoom in to so you can read things right But just sort of looking at the lines the dependencies are all over the place. There is no single linear sequence And that's fine you and your team will choose what your sequence is based off of what your Where your value delivery is going to be and what your context is So Just want to start Exploring this a little more deeply So what are some let's just start with what are some practices that your team is Aspiring to do doing it okay, but not a fluid up having occasional trouble with Or some team at a company, you know deploy okay, so So that's so this is an example of part of the reason that I first wrote this is a lot of the terms that we use People use to describe what actually isn't just one practice and when you say deploy and he says deploy and I say deploy We mean three entirely different things that to us are each deploy right So I'm gonna need to ask for a little more nuance on this and I'm going to with everything that everyone asked if you said refactoring or TDD I've observed 14 different definitions of refactoring and seven different definitions of TDD So deploy fewer but so when you say deploy, what do you mean by that? Okay, so fast automatic deployments. Okay, does it include the ability to automatically verify whether that deployment is Worked correctly after the fact after it was deployed. Okay, does it include the ability to automatically roll back? Okay, does it include upstream automatic verification or before deploy or Are there allowed to be manual steps before deploy? There can be manual steps before deploy. Okay, so What we're talking about here? Come on screen Is this one automated deploy? Okay, well, we've got some automated build verification going on Right But if you go look further to the right of automated deploy there are some of the things that I asked, you know Like automated deploy verification This is this is where you're starting to do a bunch of smoke tests to on your production server all of the time to see After the fact whether your systems are running and the like and automated rollback and all sorts of things that are in the future of this, right? So the first thing is if we're working on deploy scale it right and make sure we know what we're looking at Right if we tried to do if we're in the system here that he's describing where we're having trouble with automated deploy and We might be having trouble down here, right and we included in that trying to do automated rollback Life's gonna be hard and I don't like hard, right? So let's get this one working. Well, okay, so automated deploy Do you already have an automated build verification? Okay full CI for the whole system with automated verification? What was it? Sanity checks, okay, so there's still some manual stuff that's going on as well, okay All right, so Okay You already have automated packaging all of that stuff's already in place, okay You've got some degree of automated developer testing going on Okay, all right, so it's sounding to me And I'm not asking enough questions and you would really need to answer it but but my impression is that you're fluid at this level, right and You're aspiring to automated developer testing, but you aren't yet fluent at it and you're aspiring to automated build verification And you're aiming at fluency up here and so this is one of those examples where I'd say great Yes, deploy is the goal and there's a bunch of things that we want to do to improve the goal And so we're gonna set that as the goal and we're not gonna focus on it at first We're gonna focus on a prereq, right And then we'll get that prereq and get fluent at it and then the next one and the next one and then the goal and This one it sounds like you're only two or three prereqs away, but I would start by okay How do you become really fluent at that automated developer testing? And automated build verification so that you can deploy it without those steps Yeah, now you still can be doing the deploy that depends on the manual steps and whatever else that's aspiring level And that's better than nothing right that's better than we deploy by Manually overnight five copying a bunch of files and hoping that we end up in the right place Definitely better But getting to full fluent level will require fluent level at these pre-reqs So what's another one that some people are experiencing any old? either a problem that you're having or a practice that you're You're not yet really fluent at and you want to become better at fewer bugs Okay, so that's a good one So when you say fewer bugs Everyone aspires to having fewer bugs What is the definition of a bug? Okay, so Definition bug includes that it is visible to a customer. Okay. All right and then When a customer gives you a complaint Are all of those complaints bugs or are some of them not bugs There's no right answer to this question, right? It's it's with your team and in your context is is every customer call to your tech support line for example a bug Or not Not okay. All right so you're focusing on Then reducing the bugs that are customer visible that pass some particular screen and I'm not going to go into depth on exactly what that screen is But you have an intuitive sense And I assume that actually a lot of you are in a similar case and you all have different screens But you have something that's that's there that's the difference between a customer complaint and a bug and you're focusing on the one Category and not the whole set That's a pretty common state if You were over that tells me that you are over towards the left side of this chart If you're over towards the right chart side of this chart Like bug zero, which I'll be giving you talk about that in a couple of hours The definition of a bug that teams use over there is if it would be visible by a human That human could be another dev that human can be me Just in the short term in your future If it would be visible by any human other than the person who is actively writing it right now So if I check it in to source control Even if I don't push me if I check it in it would now be visible by a future me That's a bug Right and the definition of a bug is anything which frustrates confuse or confuses or annoys a user WTS all count right any call to tech support would count any dev who looks at a code and goes huh bug It's a much different definition of bug Right and both definitions are okay That's the first thing is that yes if we want to get all the way out here and really be living the life of not having any bugs and Really cool things that are over here We eventually will need to acquire that definition But we're probably not there today So we shouldn't take on that definition right now because it will just drive us freaking crazy so if I'm over here probably And I would guess if we if we start looking at the things that lead into Getting rid of bugs. There's bugs decreasing over time, and then that has some pre-rex. There's no bugs in new code You know we accept that all of our old code has a whole bunch of bugs and that when we modify old bugs old code We still introduce bugs, but if we're writing new greenfield code We can do it without bugs in any way right much narrower definition and useful step along the way All right, and then I'd start looking back and I'd start looking at you know Typically the ways that you're getting to no bugs in new code involve a number of things So it directly depends on being able to test units and actually being able to work together for discipline All right, so this is an interesting one because We often look at the pre-rex of these things and you know no bugs. Oh t2d that should solve it And things about refactoring and things about testing we get we lump those in and yeah, that makes sense but pairing or mobbing Also huge impact on defects in fact, huger If we look at Corey Haines does an interesting experiment on himself every year which is He does a whole bunch of different projects over the course of the year And there's some self similarity between them and they're small relatively small you know four or five month projects and For many of the projects he applies all the various techniques and everything that he knows and then A couple of times a year he intentionally drops one practice So he'll do all of xp except i'm not going to pair or he'll do all of xp Or except i'm not going to write any automated tests or all of xp except I will never refactor I'll write tests, but I won't refactor Or and so on and so on and so he's able to see what is it that each benefit? What are the benefits that each practice brings? All right, and so he sees that for example Testing doesn't actually decrease his bug rate What he finds is that in every project He gets better than the project he was before He's able to deliver more value with less effort with fewer defects than the prior project except If he didn't do tdd on a project then his next one is the same as that one Tdd's purpose is learning for the future That's the value it delivers Refactoring drops bugs pairing drops bugs Mobbing drops bugs so That's where it's it's interesting to look at some of these and another one that's that's uh really interesting is several of these You know no bugs in new code really depends on Some some of the stuff about learning and retrospectives All right, because root causing defects is a primary way to eliminate them So um what I would suspect is that with the definition that you gave You should probably look more towards the left side of this graph And there are a number of these things probably around refactoring That the team doesn't do or doesn't do fluently And I didn't ask any questions. So that's that's on the basis of guess not data But I guess it's probably true. Um, and so those were those are the things I would start looking at Yeah Why after can anyone answer that question? I believe in the simplest talk that could possibly work. So I'm not going to answer things you are Why does yagney and simplest uh and simplest thing depend on bug zero In particular, why can't you do yagney if you're still introducing defects? You're not feature complete Yeah, yeah, that's that's part of it other things What was that? There'll be hacks in the code Yeah, so the practices that lead to really being bug zero Um and being able to to maintain Not writing bugs in the first place Require a tremendous amount of discipline and they require that's where you do a lot of the learning to be able to Make a change in a small chunk without breaking anything All right, so what happens if I design a system using yagney and I don't have the ability to Then in the future change it without breaking anything What happens when I change it in the future because? Simplest thing that could possibly work today guarantees. It's too simple to work tomorrow Right, so I'm going to have to change it. What's going to happen when I change it? It's going to break It's too risky for me to do simplest thing and simple design If we're in changing that design, I'm going to break it plan ahead Predictive design is a great freaking idea. In fact, if you go look at it over here There are a whole lot of things that do depend on it You know some of the predictive design pattern oriented design big design upfront Those are good practices and I don't have hard dependencies on things because I haven't been able to figure out exactly what the hard dependencies are but these deliver value and being good at those things Is a really good and useful thing that will make it easy to do other parts of development right and as you go on and as you bring on other capabilities You can start getting reflective design for example where you've got both predictive and reflective going on somewhere I'm sensing what's going on in the code and so on right and yeah It's not until I've combined all these capabilities together that I'm ready to actually just do yagney If I were to do it before then I'd have some problems Yeah So reflective design includes don't over design Right, which is different than full on yagney Yeah, yeah, it's it's it's uh, yeah rather than simplest over simple thing. It's Define something that's Not crazy complex that we reflect that we do something and then we reflect on what's there and we use that to simplify Right. Um, and so the concepts Like yagney again yagney is one of those like tdd that's it means different things across these levels and it's absolutely worth thinking of red green refactor when you're down here And just starting to talk about refactoring because what red green refactor tells you when you're just learning refactoring is I should separate changing behavior from changing design That's an important and useful thing That's the only benefit that you gain from thinking red green refactoring at that point And it becomes a far more specific nuanced thing later when you have other capabilities But it is absolutely Shows up here and yagney and simple design do show up They're a good concept to keep in mind And they show up in various forms throughout these things But but when you hear like when you observe the way that ward codes things Ward cutting him codes things, right? He's he's doing this kind of yagney that for most of the rest of us result in broken systems Yeah, okay, so um a couple of things about this first this chart The chart itself this is based on my experience and the experience of a few people Several people out there that I know It is hosted on github Um, I accept poor requests. I hardly encourage poor requests I do not claim that this is perfect. In fact this morning I was talking about it with nicole and we were Because she has all this awesome data about continuous deployment and continuous delivery and I asked so what's missing And she filled in, you know this build fast enough trunk based development feature flags those elements The ones that look like they're sort of in a funky place on the chart I identified the right dependencies, but I don't know actually where it sits on the chart yet because that showed up this morning So This is live and it's intended to to change as as we incorporate knowledge for more and more people Please send some poor requests and participate And all you have to do to do so Each of these that one's boring. Some of these are boring. Um, some of these people have filled out already So some of these we've we've filled out, you know, what it is the benefits that it gains Um the key mind shifts that are necessary in order to get there Um A lot of these I see punctuated evolution. I don't see teams just sort of getting a little bit and then getting a little bit they sort of they are Aspiring and whatever and then suddenly there's this mind shift that happens and they think about it in a different way And they become fluent very quickly after that and so for a lot of these there's that core mind shift Um, and this one, you know sitting together The mind shift is that we're switching from I need some quiet time to do my work to Work is a collaborative thing And that's the mind shift that switches it from sitting together. Yeah, occasionally too. Duh right And then some stuff about acquiring the skill entertaining fluency and recipes and so on so People are contributing those as they discover practices that work well for their teams and I'm continuing to push those and recommend so Anyone have one of these That your teams have recently done and become pretty fluent at Just if you don't know exactly what it is on the chart just a a skill Or a practice that within the last three months You went from an aspiring level to a fluent level at Yeah, I'll work visible on one board. Okay Cool Great So Let's edit it So the data for all of this is a big jason file Um, and you can live edit it on the page and then when we're done editing um, it will have Updated the jason blob that's right there and we just Copy and paste that into the file that sits in the thing and check it into source control All right, so anyone at any time can edit Whatever we want so Sounds like your team has some insights for the world On our work visible on one board so So I think now it's become central to what he means To get the board and let everyone else in the team know what I'm doing now or where I'm starting Okay Yep, so you described some of the value and some of what it is Okay Okay So let's go ahead and do uh, how it helps more specifically What value have you seen out of really becoming fluent at it about becoming your norm? You've got to spend less time doing a question answer session because everyone knows what they want to share with you So you cut down the amount of time spent in asking people what they're working on instead it becomes a deep dive sort of time So instead of me asking you about what you do and then the next guy spends five minutes telling me what I just let everyone do the updates in 10 minutes and then Whoever needs to talk about something It helps Okay, so I heard a couple of things from that right so um It cuts the status out of status meetings And in two ways right Both in the way of tell me your your status what's going on right now and and so on and the other way of In any meeting in which you are describing what you're doing and everyone is everyone is basically justifying why they have a job And you see status fights effectively of oh these were the things I did yesterday and I'm cool And as soon as that gets out of the verbal and just on to a board and what's saddest well there Then a lot of that one-upmanship fades from the meetings and it becomes much more about what you were describing problem solving Come So what were some of the techniques? That you did I skipped several of these steps Pre-rex recipes What were some of the ways that you attained fluency Of using the board to write that So here you wrapped a process one of your existing processes you used it to wrap around the thing that you were trying to bring on Okay Yeah Yeah, yeah, so what I was What I first heard you say Might not have been right was that you were you had had regular meetings of some sort around Status and what was going on and then you changed that meeting at the same time as you introduced the board in order to Incorporate and use the board Yeah Okay Yeah, so that's a that's an important thing That's actually a general practice right if you're trying to bring on a new thing and make it fluent Incorporated into the things you already do fluently Right and something that makes work visible fits really well in the place that we're trying to see what the hell's going on Right But you but similar practice approach works other places as well When I'm trying to learn to refactor When is the time that I should refactor code? thoughts All coding is refactoring. I disagree sometimes. I'm changing behavior Sometimes sometimes in order to to verify whether I did something right. I have to run test in which case. It's not refactoring If I'm refactoring if I'm really refactoring I don't need to run tests to know I'm right I can refactor just as cleanly on test free code as on highly tested code And just as safely So when do I refactor? By the way, this is a very different This is the much closer to martin fallow's original definition of refactoring than most current definition Most current definition of refactoring is oh, I changed the code I don't think I broke anything All right, but when is the time that I can I should most That I should really focus my intention on improving the design In known safe ways that are guaranteed Bug for bug backwards compatible What was that? After you took a green line after green Yeah, so during writing of the code when I'm doing the initial writing of the code Yeah, so that's the answer that a lot of people give and that's because that's the answer that a lot of people have been teaching for a very long time I actually find that when you're writing the code is when you have the least idea of what the design should be Because the most important thing about code design is does it convey intent? And at the moment that you are writing the code You already have all the information that it should convey in your head Therefore you are completely insensitive to being able to tell whether it conveys intent at all So the time that you should refactor is when you're reading code That's the moment where you don't know whether where it either conveyed intent or it didn't All right All right, and so that's that's another example of exactly this case if I'm trying to bring refactoring on If I bring if I tell people to refactor at the time that they're writing code Then they end up with a very sloppy definition of refactors. I'm writing some code Oh, I think that design doesn't work and back and forth if I say no, you need to do it when you read code So I need you to do a practice that is for It's legacy code. So there are assume there's no tests Assume that the thing is unintelligible and the way that you're going to read it is to Refactor it and I want you to have the same defect characteristics as other ways of reading code Which means you know way know how ever introduce a new bug or accidentally fix one You bring on a very different definition of refactoring Very naturally, right? It's that same technique of wrap it into an existing process So um I've gotten the magic flag that says we're supposed to shift out of this kind of q and a to the other kind of q and a Which is somehow different So feel free to ask any arbitrary random questions if you haven't already Is b to d on here So b to d and t to d are both terms that I explicitly Did not put on here because they mean so many different things to different people However, many of the things that people mean when they say b to d are on here and at many different ones so When people are saying b to d one of the meanings is Having a clear done definition one of the meanings is Somewhere I have test a spec Um, I don't remember where it is, but it's trust me. It's in here somewhere. I just not seeing it at the moment Oh, there it is right here Right, um, and there are a number of other meanings as well that show up Some some people use that to mean integration testing which is over here on the left automated integration testing So yes and no both Yep anything else Okay, then, um, I hardly encourage you to play with this do whatever You find useful. It's up on github um on my github Arlo Belchi, um, you can also get to it at bitly slash agile engineering stages Which I will tweet the url right after this talk because I don't have any slides for this talk So there's nowhere for me to write the url. Oh, yes, there is I believe There we go I put it on the document There's a pdf version that I update every every so often Um, as well as the uh, the live version Um, if you go look at this right now, it's got some changes like the ones from this morning that are not incorporated into master yet I haven't accepted my own poll requests Um, but I continue to do that and that will generally be the case. So I encourage you, um, please use it However, you find useful. Um, and when you do make a transition and become fluent at something if you can Record some of the things that you did that worked and incorporate that for other people to share. Um, I would hardly appreciate it So thank you very much