Kanban vs Scrum: what's the difference, and which should you use?

learning what scrum is normally something you pay a lot of money to somebody else not me I've done other business somebody else and sit in three days of classes right so we're gonna do in about 25 minutes what would normally take three days totally doable in my opinion okay scrum in a nutshell you form a team you collect work you prioritize work you pick up some of the work you do this in something called a sprint and I'll define a sprint more then you show what you did and then you think how well did we do what we just did a moment of reflection called a retrospective and then you do more of that you pick up some more of the work do another sprint show what you did in the second sprint and you reflect again on how well the disparate go compared to the last one while this is going on work continues to come in so that's one thing that's very important to understand about scrum is it expects a changing environment it expects that what work was previously thought of my change in size or shape a new work will come in though scrum is really all about trying to deal with change and remain sane in that process okay it's good to spar body form a team I'm going to talk about a few different roles here by the way all the scrum stuff I'm gonna define in the way that I've seen it actually play out in real life and I started doing scrum in 2006 just like lemon years now and I found that some parts of the theory work really well and some parts were total BS and so I'm going to not you know go into that part but just try to tell you what I think I will actually work okay there's somebody call a product owner the product owner is the voice of the customer you all have customers I hope you understand that I am actually a taxpayer so that makes me your customer okay there's only one voice of the customer they are not many voices clamoring for attention that's the first thing to understand about the product owner is that product owner represents one voice or as many voices as needed only one voice that stops they can talk to the scrum team at a time the scrum team does not want to listen to 20 different people that's the job of the product owner to be that interface that says look I represent the voice the customer and I can tell you what needs to be done okay then you have somebody called scrum master people think the scrum master is the project manager actually not really not in the sense even known project managers not in the sense of somebody walking around with a clipboard saying what have you been doing lately not in that sense a scrum master is one person on the team whose principal responsibility is to remove what we call impediments and impediments anything that's stopping you from getting your job done so scrum master may be very busy or totally idle it really depends upon how difficult the work was in any particular sprint and because there are times when a scrum master may be totally idle it's not necessarily a full-time job that means that scrum teams don't necessarily have full-time project managers which is kind of a strange concept I know but the idea is you don't really need it and also anyone can be scrum master who wants to gain the job of clearing impediments and then finally we have the team and I described to the team as people who can fall so pole here is like special pole most of the time most of my career we came up in a world of push push means somebody pushes the work onto you right so there's a piece of work give it a job this is also John's work let's keep pushing on time this also looks like John's work push it on tip when you push on to work right that's just you thinking John's gonna do that work right and that's you being oblivious to whether John can do it what John is has on his plate pull is the reverse pull says when John becomes free when he gets done with what he was doing he will pull the next most important item and that's a big difference because when John pulls the item you could actually legitimately have an expectation that maybe John can answer for that item but frankly if you just push stuff on him and then you say where's the stuff that's not really a fair but if it John pull that stuff it is totally fair now say hey listen you picked this item so now I feel like you really own it so you need a scrum team where people can transition hopefully really fast from being pushed upon to pulling and actually that's a very profound cultural shift which can take sometimes a long time in an organization because we have grown up from kindergarten getting pushed homework right no one has ever pulled homework right but think about that right what if you pull down homework okay collecting work we will talk about something called stories and something called the product backlog a product backlog is a collection of stories it is not necessarily a bounded collection sometimes it is because the overall scope of the project is known so that's the limit you don't have stories that go outside that but sometimes this overall scope is subject to change the boundaries a little fuzzy so new stories can come in at any time it's prioritized from top to bottom very simple stuff that's important that is on top then goes down to the bottom and what's the story a story represents a piece of work that needs to get done and I would define it here as something that needs to get done that can get done in one sprint and then I'm going to define sprint in terms of working what it can do in a story so that's where the recursive part comes in but it's printed a piece of work and it's actually a piece of work that's expressed in a particular way as I'll show you and that piece of work needs to be something you can do fairly soon that very soon is how long your project iteration is and here we're talking days and the very few weeks that we're not talking months so we'll talk about how do you boil your work down to the level of a story but consider that everything that you have to do can be written up as a story and when you've written up all your stories you have a product backlog which you need to prioritize the product owner prioritizes that backlog that's the principle responsibility of the product owner is to make sure that product backlog is complete and each story is good like you can pick it up and you can work on it this is an example of a story as a small business owner I want a single place to file all my quarterly reports so I don't have to deal with multiple agencies this is a story I would urge somebody in this room to pick up because I'm a small business owner I would really like one place to file my report so if anybody gets inspired enough to actually do this I'll be really happy okay but this is how a story is normally written and this is this could be a typical story the components of a story you could write as a particular way there's an aza there's I want to and there's a throw that I can so let's see what this pieces are first of all as a who I wrote the story as a small business owner I don't know that's good enough it might be it might be a place to start but you don't want to write stories where first of all you can't distinguish between what a fellow employee in agency wants and what a citizen out there wants that's a common mistake people make they'll think the people out there want what we need nor do you know we want something completely different we talk differently than you folks right to get the who right because that focuses on what who this is for maybe it's not enough to say a small business owner maybe you need to identify me as a small software business owner before you can get clarity around the story because as a small software owner who actually doesn't want any physical assets I have different needs and maybe somebody runs a dry-cleaning business who has an environmental impact right so you really need to get the who part figured out then there's a watch what is it that I want if I'm a small business owner this is one of my wants that actually have many wants then pretty what's the list I'm upstairs I have a lot of ones but that's the essence of the story as this person I want this and what I always recommend is the last part the why because later on this is going to provide direction when you start doing this story why do I want it because I don't want to go to an unknown number of websites file reports right so that's why what a story does not have is how it does not say anything about how that's going to be done in the sprint they just expresses a bunch of things that need to get done it the product owner makes no attempt to figure out how it's gonna be done he just says look this is what the citizens want this is what the agency needs whatever it is that's what a story is any questions so far okay so you've heard of stories and you heard of epics what's an epic a really long story so an epic is a really big story that you can break down into multiple stories why do you want to do that because you want the story to be small enough that can be done in a sprint to look at that one story as a small business owner I want da blah blah can you do that and let's say two weeks probably not in that case you need to break that down you keep breaking that down until what you have left each piece you feel you can do in a sprint so that's how you go from epics the stories to think of an epic as some really big one and a story as more think of a part of that one that you think you can get done so why stop there you can also have the concept of epics stories and tasks right so you start off with a big one like I want this and I want world peace that's about really large epic and then you have stories related to that and then as you start working on the individual stories you have these things called tasks which are very very practical do this do this do this do this write the tasks start getting into the how the story didn't the story talk about what I want but the tasks start getting into how do I achieve that want well here are the five things that will explain the how of that okay and you'll have multiples epics so here's an example let's say we wanted to create a mobile-friendly version of the oil femme agency website I'm not picking on them by any means but I just want to find an example that I hope you guys can relate to that took two stories that are possible actually there many stories that are possible but one says as a citizen what do I want and the other story says as an employee I want something completely different it as an employee I want to be able to access HR Docs on my phone oh as a citizen I have no interest in that but as a citizen I may want to look up salaries of certain officials okay I mean that last story which says as an employee I want to be able to access HR Docs you can think of one task which is okay the lot HR Docs one of them is the sick leave request form let's reform at that one thing because that one task will get us somewhere towards accomplishing the story so here that's your hierarchy epics stories and tasks we use something called story points what a story points 20 points are made of things some people think they're the same as hours and days they're not really their way of saying this is big and this is much bigger and this is really huge so the simplest thing you give a story point of one like this is the simplest thing I can imagine doing maybe takes five minutes maybe takes an hour that's the relative thing then you look at the other thing go this is twice as big as that thing now I still don't know what that first thing will take but this looks twice as big twice as complex that's two points this looks three times as big this looks five times as big this looks really big like eight you notice my would start getting a little bigger because as things get more and more complex you're really really guessing so what really helps is something that you may not remember from high school math called the Fibonacci series which is a way of take picking numbers that get progressively larger and the reason you need that is because I the way like to put it is that complexity is not linear which means something that is twice as difficult would probably take more than twice as long that's why story points are not ours you thought you can do this in one hour this is twice as complex you might need more than two hours and this is eight times as complex you're definitely gonna need more than they're right the story points in scrum we start to think in terms of same I really don't know what any of these things will take but I can tell you this is twice as big as this one and this is five times as big as the other one so in a sprint so we talked about planning the work we have stories in it before a sprint we do something called grooming the back of this is something the product manager does constantly the cut the product man owner is just waiting for the next sprint to start they can get more stuff done so the product owner makes sure the stories are good and they're in the right order there's something called sprint planning which is a formal meeting but the entire Sprint team sits down with a product owner and says how much of this backlog can we bite off okay let's say I have a one-month sprint which is kind of large by the way I talk about how big sprint should be I'm one month sprint I can do five things maybe three things I don't know it depends on how big the things are right and how much time I have but they try to pick a doable set of priorities prioritize items so you remember your backlog is this long list of stuff in priority he starts so I'll do the first one for sure can I also manage the second one can I also manage a third one and when you reach a point where you say I can't do any more in this two weeks you stop and what you've done is taken a chunk and said this is what we are committing to do in this sprint okay during the work you have daily stand-up meetings and these are designed to help people quickly understand where they are relative to everybody else it's like I haven't seen you for 24 hours because I mean lockdown in my office working on this thing what's been going on in your life and this is what I've been doing by the way I talked a little bit about burn down burn down as a way of trying to see if this print gonna make it like we said we're gonna do five stories and let's say they add up to 25 story points we're halfway through the sprint are we gonna make it well it would help if you knew that you had done half the points already but if you've done like two points you know you're not gonna get the remaining 23 points done in the last half of this sprint right that's probably not going to happen the bone down chart provides early warning during the sprint about the likelihood that the team will deliver what is promised so all it does is kind of prepare you for what might be a disappointment down the line you can also suggest that maybe the steam is boring to the worker like so and they can pick up more work that that would be nice doesn't happen troll how often to be honest at the end of sprint there is something called show-and-tell so the team presents their work formally to the product owner that you asked for this thing you said as a small business owner I want block here do you accept what we've done that's called done it done really mean something important here done means the product owner accepted it and hopefully you will never revisit it okay so there's something called a sprint show-and-tell at the very end and finally you have something called sprint retrospective this is something that's often overlooked because people say ah it's kind of like fluffy stuff you look back and you say how do we do the most important thing you can do in a sprint retrospective is say how good were these stories cuz you're actually judging the product owner as much as you are judging the team because did the product owner do a good enough job the stories were clearly defined they were small enough they were sized right that we could actually do them if he did if the stories are good how do we do as a team like you actually finish did we overcome it did we love all our commitments and you want to have this reflection that they end up every sprint so you can get a little better for the next one how long should a sprint be it really depends in my personal opinion in one week is pretty short I know some people out there who do one-day sprints I really don't know what they're doing one month is pretty long I've tried that and the problem with having a month-long Sprint is you forget you're doing scrum so I personally settled on two weeks I find that to be a really good number if you ask me I will say two weeks but what's important is in what about my size is printed I need to be able to finish at least one story right so I have to make my stories small enough I'm a big sprinter long enough to at least one thing and get done actually I need more than one thing done but if I don't get one thing done then something is just not working here whatever your Asian is try to be consistent try to follow a pattern it's two weeks this time it should really be two weeks next time unless you find that two weeks just isn't working for you in which case you can change it but don't make them like random numbers don't decide that you're gonna have a short sprint for some reason because it's like Thanksgiving week no it's not it just means you have the same duration sprint but you commit to less because people are gonna take off in Thanksgiving right you don't you try to keep that rhythm going rhythm is really important scrum so in an ideal world you'll have a product backlog on the back I hope you guys can see it in the back you do one sprint let's say you pick up three stories they can move out or done you do another sprint pick up three stories they get moved over to done and now you got just two stories left and the last one just cleans it all up that's how it works in theory in real life this is what happens you start off trying to do three stories and a third one doesn't make it in scrum it's kind of binary other story is dun dun dun it's not done is not 80% done it's either got accepted as a complete story it's not done so don't play percentage games I mean never play for snitch games anyway but don't do it in scrum because it really makes no sense here right so really what frequently will happen is that third story will be almost there but didn't quite make it and if you didn't quite make it it goes back in the backlog where it can be picked up for the following sprint so you might find that it doesn't take history specifics four or five sprints maybe that's a learning process you guys are going to go through okay but remember done has to be really done you cannot have it any percent done one sprint and 20% wind up in the next one because you know you know how that 20% goes right you'll never get done so imagine this is a time line you're doing all these stories and depending upon how you're doing them and epic might be delivered finally after one and a half Sprint's maybe another epic gets delivered towards the end of that sprint right because an epic is a collection of stories so that's gonna get done and this is the basic cycle so during the sprint the most important thing is to protect the team which means at the beginning of the Sprint the product owner has a lot of opportunity to voice preferences about what should get done what should not get that once the Sprint starts the product owner needs to shut up and remain shut and wait for that sprint to end because it's not like a six-month sprint right it's only two weeks and we have it through this week so it's like three days you know as Franco said was right you're not that far away from being able to voice opinions again until now and then you really need to keep sharp as a product owner because we are are trying to protect the team but they can get done what they committed to without you randomizing them okay I'll show you an example of a burn down chart only I'll talk about them in a second the Show and Tell I already emphasized the product owner must formally accept okay let's talk about the daily stand-ups in a daily startup normally you want to answer three questions what have you done since I last saw you at the yesterday stand up what are you going to do between now and tomorrow stand up and what's blocking you and this should take no more than two minutes that's why to stand up we don't encourage sitting down during stand ups because people get tired of standing and they leave faster that's why it's a stand up by the way idea a place to have a stand up isn't a hallway a busy hallway where people are getting annoyed by you that puts social pressure on you to finish and get back to work do not have a stand up sitting down in a conference room that is not a stand up anymore that is a meeting okay and I explain a little bit about the scrum master stuff a burn down chart is a simple chart that says how many story points are remaining that's the vertical axis and how much time you have left and in an ideal world you burn down chocolate go like that every day you're getting like some part of it done right that's the ideal theory of a burn down chart and reality your burn down will look like this nothing will get done for a long time and something get delivered then nothing gets delivered for a long time and it all starts panicking but actually when it finally gets done it's worth a lot of points and boom you get this big and you're like ahead all of a sudden and then you're behind and then you get slightly ahead and then you run out of time and now at something didn't quite make it that's what burndown charts to look like the point of a burndown chart is if that is really a wacky shape the product owner can manage his or her expectations of what they will get before the sprint is over the sprint is not like some black box that the product owner can't be into product order can see what's the likelihood of things getting done the team has a light sense for the likelihood that they're actually gonna make the commitment okay so that's concept of a burn down chart there's a concept for something called velocity velocity simply saying okay we did sprint how many points do we do 10 20 it doesn't matter okay so how many do we do the Sprint before 18 maybe a velocity is 19 the average it's a way to look back and say you know this team teams to do 19 20 points worth of work every two weeks that's really helpful for helping figure out what are you gonna do in the next two weeks because when you plan your next two sprints next sprint you can say okay we know we can do about 19 20 points um let's only commit to that what's important to understand about velocities because it's looking back in the beginning you have no idea what the velocity is you need to accept that your manager needs to accept that you cannot tell anyone what your velocity will be honest at least two or three Sprint's have gone and then you can look back and say you know I think I know the capacity of this team it runs at about 15 20 points that's now you can look at all the walk stuff in the backlog divide that by velocity and tell you how long it'll take so it's kind of problematic for a lot of managers because it's like until we start the work we can't really tell you really whether or the end it oh yeah I think that's really important this is one thing I want to emphasize velocity will flatline do not let your manager ask you for increasing velocity every print the only way to give increasing velocity every sprint is to game the system which is really easy because now because we're dealing with this funny-money called start story points you can start giving more story points to yourself to something that you were previously ever that was only two story pods now at three points I won't take credit for three and she one more story bigger velocity I'll give take much credit for four right so you're dealing with funny money here and you can very easily end up with inflation so story points increase a little bit as the team gels your velocity should flatline and no manager should boast to another manager my team does 20 points your team only does 15 because you're both using funny money from different countries right so it's totally meaningless way to boast to your peers getting scrum right this is where theory really department really first of all scrum does not believe the team can be distributed I have never worked with with a team that was not distributed so we need to figure out how to make scrum work when your team is not in the same place I assure you not one single person's room it's truly co-located with their team all the time unless you're living with each other you're here in a conference room your team is not you just got became part of a distributed team right now you're distributed if you go out for lunch he became distributed for one hour right so every team is distributed our own character team is distributed in a kind of extreme way with spread out over 10,000 miles which turns out to be as far as you can go before you start coming back again the other problem with scrum theory is that assumes anybody can do anything I don't know why it seems that because I find that first of all that's not true and secondly I can do scrum with other assumptions so in my opinion that's a helpful misleading assumption that you might find somewhere it says oh it's just this beautiful pure team that can just like anybody can pick up any work and do anything yeah I don't know what that's about the other problem with scrum theory is it says the story point should only be given to things that add new business value but this other stuff you need to do as a team the things we call chores maybe just going to training is like a chore I mean you have to do it right all the defects in the work that you did that need to be repaired top Tom thumb's campaign trainers like to say from a theory point of view if you're just repairing something that was previously accepted as dogs you don't get to call that any story points I find that really not helpful in planning because I might have a whole sprint where my velocity is suddenly zero because all I'm doing is like fixing bugs which are really really important to fix but now my velocity just kind of goes like this and now I don't even have a lot useful velocity numbers like I don't know how that helps anybody but that's where I totally disagree with the theoretical thing it says only count things that add new value and if that's not my life what I find very helpful is have a sprint dream you got a lot of stories to do try to find a theme it works much better when everyone thinks ok I'm all we're all working together and this is a little team you know this is bit of goal we can achieve I suppose we all working together and it's totally random we just pick stories around them that stop that's that's hard you know for a team so try to take us Sprint's team that that unites the team you know okay finally we have what I call the nuclear option a nuclear option is really really important once the Sprint starts it cannot be changed in the middle if I was a scrum master I'm a product owner says oops I sorry I forgot to bring this in two days ago during the Sprint planning what's really important can you add it is I would always present a nuclear option and say listen I cannot change the Sprint if you like I can blow it up we will stop the Sprint it start a whole new sprint this print is a washout it really works well because it makes a product owner think how important is this thing that I've suddenly thought of doing do I really want to exercise a nuclear option here does that see only you know parents don't really like that kind of option but you have to present it in that way think it's all or nothing we're gonna blow this printer let's stop right now fine because you know we're probably responds to people we do whatever you want but this is what you're asking for you're asking to blow up the whole sprint okay where does crumb work best not everywhere by the way it's not like everybody needs to start scrumming right away it works best where the work is new that means your strategy and your tactics are not completely known sometimes you have to do stuff but your agency has never done before right recognize that uncertainty in there and try to organize the projects to deal with that uncertainty sometimes you do stuff that is very well understood and you don't need to come to be honest okay work use common situation where things are fluid maybe the policy is fluid maybe you're working with technology that is that is kind of fluid all the requirements everywhere what is uncertainty to come help where there's certainty come is kind of overkill my opinion and work you scrum where you can establish a rhythm like saying hey we have a two-week rhythm we're trying to do that you know there should be some some natural rhythm if you're trying to create rhythm we're actually it's a there's no rhythm to be had or no rhythm that emerges it's probably a bad fit if you're trying to make a team adopt the two weeks print or a three week sprint or whatever it is and actually everybody has some different thing going on you know and but that's not a scrum team in my opinion government makes it really hard to describe my opinion because you need regulatory flexibility which you probably don't have in terms of purchasing services you cannot hire a bunch of consultants or developers for example and say we have this scrum project it's not about fuzzy edges you can't actually put on our pillow the drama it's hard because you need budget flexibility which you may not get it's like we are going into a project with a lot uncertainty so we'd like a little bit of fuzziness on the edge of our budget that's kind of tough it's tough at a very large level it's actually start doable I have seen agencies do it at a small level and start to establish a track record that they can use to advocate for more and more of it we won't start small but you need some flexibility around that we also need organizational flexibility and this is often misunderstood here or overlooked I would say you know a scrum master is not an elevated position almost an administrative position the project manager disappeared that messes with people's ideas of how the career should develop it also messes people's ideas a little bit about the idea that everyone on the team is kind of empowered even though this person just joined and I've been around forever like that's really my equal you know it also is hard for the junior person to say I should really speak up I should pull work but there's a lot of organizational issues around this and I'll be frank scrum is hard to do in government because government is not set up for flexibility around people money or purchasing but pretty much anything actually you know but it is being done and what people are doing is doing it on a small scale showing their management throwing the the funders you and look this is this leads to better outcomes it's a fuzzy process on leads to better outcomes because you know the other stuff where you pretended you knew exactly what you're gonna do how much you gonna spend when it's gonna be done you know that was just a joke right I mean it never happened that way right where does Kanban work this Kanban works best in a lot of places by the way probably more than scrum in your particular environment I think Kanban works well when what this comes in continuously and it's roughly of the same size and shape perfect example I would take is an IT Help Desk all day long to get call back people say Turner doesn't work I forgot my password when it doesn't work brought my password right all day long that goes on right and every instance is about the same size you forgot a pass over I have to help you reset it doesn't matter if it's a the director of the agency or an intern about the same amount of work to reset password right and it keep me down by anybody to anyone who picks up the phone or picks up your ticket in the help desk and work on it doesn't really matter and to reprioritize continuously because it's just like a you know continuously changing pile of stuff the work is really well understood no one has to reinvent multiple times how to reset a pass or to fix a burner and so anything where you're doing case management where the work is very well understood and can very easily be categorized there's no discovery involved I would say karma works really well scrum is probably overkill comm is really great when there's uncertainty but there's a lot of things that you guys do for which there is no uncertainty right thoughts e-liquid karma also recognize that you are never flying solo you are part of many different collaboration networks right now there's something that you do by yourself for yourself there's some things you work with this person some things you work with these two people tell me where some of these people come together almost every sort of white or pink color shirt person like me is working on multiple things at the same time but they're actually part of multiple collaboration networks we don't recognize that we think we'd only do one thing with one set of people I would say just reflect on that sometimes not right now and think about it how many different people do you actually support how many initiatives do you have a finger and then how many committees or all things that are going on things are you expected review you're not really part of the team but someone wants you to review it you're part of that collaboration Network in this kind of a situation oh okay you're here this stops working really fast this is how a lot of people approach karma sticky notes the problem with that you know apart from the fact that I need like a fisheye view to even capture this board that is this is fine if I'm standing in front of it but if you accept my premise that I'm not standing in front of it all the time that's a problem if I'm working out of Spokane or Yakima I may never visit Olympia so the fact that all your Olympia folks are having great time hanging around the stickies actually it's pisses me off you know right it's really exclusionary because because I'm trying to figure out what's going on and you guys take it for are nice and distinct no a bunch of stickies the other thing is well zoom in on a sticky it has three words on it and I can't tell what it's it's a compliment a problem or just some random thought but it's so compressed and I just have to wait for that sticky to dry up and fall off right and then you think then we all kind of equal so I really believe what we need a software tools this is an example of a somebody in orphan booth let me share this thing he's been using actually the product that I've been developing which this is a personal task board he lets a lot of people see at any time what she's working on the beauty of that is self a lady named Melissa I never have to wonder what is Melissa working on or why isn't Melissa gone to my thing yet well I can kind of see why she hasn't she shares all the stuff going on here but this is personal Kanban that she's doing here you can also have more complex example I know this is gonna be really fuzzy in the back there but Timmy afterwards I'll show you the stuff in more detail you can have teams of people working together this is an example actually from department agriculture that I took this is a board that are using for grain safety I'm trying to relate to you folks out in government so you know you have to give you points for effort at least okay this is an example of a marketing team not in government who uses it for scrum so you can't really tell other points are there two boards here you notice that they have the same backlog that's because one is sprint 94 and now they're doing 95 which tells you how long they've been doing this after 95 Sprint's already okay so these kinds of tools are possible where now your stickies you can capture a story as a virtual sticky and you can actually write some detail around that you can create tasks around that you can attach content to that the files for example you can chat and so forth so once you start doing this in certain software right get sticky gets infused with magic that only software can bring I've obviously in the software business I believe it has magic you can have open one of these sticky notes and have a lot of rich containers a rich information about it you can find out about the work some details around it you can find the files that were attached to it you can find out what people talked about right please my shill in the audience says is there some software I would like to recommend I happen to be in the business of producing such software oh let me think that would be my product characters character is upstairs where spawn service of this thing by the way I don't want to push my product here just I really won't run it do like to make a class out of this it just so happens with every problem that I said your face we have to have already solved it just correct happy coincidence that all the things can be done if you come upstairs and who visit me okay the main points out summarizes you do need technology to scale whether it's Kanban or scrum you need to be able to scale kale within the project and across products as a department you need to be able to see what's going on on many things at the same time you should be pragmatic not dogmatic I am NOT a consultant so I don't try to sell the theoretical version of scrum do that I don't get paid for that though I have no interest in trying to tell you that this is the button this is the theoretical model you have this perfect team very sociable well-organized never leaves any website and it's never disturbed you know nothing ever happens to that team that's not actually how it goes in my opinion do you need pragmatic that's last point I want to make on this slide I'm gonna come back does which is think of scrum you know in in software which is where it came from every way of doing work eventually gets the status of religion right and you get religious wars around it that's fine if you're gonna take that metaphor and say if this is a religion try to understand the philosophy of it instead of just following the rituals so instead of just saying we have a daily stand-up because we heard that's a good thing don't understand what is focus to the standard for the book so the stand-up is they where am i where you what do you blocked on that's what I really want to know what's stopping this scrum team from achieving its goal so that the scrum master can run off and start knocking down those impediments how many of you folks knew that was what a stand-up is meant for okay couple of folks but how many a few folks have been doing stand-ups without knowing this no one wants to put the hammer I don't believe you guys the point of scrum like Kanban is that it should be a reflective or no that's right it should be a process that involves reflection at the end of every sprint have a Sprint retrospective don't skip that because you're tired or you don't want to do you don't have time a sprint retrospective answers the following questions how good were the stories or they clear enough that we knew exactly what needed to get done over time the stories will get clear enough in the beginning it's highly unlikely that stories you got from the product owner but good enough they probably involve going back and forth a lot so you want to track I'll be doing better with the stories that we did like the last couple of Sprint's if you're not we need to work with the product owner and say why presenting stories in this way when obviously we don't understand looking from this direction we in John stands a team how the velocity is stabilizing or we just like going all over the place why is that velocity changes most often because of one simple thing that game changes you cannot swap one person out with another without the velocity changing okay so people say I have five people before I fight people now why is my velocity changing because one of those five people is different the scrum is actually very human centered it says understand that this team of five people who come together and have interactions that can't be captured in a measurement software but you can observe the result of that by saying they do 20 points now if you change one of those people you either get 15 or 25 but you probably won't get 20 if you don't get 20 you need instead that change you made is probably the reason very rarely it's because you change the duration obviously then you can normalize the numbers already twenty two weeks or three weeks prints you can't compare the two outputs anymore that's not usually the case the biggest problem I find it people swap people out and think that nothing happened karma expects to the team dynamics change when the team changes so velocity doesn't really stabilized until the steam has been in place for a fuse for a few Sprint's right so really try it out and make sure everybody understands that you obviously need to get by right so this is a different way of working I don't know how feasible it is for everyone in this room I I'm glad you all came and listened to the stuff now you might be going over thinking this is not for me but I believe it can be done in government but in a small scale initially to start creating some proof boards no one's gonna believe that scrum is right for agency simply because you came to this conference and you met this incredibly persuasive guy here right you like to go back and do a little bit of scrum a few sprints and start seeing you know can we do we have better transparency do we actually a better idea what predictable in terms the world actually get done I suppose you know as opposed to what we should get done what does it mean to start working in a full model when people don't get pushed work on right oh I forgot to mention one of these also doing a retrospective is very important nearly always overlooked check the health of the team the health of the team is the team still relatively happy very often this gets overlooked because the team has been under pressure print after sprint and is actually people are starting to get really burnt out and no one is asking them how are you feeling as a team the everyone is just looking at the numbers but looking at the health of the team is a critical part of the retrospective right so there's a lot of stuff stuff nothing is really important that's why I said I'm saying the philosophy of scrum it deals with uncertainty it deals with people right just don't say what's my burndown Chardon let me points to her and blah yeah that's all those are all artifacts the ritual right they're not the key thing here in my experience and I've worked really long time turns up 35 years something like that as a manager a team that's burning out is always a serious factor in other words never be tempted by the idea thing I know this guy's just about ready to break down but we only have one more sprint left too much Sprint's laughs right because that person could be whose burnt out ultimately gonna have a toxic effect on everybody around them because everybody else knows they're burnt out if you no one's talking about it right I've often been tempted to say you know I never liked this person anyway you know let them burn out just two more weeks and then like I get my bonus or something no don't don't don't I'm not saying you bid you don't think of doing that I started doing that didn't work for me don't I'm just telling you that you know won't work for you so the question is in software you know our units of measure like lines of code applicable but this doesn't say you can't measure that right but frankly it's kind of irrelevant in this thing because from the beauty of scrum is you say you recognize that all you can tell is that something is twice as big as the other thing without necessarily knowing what this other thing is right I love the idea of story points and also I love the idea of this increasing range Fibonacci because when you get to 5 8 13 21 you're just getting your ass off at that point right and so you can't go from 8 to 10 you go from 8 to 13 you don't go from 13 to 50 13 to 21 and 21 basically means I have no clue what this piece of workers so how do you go about doing individual performance metrics come by stuff doesn't really actually pay much attention to the individual it does emphasize the team and the idea that how good is a team doing I think you can still measure individual performance and I think scrum would encourage you to measure that individuals performance and how they raise the team's productivity right the most valuable people in a scrum team blow away everybody else's impediments and that is maybe all the scrum master does is just make sure nobody is blowdown or block but just think about how nice start is right knowing that you can work the moment you hit an impediment you can just raise this red flag and somebody solves that for you somebody chases that manager and the other department who won't return your phone calls that's it that's actually amazingly good feeling you know right and that posed to can do it I would say that's the most valuable person on our team does that one person makes everybody else get that job done so maybe I'm a different kind of approach of performance but I think the most valuable person on a team who gets the team to do the most work ideally ask a scrum team should self-regulate right in practice once the team is mature and in some industries like in software but some teams get mature enough that they will expel the foreign body that they can't absorb right but that's only possible in an environment where the management also has to trust the team that is not some something petty going on if you ever experience people are scrum they can recognize on their own what their problems are and fix them in my teams we always have some performer who disappoints and I use the word disappoint because you know maybe the problem was my expectations the way I've dealt with it is the team has readjusted to saying okay it turns out this person is only capable of this much we thought it was this much but it is not it's this much so in future sprints we plan accordingly so I guess our team my teams have always been more evolutionary you know just say okay we'll try to figure out how to live with this thing and they're just expectations you'd only want to expel somebody if they are for the same reason you actually have a real problem with them in there like seriously antisocial or something you know they're actually harming people you know but somebody is simply not performing at the level you wanted to I think the team should just adjust its future commitments because you now know what your true commitments are what your ability is that's a reality right you know you don't have a team of superstar yeah a mixed team you know that'd be some spread there'll be some people put in you or week or whatever first days as long as that person is not a bad employee I don't think the Trump team needs to expel them question that so the point of the nuclear option is to make an option so frightening the normal exercises hopefully we will find that out what I like what the nuclear option is that see whenever I've gone in to introduce scrum and I've had to go in and introduce come into organizations first one was Microsoft in 2006 one part of Microsoft and we had a problem with the product owner who sat down the hall from the team and just kept walking down the hall with new new ideas I got an office that was in the middle of the hall and I kept my door open I just waited for the product owner to go but I jump out and stop the person at first it was diversionary tactics I try to talk about something else Oh coming I wants do you see something profitable I realized I wasn't working so I sat down and I said I'll give you the nuclear option if you believe this print is badly constituted you can blow it up anytime you want ego here's the nuclear football right go ahead but consider that everyone will know you blew this print up and somebody will probably ask why did he blow this print up and you have to have some non petty reason for having done that right and in all the years I don't know if anyone that's ever exercised the nuclear option means it works really well as a nuclear option there's actually a very interesting technique used in scrum which I didn't get into it's kind of a detail it's called planning poker if you guys heard of planning poker one person asked okay what you try to do is you give everybody a set of cards which contain these numbers like 1 2 3 4 5 then you discuss a story and you ask each person to think how big is the story and then you say okay and everyone puts up a card at the same time which is their best guess then you see how widely spread their numbers are if something to put someone and some guy puts up 21 then clearly you do not have shared understanding of a story so you go back and rediscover story why do you think it's one why do you think it's 21 and you do that repeatedly playing more and more rounds of the spanning poker till you get like everyone says it's actually a 5 right so that's something you can do in sprint planning to get convergence around like are we all talking about the same story in the same way I find that really helpful because you know when you see somebody bidding really high somebody bidding really no yeah that's like why do you think this is like a no piece of work why do you think this is gonna take forever and often you you learn a lot about the story in the process any other questions I'm upstairs and here today and tomorrow frequently lonely so come and visit I have our very best chocolate you may have heard of my chocolate it's quite well known among people Oh No thank you all for coming [Applause]

Channel: Kerika

Views: 19,609

Keywords: project management, task management, team collaboration, collaboration, task board, taskboard, agile, kanban, content management, scrum, lean, google docs, google drive, saas, productivity, distributed teams, leangov, lean government, tutorial, talk, presentation, best practices, scrumban, kerika, burndown chart, daily standup, epic, story, planning poker, work estimation, sprint, work management, arun kumar

Id: 7P6mR8McW_c

Length: 57min 40sec (3460 seconds)

Published: Wed Nov 15 2017