Agility ≠ Speed - Kevlin Henney

this is the third time I've given this talk it turns out that although I had proposed it here first I then went and gave it it to other locations beforehand so this allows me to recall Alan's observations about you know whether or not a talk is new and so on so this is I I never rehearse my talks or rather I've rehearsed it twice in front of live audiences and they still survived they're good you know there are actively witnesses so we're good so what I want to talk about is this charity does not equal speed and it's an emphasis for nearly in equality worth making I was gonna leave out discussion of books but Alan promoted his books so hey I've got books I've got photographs of my books I got more books you know hey and here are some pictures of books that are not by me because I like taking photographs of books actually have a mild obsession with words I don't think Patricia is in the room but I'm just gonna say can you say absolutely okay 50% of the speakers have said so it's normal it's just that she noticed though I am obsessed with words I think words are interesting because they are the vehicles of meaning and when we develop software we are developing systems of meaning we understand a misunderstand so I actually run a page on on Facebook called word Friday where I explore words language and stuff like that just posting ferrous bits and pieces but I also like coincidences so here's a nice one it arrived it was delivered it was delivered a couple of years back I just thought Oh brilliant Yeah right my wife is all for let's open it and it's just like no not until I photographed it so yeah this is an agile package it must be true because it says so and we use the word a lot we use the word agile a lot and what do we often mean by it well it turns out there are various definitions we can find online there are various definitions in books but let's go back to a simple dictionary definition if I find a simple dictionary definition concise OAD it's an adjective that's the first thing to notice it means it's it's a property of something you make an observation upon something okay agile is a judgment is not a thing that you do you can do scrum you do Kanban there's all kinds of things you can do but whether or not you are more or less agile as an observation you make upon something which means you need to observe we're going to come back to observe and there's a this is one of the nicest I I'm sad enough to own lots of dictionaries electronic and physical and I found that this is actually one of the nicest most direct ones able to move quickly and easily that actually says everything that you need to know able to move quickly and easily but what normally happens is people kind of odd you know there's so many words up there oh my goodness that's six words in the definition people kind of peter out after the fourth word and we end up with able to move quickly which for those of you with long memories takes us right back to the early 90s rapid application development or rabbit and application development as it was also known people moving at speed to develop stuff and churn it out no matter what we were filled you know our screens were filled with no matter what yeah this was not good again I use the word so we've ended up with an oversimplification many executives want this many people read this they say okay we're moving quickly now agility implies something else you know when I think of agility if I think about quickly and I think about speed and people love sporting metaphors when I think about speed I'm thinking Usain Bolt when I'm thinking of agility I tend to be think gymnastics these are very different things they they have a very different quality and one of the things about Hussain Bolt is he's one of things he's really good at is moving in a straight line great speed we need to talk about speed so it turns out what we have here fundamentally is a problem with our relationship with time one of my favorite quotes Blaise Pascal I've made this letter longer than usual because I have not had time to make it shorter applies to many things now I've seen this attributed to various sources people have quoted Mark Twain Abraham Lincoln I mean you know leave it long enough and the grumpy cat will have said this eventually but it is actually it's from the provincial letters here's the original French so we do know from the 17th century this was Blaise Pascal and it's to do with time this is the bit we struggle with as humans we are not gifted with a good sense and relationship with time how we judge it how we judge how long not only how long things take but how long we devote to them even during a period of time if somebody says what are you doing if you tell them you're probably actually not telling them the truth not dishonestly you're actually not very good at judging how you spend your own time we have a very poor relationship with time indeed it turns out we have a very poor relationship with how we judge things I'm going to talk about value a couple of times let me first of all quote George best the late George Best Northern Ireland footballer played for Liverpool did really well in the 60s 70s sadly I had a hell of a drinking problem huh yeah well here gonna get to other things sadly he had a bit of a drinking problem but he did he was a source of good quotes I spent a lot of money on booze birds and fast cars the rest I just squandered now that is an interesting thing because it also tells you from that person's point of view what they value it's because we often sort of assume that the business when the business states the things that it cares about that everybody believes that or sees is the same thing it turns out that's not true because it turns out and this is the big news the business is not a single entity we have a problem we often use what we might call unified anthropomorphic entities feel free to just drop that in a conversation any time ok a unified anthropomorphic entity what we've done is we've said the business is if it were person unless the business actually is one person then it's not a person it's a group of people and group groups of people behave like groups of people they pull in different directions they have different objectives they miss read one another they try to pull together but they also have their own agendas and understandings of things okay so therefore when we say the business thinks absolutely it doesn't is the one thing we can be sure of the business wants no it doesn't there's somebody that in the business that wants that but I bet that somebody else has got a different take on it or you're using the same words but you come to a different conclusion about the value but in also so we end up with these kind of false ideas we've unified them we've made them human but we're also very poor at prioritizing things this this from a conversation last year I can't get this co-working did you check it before integrating it yes I checked it in the interpreter did it work there no now in this you see a number of things at play one is an individual sense of urgency we've got to get this out there and the second is something that we find across many people involved in software development unconditional optimism you have it if you don't you might not know that you have it but you have it because otherwise you wouldn't be in this you know discipline you somehow you believe it's all gonna work out okay yeah and all of the evidence and you go yeah evidence we like evidence yet all the evidence says no you're wrong and still we go on but in this let's just pick up this pat we're not very good at perceiving these things but also there's this question of speed we find it enshrined in engineering mantras this is not Facebook that invented this saying but actually Facebook helped popularize it move fast and break things notice the urgency in this it's just like it's always like get out of my way I'm doing cool stuff yeah this is fine they're actually one you are doing cool stuff and two you're not actually hurting anybody there are cases for this if we are free to experiment then that's great but it turns out that people get are involved and people get broken people get trampled on it turns out that this is actually not OK in a number of contexts but we are obsessed because it distills this obsession with speed now we do have an obsession with speed but sometimes we reframe it sometimes we use different words and as I said I'm obsessed with words unfortunately I also have a degree in physics somewhere in my past how did these two match up because people use the word velocity don't let me catch you doing this speed and velocity in common parlance are the same thing but they're not the same thing velocity has direction but turns out most of the time that people are talking about the loss to the actually means speed when they're talking about their development velocity they mean speed I don't care if they are using story points or not if they are using a linear measure and the chances are they are then they are talking about speed they are not talking about velocity velocity has direction it turns out direction matters yeah call me old-fashioned but heading at 150 Keller yet this is one of the things I love I love going to Germany I love I do a bit of work in Germany on occasion I get to to rent a car and there you are on the German Autobahn and you sitting there going like yeah this is it I have no speed limit and your crew yeah you're shooting on 150 160 km/h and then something overtakes you it's normally black it's going too fast for you to tell whether it's an Audi or Mercedes or a BMW but it's normally black and white okay that was about 200 yeah yeah and you're thinking yeah I am the king of the road except for that guy who just overtook me at speed I am the king of the road and I remember that one experience one time when I was driving along at great speed and then realising the Sun was in the wrong place I realised I was heading in the wrong direction does Direction matter no I'm just got to keep driving until you know maybe I hit Denmark actually I only used to be driving south so the point here is Direction matters I would have been far better off walking in the right direction than driving at speed in the wrong direction and yet most projects are quite happily going off yet we are optimising we are going in that way yeah but we need to be going that way yeah but we're going that way and what it what is direction well direction is what is it we actually want to do how are we doing it we doing it well what's our technical debt or our practice is any good these are all direction and therefore they require us to understand that so most the time we've ended up oversimplifying it we've ended up reducing it to a complex multi-dimensional concept velocity we've reduced it into simple one-dimensional thing the problem is that when you measure things in a one-dimensional way if you make your objectives one-dimensional your results are also one-dimensional with some curious multi-dimensional fallout ah you sickin their thing you're like damn I didn't know there be equations yeah lock the doors don't let anybody leave here's another way of looking at it we're going to change things this s normally stands for displacement but given that we're talking about software I'm gonna use some technical terminology here S stands for stuff okay stop me if it gets a little bit too techie here okay stuff we're entirely sure of the nature of stuff but we're developing a lot of it because we can measure stuff in lots of different ways and stuff prime basically means the rate of change of stuff with respect to time okay how much stuff are we changing per time let's keep it simple okay it's just imagine we're doing this constant velocity well this is the problem we end up with graphs like this yeah your classic burn down which is always presented the ideal version is always presented as a straight line I've always wondered about that one I find that slightly disturbing it seems very not human yeah humans don't really we're not very good at straight lines even when we're sober honestly the whole thing about this is representing a development of a team perhaps learning about something new I don't expect a straight line I'd be suspicious of a straight line it's one of those things of like and from one of the things I learned doing physics and should I admit this oh it's on camera okay might as well admit it one of the things I learned was how to fake results convincingly okay you could go to the pub sooner and it takes a great deal of skill to understand how to fake results properly this is probably why I don't become a physicist is you need to know what you're actually expecting things don't work out in the ideal way this obviously fake yeah that's not how it looks but this is a burn down chart I tend to prefer these and we can combine everything and call it a cumulative flow diagram if we wish sometimes people call this a burn up chart now as a father and therefore somebody with children burning up is not good that means the kids have got fever you know it's just like Oh 40 41 degrees that's a little bit hot you're burning up this is bad I also have a mild obsession with spaceflight again burning up bad thing I like I like constructive terminology this is a build up chart we are building more stuff with respect to time but again we are left with the question of what do we mean by stuff so you know what's what's really great about coming to Sweden is the opportunity finally I get to talk about sex in this talk perhaps S is for sex perhaps we are talking what we're doing is value because we often use this for cadbury of value which oh yeah we're going to prioritize by business value we can do this by value I have some bad news for you you can't prioritize by business value it's actually not possible this is not a sort of an ideological thing clearly the pursuit of value can lead to some problems as this Tom Tarot a cartoon highlights yes the planet got stroyed but for a beautiful moment in time we created a lot of value for shareholders there is a notion here that we've got a wonder if we make it a one-dimensional objective we get we get what we we measured but there is a there's something much more fundamental here you cannot prioritize by business value for a simple reason you don't know the business value yeah nobody ever knows the business value unless they have a time machine I have a time machine it looks a bit like a toilet but let's just leave that as it is because what you are doing you can prioritize by an estimate of business value feel free to do that but next time somebody says I we're prioritizing my business value so how do you know because you don't know the value of it until you go into the future you can prioritize by estimated business value and an estimate has a shape it is not a single number it is a probability distribution so therefore even if one thing is probably worth more than another it may have a different range it actually gets slightly depressing when you start looking at this and you say we can say nothing about anything but no but there is this notion just temper your vocabulary it means that when people are saying we're prioritizing by business value but you developers have to give us time estimates they're not using the same rules for themselves it also is this also means it's something you can learn from so let's go back to this how do we measure this in pursuit of measurement well a little more dimensional analysis it turns out that we measure time as time who knew we have a choice here the time that we spend developing can be measured in hours it can measured in days there are lots of different ways to measure that how do we measure stuff turns out people are very fond of measuring stuff in terms of time as well which is slightly unfortunate really now a lot of people don't know they're doing this few years ago there was a very explicit I noticed a lot of the scrum literature has appeared about ten years ago where people were talking about your product backlog should have estimates and hours and you should have the hours I started thinking that's really dodgy and it was actually visiting one company and seeing this I said you do realize you're plotting hours against hours you know you haven't actually told me how much stuff you're developing but you told me how long you basically you're either measuring your utilization which may be of interest but if you actually wanted to measure stuff per time like you know velocity and perhaps even true velocity not just speed you've got utilization or you're measuring the quality of your estimation but you're probably not measuring how much stuff you're developing now we've got clever since then we sometimes go through levels of indirection so ah we're not going to use time man we are so over time we we use story points and somebody says yeah but don't those represent no that's the team thing and whatever yeah okay but can can you give me a conversion rate to time and you know what happens when you have a conversion rate you've got an exchange rate do you know what happens with exchange rates speculation economics happens yeah bitcoin happens yeah all kinds of crazy stuff is I have bitcoins of currency no it's not it's a speculative asset as indeed our story points in some organizations in other words they get base to come to economic pressures social pressures which are actually utterly independent of the whole goal of hey we're developing software we're trying to develop the right thing really well somehow that's on that's somewhere on the far horizon we're playing a different game all of a sudden so this suggests that we pay a little bit of attention to things now the OODA loop was introduced to me by a friend of mine John Jagger we've run a number of workshops together on various things and John read biography of John Boyd a US Air Force pilot who basically changed the nature of or the approach that people would take to fighter combat and what I think is interesting is that if we go to the kind of top speed or sorry Top Gun approach of thinking about fighter combat then the need for speed is the kind of catch phrase that comes from Top Gun you're always the guy it's it's about speed you look at these vehicles ridiculous amounts of money spent on things that go incredibly fast and you're thinking it's all about speed yo I like about this is that his whole approach and this this got popularized in the business literature by the way any military idea will eventually become popular in business literature yeah those of you remember the 1990s Sun Tzu was really popular the art of war okay that's yeah it's just like every military man sure becomes a business mantra at some point so doodle-loop is popular in certain circles but I don't think people pause to think about what it really means so observe look look at what's going on see what's happening orient yourselves this is where we understand the notion of velocity involving direction where am i where do I want to be this is a really interesting question people sometimes get so absorbed in their sprints so they actually forget where they are or even where they want to be in fact sometimes they say how we want to be at the end of the Sprint yeah decide develop a plan for action make it so okay let's let's carry this one forward now this is interesting because notice that most of this is not about speed the only bit that's about speed is this bit everything else is actually about the exact opposite take your time look around don't shoot past whatever you do don't don't respond to instinctively use use both system 1 and system 2 type of thinking ok have a look at what's really going on now John and I one day were discussing because you see we were discussing which loop because it turns out in the business literature there are lots of loops so let me just flip this one through 180 degrees decide act observe orient it was when we were trying to combine some of our taught material because I said well I'm a big fan of PDSA and it's at that point we suddenly realized that the two things were identical plan do study act yeah the act the words are slightly different but if you look at it develop a plan for action plan okay we call it plan there okay do it that's called act in this case study that's your observe let's have a look orient yourself where do we watch you want to be act so the words shift ever so slightly but you can see there's an overlay there many people know this is the plan do check act cycle PDCA but it's original formula both by Deming and by Shu heart was a study and I prefer the word study for a very simple reason it sounds slow the word check sounds quite fast yeah I gotta check that done how long does that take oh I checked it in just moments study you can't study quickly the word says slow down so what I'm going to try encouraged you to do here is slow down now Alan took you back to 1970 yeah I'm an older baby I'm gonna take you back to 1968 in fact I've this year I've been pushing a talk called 1968 because it turns out an awful lot happened in 1968 from a software point of view but as of yesterday was the end of the 50th anniversary of this very key conference the NATO sponsored software engineering conference in garmisch this is probably one of the most widely quoted and most profoundly misunderstood conferences in the literature because it turns out nobody ever reads it what I love about the Internet is the fact you can find all of the proceedings so I sat down and decided to read it and what I found was not a group of people who were desperate to apply bridge building metaphors to software development you found a group of people who had very diverse thinking they didn't all agree with one another but they had thinking they were thinking they had some really interesting ideas about software development crazy wild ideas a lot of which they actually agreed on for example this one this yeah okay we've been a little bit slow on this one this was 1968 we might say oh no what happened I don't know disco Flair's I you know something happened in the 1970s we don't know who to blame yet we're looking for them but there was some fresh thinking out there in fact the whole thing is filled with vocabulary like oh unit tests I actually thought that unit test was the 1970s term there it isn't black and white 1968 acceptance testing oh you've got that as well yeah modularity not it's not a child of the 70s as many people think it's a child of the 60s yeah 60s great decade Neil Gaiman's has one of my favorite authors has this to offer when we're going to start talking about these iterations these changes these cycles these loops he makes a very simple observation you have to finish things that's what you learn from you learn by finishing things this is taken from a speech these giving to people who have a creative career in mind and software is one of those creative things that humans get involved in sometimes and this is one of the funniest things that sometimes you get you go to some organizations they say oh we got the developers and we got the creatives yeah you got that wrong honestly developers might not paint for art is a fairly rare skill in software I've discovered but the chances are they might play music they might do all kinds of crazy things it turns out they create software that's crazy enough oh you're creating something out of nothing wow that's pretty cool using the power of symbolic logic ok this is totally Harry Potter I'm going to use don't even use fake Latin I'm going to use symbolic forms to create Kundra from thin air a whole set of ideas and we're going to do this together as a team we're going to construct something that doesn't really you can't even kick it and yes somehow it has an existence yeah it's just like you know people would be burnt at the stake for this kind of stuff few centuries ago so we're kind of familiar with this idea we have this side oh yeah this is all refactoring no I want to bring something else here refactoring when we talk about it is that there is this in the writing community they say writing is rewriting is writing and writing is rewriting and there is this idea that sometimes people say oh you're going to do the design and then at some other point there's refactoring it's like oh no refactoring is design there's not just one kind of design there's many different kinds there is the I have built it and now I'm looking at it and I'm understanding it now that I've built it because sometimes you don't understand until you do it another funny thing about the word do that word agile why do we use it it comes from the Latin Azure a which means to do so it turns out a j'l is a doing thing you actually kind of have to do it and that doesn't mean schedule a meeting to showed you the meeting to talk about doing it actually means we're going to build it and then we're going to learn from what we built and what did that feel like how did that go how we doing and when I talk about code I talk about code in the broadest possible sense gotta sometimes watch out because developers have their own favorite idea of what they mean by code Oh code for a Java developer I'm a Java developer therefore that's my code this is my tribe and this is my IDE okay that is code don't you guys also do some JavaScript yes but that is not my code isn't this an XML in your project yes but that is not code and it's got a formal definition language and humans can't read it do you remember when XML was pushed as being human readable who were those humans yeah all of these things configuration files these are all code these are all forms these are all code so your tests your scripts all of this stuff these are all your code you might have a preferred thing I am a Java programmer and I do this I am a c-sharp programming ideas yeah but it's all code it's all codified knowledge this is the most important thing we can think about what you're dealing with is a code base is a knowledge base it's a codification of collectively as a team over time his stuff we believe we know we have codified the way of trying to use these technologies we've codified what we understand to be the business so it's a kind of an executable knowledge base which is kind of cool what does that mean for our development process it means the development process is a knowledge acquisition process if knowledge is what we are trying to get then the process of doing it is a knowledge acquisition process this is really interesting because we know a few things about that most of which comes from outside software development but yeah by the way if you're looking to use this phraseology I strongly recommend using this kind of vocabulary in presentations and in reports especially to higher-ups you know feel free to you the rest of us will just call it learning but knowledge acquisition sounds a little more you know impressive doesn't it yeah so what's the basis of your development approach oh it's knowledge acquisition because basically we're creating an architecture of codified knowledge oh wow geez we're just learning and stuff you know we're coding a bit and yeah but that's what it is that's what's really going on and then we start saying well hang on that that means it's not a production process because we know what learning processes look like they're cumulative they're revisionist you learn a few things you revise if you thinks you forget a few things and you kind of come around you're trying to find how do I understand the subject as a parent of as a parent of teenagers I get to see this process on a on a weekly and daily basis the very process of learning and how they understand certain subjects and how they improve in them it turns out that it is not a simple waterfall approach okay it turns out that it is a little bit messy it has a general direction but it accumulates and it revises itself refactoring is the kind of it it's a lowering of the center of gravity it's like ah okay I realize how these ideas are one what I was presented to me as many ideas in fact I had this moment with my younger one a couple of years back so what did you do at school he likes maths say yeah we learned about ratios oh that was that he kind of looked at me said well they're kind of a bit boring dad oh oh they're the same as fractions which are the same as decimals which are the same as percentages okay this is why he's good at math he'd realized that it's just oh it's one idea with four different presentation layers okay fine that's it he's realized he's unified the ideas but sometimes it takes us a while sometimes it can take his years before we realize oh now I understand the business now I understand the technical solution okay that you can't speed that up but you can build something while you're doing it to do it you're not going to sit there just thinking hard you've got you've got to do so it also means that if this stuff is knowledge and we keep talking about the team then the very act of doing this stuff is an act of communication your codified knowledge base needs to be communicated and the needs to be supported by communication around it curiously enough what this means for our code base is that our code base and while guidelines are a form of social negotiation okay which is news to a lot of developers who think no coding guidelines are about me being right and being able to tell other people that they are not right okay yeah partly but you know you're not the only one who thinks they're right so social negotiation that's what it's about which also gives us a different insight into software architecture software architecture is is a model of participation what you're doing is you're telling people this is how we work together you know this is how we join together this is where code gets changed this is how we as a team collaborate share knowledge and add to it so there's an interesting point here about how we think of teams and this idea and this idea of knowledge it turns out that if we care about this idea of knowledge then what we're talking about is intelligence but specifically group intelligence biggest advantage of autonomously working teams is risk reduction through increased group intelligence now it turns out that you can't just get group intelligence for free it turns out that you can't just get a bunch of smart people together and hope that magic happens this observation there's little correlation between groups of collective intelligence and the IQs of its individual members okay in Britain we call that Parliament so but this is the problem you're playing a very different game here the game of group intelligence is that's what you're trying to do you're trying to develop a system of knowledge well we need to be smart and that's we need to be smart which is not about an individual necessarily an individual smartness this is how do we get on together we've got this knowledge pool code base and all the artifacts are surrounded how do we get good at this and you can end up with some surprisingly dumb teams composed of some very individually bright people and the problem is that's how we historically recruit yeah and yeah that doesn't work out so well but if you want any recruitment tips this is taken from this quote is taken from a paper from 2011 my native Willie if your group includes more women it's collective intelligence Rises yeah so you could be smarter and the people if I'm saying I sent a say my workshop this morning could be a lot smarter if you're a woman you have a great advantage you add automatic intelligence why is that well partly there is a notion here of automatically you have a different background and this actually speaks more strongly to something else is this idea of if you would like to have group intelligence then you don't really just want replication of the same Europe you need to have breadth you need to be able to think differently if so I visit a number of organizations I do training I do consultancy and if you end up you know sometimes you see it in certain places it's just like okay you're all the same kind of group you're all you know engineering organizations oh okay you're all white male and in your 40s okay that's kind of a hurtin you've all got the same background laugh that one I've had before I've seen that in a number of places it's like okay I've visited a company all of you people are recruited from the same universities and you're all about the same age and you've done very well at university but it turns out you're all thinking the same way you have the same default values yeah for all of these things you kind of need to come from somewhere else okay and that can be a religious thing it can be from a different country it can be it can be an ethnicity thing it could be a gender thing can be an identity thing these are all forms of difference so there is this idea just like getting a group of people across a bridge you don't want people marching in step otherwise that sets up some rather unfortunate harmonics you want to break stride you need to be exploring this so really the problem is group that can we avoid group thing diverse teams a more like to constantly examine facts and remain objective what we've note it doesn't mean it's going to be easy but what it does mean is that what happens is people change their style of communication they try to take a step back because they perhaps a little more sensitive to what other people might think or might say and this book published in 2003 James Surowiecki wisdom of crowds was quite good on this one because he gave us some criteria which stand up still pretty well the four conditions that characterize wise crowds you can't just get smart people together diversity of opinion independence decentralization and aggregation now this does not mean go out and find the most toxic individuals you can know we don't like toxicity yeah I'm gonna go recruit some sociopaths into the team no no don't do that we still need people who understand that there is a game to be played and that it's not a zero-sum game it's occur it's a collaborative game and the goal of this game by the way is to keep on playing the game so it's not a game that has an end limit but there is this notion of you need to be drawing on different opinions you need to be able to think independently of others that one's quite a difficult one because humans are naturally social but we are also easily influenced in certain contexts group identity and so on decentralization you need to be drawing on different backgrounds if you've got a team full of computer science graduates that's not good enough you need to get some other people in there you know I'll speak for people with physics degrees yes it's always good to have a person with a physics degree on your team always good mathematicians not so much I am free of biases ok yeah get a mathematician in as well most interesting interactions I've had Oh a linguist that was interesting completely different worldview came in from such a different angle a historian I know a historian who has such good insight on legacy systems because they're looking at it you say oh yeah the code oh yeah blur I don't like it legacy and they go like ok what social structures and economic pressures would lead to this code bases whoa damn you know they look at it from a political perspective and suddenly you see yes you're right that explains everything I'm looking at from two narrower perspective because I'm thinking about as technical I'm trying to find the one Oh physicists we're terrible oh now I'm not really a physicist right I have a physics degree we're terrible it's like oh unified theorem there's probably one beautiful equation that defines the whole system historians go Arno is this big mishmash of trade routes and stuff like that going across the codebase and that's a much better way to understand it so along with our obsessions with speed oh yeah it's a kind of useful thing I've almost forgot you got to put it all together again haven't you aggregation what is that grits bringing these different strands because otherwise you just have people wandering off in different directions aggregation what are our mechanisms Franco Gatien hanging out by the coffee machine code base code bases of means of aggregation okay explicit meetings daily standards whatever it is these are all forms of aggregation you're bringing ideas together they're not all about just face-to-face there's the ones that are not directly face-to-face as well like the code base I'm not sort of talking you know you slack or anything like that unless you're running a machine which has far too much memory in which case you slack it's a good way to soak up extra memory and also extra speed so let's talk a bit about speed again because there's another obsession as humans we are easily impressed by physical attributes we go for speed we give a sighs ah yeah bigger better we these days we talk about scale an awful lot ok we're big on scale and there's a lot of focus on scaling but there's a kind of a question here that you have to ask and there's a hidden assumption reveal the assumptions so there are other disciplines that use the word scale so my oldest son was doing Crossfit for a couple of years and it's always fascinating learning about the jargon of another domain CrossFitters use the term scale but they use it differently by default in software when we use scale we mean scale up when CrossFitters use the word scale they mean scaled down but we don't bother with the extra words we just say scale scaled down is what you do with an exercise when perhaps you are you're you've experienced a sports injury or the exercise is new to you and your fitness level is not quite right so you do the same exercise to get the repetitions but you scale it in somewhere you use lighter weights or you change the angle you don't go if you're going down with weights you don't go all the way down you scale it but it means scale it down so conversations my son oh yeah I did this today new exercise but I scaled it he does not working scaling up he's talking scaling down so when somebody says we need to scale our development I offer you this very small small grenade to throw into the conversation just say scale do you mean up or down silence because it's thought well of course we mean ups like yeah cuz you see I agree with you but perhaps we should go the other way we are obsessed with this idea of sizing now Allen said earlier on software development does not have economies of scale it has diseconomies of scale energy there's a lot of knowledge work that has that in other words you get a simple increase so we're talking about group intelligence clearly we have the idea that having some group is better than no group but does that mean it's linear as human beings we love to think in straight lines it's just we're not very good at following them so yes more equations but I'm going to keep it easy oh okay yeah here's the easy one t equals t1 that's not hard this is the completion time for one person to do a particular release or a particular activity but you say okay this is all of the activities this involves all of the testing it involves all the be a roll it involves getting this thing into production it involves doing the code that's how long it's going to take that's our calibration point and then somebody goes out and reads Adam Smith and says I've got it it's like pins we're going to do this we're going to have n people division of labor brilliant we're gonna add two we're gonna have two people speed it up it's gonna take half the time three people it's a third of the time good grief where will this end and then somebody realizes curiously enough that the world of people in the world of tasks and the world of work is dominated by something called time and that there's another aspect of time which we're not very good at reasoning about which starts making it remember I said this was going to be easy I lied I just did that to lure you in it's just how it's okay it's an easy equation No what we've got here is this is the portion of work you can do in parallel just because you got lots of people does not mean that they're going to be working in parallel in fact we have a name for this at school lamda is law it's normally used to deal with how much parallelism can you squeeze out when you distribute things across multiple cores it also allows me to point out one thing this is an idealized model it's a thinking tool do not mistake this for how people actually work we're a lot messier than this we're not plug-and-play core processes okay but as a thinking tool this is quite powerful because what it tells you is if you have more weighting States you lose the benefit of all the people and the weighting states tend to be a byproduct of your process how many people are sitting there waiting for the work of others this is to do with your batch size and everything and you're thinking okay this is good I've got a good lesson here yeah I've learned oh no we're not done yet good god you can keep doing this all evening but I will stop here because we haven't actually talked about some other consequences we haven't really talked about the other aspects of communication this is the worst possible case if I've got a team of n people in the worst possible case they all talk they all have to talk to each other this is different from they all talk to each other casually what you've done is this is a byproduct of your practices and your software architecture if your model a participation requires that everybody needs to communicate with everybody all of the time simultaneously then that's going to start showing in your code that's the worst possible case so your architecture aunty shapes the conversation and there's your communication overhead okay enough equations let's draw a line oh look there it is fantastic okay so here we go that's number of people this is time intuitively you have zero people it takes infinite time but nobody reports a bug so that's a bit of a win then you start adding people and we're speeding up and then we get to this point now this it starts slowing down because it turns out that we're getting in each other's way either in a small office physically you know there's only so much mobbing you can do when you're sitting on each other's lap so there's there's a slowdown because you're also getting in each other's way in the code okay there's and in meetings and we're going to schedule a meeting to talk about that and suddenly it's all about the noise and the people and it ends up going on right there so this is kind of a corollary to Brooks's lore about adding more people to a light project making it later here's how to get a late project yeah yeah yeah sure fine once you've got a late project Brooks's law takes over but if you want to know how to create a late project here you go yeah that's the problem here and why I pointed out this idea of an idealization is that this is obviously not going to come out as a perfect curve in the real world it's a little bit bumpier you're never entirely sure it's like moving around in fog am i going uphill or downhill I've gone up a little bit but perhaps in the wrong direction but there is this idea if you've ever wondered well how do we do this I would offer you the best advice don't start here if you want to find out roughly where this is start here and then oh okay yep we're around here it's around here somewhere around here this is good the only way you can change this is by making the team collectively be smarter or reducing the scope just adding more people that's not going to perform magic problem is a lot we're not very good with time and we're not very good with numbers a lot of consultancies operate out here turns out you can make more money that way but also even our past experience betrays us because somebody's heart you know yeah Kevin I hate what saying we had a really big project and you know 50 people was not enough so we've got another effort starting this year which was similar and we've learned from our past mistakes we're gonna have 60 people on this maybe you want to try 25 I fortunately I was very fortunate early Mike to actually see this in practice where a project manager half the number of people on a on a team and brought the project from six months late back on schedule he was brilliant he was your original servant leader he spent a lot of time thinking and talking to people and messing about the stuff gasps interesting he was exactly the kind of person that doesn't look like they're working okay but he was cuz he was walking around on oh that's interesting you know so anyway the company got rid of him because he because he made the other managers look bad it was an axial service company and really most of the middle managers were there to you know kind of fill out the gap between the top and the bottom yeah and he had this habit of you know producing results and making people motivated and such toxic concepts like that so so the problem here is another one because often people say why it's such a big project how do you know how big a project is and people haven't said well it's to do with how much functionality there is flat well no what happens is that the size of a project becomes a self-fulfilling prophecy looking at this group of people here I think we could make quite an impressive hello world application okay you know me me and one other person we'd sit there and maybe come up with something really like well done one line but with a room of people we could create an Enterprise version we have evidence of this all over the place this is from Facebook about three years ago perhaps they've rewritten it and I don't think it's different for Android the Facebook iOS app has over 18,000 objective-c classes that is astonishing I actually did this as an estimation exercise in a workshop two years ago what was fascinating is that one person did actually choose the number 18,000 but they use lines instead of classes this is big this is so big that there are operating systems that would feel dwarfed by this this is more code not only that took people to the moon but also the Space Shuttle indeed all of the Mission Control software for the Space Shuttle and indeed Mars Curiosity which has quite a lot of code and the code for yeah in fact it turns out this is a lot of code but let me put it another way with over 400 people committing a week is it possible to create a small thing that's the other that's the right way of asking the question could you create something the right size with that many people well yes if you sent just over 400 people on holiday yes that would be the way to do it yeah so in other words it is possible to do this but by sending most people away or go and work on a pet project we've got this like core team of like four or five people who get on really well and they're developing it we have too many examples where people have developed functionally equivalent systems a completely different codebase sizes the code based size will tell you how much work you need but it won't tell you how much functionality you have and this becomes a self-fulfilling prophecy so big teams create big software slowly so going back to the 1970s Ernst Schumacher an environmental economist chooses ideas small as beautiful for every activity there's a certain appropriate scale but I want to take you even further back when we talk about scale and change it's my copy of notes on the synthesis of form which is quite a difficult thing to say even without a drink but Christopher Alexander now Christopher Alexander this is this book was published in 1964 and it was quite influential in the 60s it wasn't just in the world of building architecture that he influenced people but he focused on the nature of systems and how things are built and how they interact and what how changeable they are so he went on to invent there's a progenitor of an idea in here about patterns which became popular later but he makes this observation we may therefore picture the process of form making as the action of a series of subsystems all interlinked yet sufficiently free of one another to adjust independently in a feasible amount of time here we're talking about associations between teams we're also talking about modular structure of software we're talking about these relationships between the people and the code and the structure of the code it works because the cycles are correction and REE correction learning adaptation which occurred during adaptations are restricted to one subsystem at a time he wasn't talking about software but he could have been in fact what is interesting about this is that notes on the synthesis of form is cited a couple of times in the 1968 nato software engineering conference it was so influential back then people in the software world were going you know what this is a really cool idea again I don't know what happened in the 70s ok and he's got this nice little diagram to illustrate it it turns out this was also really influential everybody started during bubble diagrams the 1990s we decided to use rectangles but way back then it was circles here's another one with circles this is taken from 1968 this is from a paper by Melvin Conway how do committees invent this is where Conway's law comes from people often refer to this the basic thesis is that organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations I use the word communication earlier on communication is the vehicle for getting knowledge around getting the ideas that we have in our heads and generating a group intelligence it's not necessarily your organizational chart but it is how people communicate and then people sometimes quote this bit very few people read the original paper normally when people quote it they quote this bit and then only skip this bit which turns out to be quite important we've seen this fact has important implications for the management of system design a design effort should be organized according to the need for communication not the need for skill we which tends to be one of them all the availability large companies often work on availability who's available we're gonna start a project people think okay we're gonna get better than that we need skill no to do it's communication and then we can ask what is it that you are communicating yeah perhaps that person has the right skill but it sends out to be more complex thing now Conway's law comes up every few years in its terms its popularity and we talked about it in 2007 impose a five and we were very careful to say well you refer to this is a law its appeal is a force it's not a law that you must follow it's a force that is exerted upon a system it'll shape a system much as a physical law rather than as a rule that should be followed some people misunderstand it as a rule oh we must follow Conway's law it's a slight no you don't get a choice it's like today I woke up this morning and I decided I would obey the law of gravity you know yeah tomorrow morning you should see me I might choose not to obey it yeah what I will get is a bruise so there is a notion here is of course the thing that you are building is shaped by the way that people communicate okay getting at a choice on whether you have it or not but what shape it takes and how you acknowledge it so in this sense it's an analogue can be broken the force is always there only one that can be counterbalanced by other forces so it's kind of interesting because I've come across this discussion recently I've have I had some people say oh well we don't follow Conway's law or our development process eliminates Conway's law that's why I'm showing you a picture of an airplane when I step onto an airplane it does not eliminate the force of gravity yeah yes by using airplanes we have we have totally annihilated gravity gravity is not a force for us oh yes it is there's a standard for force diagram that people use to illustrate how flight works all of these are interconnected it turns out if you're not moving very fast you don't really get off the ground you don't generate enough lift you need thrust or watch out for the shape that creates drag movement through the air in other words these are all interlinked now I don't overdo it but let's try that let's calm way pulling you down a bit there's your design effort we're going to push this effort into design there's your technical debt and other problems pulling you back your practices are what elevate you or don't so it's a force diagram brilliant that means I can talk physics get excellent F equals MA force inertial mass times acceleration a is also fragility that's convenient what a great coincidence it's like it all lines up perfectly M is for inertial mass it's the stuff that holds you in place and yes Stonehenge wonderful big heavy stuff awesomely heavy so this is a photograph I took on Valentine's Day because that's how my wife and I roll that's that's how you do romance yeah it's just like hey let's go look at some old rocks yeah 4,000 years old works for me we took the kids with us because you know that kind of thing happens and there's the whole notion of are you looking at this dad why is it there wow I don't know son it's a legacy system we have no idea the original developers they're gone usual plans I don't know how does it work well yeah a couple of couple of times a year gives the right results but really you know we're really not sure what to do with it you know and we invite people round just to look at this tourism yeah maybe you should do that with your legacy system yeah invite people in hey look this is how our company works we have no idea but look look there's things there Emmys for monoliths monolith Oz one stone one sodding big stone and people like the whole stone coating the old stones yeah yeah look this is this is this is these are the stones that we want you know so this is my youngest son when he was five he arranged this after a little chip to Clevedon beautiful Japanese aesthetic of a seaweed and people look at that and they go yeah this is what we want this is this is our architecture we don't want Stonehenge we want this and sometimes when I show this picture people go you're talking about microservices careful and aren't you you know if that makes you feel good yes I am okay really I'm talking about any kind of separation which allows us to control the as it were the knowledge structure and organize the knowledge whether we're talking components whether we're talking services whatever structure and technology we're using we are talking about an organization of how we think and how we work together so micro services works for you that's great but do not assume that magic happens all we're doing micro services because you normally end up with this yeah this is a lot of micro service architecture and you know it's just like it's just that yeah we broke everything up into small pieces how's that working for you yeah Alan Perlis in the long run every program becomes Rococo if you're not sure Rococo is it makes Barack look minimal just yeah and then ruble so this is a very kind of important sort of self-fulfilling prophecy so what we see in all of this is we have these obsessions it turns out that speed is not one of the most useful ones speed is not helping us get the right thing it is giving us in a false sense of urgency that when we think about the technology there's this term that seems to become very popular the full-stack developer which I'm very not you know I'm really not keen on it because normally it's just somebody saying I'm a web developer just say you're a web developer it's a lot easier I know how big the stack is it goes a long way down into the metal and that's quite scary yeah you don't to be a full stack developer but the other thing is even that's a technic techno centric view because the full stack also goes out into the world it turns out that the the socio aspect of associate technical system is quite important it turns out the people stuff matters so the spec includes the world the people who are who want the software the people are going to use the software not always the same thing and the people are going to build it actually shape it in many many ways so I've got to leave you with a kind of a thought that an observation that was given that I picked up all in the late 90s and I thought this is a lovely way of looking at these things because for me a lot of the practices that have in agility and that we recommend fall into this category there is a simple and obvious answer to this question that is correct okay why do cars have brakes cars have brakes so you can slow down and that is one of the key reasons that you want all these practices now people often get a bit disturbed when I start talking about architecture or TDD or any of any practices that require you to stop and slow down and think to study to observe to take stock because they say aren't these practices going to slow me down and what they want is for me to say no of course they're not it's okay you can go back to your team I bless you you find it won't slow you down so I say yes they will slow you down what what kind of crap answer is that I want these two practices to speed me up it's like yeah they do it's a very simple twist this answer is also correct both answers are correct but this one reveals something different it is less obvious how fast would you want to go in a car that did not have brakes I'm fine thanks I'll walk you no I'm good it's a question of safety we have we have these things to slow us down so that we can make reasonable progress that we can adjust our course agility is to do with direction it is to do with rate of change it is not simply to do with even velocity it is how fast can you change your velocity you may maintain the same speed but go in a different direction this is the whole thing try doing that without brakes you're not going to get very far well actually you might get very far indeed just it might be a little dangerous then you might stop rather suddenly this is why we have these things they are there to allow you to go faster but with a little bit of control and response thank you very much thank you questions questions questions cheap abuse expensive abuse fruits preferably fresh yes you refer a lot to this talk conference from 60 yeah so I have a whole talk called 1968 oh yes I I watched it yesterday and so you've seen all the jokes I'm really sorry I wonder if a lot of the things we are discussing were so well known 50 years ago why do we keep forgetting them because we have a poor relationship with time but we have a we do because also memory needs to be used if you have an idea you need to use it and the problem what we've basically been doing most of for the last 50 years it's not that we haven't done anything news just that most of the dreams that people had have only come to be realized through hardware and I say that as a software person it's hardware is allowed us to properly achieve these things because sometimes I say to people say oh yeah but Kevin look you know you go back a few years you didn't have all these nice glossy IDs these big screens and I say and this big screen is that a software thing is it a Hardware thing because I think it's pretty kickable yeah that's a hardware thing and that that IDE what kind of CPU do you think is needed for that I'm gonna tell you that isn't what we had in the 90s yeah so therefore a lot of these have been enabled so we haven't never to exercise our this that's one aspect we haven't been able to take advantage of this we had the idea and then we couldn't use it then it just fades from collective memory the other thing is that if you keep pushing something enough it goes even if it's not the fastest that as fast as you want it to go and that that's what happens with software software has grown it runs the world okay now somebody said you know what we're not going to fund any more software until you guys get your act together I think we get our act together but we've never needed to it's just are we screwed that one up but give us more money anyway because it turns out it's filled with opportunity even when you get it wrong so there has never been a need to consolidate if you look at a lot of other professions they have periods of expansion consolidation expansion consolidation software is never needed that because it's been riding on the back of hardware which has been going up like this so there's never been a a force acting on software development collectively to say oh wait a minute slow down a bit we need to sort ourselves out in a few niche areas that has happened but collectively no it hasn't okay good question there was a question over there yes you talked about to dilute before and plan young study yes I like that what's your take on complexity theory there no probe since respond ah right okay complexity theory and can Evan yes I only see the word you're from the UK so you can say that one oh no that's well because honestly a lot of people have said they be I fortunately I live in Bristol that's just over the bridge from Wales so obviously we get it by osmosis yeah though the Welsh language the Welsh language is is a procedural language no seriously it's a it's what's called a a VSO language verb subject object whereas Swedish and English are subject verb object SVO languages so yeah it's a procedural language you lead with what you're going to do you know that's it so can Evan yeah it's crazy crazy pronunciation but the a lot of this relates to that and in fact you kind of get a slightly bigger slightly bigger version of this talk if you try and take in these different dimensions so that you have the simple domain and in many cases you can't actually say we are here that's there let's go in a straight line what you're dealing with with a lot of this stuff is genuinely we need to be able to change direction because we're not entirely sure what that direction is that idea of the dark we're in the darker in the fog that also works out as well so I mentioned Usain Bolt right at the beginning travels in straight lines very very good at doing straight lines very very good but it turns out software development is not like that which is unfortunate because the language of sprint for other reasons is baked into the world of scrum for example over marble who love a model who works for Tandberg at all was a tempo but now cisco in oslo had this lovely example it was in 97 things every programmer should know where he talks about the idea of software development is really like more of a long distance hike in the dark without a map and that suddenly starts sounding an awful lot more like the pro sense space in other words it might feel like i'm going up a mountain but actually it might just be a hill and i'm actually heading in the wrong direction so there's that notion of you're always looking for your bearings you're always aware that whatever you're doing now take it make a note of it but it's always contingent because the truth might change and you're always aware of that whereas the the velocity or speed model is a simple one it's it's a one-dimensional thing we are moving in a straight line we know exactly where we're going and and that's it and our best practices are enough where as what you're looking at here is that I know we know you need to change direction the agility is the ability to change direction and that for me is is is the key thing so you need to travel relatively light in this sense thank you thank you I think it is time to wrap it up for this year Thank You Carolyn for coming thank you very much this week you

Channel: BrewingAgile

Views: 35,114

Keywords: Agile, Scrum, Lean

Id: kmFcNyZrUNM

Length: 68min 26sec (4106 seconds)

Published: Sat Nov 24 2018