The Dehumanisation of Agile and Objects • James Coplien • GOTO 2017

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

He's a decent speaker, but...

There's a long line of these types of nebulous and flawed software design solutions, each one sufficiently vaguely-defined to allow self-appointed experts to endlessly debate it, present it, write books on it, conduct training courses and so on. Patterns, Extreme Programming, Agile, Scrum, Lean, Flow, etc. Each one is sold as the panacea. Then when people point out it didn't work for them, they're told "that's because you're not doing it right". Eventually the "experts" starting changing the tone of their output to "Why it didn't work...", invariably by blaming the practitioners, before quietly moving onto the next bandwagon.

👍︎︎ 12 👤︎︎ u/ford_madox_ford 📅︎︎ Jul 29 2019 🗫︎ replies

I generally enjoy watching talks that are a bit over my head, like this one, because they give me a clue about what else I need to learn to become a better programmer and manager.

That being said, I found this speaker extremely dynamic, but very difficult to understand. He seems more interested in seeming funny and smart to his audience, rather than making sure they really understand his message. For someone like me, who isn't familiar with Piaget's research, or what the Toyota Production System is, this was a very dense talk. Sometimes frustratingly-so.

👍︎︎ 2 👤︎︎ u/BillyBBone 📅︎︎ Jul 29 2019 🗫︎ replies

Great talk, very happy to see people posting it up. TBH, almost everything on the GOTO Conference channel is a worth while watch in my experience.

