Introduction to Scrum

okay so a good day or good evening to everyone wherever you might may be joining us today welcome to the intro to scrum webinar brought to you by AK so soft and scrum org I have a few housekeeping items to to go over before we jump into today's presentation the first one is that this webinar is scheduled to go for one hour with the first 45 minutes reserved for the main presentation and the last 15 minutes reserved for general Q&A as some of you have already noticed you do have access to the GoToWebinar control panel there is a section where you can post your questions we will be reviewing questions as the webinar goes on you're welcome to post your questions as we go over certain key concepts as towards the end we'll be reviewing those questions and trying to see if we can answer those towards the end this webinar will be recorded and the recording will be made available in a few places it will be made available on the axis oft YouTube channel on the scrum org YouTube channel and also it will be sent via email too so if you register for this webinar you will get an email 24 hours later with that recording let me go ahead and introduce myself so my name is Jonathan Silva I'm the director of customer success here at AXA soft for those of you for joining us from the axis top side if you're an Amazon customer welcome back it's great to have you a few notes about access oft we make the agile project management tool and we also make another product call it get crackin if you have development teams who use gift has the version control of choice then get crackin is a graphical user interface that helps you visualize what's going on in the in you know in your repository who made what merging branch software in my opinion that helps reduce the barrier to entry for any team who is looking to implement gifts in their organization but today we'll be focusing on later in the presentation I'll go through some examples of how you can implement some of the scrum framework key concepts that we'll discuss in the main presentation today and so that gets to next right here which is the main presenter I'm happy to introduce Eric Naver Eric hey how you doing all right Thank You Jonathan and Jonathan say good morning good afternoon good evening depending on where you might be in the world thanks for joining us today a little bit about myself I run marketing we're scrum dot org and have a fairly long history in software development and delivery I started my career back in the early 1990s building a data modeling tool as first product manager for a product many of you may have used or know called Arwen which has been bought several times and so on spent many years at IBM and rational software and in other places always focused on helping developers deliver software more efficiently with greater value scrum org is the home of scrum we're run by Ken Schreiber one of the creators of scrum and what we do is training and certification around scrum as well as helping individuals and organizations improve how they deliver software by taking scrum evolving scrum adding capabilities like how scaling scrum through the nexus framework and so on but enough about me and enough about us let's let's get started a little fast there so our agenda today we'll talk about what is scrum the scrum values we'll go through the framework and Jonathan will take you through how do you implement scrum using AK so soft so a little brief history scrum started because people were having difficulty delivering software with predictability on budget the right values and certainly delivering the right thing many of us are familiar with waterfall processes and when in a waterfall process you often start with a whole bunch of requirements upfront and 18 to 24 months later you deliver something that may or may not be what you expect it generally doesn't hit budget doesn't hit on time and often doesn't meet the requirements that are in the market at that point in time they may meet the requirements from 18 to 24 months ago but that's too late and what Canon Jeff the founders of scrum ken schrader and Jeff Sutherland recognized along with many others as they were looking at the need to be more agile is that we need to be able to start delivering value in smaller increments we need to not gather everything upfront but gather enough to get started and deliver a little bit and then gather a little bit more and deliver a little bit and so on it doesn't mean we don't have a vision upfront for what we're going to deliver but it means we need to be able to deliver some things validate those with the market with our stakeholders and keep going on so they created this framework it's not prescriptive and that's part of the goal it's it's really the idea is it's a framework to help me deliver more efficiently um it's all built here in the scrum guide which is the not a body of knowledge of scrum written again by Ken and Jeff and that scrum guide is short it's only 14 pages because it's not meant to be prescriptive what it's meant to do is help you deliver more value more quickly now what is scrum as I've said it's a framework not a methodology methodology had lots of prescription you did it then you do this and then you do this and you must follow all of these things and oh you better not change that unless everybody in the organization agrees and so on that's not the idea of scrum scrum is empirical it's empirical meaning that we learn and we adapt and we organize as a team and we do the right things based on what's going to make the team successful my team is very different in makeup from your team and from somebody else's team and if we all try to follow exactly the same process generally we won't be successful it's lightweight in its iterative as I talked about it's about delivering in small increments generally one two three one two four weeks and delivering that you may deliver multiple times over that period of time but certainly within that's that that small period in string factors that are really really critical in my opinion to scrum are these circles you see here on the right transparency adaption and inspection what we're doing must be transparent to the team into our stakeholders because if we don't get that feedback if we don't do what we think we're supposed to be doing how do we make sure that we're doing the right things if we're not constantly inspecting and adapting looking at how we work and what we're doing in making changes to improve how would we get any better so we'll talk about all of this and how the framework really helps you do that so the scrum values this was actually added about a year ago as last July to the scrum guide and we released the kind of Jeff released a new version of the scrum guide and the scrum values were a key component and it's not work on different scrum teams in delivering products to market I really find these super important really key how the team works together now you may look at this and say oh this is common sense well yeah in many ways it is um you may look at it and say oh well of course we do this well if one if it's not written down often we forget it too we need to really enforce and live by these values within the team because if the team doesn't feel like they're protected by these values they're going to act very differently they're going to start worrying about perceptions and worrying about what's around them and so on versus feeling that ability to really be open transparent as a team so the scrum team must have courage courage to speak up courage to do the right things courage to talk open and honestly within the team and without outside of the team but certainly within the team as well they must have focus on the things that they are going to work on most focus on their individual work as well as the work of the team a big part of scrum is this is all about the team it's not about the individual we together as a scrum team are delivering it's not individual work now I'm working on my pieces you may be working on your pieces but still about the team we must have commitment to the team into the work that we're doing we must show respect for one another but open and be open to each other as well and really be willing to say the hard thing to have those conversations we'll talk a little bit about retrospective and how all these things fit into there but they fit into everything we do on a daily basis so this is the scrum framework and I'm not going to walk through it now because I'm going to touch on each piece but when you look at this framework think of this as one sprint and a sprint is the duration of work so this is all encompassed in a sprint one of the things you'll see kind of over on the right the increment that thing that's delivered you must deliver at least once per sprint now deliver doesn't necessarily mean product to production but it should must be production ready so it might be in to another environment maybe you're in an industry and attire but highly regulated you can't just deliver at any point in time but you can also deliver many times within a sprint that make that increment that gets that gets delivered as well so it's not just one increment per sprint that's a scrum miss I often hear I've been in presentations where people say oh we can use scrum because we want to deliver daily and scrum says you only deliver once per sprint well no scrum does not say that scrum says you must deliver at least one or sprint purse print you can deliver multiple times per sprint as well you'll hear me throughout this presentation talk about Mis because there's a lot of them out there and I like to try to address those as they come up so scrum is made up of a set of roles and there are three roles within scrum we've got the scrum master and the scrum masters job is to support and help the team to teach the team scrum and make sure that the team is abiding by the five by the rules of scrum it's to help coach the scrum team it helps facilitate the work within the team as well making sure that the team is working together working well together helping them overcome the pendency issues and impediments and so on the scrum master part of their job is also put up a shield around the team to help the team remain focused so if people from outside the team are coming to an individual asking them to do something that's not part of what's planned in that sprint the scrum masters role is to shield them off and to handle that maybe through them or this product owner that we'll talk about in a moment but it's to really make sure that that we're focused and to help them do that a good scrum master over time might have multiple scrum teams that they're supporting that they're a part of because as they teach as they facilitate as they coach you're getting those teams more and more up to speed they're making those teams more and more self-reliant and independent and they're able to kind of scale out the product owner at the end of the day is maniacally focused on delivering value to stakeholders now stakeholders may be customers they may be their senior management of the organization they might be other folks within the organization internally or externally they're the stakeholders their job is to bring that feedback bring those requirements in and build out a backlog of those requirements that drive value they want to do so just in time and make sure that we're developed providing our ally certainly to those stakeholders but also removing non valuable things one of the things can show ever talks a lot about is technical debt and one can we avoid technical debt but if we can often we can't is removing that over time because that just gets in the way it makes it very difficult for us to continue to evolve our systems and to manipulate those systems as we get more and more technical debt right so we want to keep that lien architecture in place and we want to remove that over time so part of the product owners role is not just a look at what do we want to add but also what we potentially want to remove now the product owner is ultimately accountable for the product and they must be empowered to do that they must be the person that is empowered to make those decisions now do they do these things alone absolutely not most product owners are going to rely on others like business analysts the developers the there there may be product managers and so on to get feedback in but they are ultimately accountable to make sure that we're building the right thing and they must be enabled to do that their job is to prioritize the work and their job is to make sure we're doing the right things the last role is the development team the development team is self-organizing they work together to figure out how they're going to deliver the work is defined by that product net product owner they're going to do forecast they're not committing so when we pull work into a sprint I'll talk about the Sprint backlog in a few moments they don't commit to who this is all of the work we're going to do but they forecast that this is what we are going to be able to do because we're timebox within that sprint or you get the work done we believe we can get done in within that sprint they transform backlog items product backlog items into those increments that we talked about and they're constantly learning and collaborating they're working together as a team and that development teams ultimately responsible for delivering the value the product owner defines the value the development team delivers that value and in the products that they're delivering so next are the scrum artifacts so the first artifact we'll talk about is the product backlog the product backlog is and as the title states it is the backlog of items to be worked on that product backlog consists of all of the open work that needs to be done now over time that backlog gets longer and longer and then hopefully maybe even shorter as we're checking things off but it's not fully defined at the beginning we probably have some big items and some smaller items and some things that need to be refined over time we certainly have at the top of the backlog those things items are pretty well defined and refined down so that we're able to start pulling those in and working on them but as we're going through we're constantly inspecting and adapting that backlog we're constantly looking at that product backlog to add more capabilities and so on based on the vision of what we're looking to deliver the product owner is ultimately responsible for that product backlog defining the items within it and prioritizing those and as I said they're not necessarily the only one doing that they may work with product managers and business analysts and others to help create that but they're the ones ultimately responsible for it and they're the ones that are prioritizing that work because the product backlog is going to define the value that we're delivering burnt backlog is the work that we're going to do or that we plan to do remember not a commitment the work that we plan to do within a sprint so and maybe I should have even reordered this and had some of the events first but I'll talk about sprint planning and how the product back the Sprint backlog fits into that in a few moments but the Sprint backlog are the product Baraka items that are selected for a particular sprint that the development teams planning to deliver within that sprint and I'm pulling those items in and those items are owned by the development team and they may be refined further and they're going to be selected by a member of that team once in the sprint backlog is as the work that they're going to do I'm only going to have one sprint backlog and that sprint backlog so Vaman sprint in this example on the slide on Sprint three to sprint one is complete sprint two is complete on now on sprint number three I'm not putting a sprint for backlog on until I've completed sprint three not necessarily all the work in splinted three but the time box off sprint three and we'll talk a little bit more about that but we're working through that we're pulling items in and Jonathan will actually show you a little bit about how that works as well the increment is that ship ready product it's what we've now developed during the sprint and are ready ready to deliver like I said earlier I can have multiple releases within a sprint that make up that increment but I must must of at least one increment I worked on a project or a product rather recently where we were able to every sprint release a little bit more capability what was important to that it was amazing we're rebuilding a website and at the end of our first sprint we had a working homepage so because we had a working homepage not some document you know some JPEGs or something that we could review and say all day that looks nice that's pretty I think we all show this to some user they can use it well that JPEG isn't reality you're not really touching it you're not really using dropdowns you're not clicking on links so it always looks good in in picture but then when you actually create it in code you get a very different opinion and very different set of feedback so what were you able to do within the first sprint is design develop and deliver a working homepage what this allowed me to do is now share that with some of my stakeholders and get feedback we were able to touch it we're able to click on it we were able to say well you know what and picture that looks great because the text is set the way it is and and when I scroll it's still on one page but then when rendered in HTML on a real website in a real browser oh geez now we're scrolling forever the text is overlapping each other did this piece doesn't work right oh this part looks really great we're able to get that real feedback and we're able to adjust that in the next four and adding new backlog items and so on so it's really important to do that Kent aux tells a lot of stories and there's some videos on our website that that tells some of the stories that he's that he's seen over the last 22 plus years of implementing scrum in organization but I know one story he talks about how they were able because of this because of their ability to deliver working software within 30 days they were able to get feedback and he's working at a company called fidelity and they were able to start building their web-based interface and getting feedback immediately and delivering it much more quickly and delivering functionality that was needed over time rather than waiting till the end in being late to market maybe delivering the wrong thing so the last part I wanted to talk about and really kind of hit on are the scrum events the first event talk about a sprint planning I've kind of touched on hold these a little bit as I talked about the other pieces but sprint planning is an event that takes place at the beginning of every sprint now what's really important here if you remember back to the beginning I talked about the fact that you're old this entire picture is a sprint you're only sprinting so the minute I stopped for the minute I stopped the last sprint I start the next sprint so sprint planning is that I'll call it kickoff in quotes to the current sprint and we are now sprinting once for in sprint planning sprint planning is a meeting where we get together with the scrum team to look at what's in the backlog the product owner creates their goal for the Sprint and as a sprint as a scrum team and development team we pull items in to that sprint backlog that we plan to work on during the sprint will often do sizing and there's lots of different ways to do sizing to start to estimate what that work might look like it also by doing sizing helps me see do I really need to refine this item down into multiple items because it's really really big and it's probably not defined well enough it helps me to look at those items and make sure they're well understood between the product owner and in the development team it helps me build out what we're going to do now one thing I actually was just reading an article that I was quoted in and there's some misnomers here as well as the myth you do not need to build out a full sprint backlog to start the sprint you need just enough work in there to get started so the article I was reading said you did that this prime backlog is built to define all of the work to be done in the Sprint over time yes but beginning now we don't know that in what we're going to have maybe we can define it all but we don't have to we can keep pulling work in and that's why if we're working together as a team and because of the transparency in the product backlog we can keep pulling items in as tied to the Sprint goal and prioritized by the product owner one of the myths on what I want to hit on here is the fact that the comments that I often hear about velocity I've heard people talk about hyper velocity it's all about delivering faster that's not necessarily the case it's not about speed now speed is important don't get me wrong but it's really about delivering value all right that's why we talked about that that increment that's why we talked about the Sprint and in the time box of the Sprint we want to deliver value and if I deliver the right things we're going to make our stakeholders or our teams more successful I can deliver a whole lot of garbage fast and I'm just delivering more garbage if I'm delivering a lot of value that's what's really important and that is really at the heart of scrum it's about delivering value so the next event is the daily scrum the daily scrum is a 15-minute pine box and the goal here is to inspect and adapt Galli the members of the scrum team or of the development team attend the product owner cannon should but doesn't have to the scrum master can and should that doesn't have to the scrum masters job here a role is to make sure the development team knows how to run their daily scrum in that it happened the goal is to have it always happen at the same time same place every day because if you start moving it around what's the next thing that happens it just gets in the way it gets inconsistent you want it to become a habit so the goal is to have it always at the same time same place same day and it's 15-minute time box can always be shorter but we want to cap it there it's not a status meeting there's a great video that one of our professional scrum trainer Stephanie Ackerman just videotaped it's on our home page of our website about how it's not a status meeting the goal here is the goal of scrum constantly inspecting and constantly adapting now we're going to look at what kind of work has been happening are there impediments and Jonathan will give you some demo of how a daily scrum takes place we're going to look at those things in are the things getting in the way is something being blocked now and at the end of the day we shouldn't be waiting for the daily scrum if I've got an issue and we can resolve it outside of the daily scrum we should do that and we shouldn't wait oh well you know I've got a problem now and it's nine o'clock and my daily scrum is until six o'clock we should just sit around on our hands no let's resolve that but this is the opportunity for us to talk about the work that's going on expect what's happening and make changes if we need to this is about inspection and adaption and we often hear people talk about the three questions what did you do today what are you doing or what did you do yesterday what are you doing today and what's in the way well those are good things to kind of think about as we're having a scrum but that sounds very much like a status meeting so make sure and it's clearly defined in the scrum guide is that those are optional questions to help you get started if you don't know where to go and what to do let's make this about a conversation let's make the daily scrum about those sorts of things and so on sprint review and honestly and I think I talked about this in the beginning I would actually bring the increment inside the sprint review and have this front review on the outside not kind of the way this is drawn here there's actually some work we're doing it potentially change that because the sprint review is not a phase gate for the increment the increment happens the sprint review is our opportunity to review the work that we've done to create that increment and to review that increment or set of increments that make up that that whole increment this word review it allows all stakeholders those who are available to come and review that it's not a demo it's a conversation which will include seeing the delivery the product so you can see how the word demo sometimes fit in there but it's an opportunity to inspect that increment make sure we're delivering what we thought we were going to deliver make sure our stakeholders see what we're delivering and carotids feedback and this happens before planning so that we can now plan our next sprint based on that feedback as well we may change some of our priorities based on that well it's an opportunity for everybody to get together scrum scrum master the product owner the development team as well as stakeholders to review that increment and keep that increment in and inspect and adapt based on that increment understand what we've delivered understand things that may have gotten in the way and so on that's sprint planning the last part of our sprint is our sprint retrospective at this point we asked our stakeholders to leave at this point if theirs energies in the room who are stakeholders but are not a part of the development team or part of the scrum team we ask them to leave this is just for the scrum team because we really want to ensure that we have the opportunity to be open and honest with everybody in the team this is where we walk through the last sprint and look at what happened not from my what did we deliver standpoint but how did we work together how might we want to change things were the things that were a problem was Joe just sitting around the whole time and maybe we've got to be honest with them about it right do we need to look at how we adapt how we change our process of working the retrospective is an opportunity for us to do that it's an opportunity for us to look at how we're working again if you think about all this and you go back to what I started with of why did scrum star why scrum become so popular some people estimate that over 11 million people take part in a daily scrum every day well why is that because if I wait 18 months to start really inspecting and adapting it's way too late we've lost it I can do this every two weeks or every four weeks now I can really start to learn I can learn about my team members my co-workers I can learn about how we're doing things and I can continually improve on what we're doing it this is really really critical if we're going to deliver value backer stakeholders and back to our business so this is a really brief overview of scrum hopefully this provides you kind of that insight and so on as you can see so I'm going to hand it back over to Jonathan is going to take you through some examples of how this can be now automated Thompson Thank You Erik all right so as I mentioned earlier in the introduction I wanted to bring some of the concepts that Eric touched on during his presentation and how can you bring some of these key concepts to life in your organization and what I'll be doing is I'll be using access off as a quick example and so for those of you who are access off customers hopefully this view is pretty familiar and the first key concept that was covered in but I want to go over or highlight that was covered in the presentation is the idea of a product backlog one of the key concepts with a product backlog is it it will be a list of you know product backlog items and these are things that just have to get done in order to you know push product out the door you know if you're building a new product you know what has to do you have to you know set up the infrastructure do you have to you know decide on okay we need to database here we need a sequel server database they're like be the nitty-gritty of things that need to get done but then they're also the feature request that you want to build out so these are all ideas that the product owner is debating things off of business value that they he or she feels needs to be communicated to the team and then the other major component of the product backlog is that it should be something that's public and easily accessible by your team so how can you how can someone who is a product owner build out the backlog how can they make it accessible to the rest of their team members and there's a way to do that and I'll just show you real quick how you could do that here and racks those up so for those of you who are seeing this for the first time this access off there's just a I'm going to keep it brief I have the organized panel here on the Left which filters all the product backlog items that I see here right now it's a nice short list and I also took inspiration from one of my favorite films just to build out some of these test items so if I am someone who is a product owner I built out a project folder just to help me stay organized like okay here's the backlog that I'm going to use but I want to prioritize these items based off of what I determined to be you know the this item is of higher business value than these other items so one way you can do that is by going to rank View which I have here and it's a stack rank it's purely based off of position and what we can do here is take items so I can promote to this unranked item all the way to the top so now that item 20 is ranked higher than item seven item ten item four maybe I want to demote an item and so make it unranked so I move a item eight all the way down and once I'm done I can go back to a ListView and I can sort by this rank and so here we have item 20 at the top then seven and then so on and so forth so essentially what I've done here is I've created a list of all these items and really what you need is just focus on is you know I could have remember what I mentioned earlier build out sequel server install you know those are all just the product backlog item itself it just shows you that this piece of work needs to get done and now that I've have a list that I can refine further if I wanted to but I want to make this easily accessible by the rest of my team members how can I do that and there's a way to do that here in Access soft and it's a lot like for those of you who remember either writing essays or reports in Microsoft Word and you remember the save as function it behaves a lot like that and so here I can right click on this tab here what I wish I have call work items I can right click and I can save the current tab which is essentially just like that save as function I already have a backlog but I can name it whatever I want but I already have a saved tab called product backlog that I can select and I can choose to make this public so what is this going to do essentially this is going to save this view so that anyone who adds the product backlog tab will see exactly what I see so for example I'll hit save and say I were logged in as someone else all I would need to do is go to the publicly save tab section click the product backlog and it'll recreate that same exact view automatically so I've effectively shared the product backlog with my team members they can review the list whenever they like and if they even want to they can refine the backlog even further so in this case I have item 20 selected I can hit edit and this is where you know you can customize this how you want but the general idea is as you get more information as you're collaborating with your development team you can refine the item and add more data into the item itself just so that when someone actually gets to work they have more information on what needs to be worked on or if they finally have a good idea of what needs to be worked on maybe they're finally at the point where they can estimate the item so those are two major things I wanted to show for the product backlog that's great Jonathan thank you and so when you're thinking about estimation and thinking about this it really needs to be a team effort when you're looking at things and there's a question it had come in can you describe a little bit about how planning poker plays for example and that's one way of doing estimation and what's important about planning poker any estimation I've seen people use shirt sizes small medium large extra-large to Excel and so on it really doesn't matter what way you do it if you use planning poker we're using different numbers to validate the size of work what's important is that you're agreeing on it as a team so that if I think something is an extra-large and Jonathan thinks it's a large one we better have a discussion to figure that out otherwise we're now not on the same page and maybe there's something that one of us is missing as to why he thinks it's a large and I think it's an extra large it also comes over time so on scrum teams I've been a part of estimations pretty hard up front but over time as you start to work together as a team you start to think more as a team and you start to realize well yeah what I mean is a large you actually do mean as an extra large and ok look at the team let's come together and bring those together so I think this is a great way for the team to be working together and sharing information and one of the really important pieces of this backlog is the visualization of it and we need a way to be able to visualize the work that's planned as well as on down jump back here to this I like the slide II have here Eric where you kind of show the scrum framework nice nicely here and so what I just covered was the product backlog but I also wanted to show once teams have gotten to work you know what are some things that they can do to again visualize and see how things are going and so there's one way to do that here and acts off and there's one super visual way and that one is the card view and I'm going to look at a specific sprint that I've already planned so here I have sprint one and this is pretty nice here because I have a card view and I even zoom in a bit let's see here we go and so here I have just some of the product backlog items my team members have already gotten work to it I'm at a point where I want to take on another another project backlog item I have the availability I have the skill set I can take on say this item number 16 so I'm going to pull out the organize panel again and this time I'm going to pull out the users and team section and Here I am here's me and I'm just going to take this item and I'm gonna take it so here it changes to my avatar here it is now on my plate and it's it's just a matter of me diving into it I can look at the description the requirements based off of conversation my team has had with a product owner and I can go ahead and get to work and then as I'm making progress I can move the item just by dragging and dropping it over to the appropriate workflow step and then if I'm just interested in seeing how everyone else is doing just at a quick glance one way I can get that information is just by grouping by the assigned to so I click this character right and then once I hit assign - I see just based off each user you know how things are going for them just quickly at a glance it's nice to see the swim lanes it's nice to see where their items are in case this needs to be in the case or the conversation I want to have during the next daily standout now innocence great right this now gets to more of that visualization that we just talked about what you're seeing here and part of what Jonathan doing is I assigned work to myself someone does not assign work to me because we're a team you're working as a team now we may have a discussion as that who you know who may do what but at the end of the day I'm pulling things from the backlog in that I'm going to work on one of the big discussions that often happens as part of scrum team is something known as whip might work in progress and making sure often that we don't have too much work in progress as individuals if I have five things in progress now I'm context changing all over the place which just slows me down and makes me less effective in Lex and at fault so that's something that's usually discussed at retrospectives and at planning it's part of maybe even our definition of done is to how much work in progress can can one individual have and this is a great way to start to visualize that as well you can see here that that same person has three things in progress Admiral Admiral Piett right so that might be a conversation we're going to have at the next daily scrum to talk about well Admiral it's great that you're working all the things that you've got three things in progress what's going on how do you how are you going to complete all three things if you're working on them at the same time and maybe it's because they're really two of those three or complete in his mind they're just waiting to be implemented into the build so that they can be ready for testing in the fourth one and the third one is the one of these really working on but we don't know that just by looking at this but we could see that in the notes in other ways and then the last one that I'm going to go over real quickly here is the daily scrum and so as Eric mentioned earlier this is a conversation that you're having with your team you're looking to communicate inspect adapt make changes as needed and we have just something here to help facilitate that conversation so here I am again logged in as my user and I have a scratch pad here in the bottom right where I can make some notes and so I have you know some quick notes maybe I've discovered some impediments and I wish to communicate that to my team but you know I want to jot them down now so I don't forget and then once I have jotted down all the impediments let me go ahead and mark this to be used for the daily scrum so what does that mean so to help facilitate that conversation that you might have on a daily basis we have the daily scrum here an axle soft and when you launch it you can start a timer to help you stay in that 15-minute time box and this is just here to serve as a visual cue as you are having those discussions so if I jump to me for example here you see if I've logged any work if I have reported hey I've done this much work it'll be over here on the left and then you can quickly see anything else that's on my plate but the most important part is the notes that I have down here at the bottom so when it is my turn and I do want to share how things you know what's going on I can share that hey I've encountered these three impediments let's talk about or at least start the conversation and if we need to continue the discussion offline we can go ahead and do that and so that's just real quick this is just meant to be put up on a you know conference room projector board projector or on a monitor or just somewhere that everyone can see and again it's just meant as a reference because the most important part of the daily scrum is the conversation that you're actually having from team member to team member great so I think this is awesome I think you know what we're able to show here what Jonathan's really able to show is how do I now take scrum and apply it right and that's why those examples are important so we're going to get the question let's really get the questions in a moment I think there's some really good ones out there I'm just in a nutshell kind of summarizing what we just talked about screws a team commit to delivering work and working soft within 30 days or less a time is scheduled to show that software the Sprint I'm sorry the Sprint review the team creates the software all right this is the team effort it's a team approach and the team offers their work up for inspection and an adaption during during that planning as well and then you constantly do that the constant right we repeat what rinse and repeat and we rinse and repeat so I think this stuff hopefully you learned a little something today and you'll probably learn a lot more from the questions sometimes I find that Q&A is the best way to hear because you're hearing what others are thinking um thousand all right so it does look like we have a very engaged audience it will see lots of questions posted here so let me take a look at a few here let's see what is APB I so a PPI is a product backlog item so you could think of it maybe as a requirement it's an item that's sitting in the product backlog that's been not necessarily refined but over time will be refined into likely multiple product backlog items so it's what Jonathan showed in that first demo and then a follow-up question and then folks as yeah so now that were jumped into the Q&A session you're more than welcome to post questions as we go along we'll try to answer as many of them as we can we have one question that came in earlier from Shrivastav asking who will place the items from the product backlog over to the Sprint backlog so the develop during sprint planning the development team will bring items in from the product backlog into that sprint backlog as part of the work that's happening during sprint planning and during the sprint they may pull additional items into that sprint backlog the Sprint backlog is a definite definition of work plan for a particular sprint okay and we have another question from I think Katie or Katie I apologize going to pronounce that does the daily scrum have to be the first meeting of the day no it doesn't let's work it what's right for the team I'm on a scrum team for example which has people in multiple time zones so we do it in the middle of my day which is the morning for folks who are I'm on the east coast of the US which is the morning of the folks on the west coast that are on that scrum team so you need to make it so that something that's available to all scrum team members or developing team members and then there is a follow-up question from William Griffin asking what do you mean by 15-minute time box for the daily scrum what happens if questions come up during that 15 minutes and you need to stick to the 15-minute time box or extend the meeting that's a great question in one that comes up quite quite often William so let me give you a little a couple pieces to that one is if I schedule an hour meeting we always find ways to fill the hour if I schedule 15-minute meeting it makes us be succinct so the idea here is let's cover what needs to be covered in the scrum or in the daily scrum in the daily scrum and then we can have action items that come out of that for follow-on meetings in my scrum team that I'm on today we call those posts crumbs so if something comes up and you can't see me but we'll put up a little hand signal with two two air quotes above our head called yoga's rabbit ears and say we're going into a rabbit hole here right we're going to deep the whole team doesn't need to be involved in this let's take that offline and let's make it a post from discussion which could happen immediately after it could happen later in the day but the whole goal here is let's keep this time box of 15 minutes so we're succinct and focused on just what is the work that's happening today were there any issues and and how do we learn from each other and then anything that doesn't really have to impact the whole team we can take that off as a side item but really try to stick to that 15-minute time box because if I give you an hour I promise you you will fill an hour it's amazing in a post job facing schedule all my meetings for 45 minutes instead of an hour it was amazing how we always were able to finish in 45 in the people who had the hour meetings always finished in an hour the you we find ways to fill meetings if it's there then we have a good question here what are some tips for coaching stakeholders especially the non-technical ones who want a complete perfectly working product out of the gate how do you get people who are used to waterfall type management practices to buy into scrum and that was from Andrew sure andrew is a great question and you know there's a lot there a lot of techniques out there for doing this I often start with find me a product that was delivered right the first time and by following a waterfall process come it's all ask that question right and and look through have that and start down that path because what often happens is you get people who just like the command and control much more than we have to define everything up front and I'll talk about that and I'll give real concrete examples of projects that started with lots and lots of requirements and what we actually ended up being delivered at the end and how those didn't meet the needs and I've got a lot of examples I'm sure you have examples that you can pull from your history your work history that you can use and then I talked about different ways that we can do this differently right it's not about not delivering something in the end it's about delivering things incrementally over time so that we can always review inspect and adapt and I think if you go to your stakeholders and talk about that piece that's really really helpful I mean you you I've gone to stakeholders and said well you remember that left that project you worked on it whatever point or give me a project where everyone went off into a black hole and showed up three months later with what you didn't want and almost every stakeholders had that experience I've had that experience so I talk about that and then say hey what if every two weeks or every four we came back to you with what we've done you can actually play with it a bit and then we can continue to improve on that and in another two weeks we'll deliver some more and another two weeks will deliver support so your constantly being able to make those changes and you're able to incorporate your feedback right make it about them not about you we're able to get your feedback and incorporate your feedback and that's also very helpful another question we have is if you do not follow the scrum guide 100% are you still doing scrum so that question is from da dam yes so know right that the scrum guide is the definitive definition of scrum is it's just it's less than 14 pages as we just talked about there's three roles the event and in that that's it okay so if we're not if you're not following scrum are you're doing scrum now you might be doing pieces of it and there's a lot of people say well we do it daily stand-ups so we're doing scrum well known the number one I hear a lot of people who can't stand up so you just insulted them by calling them that but I don't care about that piece I don't care what but if you're not if you're not doing all of those pieces you're not doing scrum scrum is defined in this scrum guide and there's one scrum guide as defined by the creators is from Ken and Jack so if I'm only doing pieces of it now now am I going to inspect and adapt and I I'm sure this is where you're going with that question because am I going to add things to it absolutely you're going to add things to it but how do I inspect and adapt if I don't do a retrospective if I don't do my planning if I don't do my review I can't I don't do my daily scrum so it's about abiding by those artifact the body and by those events and abiding by those roles beyond that have at it so speaking of adding items we have one question from Jeff asking how would production issues or hot ticket items be addressed in the scrum process would those be added to a current sprint and just ranked the highest that's up to the product owner it's the product owners job to prioritize those items so if you have items that are hot tickets you should be working with your product owner prioritize those they may have to bring it into the current sprint the website just crashed no I'm going extreme but yeah look let's get on that right away they may need to bring those in but they're going to prioritize the work because they're prioritizing the value and they're the ones ultimately responsible for and accountable for ensuring that that value occurs so you bring those to the product owner they're going to prioritize those in the backlog and work with the development team to make those happen which actually ties to one of the first questions that that came up so I think we could probably address this as well at the same time can a sprint be canceled at any moment and who will be the decision maker in that case so yes the Sprint can be cancelled it can only be cancelled by the product owner because the product owner again is ultimately responsible and accountable for that sprint or the work that's going to be done while the development team is one responsible for doing that work so only the product owner can cancel it and that's an extreme event you don't just randomly cancel a sprint but it does have to happen at time and it's only if you feel like you cannot achieve that sprint goal because the Sprint goal has changed so the business has changed because we just got acquired not you something traumatic happened or whatever you know that's a product order decision to cancel that sprint so I want to address that could they kind of tie together and then we have Julie asking while using scrum how do you suggest we answer senior management management's question about schedule ie when is it going to be done sure that's a great question how do you ask is how do you how do you normally handle that because I've been on many of these projects where every month we had a review and every month we were six weeks away or six months away and next month we had that review and we were six months away and next month we had that review we were six months away so I addressed that by saying here's what we're going to what we plan to deliver in the next two weeks for weeks whatever our sprint length is and here's what I plan to deliver in these next two to four weeks excuse me I also talked through my vision so I have a vision for what this product is going to be and I can do some estimation on that but again it's just an estimate no different than if you did all of your requirements upfront and estimated out when you were going to deliver on that there are a lot of books out there on software economics and software estimation and all of them will say anything more than about six weeks you can't predict so you can go and build out all the requirements and get all the contracts in place and all of that and say okay we're going to deliver this in 18 months I can pretty much guarantee you you will not deliver what was in that requirements backlog in 18 months you'll deliver something maybe but it's not going to be what was in that backlog so now if we want to say okay what are you going to deliver in 18 months we'll deliver something that's working software that meets the stakeholder needs but I'm not going to tell you exactly what that is because I can promise you our requirements will change over that period of time and we're going to learn as we're building over that period of time but if anyone's had a product a project that delivered exactly on time exactly what was defined on the budget on the they're kind of miracle workers okay so we're reaching the top of the hour here there are so many good questions here I do appreciate everyone who posted those in as we mentioned earlier this webinar is being recorded and we will have the recording up and ready to go hopefully within one business day up on our respective YouTube channels we do invite you to subscribe to scrum or his youtube channel to access our YouTube channel you will also get the follow up email tomorrow with a link to the recording so thank you so much thank you Eric first of all for such a fantastic presentation and thank you everyone else for taking the time out of your day to join us it's been a pleasure having you and I think we can adjourn this webinar thank you so much everyone hi folks

Channel: Scrum.org

Views: 89,469

Rating: 4.8516803 out of 5

Keywords: Scrum, scrum.org, axosoft, scrum guide

Id: GR9-8lOUhwA

Length: 58min 15sec (3495 seconds)

Published: Thu Jun 29 2017