Merken

Fragile development

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
if you word to read the definition of something
that red that's something let's call it X for that X. there certain rules artifacts events and rules that the defined somewhere and these roles artifacts events and rules are immutable and although implementing only parts of
X is possible the result is not x the if you read something like this and your wired anyway like me then perhaps you might think about this being something like a radical political ideology that we're talking about or maybe a religious cults or something of that nature the In fact the X that we're talking about is from by its own definition this is a direct quote from the Scrum Guide the I came to Jeff Sutherland which by its own definition is sort of the definitive guide the definitive reference too scrum today so when we're talking about actually implement things from the will 1st have to think about what it actually is so what is scrambling really well the thing is that it's from even by its own definition isn't exactly sure what it is because if you look at the opening paragraph of those of the Scrum Guide the it
will say that's grammar is a framework for developing and sustaining complex products find that sounds relatively reasonable but then you go on to where it says definition the and then there's a definition of Scrum where it says a framework
within which people can address complex adaptive problems but productively and creatively delivering products of the highest possible value I I think if you bingo cards just went off but by the way just for the sake of completeness Wikipedia has an alternative definition and that is Wikipedia's as and iterative and incremental agile softer development framework for managing product development which I guess is a sort of a retroactive definition the regardless as you can see that's basically that's a bunch of jumble buzz words right the and it's been like that since about 1995 so can Robin Jeff Sutherland will figure we refer to as Canon Geffen these from literature 1st presented scrum in 1995 so I'm at a little over 20 years old by now and then uh the claim that it had previously been and I quote tried and refines before the formalize it before the 1st the presented at a conference in 1995 and companies like um individual are that so that was a news the company that was subsequently acquired it was there was a series of acquisitions not a part of writers Fidelity Investments those still exist today and IDX Systems there now part of GE Healthcare also be a series of acquisitions so they're saying that's by the time the 1st world it down by the time the for the 1st presented in 1995 there already been tried and refined In actual development used at a bunch of companies successfully no I don't believe any of that but that's what they say the so let us on like this again this is taken directly from the scrum died I'm scrum is defined to be as and again these are a few buzzwords here that should really set off a few alarm bells if you've ever read anything like this before Scrum is said to be light weight the simple to understand but difficult to master to now I think that is actually a stroke of genius because what the authors managed to put into the very definition of their method is the possibility of you media and everyone else simply being too stupid to do it because remember difficult to master so maybe just competence and you're doing it wrong also lightweight and simple understand and simple to understand and translate that for you and that's basically well when I actually defining a lot but these were describing that in simple terms that basically more or less almost nothing so let's look at some of the things that scrum actually postulate some of these it postulates explicitly some of them are implicit and sort of underpinning the idea of Scrum or the ideas and the methods a ascribed the and we should just look at what's from postulates but more importantly whether any of it actually makes any sense so there's 1 very very central tenet in SCOP and this is 1 that by and large I'm actually not going to argue that much about and that is Scrum says teens self organized now I think every 1 of you will at some point in their lives have been in 18 that was perfectly capable of self organization I certainly wasn't sure you have so this is not something I'm going to argue as being patently false it's very clear and I think it's self evident self explanatory the teams are capable of self organizing but from your own experience your probably agree with me that there must be a that we must meet a very critical precondition to teams actually being capable of self organizing and that is stability the more stable a team is the lesser team changes the mother has a chance of actually becoming self organizing In contrast if T is constantly change in the same still more chance in hell of self for him now let's see how we can apply this to the software industry in there's 2 things that are true about the suffering is which is the 1 we are very growth-oriented industry if suffer companies are healthy they grow they hire more people they grow
their teams teams change we also a very competitive industry competitive in the sense that employers companies compete for developer talent it's clearly more or less a seller's market when it comes to job talent in the software industry so as a result because you know the colleague that you're working with might easily have an offer that's
good is too good to turn down on the table next month and and that's 1 of your colleagues that's gone from the team and maybe at the same time you're hiring a new person or maybe you growing answer your bringing more people onto the tee now some of you may be familiar with something that's sort of the uh almost all rag in in psychology you know Tuckman's stages of group development some of you may have heard about that was 1st written down in 1965 you may have heard about this thing of where teams go through a out of forming storming norming and performing stage right I'm not going to try and that beta did worse here too much is is also a very reasonably well known and has anything in the behavioral sciences always honors a certain degree of discussion but I think we can all agree with is that when a team goes through these stages in the evidence is pretty good that most teams do then at the moment there is a person joining or leaving a team you have a new team any effectively start overnight can have people were very very at capable of dealing with these changes in Andy's phases are somewhat compressed and there they take less time to complete but the thing is your teams will go through these phases and so the very idea very basic postulates of Scrum but was out the window when we apply to the software industry for the very simple reason we don't work pretty much unable to meet this person prerequisite esteem stability that's about a few other things that are defined in at it is fun we have our basically a timebox time period which is sort of our central unit of planning in that period is called the spring the but in the scrum guide says the sprint is 1 month or less it doesn't really say much about anything else in theory could aspirants that are 1 day in length that doesn't really make a lot of sense for most companies will be something like 1 month or half a month or maybe a week if there is if the iterate extremely quickly if you are by the way if the company is using springs that are longer than 1 month congratulations your company's not using Scrum because remember In our rules roles artifact and events are immutable and if you change anything that's no longer strong right but 1 thing is that the scrum expressly says every sprint is followed by another spreads like immediately without pause in between it also says a few things about how is print should be organized from a sprint planning sessions UAI to the actual developments print that you're doing to a sprint retrospective and so forth but the important thing is that every sprint is immediately followed by the next spring 0 it strikes me as baffling how someone could come up like with something like this because effectively it's white running the Newark City Marathon as a series of 100 meter dashes the that's not gonna work too well and and suffer development is very much a long-distance sport and I am of the conviction that if your organizing soft development as 1 sprint after another spread after another spring the only thing that this can possibly lead to is very very profound exhaustion and eventually you're either going to run yourself into burn out or worse you can do that to other people the the then there's this thing in Scrum again this is an immutable events to the Daily Scrum I the biggest problem is defined as is actually funny is defined as the time box demand of exactly 15 minutes OK let's get the benefit out here a little bit OK so let's say it's approximately 15 minutes but it can be long that involves the entire development team and that the every member in the development team answers the following questions 1 what did I do yesterday to help my team achieve the sprinkles to what I'm doing today To help him achieve the spring sprinkles and very was holding the uh what are the obstacles that I see impeding myself for the rest of the team from making progress no I find it amusing that the authors of or the the inventors of Scrum means that there defining daily occurrence that is so finding that actually means the whole method overall after the events in the reasonably violence contact sport that is so potentially dangerous that professional practitioners of the sport recognize a safe words which they either in the scrum when the fear that their next might be broken OK if you're professional rugby union player people will recognize the say for next the if players are pushing down so hard on your own that you fear it might snap I think it's really was to use something like this as a metaphor for ideally team meeting I think it's really really weird but that's just a technicality assist you know naming things that's 1 of the 2 hard things in computer science the things are the cash elevation and often errors on but what we decide the name right even if scum called it you know the floor meeting or whatever the very idea that your entire development team who gets together at a fixed time every single day of the week to discuss these things strikes me as positively anachronistic was fine I guess in 1995 when people could generally be expected to work out of the same office when development teams were rather geographically closely located but I think it's completely out of this world in 20 16 when the default is that suffer development teams are geographically distributed some of them may work in offices some might not OK fine we have excellent videoconferencing technology at this point so we might actually use the physical a and translated into something that is virtual but people work in different time zones people work based on their own their own way of of basically you know jumping up that that the data into into work time and family time and so forth the idea is for everyone to get together in a 15 meeting at the same time that is somehow compatible with all time zones I don't see how that works I and II I have a colleague works in Brazil if we need to get together on a conference call with a custom in Australia that's almost impossible a schedule even if it's just for 15 it's try doing that every single day that's not gonna work too the the another thing this is not expressly stipulated in the scrum writer all but the it's something that strikes me as relatively typical of organizations that are attempting to practice from you might who have garnered at this point I don't really believe actually implementing strand is physically possible but at least if you are a lot of organizations try to is the thing that you are planning generally covers the current sprints you have basically is a short term planning that's you're what you daily work and then you've got your sprint and that's about it all the definitive planning that you're doing beyond that you have a product backlog the product backlog is prioritized so you know in which water you're going to be doing certain things but you don't really know what you you also know when your next spring is going to be but you don't really know OK what are we gonna do the next print what we knew the spring after that because that's that's kind of do you can't do that now OK fine this might work in Ireland humble opinion it will likely only work if the number of customers that you have a 0 the customers and uses it doesn't really matter and that people will want to have some sort of information when they can expect certain functionality or certain features now people are generally find with understanding that's offer schedules tend to slip and that these I mean if unless you're actually done enough to make a binding commitment but if you just saying OK were expecting this feature the land by time or by release X which is expected at times x you people are generally willing to understand that these estimates are to some extent tentative because you might be running into certain issues you might be running into Boggs certain things might take priority and so forth but having no planning at all the is something that has also been described as just being dangerously short term you generally tend to lose sight of the big picture is the only thing that you're really caring about is that is your sprint the In nothing beyond that now I'm not gonna argue that something akin to what were doing in the scrum development isn't it reasonable under certain circumstances the example and methods like Scrum it's not going to be scrambling method like that where a team comes together elect not so much a leader but a
spokesperson and then just starts hammering away at a task that's something that's entirely reasonable for emergency situations you know I and I don't necessarily mean life-threatening emergencies and maybe it may be something like OK you know if we don't ship this by time funding round doesn't come right or something like that so under those
circumstances I think it's perfectly reasonable to use an approach like OK we're going to get together and we can elect a spokesperson we work and when the start rolling and then importantly when is done we go back to our usual mode of operation and if you if you using a development method that is reasonable for emergencies all the time that basically means that were acting as if our company was always in an emergency if your team is permanently operating in emergency mode you need to quit it doesn't really matter which side you're on if you are basically a developer on that team then you need to get out of there because if you're in a really bad place and it's only gonna get worse for you and if you're someone who actually opposes this method on the team then you're doing something even worse because you are basically burning your people out that's not something you want to do by the way just for the sake of completeness specifically in large corporations if you are up at the c or CXO level it's relatively common that those people are going to spend most of their time fighting some sort of fire responding to some emergency in the original sense something that has just emerged that they need to react to fine but it's not something that should trickle down all the way and should not govern your entire company the 1 thing that from advocates and I can ask for a a raise hands for strong evidence here 1 thing that's from advocates frequently tend to say or put forward in in favor of strong or in defense of scrap or for that matter really in the defense of agile is that they're saying the latter file method is bad and Scott insert agile here if you want to is a novel so Scrum is kind like manna from heaven that finally of sets us free from waterfall I now this is almost like a bit of a straw man right but it's also not true I mean the whole novel thing isn't true and it hasn't been novels since about 1975 if you are in any kind of sulfur development or engineering rule and if you have not read this book you've made a big mistake you really should it's a classic is Fred Brooks's mythical man month season's offer engineering originally came out in 1975 it had um a 10th anniversary of the 20th anniversary edition were additional content was added but what he said back then was waterfall is a terrible idea and in fact guess what he proposed he proposed a model of iterative development he basically said what you should be starting out with is a piece of program as was called at the time right we're talking about programs because were programming from mainframes at the time but basically he said you should start out with up program perfectly does nothing that right as perfectly fine and doing nothing and then you add features iteratively and you always continuously have a working program now at the time he called this the spiral model of development since then that term has slightly shifted so that's why I am not referring to this model as the spiral model because now you thinking aspire Muller something slightly different which is a risk-based development method where you have a certain set of features and you're thinking about OK changing these and then you try to assess OK what's the risk that associated with this it's a very very defensive effort and so the the meaning of that has has changed all that but if you want to look at iterative suffer development you really don't have to go you know to 2005 in 1995 that's an old hat something that's much longer and so 2 % crime as the antithesis to waterfall that's just yeah OK and you're comparing it to something that we all know is terribly imperfect anyway the something I think is particularly toxic about scrum is that scrum advocates frequently tend to argue along these lines which is if the scrum method doesn't work for your team your problem is you're team you should be firing some of your people and you should be hiring people that are better at doing Scrum I firmly hold this to be untrue if scrum doesn't work with your team your problem is from not your team and what you need to change is the way that you're doing your development method and not necessarily the people on your team a Kerala corollary to that or something that we've that you frequently finds it in the same vein it is it's crimes miserably fails to deliver results in your organization it's because you're doing it right I think this would only at this is because you're doing it wrong I think I think this will only happen if you do it right I don't think this is possible mind you I don't think it is possible in an organization to implement Scrum by its own definition which means with all the walls roles artifacts in events completely unin changed I don't think you can really do that but if anyone wants to do it I think would certainly lead and lead to disaster and straight into it yeah so my 1st message please just don't abuse from back OK trying to not be as from that if you were at some point but at the cost here's react for recovering scumbags in all 3 because it turns out there are certain things that we find in Scrum an agile and so forth that are actually reasonable now mind you I'm not going to argue any of this is doing sort of scrum-half fast because by some definition you cannot do that so what I'm talking about is certainly not spam but there are certain things that we can salvage out of what's crown postulates any of salvaging things it not is
not necessarily bad thing something sometimes you can go through a pile of rubble in the landfill and find some really really valuable things this is the the Atari Game The in New Mexico in 2015 and Atari in the early eighties dumped a bunch of game cartridges for games that didn't sell just basic and bury them in the ground and so on and now of course some of these cottages are like worth hundreds of dollars so they but those up and you get a special permit for the the Duggers up and and you can there's like several Torre 26 100 cartridges of ETD extraterrestrial and the dog out from this landfill so there's 1 thing that I personally actually think is a reasonably good thing in scrum even if it's not very adequately means right a product backlog a backlog is something that's sort of akin to a traffic jam right it's an impediment to movements so it's like it's a little weird as far as the meaning is concerned but the very idea that you have a transparent lists of things that you a product should
at some point do and then be able to prioritize that's so you know OK this is what's more important than this other thing provided you actually take an order of priorities that ranks things that are important higher than those that are urgent I I think the product backlog is absolutely reasonable to have basically keeping track of all the things that you want the product eventually to do is a perfectly fine thing to do the the strengths well kind of useful so we use a few things that I already mentioned this the life that I think are really terrible about springs of 1 were only planning in the current spread we're not looking any further tune but we have the not really worrying about anything that is further on down the road 3 every spread Italy follows an express so the way I do it with with my development team it is number 1 we have a product backlog we have the immediate next sprint and we use a typically a 2 week period sometimes a 1 month period for that and uh so we know when our current Sprint is when a next print is going to be 1 an expert is going to be what we do now is we put down all the items all the user stories that but the part that what items that we want to do it on our current and then on futures friends and everyone on the team understands that only the current spring is binding only the spring task for for the current spread is binding and everything else is completely tentative and subject to change so what does that give you that gives you a bit of an a better overview of where we're going and we know we're losing this completely short term focus and we can look out a
little further and also and I think this is just a reality in a fact of life is perfectly fine in the project to have a hiatus it's perfectly OK to have a sprint that is followed by a break and then a couple weeks later you pick up an expression remember this is not stomach of this crime you cannot do this in Scrum explicitly in every project yes Brenda sprint of the part of so I think the concept of springs is kind of reasonable it's something that you can use albeit in a very modified fashion the next thing so points right so in 1
admirable thing that uh tends to do what has to want to do is rather than assigning a measure of and you know this is gonna take such and such effort or worse still this is going to take so in so many person-days right remember we upon Brooks mythical month in 1975 you wrote the man months is a dangerous and deceptive myth for men and months are not interchangeable right that was the exact exact quote in in 1975 and so let's come tries to do is it tries to assign an abstract measure of complexity so some teams tend to use the term bananas for that right so users stories and so many bananas or whatever you come up with a family enough but scrum doesn't really say anything about perhaps renaming a story points maybe that's which is actually the and so the idea is that you have sort of this abstract measure of complexity and then you figure out in all the your burned down like into into what time that translates right so you've got so in many bananas and your your burning so so many bananas for Sprint right and so then you get this abstract measure of complexity now again this in my humble opinion is something that self explanatorily only works if your team is stable because only few teams stable would eventually converge on a reasonably accurate measure of complexity across teams right and or and I really think this is far inferior to a different approach which is and believe me this is a complete scrum no no this to actually taking user story and break it down into tasks in my degree of granularity that I think is is of makes the most sense to me is the most reasonable to me is break it down into a granularity such that the task in your user story could at least in theory be done by a single person so basically you have tasks in there that all that do not require splitting up anymore and then what you can do is you can have people basically I estimated the complexity of those tasks separately and then you can add them up again like I said an agile petitioner will say neural is a terrible idea because what the team should do is it should take an arbitrarily complex user story and had somehow come up with a measure of complexity for the whole thing by consensus I think that's a really really terrible idea and I think that breaking it down into individual manageable task and estimating those separately and adding them up is something that simply works way better for human nature so my my person would appointed by the way you know FIL by means to free division disagree with me on this 1 is so points are to be useful to an extent not a lot but it there's 1 thing that's related to story points that I think is paddling the occurs and that's the idea of playing poker right so the idea of planting poker is that and you when you have when it when the team comes together and it is expected to assess the complexity of a user story by consensus you have this concept of anchoring where whoever says any kind of value 1st that's what everyone else is going to be calibrated against right so let's say for example the and we have a certain task which someone estimates to be 20 bananas but the 1st person talking says find and they say well maybe I was a little high on that if I make it a double the estimate of the other person we should kind of sort of you OK and then they say 10 and in reality you find out more like 20 to and you would have been right in the 1st place if it were not for this anchoring things and so the idea is that you you you get the stack of cards and you put down everyone selects their estimate puts a face down and you turn it up all the same time but I think if you're if you're thinking that that makes any difference news completely lying to yourself because eventually discussion is going to ensue and then you have the exact same anchoring problem again which is what happens if you've got 3 people in this area
at of light and so in so many story points and you've got 1 person who like well below effect as the person who is you more competent to knows and understands a shortcut end correctly estimates that it's actually not as complex what is the person who is just the overly optimistic right I don't think that playing poker really adds anything to the whole thing so for me that's a clear null so like I said there are certain things that in my humble opinion you can take out of the postulates of Scrum that you can and perhaps should do but it's actually not strong at all by its own definition and scram by its own definition really needs to go out the window now this being a technology conference of course and what would I do if I would also talk about tools I so I that we did in our own development team was um we've looked at and you know there's a bunch of Agiler agile each of project management tools out there we look at a few of those and so what we calibrated them again served the way of of managing or or development projects and to see how well they were a suitable for that we looked among the tools we looked at were assigned Trello there's an agile mode for June so we found all of those lacking to be in 1 of buttons to be lacking in 1 way or another and we eventually settled on a tool which some of you may may know some of you may not so many years heard of Tiger 1 OK and the ovaries and good so the title is a is a uh of it defines itself as a project management framework with scrum in mind OK so that is a it's scrum it just says With this crime in mind but it's a it's a a particularly useful tool it's something that you can get but as a service this comes out of a company from Argentina the in it has a a handful of tools and that you will find quite quite not quite reasonable and and useful so for example and this is just a regular a project that word where you you basically get an overview of like the projects so your currently part of the things that you're working on whether
those are tasks or issues or something else and and that's reasonably useful 1 thing that I particularly like about Tiger is the fact that the number 1 it supports get have log in that's always helpful so it only to basically 1 on their it also has a very very good did have integrations of for example you can do certain things like and there is a a b 0 you can you can update the status of a user story via get up commit message In get now that's
and those those things are kind useful arm but 1 thing that I think is is particularly need is that you have development teams that are per projects and you can bring externals in on individual development team so specifically fear contracting out some there's often suffered element this can be very very helpful where effectively or but not your contract is up you're the contract it for suffered element where you can for example bringing your customer as a product owner if you want to use that terminology right which is what we're doing for example here but with the with the codified course that's for of 1 of our customers GigaSpaces and will bring and some of their team on effectively as as as product owners and and people on the team to and you also get you know if you like burndown chart you do get burndown chart and you do get a
task list and and so on and of course you also get uses stories the I that you can then break down into tasks you can add attachments you can add comments and so forth and there's something that I think is particularly cool about Tiger the and that is this thing is is relatively new to Tiger the caller tiger tried I'm and you can effectively defined user story and you can then contacted out if you want to you can post it as a gang on Tiger tribe and then you get connected to to a developer who might that be a suited for doing that and then you can basically a contract job out on on on on a one-off basis and hopefully actually um establishes a relationship with that person so if you're hiring manager that may be a good way to find talent as well and best of all and I will be talking about Tiger if it wasn't this it's all open source and so it's not 1 of those things that you can only run as a service and what not you can sell follows this thing it's under the Affero GPL 3 all the of all the code is upon get everything go to get a dot com slash tight I own and it's everything is the front and the back and the API so everything's upon it out and is under but the a
GPL license and there also eating their own dogfood so they have their own user stories for Tiger in tiger as public projects so you can effectively follow their our development transparency and if you do go by the way with the with the um who's version and it's currently I think they have any intention change that free-for-all public project so if you do the same thing that they're doing with their project which is make everything public for everyone to see that for free and only the of private projects of people on our team cannot see those are what you pay for of course unless you self post in which case you can rule this out on your own server and it's actually pretty cool stuff as something that you might want to look into this is something that interests you just in case you're curious what have we use this for what have we of built with this and you'll see that effectively were using this for something that is pretty much straight up Soffer development but we're also using it for something that is more rounded them up side of things we run a but learning management system called academy that it sticks to the common we're originally a professional services company that offered in the and and a lot of face-to-face in-person training on things like uh RSF and and OpenStack and distributed knowledge e and so forth and what we wanted to achieve is uh we want to its to do all of this in what we call spot self-paced online training to basically the idea that you can log onto this thing and you get your own set cluster play with and you run through a series of hands-on labs and exercises and so forth that basically takes you from 0 effectively having blank servers to having say for example a fully working OpenStack cluster a fully working set cluster and so on if you if you got your user can certainly visit us at academy down aspects of outcome hello to see that so we manage that we manage effectively the iterative development of our own learning management system platform which by the way is based on open at x but with tiger and with this development method development management method but we also do the same thing for the of full integration of the open addicts Learning Management System stack and OpenStack so we worked on making open addicts work on any OpenStack clouds if you're anyway interested In a learning management systems in running those in private or public clouds that something that you might be interested in as well the and this also includes interacting with OpenStack the room and these on-demand lab environments where effectively we can point our system at any OpenStack private or public cloud how to fire up these arbitrarily complex assumed systems for labs as as learners need them and finally um what we have to do in order to do that is make some contributions to open x itself open at excessive a plug-in system they're called open it expects locks the so we wrote a couple of those and those are up on get up their open source their public and also the the tiger the project words for those Republic as well and we use that the that just the same but it's a development approach that we have been using for just under a year and a half now it's something that were quite happy with maybe it's something that you want to consider before the questions on to I'll be happy to share
the slides of all my slide decks are normally under a Creative Commons
Attribution Share-Alike license so if you want to use these modify them whatever you're certainly free to do so
and the slides are and help that I 0 slashes fiancé flash frost
on 2016 and those are the ones that those are actually the sources for the slides if you want to go to the slides directly they're
here if you're grab these and she worked fine on your phone and so forth as well OK with that I think you for
now and I'll be happy to take questions or but and that that of but what's your reasoning for saying that but if you keep a prioritized backlog and only plan for 1 sprint in detail you cannot keep the big picture in mind so this is not so much a challenge for the for the development team right so if you if you have a smart development team and by defeated by definition normally you do right but they will have a fairly good understanding of OK this is this is where the backlog looks like this is the priority list and so forth but how do you communicate that your customers and users if you don't care about that all which in my humble opinion you can only do if you have 0 of them then you don't mind either but I think it's very important to have at least a rough idea of this is going to land this is going to complete your will be finished in about such and such time frame for but again that's just like in and by all means please feel free to disagree sir yeah but if the product owner for that if you if you really do a scrum new Ching isn't supposed to talk to your customers that's the product almost task we had method of 100 good that yeah that's I mean yeah fine so of course yes you accusing talk but where does the product owner get their information from the only thing that they do is basically a backlog and they're not allowed to put anything on a future for either the it with except they can put stuff in the back but steps yet wanted to have a strong I said I mean the only thing that you can actually tell people is you can effectively make relative statements well you can make the absolute statement we are going to do that we're not going to do that you know you could of course you can offer this is completely out of scope don't hold your breath is never going to happen and you can say OK so we're going to do this but not until this other thing is not so basically you can tell someone that well come back after exercise on so we can talk about why but that's about although there are many users of and on that note if that's then plus already that's in the origin of the firmament yeah it's true you know it OK we have I saw a hand over here and over that the you the it is that you don't care about depleting that much at all them but said starting points can be important in a way at least maybe bundle on but it cannot this from the air was so you can't have started plans with other planning program I think we you can have story points fi actually having at least a tentative breakdown In the tasks if you can break a user stories into the past to the point that that you can you can you can define your task has been manageable y by 1 person then most probably what you're thinking about is too complex for a new story anyway you basically have to break it down some right I and me if you are able to effectively say alright so here these individual tasks and a and you can now effectively estimate the complexity of these individual tasks and then add them up but who estimates for that but who estimates apart from case that ideally idea if you can break it down to like a single person and you perhaps actually have a person mind you might be the qualified expert to do this by the way again this is something that is from is a big no-no because it's from everyone's a developer right this by the way I that and it's is it is it explicitly mentioned in the scrum guide is that within the team there's only 1 rule that is acceptable and and always developer and have it explicitly says the sum I call on there are no exception to this rule period so if you work on a team that claims to use from and your business cards as anything other than developer and those from the sale I and so like I said you know what what's what's ground dies and is is that there like bridge everyone's equals and no one's a specialist and of course well if that's what it is that you can reason we get to the point of OK let's break this down let's talk to this person here she is the expert for exactly that thing and here she is going to be able to tell us OK this is about the the estimate that we can do and of course that person is probably not going to be quite are specialized in something else that they're calling is qualified to do so like I said this this whole idea of you know let's somehow draw an estimate for a user story I complexity estimate for user story out of thin air for me just completely doesn't make sense but processes time I rings where you have to do it for the world work or and they have no place to if you you know think so that's the that's in the comment was exactly what I mentioned this is fundamentally impossible almost for to just basically fish out a complexity estimate a lot of Fibonacci series of course right so we're not doing anything else yes sir the what a lot of people who suggests scrambly is a good method for start ups but from what you've just told us it sounds like a better terrible idea the costs in start ups you never have stable so that the BER part of this I agree the who thinks question the sum of the total the I really think it is a terrible idea I think I think that the idea of expecting out of the team to somehow magically organize itself while it is constantly changing is ludicrous it's it's it's an it's entirely unrealistic expectations so I was just curious because the it's the suggested so often on the internet so this trend is the most suggestive thing for start ups if if the Internet would have been around at about the maybe 218 it would be full of statement saying that the sun revolves around there graphic but with so the the the the the appeal to majority never really works actually higher than that and we have the gentleman in the world right green shirt of and the yeah if the other 1 was so that you should say look at ScrumMaster framework of tools uh you should see um the yeah just but the Pepito's you like and use some of you like the solution measure like and notes let's scrum of master your process but use ScrumMaster to show that the new process and you are perfectly free to do that with in the very very limited freedom that's from allows you the right so for example you can organize your daily scrum in any way that you want you could for example put out the rule that everyone has to stand on their chairs or something more that everyone has to come in red T-shirts but it has to be daily the 15 minutes so the freeway yes it is a framework which are relatively rigid 1 the right it's I mean I guess you could call a full body cast a framework it but it doesn't allow you a lot of flexibility and on the register in a distance the word we use come and as a company the decision wouldn't gullet scrum analysis it doesn't the above a district rules and don't be a stronger the sales crime Bession going on here and it's like OK do have to stick to the rules and some literature but in come on the if you at that it's a set of guidelines use your brain and at accordingly right stick to the good mood doesn't I've never seen right fair enough and what does that say about a method that explicitly said you must stick to these rules otherwise you're not doing it I'm sorry this is not a method the the there are other 2 all it thank you very much and that was but what I'll be happy to take questions later on of that vector coming of age and that
Resultante
Mereologie
Natürliche Zahl
Schlussregel
Ereignishorizont
Quick-Sort
Computeranimation
Schlussregel
Open Source
Freeware
Offene Menge
Wort <Informatik>
Elektronischer Programmführer
Ereignishorizont
Zentralisator
Stabilitätstheorie <Logik>
Punkt
Gewicht <Mathematik>
Selbst organisierendes System
Formale Grammatik
Term
Framework <Informatik>
Computeranimation
Anpassung <Mathematik>
Adressraum
Biprodukt
Kontrast <Statistik>
Softwareentwickler
Softwareindustrie
Autorisierung
Vervollständigung <Mathematik>
Präkonditionierung
Reihe
Biprodukt
Quick-Sort
Chipkarte
Framework <Informatik>
Komplex <Algebra>
Hypermedia
Mereologie
Wort <Informatik>
Axiom
Resultante
Zentralisator
Quelle <Physik>
Bit
Punkt
Momentenproblem
Hochdruck
Familie <Mathematik>
Gruppenkeim
Computeranimation
Videokonferenz
Einheit <Mathematik>
Prozess <Informatik>
Bildschirmfenster
Meter
Elektronischer Programmführer
Default
Softwareindustrie
Phasenumwandlung
Lineares Funktional
Dicke
Reihe
Systemaufruf
Biprodukt
Frequenz
Zeitzone
Ereignishorizont
Scheduling
Verbandstheorie
Rechter Winkel
Information
Tabelle <Informatik>
Stabilitätstheorie <Logik>
Subtraktion
Quader
Selbst organisierendes System
Wasserdampftafel
Mathematisierung
Automatische Handlungsplanung
Zahlenbereich
Term
Physikalische Theorie
Erwartungswert
Arithmetische Folge
Maßerweiterung
Softwareentwickler
Ganze Funktion
Informatik
NP-hartes Problem
Schätzwert
Schlussregel
Quick-Sort
Office-Paket
Minimalgrad
Wort <Informatik>
Axiom
Resultante
Bit
Selbst organisierendes System
Iteration
Unrundheit
Term
Übergang
Task
Selbst organisierendes System
Informationsmodellierung
Spirale
Vorlesung/Konferenz
Inhalt <Mathematik>
Softwareentwickler
Gerade
Metropolitan area network
Nichtlinearer Operator
ATM
Vervollständigung <Mathematik>
Klassische Physik
Softwareentwicklung
Schlussregel
Elektronische Publikation
Quick-Sort
Ereignishorizont
Großrechner
Arithmetisches Mittel
Menge
Rechter Winkel
Message-Passing
Sichtbarkeitsverfahren
Quelle <Physik>
Expertensystem
Videospiel
Bit
Hochdruck
Güte der Anpassung
Zahlenbereich
Mailing-Liste
Biprodukt
Einsteckmodul
Frequenz
Term
Fokalpunkt
Quick-Sort
Computeranimation
Task
Arithmetisches Mittel
Weg <Topologie>
TUNIS <Programm>
Rechter Winkel
Spieltheorie
Mereologie
Biprodukt
Softwareentwickler
Ordnung <Mathematik>
Quelle <Physik>
Subtraktion
Punkt
Natürliche Zahl
Familie <Mathematik>
Komplex <Algebra>
Term
Physikalische Theorie
Division
Computeranimation
Task
Arithmetischer Ausdruck
Kontrollstruktur
Punkt
Maßerweiterung
Einflussgröße
Metropolitan area network
Schätzwert
Videospiel
Abstraktionsebene
Quick-Sort
Chipkarte
Arithmetisches Mittel
Minimalgrad
Flächeninhalt
Rechter Winkel
Heegaard-Zerlegung
Projektive Ebene
Soundverarbeitung
Schnelltaste
ATM
Punkt
Güte der Anpassung
Zahlenbereich
Automatische Handlungsplanung
Framework <Informatik>
Computeranimation
Integral
Task
Dienst <Informatik>
Datenmanagement
Rechter Winkel
Mereologie
Bildschirmfenster
Wort <Informatik>
Projektive Ebene
Softwareentwickler
Axiom
Open Source
Mailing-Liste
Element <Mathematik>
Biprodukt
Code
Computeranimation
Design by Contract
Task
Dienst <Informatik>
Task
Datenmanagement
Prozess <Informatik>
Rechter Winkel
Basisvektor
Rechenschieber
COM
Projektive Ebene
Softwareentwickler
Versionsverwaltung
Offene Menge
Wellenpaket
Desintegration <Mathematik>
Mathematisierung
Versionsverwaltung
Keller <Informatik>
Komplex <Algebra>
Systemplattform
Computeranimation
Datenmanagement
Softwareentwickler
Open Source
Reihe
Plug in
Physikalisches System
Keller <Informatik>
Integral
Rechenschieber
Dienst <Informatik>
Menge
Offene Menge
Server
Projektive Ebene
Wort <Informatik>
Ordnung <Mathematik>
Programmierumgebung
Streuungsdiagramm
Prozess <Physik>
Gewichtete Summe
Punkt
Total <Mathematik>
Rahmenproblem
Automatische Handlungsplanung
Bridge <Kommunikationstechnik>
Komplex <Algebra>
Framework <Informatik>
Computeranimation
Internetworking
Eins
Task
Flash-Speicher
Erwartungswert
Fibonacci-Folge
Inverser Limes
Abstand
Elektronischer Programmführer
Softwareentwickler
Profil <Strömung>
Einflussgröße
Analysis
Attributierte Grammatik
Schätzwert
Expertensystem
Befehl <Informatik>
Green-Funktion
Güte der Anpassung
Softwareentwicklung
Ausnahmebehandlung
Schlussregel
Mailing-Liste
Vektorraum
Quellcode
Biprodukt
Frequenz
Entscheidungstheorie
Chipkarte
Rechenschieber
Twitter <Softwareplattform>
Menge
Rechter Winkel
Mereologie
Wort <Informatik>
Verträglichkeit <Mathematik>
Information
Ultraviolett-Photoelektronenspektroskopie
Computeranimation

Metadaten

Formale Metadaten

Titel Fragile development
Serientitel FrOSCon 2016
Autor Haas, Florian
Lizenz CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
DOI 10.5446/32425
Herausgeber Free and Open Source software Conference (FrOSCon) e.V.
Erscheinungsjahr 2016
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Anyone doing any kind of Agile development has heard of or practiced Scrum, which has become a favorite among development managers. In reality, Scrum is a scourge, not a boon, and it's time to understand that the emperor is naked.

Ähnliche Filme

Loading...