Scrum is bad 2

hi i'm jonathan can you believe it's been a year this is scrum is bad part two or really what i'd like to say is scrum is irrelevant i received a little bit of criticism over the last video mainly to do with the fact that they didn't think i was really really critiquing scrum itself i wasn't attacking an artifact or a meeting per se i was attacking a general kind of situation that happens in any team and since then there's this kind of division between those that think that there is this dark scrum mode and then there's scrum the ever holy method or framework and we're going to address that right here now [Music] okay so first of all a little bit of a disclaimer i'm not here to dictate to anyone in fact that is my stance on most things it depends there are constraints there are contexts we all operate under similar yet different conditions the disclaimer here is if you use scrum and it's good for you go ahead i'm not here to tell you to change from my point of view i think scrum is bad i wouldn't recommend it to anyone i wouldn't suggest anybody take it up or move to it i would recommend people throw it away and choose something else but that is an opinion and that is something that i hold and you can think for yourself in fact i believe so strongly in that when i present a version of a framework for you to follow it is not saying it is the best and nor is it saying you must follow it i am not providing it as a certification you're not going to have to pay me a thing right scrum is part of many methods that are out there trying to get your money snake oil so to summarize the first video i would say that scrum creates a a fertile environment for micromanagement it creates the environment for cards cards to be ticked for you to stand every day and say what you're doing what you're going to be doing next or any impediments you may have it's open view others are doing the same there's this idea that you're self-managing that your meetings are internal it's open communication but really it's also a way of i am still working on x yes i'm still working on x day three yes i'm still working on x why are you still working on x what is the problem there and now you start discussing that's part of this kind of idea that you are in an environment that's very exposed but more than that more exposure perhaps using something like jira or perhaps some other technique but people are monitoring and with burn down burn up velocity monitoring what is being done in the sprint your active participation in that and what is going on and they're doing it from a data point of view looking at data looking at these estimations and story points and all these things and they're looking at this and they're coming up with some kind of evaluation and they're basing it on nonsense the reason why you did this story of eight right it was you know given a number of eight and this one's given number of eight the reason why this took 12 and this one took something else i mean these are variables that nobody understands these are underestimates it's a group think the group got it wrong you got it wrong you didn't understand something you had to learn something but you're constantly focused on whether you did that correctly or whether you know something and you're also also focused on this value output so now you have to deliver this value we've got to send an increment over there so now people are in a daily stand up pressurized to tick a card and say move on because they don't want to be embarrassed again on day three um they they want to take it off they want to they have a motivation to take it off i have a motivation to cut some corners um let me just take this off quickly i don't want to stand up again tomorrow i say the same thing i'm going to move to some other cards right tick tick tick right get it done as quickly as possible great right however less thinking less design more focus on card more focus on tick statistical analysis what's going on in the sprint can we compare it to the previous sprint what are these story points right velocity these are all measures to help instill and place pressure on everyone to tick cards that is micro management you're not there as a manager but you are there by proxy now you could say well you know i'm a strong minded individual i'm a developer i say look give me room guys and i i've got a thick skin and i don't mind standing up day five saying i'm still busy with it right fair enough and maybe there is a a nurturing sort of environment as well uh mixed in this maybe maybe one of the team members is is uh is fluent in good communication with you and and says look you know like i understand like can we do this oh look at that oh i will understand that and so on and and you don't have to like say we know what you're busy with and sort of moves around and gives you space and that can happen but that's not part of scrum right that's part of being human i argued in the first video that it creates this conveyor belt and i stand by that it creates a conveyor belt where is the card that says refactor this or this contains technical debt we need to deal with it no it's all product owner user stories you know some kind of story point let's just do it right and that creates less design and you have to elbow yourself to get design you have to elbow yourself thick skin yourself and a lot of people can't do that right so we've got a team that is just focused on getting things out and that is bad we want to get things out but we want to get things out at a good sustainable pace they use the word sprint sprint is sprint but yet they use the phrase sustainable pace and that just doesn't make sense the ideas of scrum and what people confabulate scrum to be as they are working with it are two different things scrum comes almost from a point of arrogance right from i have all the answers these are the events these are the things this is what you must do right and then you must abide by that and and if you change anything well don't call it scrum right and it's got that kind of arrogance to it but then you've got all these people trying to do very good things in this framework giving it the benefit of the doubt and the benefit of the doubt all the time so i stand by video one let's get on with part two let's look at scrum cons right so i'm going to only suggest one right there are a number i'm going to bring up one there are a number of things that i can mention in this one and i don't want to over overly complicate so i'm going to give you one con and that is scrum is solving one of the smallest problems right so let's look at what it doesn't do right we've got many problems so it doesn't solve developer skills learning education doesn't solve how they do things right and what they know right it doesn't solve this gap between domain and technical it doesn't solve communication problems it sets up meetings but you know if there's a dysfunction in meetings or people or misunderstandings they will exist they will exist with or without scrum it does not solve that problem it just creates more communication or more meetings it doesn't solve designing or coding or technical things doesn't solve scalability or anything of that nature doesn't solve complexity doesn't solve any technical aspects of of coding just because you have a meeting to discuss something and something pops out doesn't you can't credit that to scrum you can talk about anything at any time it's not solving communication problems right meetings and meetings it's not solving it's not creating this kind of framework for communication a way of approaching communication or how to communicate it it's not giving you any answers in that what is software development and what are the problems i said that scrum is solving one of the smallest problems right so let's think about it i think of software development as really three areas one is technical right so we've got all the complexity design uh figuring things out and translating it into software terms right so that's all technical stuff these are developers this is knowledge this is skill this is you know testing this is operations this is all the kind of stuff that falls under technical and then we have user experience and this is you know when you when you're navigating through that technical domain as a user is it good for me right do i enjoy it is it a good user experience does it solve my problems that that's that's another angle and the third is management just managing the teams of the people and the features and priorities and decisions of that nature and if i was pressed to give percentages to those three i would say their technical is vastly greater than the others i i would put it at somewhere like 80 percent i would say management is like 10 and user experience is like 10 so scrum is not solving our biggest problem and even when it addresses the 20 percent it's only really addressing it from a very shallow point of view you must have somebody to communicate with customers and you must have stories and estimations and so on and it's really you know what we're looking at here 10 and if it includes some management in meetings another 10 so it's 20 and these are my percentages but you can have your own uh this is 20 of that pie 20 of the problem that it's addressing and it doesn't address it that well right so scrum is irrelevant all right let's look at the jedi framework we have jfdi or otherwise known as jedi can you see what i've done there with that athany right jedi framework let me zoom in first so we've got four things what work is there right these are jobs right tasks whatever you want to call them is it the right work is it the right work should we be doing this right what is the context framed right so the work is framed the context is provided number two have you done it well obviously you now assign it right so is it the right work once you know it's a sign somebody pulls it does it makes no difference to this framework how you do that have you done it is what's important and that has decisions right so you can think of it at decisions on who does it but you can also think of as as you're doing it what decisions you're making and there will be decisions so think about those decisions next you you evaluate it you have a look in the field whether those decisions whether the job framed in that way works out and if it does good if it doesn't you can go back and start again what work is there in other words what do we do to refine this and uh that's part of the framing and therefore we have some decisions to make and we implement and evaluate all over again and we got four things right so you know if i had to think about this for ten minutes rather than five um i might come up with uh different names or you know something like that but let's not make this complicated it's a job it's a task it's a thing to do it's just that to do you want to keep it a list sure you don't want it fine right it's not my business you keep track of what you need to do and if that's each developer keeping track of a bunch of things or you're all doing it the important thing is to not commit to the list the important thing is to not make the list the thing you look at is it ticked is it moved is that priority shifted up what color is it done in red crayon that's not what's important it's just a reminder this is what we're doing this is what we're doing this is what we have on our cards to do next right it's a simple to do this and really how you do that is up to you and the framing well is it the right work well you know if you want to get somebody in user experience if you want to get in a product owner or somebody who monitors and looks at things like that sure why not right if they've ex they've got experience and they're giving you some value sure is it the right work to do so what jobs there are might come from someone might come from a customer might come from internal right framing it why is it necessary is it the right job what's the priority you have to frame it once that's done you assign it you only ask the question is it complete right so we'll go through how we migrate from scrum to the jfdi or jedi framework in a second and you'll see how this correlates with scrum terminology to kick the daily stand up habit right so we're moving from scrum to jedi framing so daily stand up how do you kick that well turn it into once a week turn it into when necessary turn it into smaller amounts of people contextually speaking only those that are really involved in this thing and you you want to move from a daily to when is really required now how do you evaluate that well very very simply put if the team needs focus and everybody together on something bring it in do a stand up do a stand up the next day you don't need to do it anymore stop it's not something that should become a ritual right you use it to advantage when required right when is it when is it required well probably way less than you think way less right at moments in a point of crisis let's pull together guys we've got two days let's get this out let's all get together i want to know what's going on every morning you can do that you're not micromanaging if it's a day or two or a week right but if you sustainably do that well now it's changing the whole nature of how you're working right so kick the habit from daily and move to when needed backlogs now in the new jedi framework there's this to do right the jobs well you can climb the backlog you can continue with that backlog but for heaven's sake do away with all the focus that you place on it right stop taking it as the definitive stop looking at it and marking it with green and red and writing comments and doing and prioritizing and moving have you checked the list have you checked the list right don't make it so important dumb it down a bit right make it simpler right put put little points on what you're doing make it way simpler don't don't be so don't be despaired if a different developer has a different list right doesn't matter are they doing what you need them to do now can you give them and feed them other jobs to do later right do you have a little list that you're keeping track of sure keep track of it don't commit that to everyone else right nobody needs a complete list of everything you're thinking all the time it's just clutter right so you want to move from taking a backlog sprint backlog and all these kind of things move to just a simple to-do list and then keep other lists private and bring it to the team only when required keep something that's active right you want to use kanban or something sure go ahead who cares right it's a simple list keep it simple next is you've got this product owner and scrum master role so let's see how we can morph these well let's make the product owner more useful with deliverables can you upskill them can they become a graphics designer user experienced person how can you use i'm not them favor of just firing people and saying you're not needed and all that so let's try and upscale let's get them in the team but what's important is that they're actually delivering value themselves right and clear-cut value they communicate with the customer and they're doing the experience they're doing the wording they're doing business analytics right they're doing all those kind of things they're looking at the market right fair enough they do that they're valuable to you keep them right but let's try and get them on the team let's try to get them in the team right look at a customer bring the customer into the team don't shield right nobody wants to be shielded i want to know what the customer is thinking and i think every developer should know there'll be one or two that don't really like talking to customers fine let them sit over there and let that guy go and do it but the customer needs to look and talk and see inside the team if you don't see inside the team it it's just these layers of abstraction and it just gets in the way the scrum master well personally i think you can send them off to some sort of digital transformation exercise you know put them somewhere else let them sort of look at digital transformation across the business and uh remote robotic process automation they'll love it right they'll love it they'll in their element right if they're software focused they're actually an architect or a developer and previous get them hands on again right get them learning the stuff get them in there if they've got architecture or that kind of skill get them get them be that sort of pragmatic architect that hands-on guy in there advising the team a bit of design and architecture but get them hands on right rename sprint to just working working right so uh you can say well i'm working on it somebody can say well i'll do it after i've done this thing right um it's in the pipeline right i'm just working on it right i'll be done when i'm finished with it right so just working okay so we don't need this sort of idea of a start and an end or you know just you know i'm working on this thing and now i'm working on this thing right i'll work on that thing next that's all you need to know definition of done well it becomes done right if somebody does something that's done and you think it's not done send it back and say please do it more done who cares it's done or it's not done that is what's important and the standard of your company right doesn't need a big term you don't need to define definition of done you just need to educate your team into what the standards and the quality and all that kind of stuff is and just work just do it retrospectives become hey pop me a message if you have any information about you know what we've been doing and whether we can get any improvement to send me a message right uh if it's bigger than that and you think that there needs to be a drastic improvement in some way talk to me we'll we'll call some little you know 15-minute meeting you can have a pitch why not right you don't need this kind of psychological retrospective you know you just need an open door right uh for people to walk in today by the way this is what i'm thinking right that's all you need burn down chart burn up chart those kind of things velocity delete james you're good right and what's up with you james i've noticed a bit of a slump everything okay at home okay don't get that personal right it's how you want to deal with your your employees but really philosophy is nothing it's what you want is just to be friendly with your team know your team know what's going on right deal with things right just help just be part of it don't hide behind numbers and try and get some kind of velocity and then apply it to people right and just that's ridiculous um yeah it's a ridiculous thing so we throw that away the review like the sprint review well that's another like when you have something to say just like bring it up right my door is open that's it right that's it just carry on with what you need to do you do your work and then when it's done we deploy we evaluate we come back again we have jobs we do it we you know that's all it is now scrum is about 30 terms right all these artifacts and all these things we have four four stages four steps they're very quick there's no duration limit there's no understanding of when it should happen there's no reviewing there are no meetings right how do you communicate just talk right should be async don't care use all of it right use what you need if it's too much communication somebody say if it's too little somebody say right there there's you know there's no right way just find what works for your team right and really these these things if you look at jfdi these things mean jobs framed decisions implement right or otherwise known as just do it [Music] you

Channel: Jonathan Crossland

Views: 4,166

Keywords:

Id: 5oPg08__v78

Length: 23min 1sec (1381 seconds)

Published: Thu May 05 2022