👍︎︎ 2 👤︎︎ u/opmrcrab 📅︎︎ Jul 29 2019 🗫︎ replies
Captions
[Music] you very much [Music] know it's a great pleasure to to be here this this conference has a long history in in my own legacy I first met my wife at this conference about 12 years ago well enjoy which was the predecessor to this conference it's changed a lot in the years when I talked a little about that and how many of you were here for the last talk by my esteemed colleague Dan North so I'm sorry that he left so don't just don't believe anything he said except about three things so one is about the certification in monofin and a modification of scum monetization is just this is a very very serious problem he's absolutely right on another another is is scaling which he was also right about and the third thing his answer to the question about you know how do you make a motivated team we've just concluded about six months of literature research on this and came out at exactly the same place that Dan pink did and Dan has done a lot of research on this that Dan is kind of a meta researcher he does our research and what other people do research on the reason I mentioned Dan is that my talk is kind of st. talk second verse and that he's saying you know we we've kind of devolved from original agile and and my talk is very much the same except what I'm doing is stepping back and looking at a couple of things and one is object orientation and the other is agile and I think we have seriously devolved both of those and surprisingly it's for about the same reason and what I want to do is give a little bit higher view of what the history was about and what these two things are about just in terms of history I want to start with a family tree and like all family trees it's probably wrong or you probably have your own but we can go back to the trail to production system which is not lene lene is an American thing and is very different than TPS and a lot of people say scrum came from lean it's not true lean is a separate path off of this and believes in things like root cause analysis and from this we have the the paper by takusan in the moccasin say which is a new new product development game in Harvard Business Review and that had a little bit of influence on XP and a big influence on scrum Jeff Sutherland also often says the scrum came from this those from came from many sources it was partly probably some of my work was partly from his work at West Point most of the things that are in scrum you find in in military training and from a lot of other places and extreme programming came from scrum in 1996 and then this it kind of died and then agile came from all of these and one of the points I want to make as agile came from scrum scrum did not come from agile so I mean the agile manifesto was kind of a cream skimming of a lot of the practices that were around at that time to some degree also from dsdm but and these in turn were echoes of earlier things like some of the research we had done at Bell Laboratories that was published even much earlier so most of the components of scrum of the agile manifesto in the organizational patterns that were at the first scrum cursed patterns conference in parallel object orientation goes back to a couple of guys in dalla neugog and they kind of had their first demonstration of this in a language called similar and similar goes back to about 1964 but the object-oriented version was in 1967 and then the notion of object orientation really started taking root in the oops law conference it started in about 1980 so if you look at the original ideas behind objects this go way way back to to 1972 1974 and we'll be talking about that the patterns community came out of this community if you look at most of the people who founded the pattern community they were all old people and and a lot of the scrum community came out of the patterns ideas so for example the daily standup which is in scrum came from some patents work that had been done earlier and some work at Moreland and then agile kind of draws on all of these on object orientation on patterns and and so forth and we'll be coming back to this family tree a lot of things a lot of us may be new to you I mean here's the email that Jeff Sutherland got from Kent Beck asking to be able to steal everything he could from the way that Jeff was using the Harvard Business Review article and saying I've been doing some patterns on this GM by putting together this thing and of course it ended up being extreme programming so here's here's here's Kent's mail or did you know I invented extreme programming I did following work by Jim Killeen and Ward Cunningham on software development with Ron Jeffries and the c3 team at Chrysler he invented a named extreme programming I mean history is written by the victors and since since since from one that just ignore everything down north said so we've seen this in the previous talk I was pleased to see that everyone in the audience had seen this before when I teach Oh ima I also may certified scrum trainer right let's guys got to stick together here when I teach the scrum class I asked people how many of you have seen this and it's about half the class and so I've ceased to be surprised but it's about half the people who have never seen the agile manifesto but this is kind of a very software specific lightweight thing and everyone everyone that now Dan North has had his say all if I could write the agile manifesto again I would do it this way everyone's writing papers about this Kent s his and I have mine and so on and so forth if you go back and look at the let the the original stuff and a lot of these original principles that even the XP people are talking about as we find an agile they go back to to this this this work by nanaka and Takeuchi so this is a slide that nanaki gave at the it was a scrum gathering in Tokyo about three years ago we were all speaking there so this is his slide and he traces the history of scrum this starts with his paper it in an Harvard Business Review the new new product development game and then a second paper the knowledge creating company and the next step were these organizational patterns as I did throughout 1993 and published it the first patterned conference most of the elements that you find in extreme programming and scrum are in those patterns and then this day I think it's wrong I think this was 93 Baracus is 94 whereas the first sprint of scrum and then later he adds to daily scrum and the scrum master and then it's almost seven years later that we have the first scrum book by Ken and Mike and in the same year the agile manifesto so seven you know scrum has been up and running for seven or eight years and then eventually nanaka together with Ken here another son has written a book on scrum more for the point of view of its foundations in Japanese culture and in the Toyota Production system not in lean if you look at the history of agile are really not agile I mean I hate these surveys to say 86% of all companies in Oh Angela how in the hell did they measure that what the hell does that mean I mean do you have to have a score of 75 percent of those things that Dan talked about so I mean all the things that Dan talked about in terms of scrum I mean they're they apply equally to agile it's there's just as much so if we go I really like to talk about Toyota Production system and because that's well known and well documented and some things having to do with the Japanese and Toyota design culture which are not as well understood and not as well documented but I do a lot of work in Japan with Japanese partners and we're starting to get a better appreciation for for how that works so a lot of this is about individuals and interactions where is an object orientation we talk about anthropomorphic user interface design we used to have something called CRC cars how many of you have used CRC cards one of the one of the best object-oriented design techniques that are out there and it's it's not there anymore because other things have taken over now we have a new card called a user story which don't get me started on user stories ongoing repair you're always making things more solid this is a deep foundation of a pattern discipline so agile says finding that responding to change objects were about programming by difference one of the big uses of inheritance was incrementally defining a new feature in terms of an old one or defining a new class in terms of an old one has a very outward focus customer collaboration we talked about in the manifesto and the original formulation of object orientation was about engaging end-users through their mental models what an object is is representation inside the machine of the mental model of something that is in the mind of an end-user it is not something with an interface that is plug compatible that's not what an object is an object is part of some human mental model and the goal is to engage the person with the software so the two together become one mind this comes out of psychological research BiPAP eart it was inspired by learning theory from Piaget and was larger the child of Alan Kay who since kind of given up on the rest of the world and how badly things have turned out including in small talk small talk isn't much better than the rest of them and he's off playing with his own toys right now and no one really knows what he's doing I suspect it's something great and last about quality it's about working software and object orientation I mean if you ask you are an object or any programmer these days people will say yes I use TDD well yes they do unit testing and these are the kind of technologies that people associate with with object orientation so a lot of the roots the structural roots or psychological roots of TPS and of objects are the same looks like a an iPad right when was this picture taken 1976 that's an iPad for crying out loud so no this is something called a Dynabook now it's not real it's a mock-up made of cardboard but it was designed using technology that was available at the time by Alan Kay as a conceptual design of how this girl could go out sitting under a tree on the grass and use it to explore the world around her explore the library explore what what her friends were doing interact with her friends and so this is a it's not gamification how many of you are at the gamification talk so now you know who I asked my question is that games are an imposition of something from the outside whereas Kay and pepper we're trying to lock children explore and so it comes from within rather than externally imposed rules that was the whole foundation of object orientation to get the concepts out of people's minds and get them into the computer and case that we feel the child is a verb rather than a noun an actor rather than an object he's not a scaled a pigeon or rat because there were all these I mean the Skinner esque School of Education was was teaching by repetition well you can teach a rat to run amazed no it's not about that he's trying to acquire a model if his surrounding environment in order to deal with it sexist language I know I apologize its direct quote we would like to look into his current modes of thought in order to influence him rather than just trying to replace his model with one of our own so this is originally what objects were all about little sounds pretty agile doesn't it instead of push development we're going to do pull development to try to engage the customer and both software that works with their model of their business this was the whole goal of object orientation though on a more individual level and this is L&K so he had written this paper which is kind of floating around I actually found this has been published formally somewhere but PHAs and others work on the bases and forms of children's thought is a fairly convincing argument for believing the computers aren't almost ideal medium for the expression of a child's epistemology what's an operational model it's not an algorithm oh do it how many were told by your professors that thinking and algorithms is bad if you're doing objects the original formulation is all in terms of algorithms it's about a bunch of objects interacting together to solve some problem how many of you do object-oriented programming really really once the last time you wrote an object what programming language you cannot Java is the only language in which you cannot do object-oriented programming it's the only one you're a class oriented programmer you're building the blueprints to build the house a class is just something that's there know what a program is is a running bunch of objects interacting with each other connected to each other in memory that's object-oriented programming it's not of objects if you're working on one class at a time you don't even know where the link to them that subject goes by design you are not allowed to know where it goes because this wonderful thing called polymorphism it's go twos on steroids and if you can't understand your program what do you do you test it test your development it's because we can't understand our code we've lost this and a lot of it has to do with with our programming language it's about algorithms that are informal and not necessarily logically consistent and this fits in well with how children view the world so it's about what K calls a genetic epistemology knowledge is retained as a series of operational models how does this collection of objects interact but I cannot look at your Java code and see that network of objects or see the flow between them you can't understand it you believe in things you don't understand you may suffer I could do a whole scrum class with what pop song quotes Stevie Wonder you believe in things you don't understand you may suffer it's much later in childhood development that logic is used and even then through extra logical strategies so object-oriented programming is kind of about the the ghost or the soul in the machine so here we have a child and individuals and interactions who have heard that somewhere before over processes and tools how do individuals interact with objects now this is what I call an agile program where the program has empathy with the mental model of the end user and of the program I mean the programmer has to be there understanding both what's going on in the computer and what's going on in the child's mind it'd be really good if if the child could go directly into the computer and manipulate things it's like if I'm teaching you I'd like to go directly into your brain and manipulate the cells but it'd be really messy so we work through this interface and thus interface has something called a tool and a tool has a controller it creates and coordinates views no the controller is not the thing through which input comes from that's it this this is another thing that people grossly misunderstand people do not understand Model View controller the controller creates and coordinates views that gives access to this model Model View controller user and that input comes from a user through the view through the controller wherever and gets down to the model and I'm trying to do this integration between the end user and the computer so in some sense the model and the end user should be thinking about the same thing that one is just an extension of the other this is the whole goal of object-oriented programming not polymorphism not encapsulation not productivity human mental models it's about people so most programmers programming classes any JavaScript programmers here you do this right you can program on objects JavaScript programmers maybe get this in a way that Java programmers never will classes are static however you sell classes don't we sell use cases software is a service that's this thing called software as-a-service software is always a service a cd-rom has absolutely no value until it's installed and running on a computer it is a service so we sell use cases and we can't understand what our programs do because we're isolated to working in one method at one class have one at a time so what do we do what do we test one method of one class at a time all the rest is mocks oh yeah like this is gonna work the GUI comes later Jef Raskin founder of the Macintosh project said the interface is the product the software is just the crap that has to go along with the interface to make it work what you build and deliver is an interface the rest of the stuff is muda it's waste lean term for waste and so if we separate into client-server it doesn't have this connection where the user is really director directly manipulating their mental model and use cases aren't designed so users can't understand them from the interface either and the coders can't understand them from the code and it's amazing that anything works or that any software is usable at all all because we've lost this vision of what objects were supposed to be about and the car was kind of a religious issue right because in Fortran or in Pascal or some of the big languages of the time people said well we're programming in terms of scenarios and use cases oh well we're new now we don't want to do that we have graphical user interfaces and it's pressing one button at a time so all the operations are atomic a good small talk method should be three lines long and that's true if you want to do something simple like like PowerPoint well if you want to do something sophisticated they're still going to be your navigation tree for page flows they're still going to be proper sequences there are still use cases that are part of our business scenarios and we need to handle these and traditional interfaces just aren't good at that how many of you have tried to make a flight reservation on Finnish Airlines on their website you can't do it and some people get this Amazon gets this I mean the Amazon Web site is almost invisible you probably can't remember what was on the page the last time you left the Amazon Web site because it's so natural it's like you know being in a bookstore and picking something up if you can remember exactly what steps you had to go through that memory is part of your learning that is of changing behavior of going through the pain of the system not living up to your expectations so object orientation has lost its roots there's there's little reasoning about the interaction of objects very few methods to focus on networks of cooperating objects my method here I mean design method the best one I know is CRC cards and that's now very unfashionable why so what did CRC cards come from well probably there's an argument well there's Ward Cunningham or Rebecca Worth's Brock bottom either they were very much popularized by Kent Beck and I mean if you're now selling test-driven development well you don't need CRC cards right it gets in the way of selling that idea so test-driven development which you know the research shows will kill you RTFM we're professionals here and unfortunately I haven't seen this kind of paper at this conference there's very little data to back up the talks at this conference and there are people talking about TDD but read read the read the papers by Abrahamson Sinha Alto all the researchers who have done real research on TDD what it is it's forcing you to do bottom-up design TDD is not a testing technique it's a design technique and you're designing what do you test methods you can't test a class a class doesn't one methods run so you test methods that the bottom of the hierarchy congratulations you have just made a bottom-up architecture and you can program in Fortran in any language and test-driven development guarantees it and the research data validate this that the coupling and cohesion metrics of systems built with TDD will kill you we know this that's a lot of these things so that's what this talk is about there's a lot of stuff we know we know how to do this right no because it's going to be different every time different object and certainly a different class you can't do it so a lot of this is just it's just ignorance and so I mean I stopped in a company booth out here that's selling agile consulting and scrum consulting and I picked up there they're a little box of of guidelines to scrum and the first floor I picked up we're wrong they're just not scrum there's a lot of things so this is why I wish Dan were here that Dan said about scrum that are just wrong Dan and it may be that Dan really does understand scrum and what he's talking about is how how ignorant people practice it because people by nature will fall back on to their old project management ways but what he talked about was not screw and it's not something I recognized in my clients and it's not certainly something that I teach so maybe he just gets worse off clients than I do I don't know the focus on unit testing an object integrity has replaced operational models and the human focus it's all about Turk tools processes and tools over individuals and interactions I mean I look at all the stuff here about about docker and automation Toyota has just removed automation from a good part of their assembly lines and replaced it with human beings because robots don't learn this is about getting better the purpose of running a test is to understand what text you will write next I want your brain engaged with the software not to tell some soft some computer to go off and run a bunch of tests I want a human being there the purpose of testing is to learn and I'll learn by engaging my brain and I do that with exploratory testing not automated testing and certainly not unit tests so there's all these things we believe may lightning strike you down if you don't believe in TDD or in unit testing or automated testing you've been sold a bill of goods so we choose to believe things that simply aren't true and there's very little substantiation of these things so now patterns have become prepackaged technical solutions and the good part so a little understood what part of model view controller handles input events well it's usually the view it can be the model but everyone says nots that's what the controller is for it's just it's misunderstanding what's the role of the controller to create and coordinate views it's not to handle input how many of you draw object diagrams a bunch of nerds you're all drunk class diagrams right you're drawing the blueprints not the house how many of you work with use cases not just scenarios use cases use case is not Swedish for scenario and vonda follow right we need only requirements can be complex and either way to structure them so and the whole culture is lost in this languages don't support multiple classifications according to behaviors or the roles they play and I won't go into this because the conference does not want me to speak about this at this conference we tried to have a seminar on DCI and on this way of programming there's a lot of research that indicates it works Hector about the cantos was a researcher at RTI did a couple of years of empirical research with 14 subjects about half of whom were professional and half of whom were students and correctness time consumption and reference during reading comprehension or what they measured and results indicate that DCI code and the trigger language supports more comprehensible code regarding correctness and improves the locality of reference finally object or any programming but you wanted to learn about Java 9 you wanted to suck a little less our industry can't afford to suck a little less we need paradigm shifts we're about with software engineering where they were with turning lead into gold in the Middle Ages in practice intellectually we know we know how to do this stuff but people are very risk-averse it's really really hard to sell agile has gone wrong similarly everyone thinks agile means fast the word fast does not appear in the agile manifesto and if I look at the roots from which agile came which are TPS it says careful decisions made with long deliberation we have how many ever heard the phrase defer decisions to the last responsible moment so there is a concept in lean called last responsible moment it's a moment beyond which your ability to effect an outcome is taken away you want to pull those decisions as early as possible not defer them the XP people got this exactly wrong 180 degrees wrong goal we'd read the lean literature you want to program the process here you make the high-risk decisions first and that sets you up Jeff knows this jeff says you manage your dependencies in the first half of the sprint earlier you abort your sprint so at least intuitively he knows this you don't defer decisions you pull them forward so yes there was this concept called the last responsible moment and then the agile people added the word defer to it it's exactly the opposite of what the lean people mean read the stuff out of the lean Institute at Stanford social design with CRC cards has been replaced by individual pairwise testing very little about the end-user mental model how many psychologists are on your team how many of cognitive analysts how many behavioral analysts if you're doing object-oriented programming every one of you should be in a behavioral psychologist that's what it is it's eliciting end-user mental models if you don't know how to elicit an end user model you might as well use Fortran processes and tools like JIRA and testing over individuals and interaction anything we can reduce the programming reduce to programming why why does the dog lick its genitals because it can why do reduce everything to programming because we can yes and certification over customer collaboration all right so agile has really lost its roots I mean in this link from object orientation to agile there's no analysis I really love Eric Evans he's a great guy he's the dhih dhih dhih guy but I mean they got rid of analysis why well they pretend that they're a faint ignorance they pretend that they're ignorant and we're going to reinvent everything ourselves using things like test-driven development I mean if you're if you're my aerospace or medical contractor I don't want you coming near my software unless you have some good domain experience we've lost the link from patterns patterns and we're actually a lot of this stuff comes from but I just didn't have enough time in this talk to cover it all while we're looking for the quality without a name sometimes we call it Kwan Oh Moo Manu Shih Tzu in Japanese it just feels right and so I don't hear coders talking a lot about this code feels right and that's worth a hundred tests and good planning that's been replaced by testing and rework rework is costly we have a product and tool focus and not on process the lean people say build the right process and you build the right product and in fact initially you know scrum and to some degree XP understood this where they said the process is all about feedback i lo how many of you have read the latest scrum guide but I mean no you can't you can release as often as you want just don't have a DevOps team how many of you have a DevOps team I mean that that's a hand off there's no DevOps teams in scrum fundamental principles that people don't understand and the good parts a little understood what's the purpose of the daily scrum anyone know and one one to take a shot not you communicate and putamen someone else share the goal anyone else information-sharing look you're all you're awesome [Music] Yuri plan the work for the next 24 hours it's a mini sprint planning meeting now here you are you're all probably on a scrum team you've been doing this a million times and you don't know what you're doing because you're getting the information from this roof upstairs the celling scrum these conferences are doing unbelievable damage because there's no authoritative nastasi no going back to the source no explanation of hawai stuff works just recipes and it's infected the entire industry and driven both agile and object orientation into the ground and then we have the Dan Norris here taunting us with things that in fact are not scrum which makes it worse what percentage of the sprints for the great scrum team fail the answer is 50% it's pure math if you understand how velocity works and you understand variance you are better be filling 50% of your sprints if you're failing more you suck if you feel less you're hiding something you're cheating you're lying you're cooking the books this is simple math this is part of being agile what's the best bug tracking strategy in scrum we don't track bugs we fix them now how many people use JIRA I won't even ask it's a really great place to put bugs because no one will find them there how do platformer scrum teams interface with other scrum teams there are no platform teams in scrum a scrum team interfaces with the end user there's a new scrum guide in Kennan Jeff were seriously considering the name changing the name of the development team to the development delivery team it didn't make the final cut I don't know why I haven't talked to Jeff but no the delivery team the development team puts it into the end users head not the customer there are no customers in scrum that's a handoff handoffs our mood ah so where we are today individuals and interactions no individuals in j-unit deferring to the last responsible moment customers and collaboration we have team written user stories oh yeah end user will ever talk to them working software well the unit tests pass CRC cards well individual class designs where are the people in this programming by difference or refactoring test quality and yeah like that's going to work engaging end-users oh just you get points for using design patterns right user centered design what's a user you know instead we're going to do TDD and unit unit testing and will eventually bump into the user somewhere and meet their needs the common enemies tools over people yell a lot of to of end result here one of the talks I went to today was in fact a commercial product wasn't that bad but I was doing a very low-level thing how many computers do very low-level things fine compilers a perfectly good tool when I'm concerned about our tools that that displays or try to help human communication commercialization or we're doing the right thing I think dan nor said enough about that commoditization let's try to make something general as valuing knowledge oversimplification and just ignorance and desperate hope I mentioned this one a lot of people believe in automation why cuz managers feel that saves money they can get by with less monkeys in the cage just let the computers do the work and it turns out that Toyota has found that no this short circuits learning the short circuits Kaizen and kaizoku so basic process improvements so if you have Kaizen minded their ever improving you don't have automation except for regression to us we know that that works there's evidence that that works regression tests are tests that you write to reproduce bugs that people find in the field you don't want to regress into old bugs automate those but the rest do exploratory testing so what should we do to restore focus so this may be you know one of the last cops in the conference so I wanna leave you some things to think about and go home with so for it's all about people and I was very gratified to go a few talks that were very very human centric here and I have to credit the conference for that in terms of white can do back home try mob programming I'm not even sure it works I know peer programming works I don't know if pas if ma programming is cost-effective if it's any better than pair programming but try it you all know it where you have one person at the keyboard and they're not allowed to think more or less they type what they're told and the rest of the team is there discussing the design and telling the person at the keyboard oh create one of these classes Oh put this algorithm here I'll create this method and then they swap after five minutes and there's a facilitator so three roles your team member or facilitator or the the driver and there's a guy named woody Zulu who has been pushing this forward and they have some fantastic if nothing else for building great teams how about ongoing repair do organizational learning so instead of getting the right process go beyond process to look at your organizational structure now what what Dan is trying to say is well we're just going to have dynamic structure and and rebuild teams all the time no there's lots of research and this is in psychology and and software people don't read psychology right I mean research is recent is this year that shows you keep a team together and that's worth about a you know a large integral factor in performance points I will not use a number like Jeff does okay and so if you just continuously I mean this is the old staff pool idea we know this doesn't work and there's research that backs it up no stable teams have value in their own right and how do you counter that you ask people to grow so if you want to just suck a little less than people can stick with their individual competencies and a scrum team your challenge to grow and to master new techniques and new technologies I mean down was standing here and saying well I can teach anyone in new technology in two weeks and by the way I agree a lot of evidence of this so if they're excited so why we organize the teams and take this order of magnitude hit on on throughput when I can spend two weeks and teach people the new technology to bring it up to a cross-functional team again I mean I don't even understand his argument it's it's not self consistent it's so wonderful to be the last talk in the conference I get to do this yes how many UX people here I love my UX people the interface is the product and we're all told there's this big thread on LinkedIn right now learn to think like a user the worst thing that a developer can ever do is think like a user you are so prejudiced by your implementation and what you've heard from the requirements people you can't think like a user you can't users think like users and I mean people who the UX people are really good at teasing off these mental models and it feeding you how many of you are product owners every product owner should be a UX person should have some UNIX knowledge this is about people not about technology the technology is easy spend two weeks and teach people the technology the people part is the hard part and last we need a balance of process focus and product focus so I think people in the in the 1970s and 1980s got caught up too much with process the whole ISO and CMMI thing and the product kind of got shelved and you can also be too focused on the product and not be worried about learning or about improvement and so you needed a balance so I mean scrum is one framework that offers this balance there's many more so I'm not I'm not going to be here as a scrum salesmen and scrum is just a teaching tool scrum is the gate through which you pass on the way to enlightenment we're doing a scrum book right now and the the preface to the scrum book is the Zen story of eight bowls if you don't know that look it up when you go home so we want to get you to the eighth Bowl or the tenth there's our tenth tumbles and that's story I want to get you to the tenth Bowl build the right process and you'll build the right product and too many people want to advocate cowboy program and going back to XP they're scared of the structure because they're scared that they're going to lose control so the kind of criticisms that we saw in the last talk are rooted in fear and so I don't want fear I want to turn people loose I want to be a joy to come to work and yes of course everyone has a say in where the product is going so the product owner isn't the boss they do have a final decision why because we're gonna hold them accountable and you heard your heard Dan saying accountability is important you can't hold a team accountable if a football team screws up who do you fire the team bought done there's five minutes oh okay some elusive Lance over the horizon and user programmability put this back in the hands of the people who are actually using it and the design movement which was this wonderful movement from you probably know it from the 1980s wonderful body of literature that no any computer science has read and yet most of what we do is design wonderful literature behind this we want the whole organization to learn and learning most of the learning in scrum happens at this double-loop level it's changing the structure and so the structure is there for a reason and it's a framework it's not a methodology extremely lightweight it has yes changed a lot in 25 years and the details inside you can change any time it wraps your practices it wraps your process it's not imposing that don't let anyone tell you otherwise the real learning happens here at the level of process and values give yourself a retrospective off-site once a year I want you to dream not just to be risk-averse we want to work with areas we can control networks of objects and teams of individuals take us out of our comfort zone and we need to reach into that area outside of our comfort zone to grow and to thrive and even just to survive dream to do great things like Alan Kay did he dreamed to change education Jeff Sutherland dreamed with scrum this book is dedicated to Nobel laureate Mohammad Yunus and the Grameen Bank for originating micro enterprise development the strategy for bootstrapping the poor out of poverty has been a model for feeding hundreds of thousands of software developers from Delaware abuse caused by poor management practices that's scrum not the daily stand-up for each talk you've been to in the past two days was there compelling evidence for the claim that this is better than anything else or that it even works or did you just believe at this conference for each talk ask how does this improve the quality of life and for how many people and take home at least five ideas that will help your team increase the human value of your product or service I'm done thank you very much [Applause] time for questions yes okay okay let me have it first one what about integration testing what about it you do it ten times a day a hundred times a day I it has tremendous value because that is more closely approximating what the end user is seeing is the whole system together so I mean that's that's about 90% of the testing I'm doing now within the integration testing there are strategies like like exploratory testing of an integration right so there's this is a two dimensional matrix but the most important testing is user is usability testing that's the only thing in the end that matters if that works nothing else matters everything else is just an indicator but the integration testing are unit testing your coverage tester and user testing it's what you should be focusing on that's all that matters in the end I'm trapped in a yavar shop I'm trapped working in a Yahoo shop what do i do language bias oh you should refactor your CV [Laughter] [Music] so the answer it at that level there is no difference so our our right brain organizes things by classification so we do have classification and classes are meaningful and kind of the domain modeling have heard of this thing called domain driven don't never mind I know nono classes only are bad because they will not support the use case so I need something else so the class model should be okay but it's not classes as people use them today and classes have to be overloaded to also do the use case stuff because there is nothing else that's all there is and Java interfaces don't work because even with default methods the binding time to the objects is wrong there's essentially become part of the class so yeah I still have classes in my domain model for for some shape of domains but I need something else which is what the roles are for to encode the use case yeah I know I gotta get together we got to do this okay I have a one very practical one that follows your lead and someone wants to take away the title of the wonderful book about design that doesn't know the title anymore oh there's a couple of them one is designed after modernism by Jonathan Kira and another one is what's it called I'm having a hard time thinking about these things on my on my feet and he can send me mail and I can send you a bibliography this is where Christopher Alexander got his big start by the ways he was part of this community but he was just one of several absolutely brilliant people a lot of this is centered in the UK by the way fur for some strange reason but there are also the people who give us the design you know the damask manufacturing movement back in the the late night late 19th century this is lada good design thinking in the UK just knock you dead literature that has so many insights into why things in software go wrong and it's timeless this is kind of a weird weather design school worldwide started to slide into post-modernism and go from the modern school to post-modernism and most of the people at this conference are still stuck in technology language okay no i don't okay thanks okay really last question one really that's a very very broad term if you read uncle if you mean uncle bob martin he also is full of but Bob and I are very good friends we love to fight in public and he's kind of the the the poster poster child for software craftsmanship and at some level it's it's absolutely the right focus and so I mean I was in the software engineering department for some years I look I'm an electrical engineer software engineering is not engineering it's not and computer science is not a science open German it's not a problem right it's informatics so it's a craft and I mean there are some like any craft I mean there are there are scientific bases I mean I need to know how to mix paints in order to be a painter so there's still some science here but I disagree with with with Uncle Bob and that the side of professional is whatever he says it is what do you use use I mean that's that's just crap I mean professionalism is that has a much much higher bar than that but from a craftsmanship point of view this notion of working in small teams of being motivated by the things that Dan talked about here that Dan pink talked about oh that's what he likes and they have the same first name in autonomy mastery and purpose and and so those are the things that I often will identify with craftsmanship and it's just another way of talking about the things pink talks about if you haven't read the book drive get the book drive and read it it's just a little bit of a warning when I read it I thought it was a little bit superficial and I was looking for for more research citations it turns out he did all the research all the research is there he just writes it in a style that's accessible to the layperson but if you read some of this other stuff all the research is there all that stuff he can back up and it's just brilliant very much about that thank you so much for your ideas your thoughts sharing with each other and thank you for being here [Applause]
Info
Channel: GOTO Conferences
Views: 42,879
Rating: 4.4637146 out of 5
Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, GOTOber, GOTO Berlin, James Coplien, Gertrud & Cope, Agile
Id: ZrBQmIDdls4
Channel Id: undefined
Length: 56min 9sec (3369 seconds)
Published: Wed Dec 20 2017
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.