Official Scrum Guide Update 2020 - Changes & Impact LIVE Event [Recording]

thanks for joining us for this on-demand replay of the 2020 scrum guide update celebrating 25 years of scrum this was a live event so to improve your viewing experience we've shortened the breaks and removed some details that only apply to the live audience we promise all the scrum content remains unchanged finally if you haven't already download your copy of the updated 2020 scrum guide at scrumguides.org it is currently available in more than two dozen languages and counting now on with the show members of the scrum and agile community product owners practitioners scrum masters coaches leaders and visionaries welcome to the 2020 scrum guide update celebrating 25 years of scrum our program begins with opening remarks from dr jeff sutherland and ken schwaber and includes two moderated workshops the first is titled 2020 updates driving focus the second is titled how the updates impact your scrum we'll wrap up with questions answers and closing thoughts with dr jeff sutherland now on this 25th anniversary of scrum please join me in welcoming the two people who started it all the co-creators of scrum hello and welcome everyone i'm dr jeff sutherland the founder of scrum inc and i'm here with the 25th reunion with ken schwaber to talk about the scrum guide [Music] and i'm ken schwaber and i'm here after jeff and i have known each other for even longer than 25 years um and have a long standing friendship and working relationship but we have been working on this and software development for a long long time so what you're hearing is what works yeah i totally agree we both saw scrum revolutionize software development and that that revolution continues now i mean we talked 10 years ago about scrum starting to spread to every industry you know not just hardware but healthcare construction human resources ai and i've we've been talking about changing the scrum guide so it's suitable for every domain and every department in every company and and as the world has changed and become much more sophisticated scientific and complex um that scope of complexity for scrum gets bigger and bigger but all of this has been made possible by people like you who have a problem have a have a situation that you want to try something with and you've heard about scrum and you try it and you find that if you work hard on it it works yeah you know there's just one scrum framework and it's been a way for companies to communicate with one another across the entire organization and now i'm hearing in different countries as people are spread across countries they say scrum is the common language of work and so we want to thank everybody who's really built scrum over many many years have been thousands of people millions of people uh scrum at its core is empirical and so all of your insights and experience are pulled into improving scrum making scrum better and that was particularly important for the 2020 version of the scrum guide a couple of things that we learned is use fewer words rather than more words more words does not simplify it complicates don't entangle ideas with each other because not only won't the reader know you're they're talking about but you won't remember what you're talking about we've incorporated these lessons we've removed the things that entangled it we've removed things that contradict each other we remove things that are too complex and as a result we think that this is our best guide so far when we did the very very first guide back in 2000 geez was a 2000-2001 right after the actual manifesto it was 160 pages and it had seven phases so um this is an improvement yeah we're down to 13 pages i mean i think this is just as good for a sales team now as it is for a software development team you just do it i mean it's straightforward and if you've got a problem there it is um so we've also made scrum guides less prescriptive as we proceeded we would get questions um how do you do this how do you do that how how does that happen and it would bother us so we would try to put something that would guide or instruct or or give people information on how to do it and i i think i started it by by the three questions you asked during the daily scrum and then we also had you know how you do your refinement um so we put in things that we thought would help you through difficult situations all it did was help maybe those people but baffle everyone else and you can always tell when your people are baffled because they start arguing and if you go to discussion groups you'll see people quibbling about things i don't think you'll see as nearly as many as those so scrum itself is much much less prescriptive he had to be to be down to um 14 pages or 13 pages and so we placed a lot of effort on streamlining and on making this work in a straightforward way um if that was all we had done i would have been just just really happy um but jeff we also found some other things didn't we yeah you know i just thought when you were talking remember we started off scrum was just one team when we were writing that paper for uh oopslog and then we went to individual and then they had several teams and i remember we did a lot of work there and then we went to idx and they had hundreds of teams and many business units um and then of course we worked together at patient keeper for many years and meanwhile you are out all over the world talking to many different companies starting the whole certification program uh and so scrum has used been used everywhere for companies all sizes and shapes and forms but getting that one team really right is kind of the core of everything right so one of the things we did with the guide was uh simplify the sprint planning topics uh and also bring in a focus on why are we doing what we're doing and uh uh an introduction of the product goal i remember ken i i mentioned to you about a year or so ago that some of our trainers were saying the product owners are not focused on the overall goal they don't have a vision of where they're going so the team is supposed to know long term where are they going as well as for each sprint what is the goal of that specific sprint so previous scrub guys describe the sprint goal and definition of done without really giving them an identity they were not quite artifacts but were somehow attached to artifacts with the addition of the product goal the 2020 guide provides more clarity around this each of the three artifacts has certain commitments so for the product backlog the product goal is the commitment for the sprint backlog the sprint goal is the commitment the increment has a definition of done they all exist to bring transparency and focus towards the progress of each artifact um when we said that there was one team a problem we had heard arguments after arguments after arguments about is well the product owner is one team but then the developers are separate development team and the scrum master kind of floats out there and and what you get with that is is you wind up with what i see in in sprint reviews where the product owner is pounding on the table saying you promised me you would do this for the sprint why didn't you do it if that person is part of the team they were part of the committing to what they thought they could do so this thing if you're all in this together um i i think i hope will help a lot well i think you know this the new scrum guide is it's lighter it's simpler it's shorter um and we all need to put our heads together to actually wrap whatever we need in our environment around it to make it work really well so we're we're really happy that all of you are here today we have a chance to talk once again about the update of the scrum guide uh we thank everyone who's contributed to it over the years uh and we're thankful that it has become the dominant agile framework in the world both for individual teams for many teams uh the most successful companies in the world are all using scrum so this has been an amazing journey ken for me it's it's all the other things we've done in our life you know that later someone balls us out for finally we did something right this is good and um it has been a journey and it's been something i'm very proud of and i'm proud to have worked with you on it and i think we can share this with um the rest of the scrum community and it'll make their life easier too so thank you all for being here and we look forward to seeing you out there scrumming day to day year to year into the future [Music] should they be wearing scrum hats scrum hats yeah you could you buy little scrum cats back when you when you started remember we had the all black shirts that said yeah they're from black shirts they don't sell them anymore is that right yeah and strangely enough they're too small for me now yeah i don't understand how that could be i think i still have one in my closet somewhere maybe i should have pulled it out with this meeting huh that would be a good one thank you ken and thank you jeff [Music] to mark the 25th anniversary of scrum we asked you the scrum community to share your scrum story here is some of what you had to say dear jeff and the other father of strom ken 25 years ago the two you created scrum this beautiful baby and we stand here today to as witnesses to the impact this has had on the world yes and today we use chrome everywhere not only in software development and marketing departments but literally everywhere we can we use scrum when we run trainings we use common hr and r d departments we use it for procurement we even use it at home to run our families we teach leaders on scrum we help scale scrum across entire organization and still we discover new ways and areas where scrum can be applied successfully almost every day yes one right it has been last but not least thank you guys so much for making scrum public domain letting everybody discover new and better ways of working we salute you salute you hi i'm diane leonard president of dh leonard consulting and agilent nonprofits and how did scrum change my life i can hardly even begin to count the ways six years ago my spouse and i listened to the audiobook version of the art of doing twice the work and half the time and right away i began to put the scrum framework into my own business framework well our firm works exclusively with non-profits and so the journey didn't end with my business we brought it right to our clients right to the non-profits we work with around the world by launching agile and non-profits and so well scrum hasn't just changed my life it's changed the life of countless non-profit professionals around the world and therefore those that they serve happy birthday scrum can't wait to see what happens next a story with scrum started in 2008 after i graduated from university i worked in a company where the managers controlled the developers to work until midnight and also during the weekend so back then i questioned myself could there possibly be a more humane way to work in software development so i searched for the answer and discovered a book titled the enterprise and scrum authored by kenshwaeber i learned a lot of things about using scrum in a large scale enterprise from this book [Music] thanks to all of you who shared your scrum story we'll feature more of these throughout the program it's now time for our first workshop 2020 updates driving focus featuring dave west and jj sutherland moderated by patricia kong hello everyone good morning good afternoon good evening wherever you are my name is patricia kong um now that you've had a chance to take a look at the scrum guy 2020. it's my pleasure for the next 45 minutes to be moderating a conversation about the scrum guide updates with jj sutherland and david west so i've printed it out um it went from 19 to 13 pages so we can say that less prescription less complex as as ken and jeff mentioned in the the video um they touched on something and the reason that we want to talk about driving focus is the notion of this commitment and product goal so uh gentlemen i hope you don't mind if we just jump right in um sure so so let me start with this so if you're with me and you're looking at the scrum guide um the update right now on page 11 let me just read this to everyone the product goal describes a future state of the product which can serve as a target for the scrum team to plan against um what do you guys think is the purpose of the product goal so i know jeff touched on it a bit um why don't we get just started into the purpose jj why don't you start sure i think what jeff and ken in conversations with them what they really wanted to do was to make sure people were using scrum to get somewhere to actually deliver something not just to do it i was uh talking yesterday i said don't agility is not the solution to your problems agility is how you solve problems and that's what i think is and so when you have a goal whether it's the sprint goal is the goal for the sprint and the product goal is this broader thing what does all those sprints and add up to because one of the hardest things in any part of your life is say okay i want to get to this vision to this place to this idea but what do i do tomorrow because it might take years to get there but i'm going to have to do tomorrow and what scrum does is it allows you to get the feedback of whether you're going on the right in the right way very quickly yeah just to sort of add to that i guess it's it's all about striving for something isn't it you know we we as human beings i think are ultimately more motivated if we have a picture or a context that we're striving to you know being told to do a task as fabulous as that task might be is not particularly interesting or motivating and also it doesn't allow you to be empowered or your team to be empowered to solve that that thing in a particularly unique way by having a clear goal in mind it helps frame your sprint goals it helps frame your reviews it helps frame how you actually approach the problem and the work that you're doing i think i'm really excited about a goal being added it it's something that i've noticed and jj and i were talking about this a little bit as we potter around the world not so much now obviously with govid but we go into many scrum teams and see them and they got really good scrum boards but the lack of clear connection with the actual outcomes the customer is something that that really worries me and you know they're great at doing work and they may have fantastic velocity but ultimately they're not necessarily aligning that to the outcomes that they all seek and and the organization seeks and and hopefully that enriches the world that we live in excellent i can't tell you how many times when we you're right we're talking about this you go into an organization you find a bunch of teams working on stuff that no one wants is it it's not that they're bad it's not that they're bad teammates aren't even that they're bad product owners what it is is there's no goal there's no connection from what a team is doing on a sprint to sprint basis and as dave was saying and on this broader scale what does the organization want to achieve so why it's so important what i'm wondering is then and and i'm seeing it come up in the questions is just why now then why now if we've been seeing this for for years why do you think now is the moment uh well go ahead so i was just going to say it it's funny because you know obviously you know jj and i are very fortunate to spend a lot of time with jeff and ken and and talk about this and and i think there's always this tension about um adding more stuff to the to the guide and and and taking stuff out and and i think that before anything's really added to the goal to the guide sorry the there's definitely needs to be a distinct need but i think ultimately i think it's really illustrative of the fact that so many different organizations and different types of teams are really doing scrum now it's a lot clearer that there needs to be something that that unifies that team in the pursuit of something and maybe when it was all software teams the product backlog you know defects you know all this sort of stuff it was much simpler but as scrum is used by more organizations and more types of people it's always been about delivering value right it's not just been about doing work but now it's even more apparent i think i don't know if you agree jj but it's something that i've seen yeah no i i think that uh most of um the companies that i work with are not software companies at all they're doing very different things they're in aerospace they're in defense they're in oil and gas there and doing lots and lots of different things and i think that what uh jeff and ken did was say because of that let's rethink how we do it and rephrase it and i just started jeff last night and one of the things he said is he said you know scrum hasn't changed we're just getting the description better and i think that's really uh what has made the difference is it's not that scrum itself has changed at all is that jeff and ken are finding better ways of describing it i mean when we think about what that adds to the scrum framework right the the central message that you guys have is really for me around focus and innovation um and really driving that forward so let's get a little bit into the details then because i'm sure as people are reading this they're starting to think about how does this affect my role how does this affect you know our teams um so straightforward um jj who do you say creates the product goal but the product goal is the product backlog it's what the product backlog sort of adds up into right so the product backlog this is a way of describing the product goal just like the sprint backlog as a way of describing the sprint goal and so that that's really where it does come from yeah and it's and of course that means because it's about the product back like it's owned by the product owner now ultimately a good product owner which jj and i might not necessarily embody at times but we do our best um a good product now um talks to lots of people and he's trying to distill that that product goal you know trying to make it so it's you know pacific it's measurable it's agreed upon and and that is a real art and um it's it can be incredibly challenging but ultimately it comes from that product owner and it manifests it's made transparent through the body product backlog an art it is so um one of the things that i notice and when we're talking about the role of the product owner is in the last guide from 2017 there is the mention of vision once in the 2020 guide i i do not see the word control f vision at all so what would you say then dave as a difference between a product goal and a product vision so it is yeah so in 2017 there's that that one statement in the guide that says you know how the product backlogs created because you know informed by a vision or a goal and and obviously in this release of the guy 2020 that vision statement has has gone so ultimately i think that in many organizations vision strategy tactic everything's a bit of a blur and it depends on context however you know you could argue that a product goal comes from an ultimate organization or vision or mission you could also argue that a product goal drives a vision which is then manifest in the product backlog ultimately the semantics is all going to be very contextual in your organization in your context whether the vision is bigger than the goal and it describes a series of product goals or whether it's actually the other way around and i don't think it really matters as long as it's clear for your organization and as long as you clearly define what this this context is um and to make it more transparent and to understand why the goal doesn't describe everything or why the the goal just describes this this element of the uh of of the endeavor you're you're engaged in like jj i wanna also go ahead sorry i was just saying i see you nodding so yeah i mean i think what uh the product goal becoming the organizational goal because you're getting all this feedback all the time is that product gold the right one to do and i think what jeff and ken were really trying to remember this conversation with ken you were there dave when he said you know vision is almost too vague you know it's like okay i have a vision but you have to have a goal and you have a commitment to this goal and it was very interesting how they used uh the scrum value of commitment that's saying there is a commitment to reaching this goal and the team and the product owner and the organization recognizes that that they have this because that's not vague right so so commitment um jj what does it mean in in your conversations with ken and jeff um and your interpretation too especially based on your experiences what does it mean when it says that the scrum guide says that the product goal is a commitment for the product's backlog what what was this meaning behind taking one of the the scrum values and throwing it in like that i think what it came from i remember ken in the last uh update in 2017 he said you know that when he's talking about commitment about the scrum value of commitment he says it's really easy to come out of sprint planning and work on something else and not what's on the sprint backlog that's a temptation i know i get it myself you know something comes up hey we should do this oh this is you know the bright shiny ball like squirrel but and then but what the commitment is to meant to focus yourself focus yourself i have committed to this i'm going to get this done because again that's what scrum is about getting things done and and that's the great thing about the use of the word commitment and i don't want to overload it but in respect to the the three artifacts you know the definition of done the sprint goal and product goal the newly included obviously definition of dun and sprint go already there but now i think you could not debate the relevance of them anymore because they are commitments um you know in the terms of the definition of done a commitment to the increment you know this is what an increment really means these are its quality characteristics this is a this is it's you know a quality or capability commitment in the sprint that there's a clear goal that we're moving incrementally towards the product goal which is a commitment to the product backlog i think it's a really nice use the um the word initially i i must admit i didn't like it jj i was like hang on we can't use it twice you know i'm a big fan of being separate if it means something else but ultimately as i've been over the last you know a few months been using it in thinking and writing and just using the word it makes so much sense because we're not saying we can get it done it's not a promise but it's an aspiration and a desire in the same way as a commitment in in in the values is so you you talked a little bit about um just kind of all the other artifacts that we have in scrum and dave your era you're a product guy so when you talked about product vision and now we have this notion of the product goal how do you see how do you see that relationship in terms of how we would be using product road maps and other product management artifacts let's say yeah so ultimately you know i think as i said earlier i think it really does depend on context however what what i i think that's super important about a product goal is that that there is one at the start and that you start working towards it and then you have the opportunity to inspect and adapt it throughout now if that product goal fits into a broader story a product vision or a road map then by getting continuous every you know week every two weeks every 30 days feedback from the sprint you literally get to refine your understanding of this thing and if you can do it what what it actually means to you how what the outcomes are continuously you get that transparency across the whole product life cycle and across the whole portfolio of product which is which is really really important i think you know transparency i overuse the word but i think it's so so valuable we live in this very complex environment and and i think covert has taught us how complex it is you know my my product roadmap for 2019 uh 2020 has not been delivered on i don't know about you jj but the ability so everything's the same exactly as i say i mean my annual plan perfect well you are obviously clairvoyant but i didn't i'm afraid so what what but what it what product goal gave us an opportunity to do is to step back from the oh this is what we're doing but what are we trying to achieve you know what what are we actually in this business of and then that allowed me to refine the product backlog and then the sprints that we deliver work at scrum.org it allowed me to refine those uh to to be better so i think ultimately you know this transparency in this flow of transparency across the product artifacts is super invaluable i could i could not agree more so three pillars of scrum transparency inspection and adaption and uh i was i was thinking about this uh last night i was thinking about transparency and one of the things is a lot of the work we do is imaginary you know it's not we can't see it we can't touch it you know it's in our heads or in the cloud or and that makes it so hard to see where everything is what is the state of what we're working on and i think one of the things that scrum does is sort of it rips the imaginary into the real because that is just so critical to be able to see what's going on and that has become harder in a covid world you know it's a lot easier if everyone's standing around a scrum board but what we've done with scrum makeup i think is really important as you're talking about changing the scrum goals what i've said to our trainers and consultants is saying don't tell me what's worse about doing it online tell me what's better let's do what's better and i think that that idea of sort of shifting the focus from our goal is not to go somewhere live to interact with somebody our goal is to teach people scrum to coach team scrum to coach organizations and transform them that's our goal how we do that well we have to iterate on that and that highlighted another thing trish we don't mind the measurability you know what is the outcome that we seek what is in the case of you know if you do a training class or if you deliver an element of a product or a product to market what is the outcome and then that helps by thinking about that that really helps us uh during a sprint and particularly at sprint review to really make the intangible tangible as you said you know jj that you know you've actually got a an outcome the the big change in 2017 guide was the emphasis of the fact that you can release that the sprint is not a release life cycle it's actually a planning life cycle it's a it's a work life cycle it's got you know you can release as many times as you want during the sprint right now what product goal and sprint goal provide us with is the ability to measure the outcome that the work that we're doing gets now ideally that's released you know or made available or is usable as it says in the guide now we've dropped the word released as well i noticed usable we have this element of work that's usable and you get that feedback at the sprint review everybody comes and talks about it that's awesome as well you've literally made something that was just an idea you know a week ago something's happened and you get to review it and talk about it now hopefully that's a positive thing sometimes it's a negative thing but ultimately you've learned something which is a positive thing which you then feed back into the next cycle right that's the great thing about scrub and goal product goal double downs on that double downs double down to say in the morning isn't it so you guys have both hit on um the power of transparency and the importance of transparency and it talks about you know the the product goal is it the product backlog and the new guide and um this week two friends have reminded me that transparency is not just about being visible but about what's um what's understood so this brings us back to focus right because it's about what we're focusing on and another thing that in the scrum guide the news forum guide it says uh the product goal again page 11 the product goal is the long-term objective for the scrum team they must fulfill or abandon one objective before taking on the next so jj i'm wondering um in your in your experience and your work at scrum inc what does it look like when you're thinking or you've been thinking about a product goal how would that change how would how would we know what would make a product goal change if you get feedback you're making the wrong thing because that happens all the time right you have like i've certainly had this you know you know i have a vision i have a great idea i have a goal and i bring it to a team and the team says okay let's turn this into a backlog and working with the team we do that and then the team goes out and starts building it and giving it to real customers to get real feedback and then they come back and they say jj that was a stupid idea so we shouldn't do that anymore and what's great about scrum is like fantastic now we've learned not to do that let's do something else and i think one of the things you really focus focused on there was the focus of the team not doing more than one thing at a time i know that if i have a team and they focus really hard on two really important things neither of them will get done that quickly now there's always something in your backlog that's you know just the business as usual keeping the lights on stuff that you have to you know just have to do like you know you have to do certain things all the time no matter what but the idea is drive that down into just what's the minimal viable stuff in your backlog that you have to do that isn't innovation creation uh do it solving the problems that you're trying to solve and you want to minimize that and so this is idea of the focus and if you do two things at once it doesn't work that well it it is interesting when you disc there's there's always balance in any of these things right but so when you discover which you quite hopefully rapidly do discover that the thing that you you that amazing idea that you had jj was actually just rubbish when you discover that not saying any of your ideas a rubbish i'm sure they're all awesome but when you discover that you get the opportunity to do you know a couple of things you get the opportunity as a product owner to say oh my god stop kill the sprint that's it i'm going to go back to the drawing board i'm going to talk to the people that invested in me and invested in this team and decide what to do or we have the opportunity to refine to change it right you know this we have the ability to say yeah jj your idea was a bit rubbish but what we found was if we do this and this and this they actually loved it you're like oh and then this is the other realization that this sort of highlights a lot of people think of the product owner as the voice of the customer that sort of gatekeeper that manages all of the desires of the world outside of the team when realistically the team ultimately has a responsibility to take those yes we're making decisions as a product owner on what order to do things what direction to go what goal to execute on but ultimately it's the team's responsibility to validate that to challenge that and to bring back that feedback to to allow us to make better decisions everybody cares about the increment everybody cares about delivering the value everybody cares about that yes the product owner happens to have the responsibility for making the ultimate choices around which to do first or what direction to go but the whole team is responsible for challenging in this case jj when he comes up with a silly idea and then working on building the you know the helping improve refining the i the the goal to improve so the next sprint that we go along or even in this sprint we're actually moving in a better direction and i think that's a really important point and to some extent not that we're meant to be talking about this the removal of the development team or the renaming the development team to developer has helped us so you add that with the goal it really highlights the fact that we've known forever uh but it's sometimes missed is that scrum is all about delivering value it's not about how how how i mean a little tangent we have we have 20 minutes how does that help us how does what help us that we're all focused on delivering value the change from development team to developers so i think ultimately to some extent scrum is still scrum don't don't get me but having a team within a team and having this sort of almost contractual relationship between the product owner and that development team and of course that's not how many people practiced it particularly the good people but ultimately got in the way of value you know the team just carried on doing what the product owner said even if it didn't necessarily deliver the value because the broader zone is responsible for value jj's the one that gets beaten by the other by the board and by the people investing not me i'm the development team i delivered it look at my velocity look at my burn down you know etcetera i think that this highlights and obviously i'm saying this as a product owner you know that though i make the decisions everybody is accountable for them great um no what it means that we're as a team we are responsible for this and i think that you know one team i think ultimately is a really good positive positive change but of course as jj said people are doing scrum today well it doesn't change it you go into a really good organization that's doing scrum those everybody cares about the value everybody's challenging their understanding of the the pbis the product backlog items and this and the and the sprint items and the sprint goal and trying to deliver the most value to the customer everybody has that hill that they're trying to climb right everybody gets it the teams that don't function effectively are ones where the product owners telling people what to do and and i think though that was never the intention of scrum i think sometimes you could you could mistake that and um so i'm really excited about this i i like that change i don't know jj it's a little maybe it's a little tangent but i i really think it all fits with this goal sort of value orientation that the scrum guys really embraced massively in this release yeah i was uh speaking i heard speaking with a um a fairly high level official in britain the other day yesterday and he said something really interesting he said uh that before he did scrum he said he'd been on in his life two or three really high performing teams like really great teams everything clicked everybody worked together well i said it was the best thing ever but it all happened by accident it says but he doing now with scrum he says he could he is able to build teams on purpose with consciousness and i think that idea of the scrum team as a whole that there is no separation of the product owner and the scrum master and the developed they're all together as the scrum team working together towards this common goal this common product goal and that is doing it on purpose and trying to build these high-performing teams consciously sorry i was going to say yes okay i just got excited patricia sorry let's touch on that jj so so you're talking about focus transparency you've talked about essentially um the the person you were talking about the intention right so one of the things that product goal um that that may be interesting for for people especially larger organizations but most organizations to think about is now about alignment so if we were talking about um product goals is there a need for organizations to ensure that there's alignment um with product goals and strategic goals and what would you think that would look like in your experience abs absolutely i mean in a in a sort of perfect world there's this broad goal of the organization this is the strategic direction we're moving in everybody even hundreds of teams any team member should be able to say i know how my task the thing i'm working on today helps that that it's all additive up and that doesn't matter if you're in a small startup or if you're like i don't know like bosch or somebody or 300 000 people it's you know how does what i'm doing today align with the organization's strategic goals because that's what happens when things aren't transparent as davis and those aren't really clear and as you were saying trish that they're understandable everyone shares a common understanding of what those goals are and what those mean for my daily work so yes you want everything if you have a portfolio you're going to have a few different ones but everything should add up together i think the most successful organizations there is that clear alignment between strategy and the goals that every every product and every product backlog manifests i think the the the challenge is that it means that we have to make choices and i think that most large organizations that i've come into contact with have a really hard time making choices have a really hard time focusing because they want to do it all because they don't know we one of the manifestations of living in a complex world is we don't know so the the one strategy in response to that is do everything because just in case because one of them will work right and that's what that ends up meaning is that there isn't a clear focus for the company that the strategy is either very intangible and like well we're going to be the best of this well what does best mean well you know you you it it isn't tangible it doesn't it isn't it isn't real and then me working in a as a cog in a very big organization like a you know a bosch or a you know or whatever i don't really understand how my contribution fits in and that demotivates me and then you know that ultimately results in me not delivering the value that i can one of the one of the things that's super interesting about this sort of the the the use of scrum is that ultimately it challenges the fundamental ideas about how work is done you know it's taken taylorism and in the industrial viewpoint and sort of turned it on its head and said hang on a minute actually the most important people aren't the managers the bosses the c levels even you know people like me it's actually the people doing the work and and they need to know why they're doing it and they need to ultimately break down those that that barrier and have it clearly communicated and so we've seen with the with the with covid one thing that's an interesting piece of data that i saw recently from a study uh i believe it was mckinsey where they showed the sort of communications between the high-level executives and teams the people that were actually doing the work has increased massively because of because of covet because ultimately it's very clear that when as a massive man of unknown it's very clear that you go and tell people why they're what they're doing is so important as they're sitting in a house with kids on you know zoom doing education where they're worried about their parents and everything this is why this is important it it it's very clear and what scrum does is it institutionalizes it it makes it look this is you have to clearly have a goal you have to and ideally it connects to the strategic goal and it flows all the way down so i think ultimately that you the connection it has to be very clear has to be aligned and communicated in that way so dave i just want to pick up on one of the things you said there prioritization people hate prioritizing because they have to choose and so they say as you were saying they'll want anything and the thing is if you have five top priorities which is usually what most organizations are going to i'm sure you probably have the same experience everyone has like five top priorities which is just silly because if you have five or more top priorities the person deciding on your corporate strategy is the most junior person in your company because they get to pick what to work on because they get to pick because you said everything's important and it's this constant idea of saying and what i i think in the product goal says your focus as the new guide says focus on one thing at a time and you'll get it done if you focus on 10 you have like 10 halfway done things of zero value a lot of work everyone's been busy everyone's worked hard right but nothing is actually done i was uh before i was in this business i was a broadcaster for national public radio npr sort of our version of the bbc in america and i was running the morning show at one point and this young producer came up to me said jj i worked so hard on this piece i stayed up all night it took hours and hours and hours and i said how much do you think the listener cares how hard you worked because they don't care at all they only care what comes out of the box they only care what's delivered to them and so you want to do is deliver that product with the least amount of work that you can do but do they have the quality and the speed because that's where you learn exactly and that yeah so i the best the the best example is when you've managed to deliver your product goal and everybody loves it and everybody's like yeah and you and you've still got 28 pbis still in your product backlog by the way 28 was just a random number i didn't mean that on purpose but you've still got work because what that means is that your team innovated it it's you know what that means is that everybody was so focused on delivering the goal they and yes the the pbis that they created were probably their idea of it but they realized as they did more work that some of those things didn't make sense and that's the great thing it you know it's not can you get everything done that's in the backlog it's can you deliver the value that the backlog is all about and and i think that's super super important you know we we often talk around sprint planning the sprint goal really frames not just the the things that we pick out and put into the sprint backlog but it means the things that we don't put it means it gives us the ability to sort of like innovate around those things to deliver what we can to get the goal out and and i think that's that's something that we often forget as we because we can't help but forget because it's that you know it's your 27th sprint you've been working through this backlog you know what it's like you just sort of forget why am i here again you know what are we doing the great thing about a product goal because it will be manifest and transparent at the sprint review at sprint planning even the daily scrum you know that making it it's there it's on the wall or the virtual wall now obviously and everybody's like oh how did that help i know it's it's the most rewarding and annoying thing so ken schweiber says to me every time we meet so how are we doing against our goals let's talk about the i'm like i just want to tell you about the work i did because it was so awesome and i worked so hard on it a bit like your uh your mpr guy uh who's probably awesome and doing a really hard job so we do we do respect him for that you know i want to tell ken how amazingly hard i've worked and he's like i don't care i care about the outcomes how did you how did you do that i'm like oh damn how did you do it i said well actually it was a complete flop but i worked really hard so you should reward me for it exactly jj all right so we've gone through the purpose of the product goal we've talked about focus and transparency what i'm hearing you guys now say you know when you're thinking about that protocol and how it drives focus that's really helping an organization innovate because what it's forcing you to do is not really just say yes it's forcing you to say no right to drive that so we've gone through that and now you know this question is here it's coming um for both of you is what what are some examples of product goals that you've seen very quickly i yeah yes i mean so i've got a few you know sort of like reach 10 000 new users um you know improve the customer experience as measured by the npr uh not npr sorry net promoter score mp npr's obviously a radio station but um to add 20 points on our experience numbers or whatever you know very very focused very specific very measurable agreed upon realistic has some maybe within a time frame is also a nice extension around this i you know i've seen lots of those i've also seen some very bad ones that are very intangible i personally like very very tangible goals that i can understand that have a clear measurement but i also don't like them instead of making a choice they've sort of added 15 goals and merged it into a really long sentence so i like it when there's a choice i like it when it's measurable i like it when it's succinct and i like it i guess it's a bit like i want to lose 10 pounds by let's say december 20th and that's very measurable it has a clear idea it would be nice if it said why i want to lose 10 pounds because i want to look good on my holiday photos okay that's good so i could look good by you know having a nose job or something instead that's an alternate strategy right and then each sprint maybe the first sprint is i give up drinking a bottle of wine every night it's a ridiculous idea but let's do it easy to measure you know it's that kind of thing that we want to see and it gives us some flexibility when we realize that in this current age and having two small children at home and i know jj is the same giving a parkour is not going to be a solution to weight loss so the you know it but ultimately i i think pacific measurable very important has a clear time frame in mind those things are the characteristics i would say i don't know jj any well i i i would agree with you but it could also be other things so thinking about uh when covet started one of uh one of scrummi's clients it's you know fairly large company and the ceo said we're going to pay our small vendors within three days of invoice whoa because he knew that these small vendors are going to have this massive cash crunch because of kovid and the accounts payable team which we had been working with for a while and they were a scrum team doing writing checks and their goal was within a sprint and they were doing one-week sprints within a sprint we have the capacity to be able to deliver on the small vendor checks within three days which i think there it was usually like net 60 or net 90 right and because they could focus on that and they said they really attributed their ability to do that because of scrum they said that's the goal that's the only thing we're going to work on you know the large vendors what we can they can wait till next week while we figure out the system to do this which we haven't done before because that focused them because that was the goal and the goal was there as dave was saying is why you know the ca said ceo said this is the goal to get to be able to do this and this is why because we know that these small companies will go out of business if they don't have cash so i thought that was a really interesting way of thinking about it you know we want this capability because it doesn't if a product is not necessarily something you know this tangible that you can use sometimes it's a capability yeah or it's knowledge or it's uh what's the right question to ask it could be any of those things and uh that what the goal is is what do you want to be able to do what do you want your customers to be able to do what experience do you want them to have whoever is getting value what's left so i want to make sure i squeeze in one more question and then and then we'll have to start to wrap this up um we could sit here probably for hours and talk about this um jj what is what is one misconception that you think people will have about commitments in the product goal just like i i think it's the same one that if people as dave was saying earlier if management goes around saying well this was the goal did you hit the goal and then you learned something you did something different than the goal you're a bad team you didn't meet your commitments rather than saying no we learned we learned what the right thing to do is and it might not have been that and uh like one company i know this the the development teams would have to commit to something that the business wanted and then a year later they finally got around to it but the business even didn't want it anymore but the pmo judged them on whether they did what they committed to a year ago even though it's zero value and so that's the real thing because the entire thing about scrum is you get to change your mind yeah i think that is a yes it's also how people misinterpret commitment in the values as well so it's interesting you bring that up they're like but i committed scrum committed i committed to doing something impossible which is which is great i think that um or in the case of the product goal it's not impossible it's invaluable or not valuable as it were i think that is a big a big misconception i think the other thing is like because they people want to cheat so they you know we focus on one product goal right so what i think another misconception is that means we can build really long sentences and use lots of semicolons and and those things to get this i think that that is going to be something that people do and it ends up sort of like not adding that much value one thing that's you know people often discard the sprint goal i don't know if you see this jj but they discard it because they're like well it's not really adding any value so we're doing what scrum teaches us from throwing things out by the way that's not scrum anymore but it doesn't matter um they said they're like because it's hard i'm like really well because you had to make choices and decisions and focus the team and you know these things well yeah that's hard yeah you know it's like uh it's like my weight loss program that i yes having to make a decision dave you'll be okay so we have a few minutes left and um if we lift this up so scrum turn 25 this year happy birthday um younger than than all three of us uh for each of you if you could give us a minute what are your what are your big takeaways for the updated version of the scrum guide and i'm going to add not only what your big takeaways but what do you think that means for the future the future of work the future of scrum and i'll give each of you a minute because unfortunately that's all we have so jj what does this mean for you what's your big takeaway my big takeaway and i'm so glad that jeff and ken did this is that they recognized scrum while it was birthed in the software business is being used everywhere and i think that was one of the real uh goals that they had because they felt that the the guide which was great but it's they used terms they thought maybe that was too limiting into a technology uh enterprise instead of like services or whatever hardware whatever it is and so i think that that is my big takeaway from this guide it's that the idea that scrum can work anywhere and i want to i was just pulling this up i just want to read my favorite sentence in the guide two sentences the scrum framework is purposefully incomplete only to find the parts required to implement scrum theory scrum is built by the collective intelligence of the people using it that's really important because it's really about the team it's not going to tell everyone everything to do and that's on purpose that's on purpose dave just to add to that i think uh i mean that was really well put jj i think going back to its roots really i mean ultimately you know when you talk about i don't know if you do jj but you talk to ken and jeff about you know the patient keeper and these projects back in the day the fbi sentinel project which sounds a bit scary um they um the they talk about basically the the beauty of this team focusing on things and that all the other stuff is just noise and you know the three questions and that so it's going back to its roots it's going back to the essence of getting teams to be those best teams you ever worked with getting getting back to that those pure simple ideas around it now does this require intelligence yes does this require you to make tough choices yes but all the best outcomes do you know if it was easy everybody be doing it right so you as this team you can do it you can literally take this framework read the scrum guide and start delivering valuable stuff challenging the status quo and improving the world that you live in and create an environment that is both productive and also incredibly happy and that and that i think that's the essence of scrum and i think that's what we've managed in this um ken and jeff had managed in this release of the scrum guy to get back to they've gone back to their roots and it's awesome on that note um thank you everybody who's watching who's participating uh you're all out there have to do the hard work and i want to thank you of course our speaker so thank you jj thank you dave um and we'll be uh we'll be in touch with more questions for you both at uh at your company thank you everyone thank you trish bye-bye let's again take a moment to celebrate the 25th anniversary of scrum by hearing more of your scrum stories an agile coach at cognizant and passionate about scrum my journey with scrum began 20 years ago in 2000 when i didn't know what scrum was now 20 years later i have coached different types of teams in different organizations and what i see now is that scrum is really like a palette of colors each organization each team represents a different shade and more get added to it as the teams inspect and adapt so wish you a very happy 25th anniversary scrum hope to see more and more colors getting added to your palette and my journey with you continues it was december 2002 at the days of fighting in an arbitration it was finally over and i asked myself this question why did i fail it was a large complex enterprise project and we spent weeks prepared the perfect plan with all the details from and months of developing one stage by another stage it was a perfect waterfall and we end up being arbitration why months later my brother called me and said hey search for something called scrum and i'm like what can you spell it for me and that was around year 2005 or 6. since then all the teams are trained and coached we use scrum we deliver we deliver our customer love no turning back to father fall for me it's all scrums remember there are rocks at the bottom of the waterfall and they will hurt you my name is andrew lynn this is my scrum 25 story thank you thanks again to everyone who shared their scrum story [Music] let's begin our second workshop how the updates impact your scrum featuring avi schneier and don mcgrail moderated by kevin ball thank you tom and good morning everyone and welcome to the scrum guide update as mentioned we are talking about how the updates impact your scrum don good morning avi how are you good morning great what's up guys good morning a lot of great questions are coming in but i want to kind of kick off the conversation and ask you both a question you could respond first what would be the biggest challenge for people using scrum the biggest challenge for people using scrum i think happens really when they first adopt it i think that's where the biggest challenge is because like the difficulty is is that they're used to doing something one way and then all of a sudden they want to do scrum and they try to map it in a one-to-one fashion and traditional project management and running a team with scrum don't necessarily map one-to-one and so that causes a tremendous philosophical confusion for them and they're not quite sure how to proceed i think that's the biggest challenge that i i see is during the adoption phase when they are um already using scrum i think the the biggest challenge is their interface with parts of the organization that might not be using scrum or understand agile ways of working i think that's where i see that don um yeah well something that this uh this scrum guide hopefully um helps with is is that i think what they were talking a little bit about about it in the last session was the the lack of product vision you know we look at it as just time budget scope let's get to work go get our stuff done um and i think that's going to be the hardest thing that for people to get used to with this new version as well is like okay what's our product goal let's start thinking about this it's not just about getting all our things in the list done by a certain date are we actually creating any value and who are we creating the value for um that's just amazing yeah thank you down sorry i just responded some of the questions a direct question for you obviously you can pitch it as well you know what are some examples of the scrum guy being less prescriptive this time and why is that a good thing don why don't you go first for this question yeah i mean there's a few right um i guess the the main one is dropping those questions the three questions in the daily scrum right you know they're fine but you know teams have been doing it for a while they don't need those right to create a plan um there's lots of ways to plan your day and so dropping those is key because they became kind of gospel in a way um what else i think there was like a half a page around cancel how to cancel the sprint or what happens when you cancel sprint i think that's reduced to maybe a sentence or two um i think as well there were things around adding a description and estimates and value to a product backlog item all good things but you know a lot of companies we work with that just may not apply to their particular product backlog so a lot of that was kind of watered down a little bit and giving a lot gives everybody a little bit more flexibility i i agree with i agree with don totally i think uh the idea of it being less prescriptive is incredibly important when you begin to adapt to using scrum into multiple domains beyond it there are just different practices that are beneficial outside of that domain and if you if you have a guide that's very very prescriptive and you think you have to shoehorn yourself into that then you think oh well then we're not going to do any of this other stuff which was essential so we need to be make sure that the framework is open and flexible so that we can incorporate what worked before into what it is we're doing now again it's not going to map one to one but we've got to make sure that we keep what's good and then take advantage of using scrum so that we can really optimize our delivery of valuable outcomes for our customers and stakeholders is i think it's really important to know as well and make it clear that just kids are no longer in the scrum guide it doesn't mean it's not a good thing right one that occurred to me just now was was the um putting retrospective action items into the sprint backlog that was in the 2017 version great practice i love you know giving it that sort of attention um it's no longer in this one but doesn't mean you shouldn't do it it's a good idea but that's a team decision so there's still some good things yeah and generally you're really talking about you know a switch uh from not being really super prescriptive what's the best way for teams and companies to actually kind of adopt that and adopt that mindset because we had the previous guy some people did i would try to shoehorn themselves and now we have a little bit of different language in the next guy what's the best way to approach that well i think i think what don said uh as he was talking about the earlier session where it's really about what what should be your product vision which in our guide you know we're talking about the product goals i think it's really important for everyone to understand that when you're beginning the outset of creating your products or embarking on new projects that you are starting with some kind of a north star however you want to term it that everyone is aligned to that says okay that's what we're going for and then to use that specifically really to use that specifically as a way to determine hey when we're coming up with new work items do they align to this and if they don't this is a great time for the product owner to exercise that word no and to keep creating a line backlog for the team to do without being distracted in multiple directions yeah it's worth repeating it i think it's been said a few times already during these sessions is is still a scrum right um so getting into these changes these new scrum guide changes i would say that the people that were doing scrum and getting a lot of value from it not much changes at all for them um i think the big focus is for a lot of groups that are using scrum going through the practices but not seeing the value um and so you know a good teams always had a product goal you know they always had a vision whether it was maybe not written down the same way or maybe not as measurable as it could have been but good teams had that good teams had that flexibility good teams did work as one team um one complete scrum team so it shouldn't seem that different for teams that have been doing scrum for a while and and good teams also had rigorous definitions of done yeah so that's not you know it my favorite thing don and the new guide is how we're calling out calling them out specifically as commitments that's my favorite part i love the fact that the definition of done is now a commitment this is something you're going to do and the best teams always had it so if them it's not really going to make a lot of difference but i think the important part is that when we call it out directly as a commitment we're constantly reminding that if you you want to have work done and that it doesn't fail in a sprint or it doesn't fail after a sprint because you know a lot of people aren't aren't always so clear that scrum is just as much about quality quality work as it is about valuable outcomes but valuable outcomes that are functional yeah that the items you're making are functional so having that definition done in there as a commitment is really very important that we're highlighting that now as opposed to just kind of being a small section in the in the past guide now it's real we're really shining the light on that yeah and then avi how do we bake that in into you know our our our sprints for the week or the two-week sprint how do we actually bait that in to make it a permanent thing like you said and just before which is something that we wanted to do but now it's a commitment yeah so there's a lot of ways to make sure your definition of done is baked into whatever it is you're doing uh for some teams for example they're putting it inside whatever team working agreement that they have the team agrees this is the definition of done for all the stuff that we do and you know before before kovit it would you know sit on the wall with the rest of the backlog and stuff like that and i think the other part is they're they're listing it in whatever electronic tools they're using now they might be listing it in the items to say hey make sure this is done before we actually say that this is acceptable and then bring it to a sprint review for customers and stakeholders to see and give us their feedback yeah yeah the whole thing's going to be a lot easier right what you said obviously is now that there are these commitments what was definition had done before instagram yeah it's in there so it was that an artifact well sort of kind of almost in sprint goal is that an art well no not really um they were just sort of hanging out and um and and we we knew they were important we put them in place but for people learning this stuff it's like so what do we call this you know there's three artifacts there's three roles there's five events what are those two things they just kind of exist um now it's so clean right it's it's you in your sprint backlog there should be a sprinkle and and part of your increment is the definition done that describes how an increment is born right how it becomes one of my favorite lines in the scrum guide is the new one is uh something along the lines of the moment a product backlog item meets the definition of done an increment is born you know and that that sort of means so much it could happen throughout the sprint it's not something that we wait the end of the sprint for um and then with the new product goal as well as part of the product backlog these these things have have a home now and uh that's what really excites me it's going to make my life a lot easier john don you broke something really good which is the whole thing that that notion of once the dod is met definition of done is met the increment is born i think one of the things this version of the guide helps can help people to see better is that you don't just have to deliver once per sprint at the end at the sprint review but rather this fits a lot more in with practices known as things like continuous integration and continuous deployment which by the way don't just apply to software you can deliver hardware or services or any other kind of product multiple times a sprint it's not dictated only once at the end and i think the wording in the previous scrum guide kind of made people feel that it was whether or not that's true or not but it made people feel that it was but in this guide we're really talking specifically about hey you know what you know you can you can keep you can keep pumping it out yeah one of the lines is as well um don't let the sprint review be a gate to getting things in the hands your customers are releasing or whatever they whether they say for that but um yeah they're really because you're right it's a it's a it's a horrible myth around scrum is that we gotta wait until the end of the sprint and that that's never been the case it really takes a question really good points so um we have a lot of you know people watching and listening to us right now some people just getting started some people have been you know doing this agile entry for a long time just want to just clarify one question that's coming in the product goal will be set by the product owner exclusively and or by the team let's kind of clear that up for some people who are might be new to this so for the the product goal um so i i'm i'm looking at how i've been using i've been using something similar for for a while with my teams you know i played the product owner role a lot and um i mean i guess my my accountability was that product backlog in the direction we were heading in so i kind of like looked at it as my i'm responsible for making sure there is a product goal and that it matters and we're moving towards it but my responsibility was also to hear my team and and get them bought in on this product goal i want them to be excited about this i'm constantly looking for ways to explain the product goal in a way that makes clear who we're doing this for whose lives are being improved by the work we're doing and then i always had it as my mission to can i get my team to meet these people at least once a sprint maybe more and and that was probably the single most important thing i could do to motivate the team is is making that very very clear so a vision for sure but then this goal i think as dave and jj were talking about earlier it's going to be a more measurable way between and you could have multiple goals on your on your way towards this inspire aspirational vision right um so in that sense i put it on the shoulders of the product owner a lot who has ultimate accountability of the product goal um and but that's me as somebody who's working out there as a product owner um i absolutely see it as my responsibility you know don you bring up really good points there and kevin i think i think it's it's all in the wording right when we say who's supposed to make it and don brought in that word accountability which as you know is a big change in the in the scrum guide as we are now calling product owner scrum master and developer accountabilities so when you ask who's accountable it's product owner right they're accountable for making sure that product goals exist but who makes them well i think that really comes down to who is the product owner speaking to that wants this thing or these things that the team is going to make product goals should be coming from conversation and collaboration with those who want them now what don brought in which is interesting is about well what about the team and the answer is well that can happen too for example if someone came to us and said well my product goal is that pigs should fly my team when i bring it to them might say that's awesome but i don't know if we can make that happen right so there's got to be some kind of a a reality yeah right exactly there's got to be some kind of a reality check that happens with the team as don says by getting them to want to participate not just buy in but want to participate in making this thing and achieving these goals but there's also got to be an understanding between the product owner and the customer or stakeholder that's asking for this thing hey this is what we want and it's all about you know if you really boil it down kevin scrum is all about having really good communication really good lines of communication between those people who want the work done those people who interface with them and then the folks the awesome team of developers that are making this thing if we can get those lines of communication open transparent and traveling then we'll end up with really great product goals that are achievable in certain you know in time frames that are amenable to the teams actually being able to do it you know in real life and it makes everything better it just makes work so much better when you do it that way yeah that word uh accountable is really powerful um i think that can resonate with with everyone you know don and avi and you know sometimes we will look and read words and say well i think that's this person's job or role i think you know that doesn't belong on me but it is a collective team from the product owner the scrum master and the team itself um delivering that value right don so let's i want to dig a little bit deeper on that since that is a new word or a different word that we put into the scrum guide as we look at 25 years of celebrating scrum right we have this new scrum guide that this has just been released and we look at that word accountability when we read the guide with all these folks in the industry and these teams they read the guide how would we suggest that they look at that and incorporate some of these new terms into what they're doing and their work on the ground every day yeah so um it's a discussion that people get into all the time over beers accountability versus responsibility um i guess the way i look at it in the scrum guide seems to align with this is accountability is ultimately it's it's on it's on me right if i'm accountable this is this it's on me now if i have work with a lot of people i trust i can assign responsibility they can be responsible they care for this they're gonna do it but you know it's it's really about me so there's a few now we've kind of made it pretty clear in the scrum guide now the latest one is the product owner is accountable for the product backlog now does that mean they have to write up all the pbis and acceptance criteria no absolutely not they work with people they trust they can delegate a lot of the responsibility um but they're accountable and the scrum master is accountable for scrum if scrum's not happening or we're not following the things we said we were going to follow as a team like even the process that we all came to greet with that we all agreed to this the scrum masters accountable for that um now they're not doing the work but they're accountable for the success of scrum in that sense so we in this scrum guide it seems to be very very clear that there's a separation there they've used the word responsibility and they use the word accountability uh very very clearly where i think before it was kind of all over the place absolutely absolutely there's one question there's one one person out here is saying you know he absolutely likes the idea of introducing the product goal right it's just that they're still struggling a bit uh as it sounds somehow determined and they certainly they can fulfill or abandon you know abandon uh an objective my thinking is i can also adjust it how would you respond to that abby yeah so listen in scrum it's it's interesting you know nothing's really written in stone as you can see with the scrum guide we've got so many iterations since it first came out we're always amenable to changing the guide and the same thing has to be for our own product we've got to be open to learning from experience the the root of why scrum works is it's embracing the notion of empiricism or empirical process design which is that we're going to take what we learn in the field and then inspect and adapt and apply it to whatever it is we're doing next and my answer to that is you have to be open to being able to change it but you couldn't just start you couldn't just start scrumming on something without having a product goal because then well which way are we actually going you got to at least say hey listen let's go this way if we we know that we've got to be open to changing direction and pivoting is a common phrase we hear in the land of agile if evidence shows us that we're going in the wrong direction but we still have to pick a place to start we're still to pick a direction to start all right avi are you saying that we should have some kind of a north star when we set ready to go we should have something that we're that we're gravitating towards absolutely this is what product goal product vision this is what these things are about but we've always got to go into changing it i beg to differ a little bit in terms of like there's lots of teams that start without that and what they end up doing and maybe a lot of people see this out there and maybe it's in their own scrum practices is we just look at whatever the customer is complaining about the most right what's in our email inbox and it's just this random smattering of stuff and there's no clear sprint goal like never mind a product goal um there's always stuff to do and they they enter sprint planning going okay what's the latest complaints let's put them in there i'll take this you do that and then away they go and they're just kind of wandering around aimlessly um the product so it's starting scrum right the product goal is essential yes yeah check out this comment that i'm reading live right now from our questions from a quick initial scan i really like the new scrum guide need to go over a little more obviously but it appears to have a lot of clarity and a more forthright in the older version congratulations folks now this is some this hot news that's coming in right as as we're speaking today so the guide is resonating with folks avi and and uh there are some things in there some some new words and we often hear write down obviously words are really powerful something's written in snow we're reading it on the paper but i think we're also saying too we have to be able to inspect and adapt and and use the guy that's going to really be best for us yeah i think the i think the right words might be it's written in stone for now yeah we had we had as don mentioned we had three questions that we said you had to answer the daily script that the daily scrum that was written in stone for then now that seems to have disappeared another great example of a change inside the new scrum guide for example is the topics in sprint planning right we've now we now have three instead of two so we're and again as don mentioned before it's it's not that in great scrum teams they weren't answering all three it's just that that wasn't listed in the guide so now we're talking about the why the what and the how and it doesn't mean that the y was missing before many teams were always talking about the y and that's that's one of these big phrases right you hear in agile all the time right start with y start with y and now we're just reminding everybody that that's the best way to start that we know at this time because it helps to get everybody on the same page as well as get everybody motivated when you know when the scrum team knows why it's doing what it's doing it tends to be able to do it with much more gusto which much more zesta yes that's we want to help achieve that and i think that that's another great change in this edition of the guide awesome don no i mean i i totally agree um the the um the other big one is is the whole i think probably the most controversial probably what people are gonna have the uh hardest time with is there's no more development team i guess um and now it's developers and and the the thinking behind that is is we're trying to what we see all the time out there is this sort of this anti-pattern where um you know stuff comes to the product owner and the dev team sits and waits for the park learn to do just amount of work the right amount of work if it doesn't meet a certain definition they throw it back at them and um they're focused more on okay what does the product your it's your call product owner whatever you want product owner um and and it was kind of an awesome them not that it was ever meant to be that way but that's how so many scrum implementations went it was a sort of a hierarchy that ended up happening or even worse the development team had to speak to the scrum master who spoke to the product owner who's likely a proxy to speak to somebody else so a change this time around was to help kind of solve that which is we're just one team there's no team within a team we're just one group of people that are passionate about this product and trying to achieve the product goal we're all in it together any one of us could talk to a customer like how do we get to that situation where we're trusted enough to just go talk to the customer we're all thinking new ways new things new opportunities ways of pivoting we're all in it together that's going to be tough um it is just kind of one group of people um all focused the same way you know i think it's interesting donna and it's interesting because and i think it wasn't necessarily not a problem before i think we've seen that problem for a long time that uh people were confused about whether or not a product owner or scrum master that these were titles or roles and we had spent a lot of time in iterations of the scrum guide and i know you and i both train quite often a lot of a lot of folks and they have a tough unders a tough time understanding what's different between a title versus a role and now the word role has gone and we've gone to accountability and this of course now as you said now eliminates the dichotomy of two teams a team within a team it's one team and people on that team have accountabilities i think the least often or most missed line in the whole scrum guide is that it says the product owner you know is accountable for these things or may or may do them or may delegate it to someone else and this is an important understanding is that product management no longer belongs to individuals the product you know the project manager this or the product it's it's a it's a collective ownership the team owns this and the product owner fulfills these accountabilities and may delegate some of that work to someone else on the team and i think that that's a really important distinction now i think that that might make it tough for folks in traditional business who are looking for well what do i put on my business card now account i'm in accountability i don't know exactly how i'm supposed to term that that's something that we're going to face as we go through inspect and adapt and help people decide or understand that just as it was a role before it's still it's now a set of accountabilities these are your obligations to the team in order to fulfill the team's obligation to our customers and stakeholders that want great stuff you got me thinking that it's it's just it's another example of being less prescriptive right scrum doesn't tell you what the titles are in your organization or the roles even right so it's it's these are some accountabilities who makes the most sense within your team your organization to take on those accountabilities um so it now works with without having to change all of those things it's these are accountabilities who's taking them on um i think that again it's less prescriptive because of it you'll have somebody with a scrum master title oh you can't do scrum right well the the scrum guide is not saying that you have to call the people on the team developers that they now have to have business cards right if you're doing scrum and marketing nobody's expecting marketing people to suddenly have a business card that says marketing developer that's that's not what they're gonna have and that's totally okay we're saying that there is there is a set of accountabilities for those folks that are developing these amazing solutions that we see in the market all the time it's an accountability it's not a title it's what you do it's not who you are right you know it's interesting i mean that you say developing whatever it is it could be a process it could be a product right whatever we're developing the question that's coming in right now which is really interesting kind of a different slant and once you respond to this you know does the removal of the development team strip protection from them and encourage the po to step over their boundaries really interesting question of how they phrase that i mean you know we're also kind of talking about the scrum raster role in terms of you know protecting the team or we're not saying well we're staying more accountable now how would you respond to that that question that's coming in the feed you know for me i would say it actually makes it more it makes it more level right where as don said it's not it's not creating a hierarchy or creating a chain of command and a communication pattern or flow that has to be followed it's actually making it more open it's making it more collaborative it's making it more group owned and unified so i would actually say no i don't i don't i don't think that's going to happen i certainly hope that that doesn't happen and i think that the team sorry um i think the teams that take that stance that we have protection in scrum i think there's deeper underlying issues there anyways that we've got to fix so i think what this will do is make it even more transparent so i mean what are they we're now now that they are you know there's one team one scrum team that this one person with the accountabilities of product owner will will bully them into doing things they don't want to do i think that will become more obvious and they have to work it out just like if there's one person on the old the old version of the guy the dev team that's that senior and bullying people one way or the other or making people do other things you know they got to figure this out their team of adults um and and and let them work on it right so we want to just bring them together as and respect them as a team and and they'll work through these things that's that's the way these healthy teams will operate yeah so it seems like gentlemen you know the the the mindset of really having that team approach having that team energy developing that team culture is going to be really essential to really driving this accountability we're at home in terms of the new scrum guide right yeah and i i love uh and it's not like it wasn't in the last guy but i love how we're really enforcing and really you know talking about the values so much because that is where the that is the root of the culture right is the culture is really the sum total of all the actions of the team but what underlies those actions and it's got to be the scrum values and we really have to and i know i know don and myself and kevin i know you too because we work together i know everybody out there who's been on this call we're we're all pushing the scrum values as much as we possibly can especially in companies where it seems like their actions tend to be contrary to that and so i hope the guide i hope those that read it can really try to use this as a way to shine a light on the fact that if you want your scrum to function optimally you've really got to live by these values you got to make them come to life it's really really essential does it mean you can do scrum without it i mean we've all worked in companies don i'm sure you have too where a lot of these values were stepped on day in and day out but how good did the scrum work probably not so well whereas when we when we can really get a group of individuals and even larger groups of individuals to embrace these values to work their teams through them to really make them come to life the the the potential of what the scrum team can do becomes unlimited yeah but we have about 12 minutes left in our segments we're going to end this at 12 15 eastern if we kind of juxtapose the the previous scrum guide it was released in 2017 we just re-released today and just just follow me here so if we were to merge those together what kind of falls out and what should we really be kind of like holding to our hearts and really pushing us forward as we continue our transformations and new teams that we're standing up in companies people who are really veterans in this what what are some of the key things that we can pull away and pull us forward in our organizations um i i mean i guess the first thing i always go to is how it is it is more inviting um i work like probably the top our top clients that are going through agile adoptions right now um they're the top three are not software for the most part right there might be a few here and there um but they're they're in all sorts of industries uh procurement to pharmaceuticals to you know working on oil rigs right that kind of stuff and when we'd work with them and then point them towards the scrum guide they'd say things like well you know it doesn't feel like it's quite for us and then my response is what do you mean the word software doesn't show up in it at all you know search for it but it did have words like you know system and uh testers and things that were kind of conducive to that or even the word release it just it doesn't fit right there right and now it's it's working it can work for anybody reading this we've we've seen it it's it's proven that this is well beyond the it industry certainly software um and a lot of people are getting value from it so that's what i'm excited about and i think that's the way i'm going to tout it i suppose if if i asked by my customers why should we go to the next chrome guider well there's you know that marketing team that you're trying to get stuff from and they're running into issues that are feeding you things well maybe you can they can apply this stuff too or that operations group or or the the auditors that are doing all the compliance stuff like maybe they can get value out of this as well we're all trying to do these complex things now it's more accessible i agree with don totally i think one of the most important things that i would distill out of it as you said kevin is the notion of increments the notion of delivering incrementally and iteratively it doesn't matter what it is you're making it doesn't matter if it's a product a service it doesn't matter if it's a project it doesn't matter if it's hardware or software it doesn't matter if it's operations procedures or or human resource procedures people operations as we we tend to call it what matters is that you're putting something out that you can show folks get feedback and inspect and adapt for the future because the the most of the dissatisfaction that we see which is why a lot of people switch from traditional project management to running things in an agile way with scrum the point of it was that when they would get the thing out at the end they were dissatisfied so for me i would always keep holding on to the fact that this guide still enforces both of them still enforce this notion of we need to deliver incrementally and iteratively in order to really delight our customers not just answer some some set of a big set of document requirements that we were handed on day one and here we are 180 days later and so much has changed and we didn't take any account for that we want to be able to show our customers constantly that we're outcome driven and part of understanding what your outcomes are is that your outcomes may change during the course of development and we're going to welcome those changes and we're going to accommodate for those you know everyone to make an interesting point what makes me think about hey you know the first scrum guy what over 100 pages now here we are in 2020 is 13 pages so what's happened in industry and business you know across the planet everybody's getting better right we're delivering more we do it incrementally and and don you said the word you know more inviting and ivy you use the word more welcoming as we think about organizations and teams that do it from the grassroots level or people who do it more formally right or that one single person in the organization's like you know what i read the guy you know i i i'm gonna really try to do this thing on my own or or his leadership gonna you know take the reins and do that what i just said grassroots formal single person doing it leadership and we think about being accountable and delivering incrementally and being welcoming what would you say in the last few few minutes to all the people who are watching us and who probably watch this recording later the best way to approach that well um i i think we hit on a lot of those there's there's something i guess more specific that's worth addressing i think that can hit on that is is the term developers you know that that's a tough one sometimes and they may not see that as welcoming um so i think the way we look at that word and because i've had to wrestle with that myself um interestingly i was i was part of a a group a while back that that dealt with this problem which was hey we've got we've got development team we want them to be one team not a team within a team but what would we call we have the scrum master accountabilities we've got the product owner and then what about everybody else what do we call and try this exercise for anyone listening go through it grab a group of friends grab some beers and go through it what would you call them these are people that are across industry focused on quality building something of value um at least once a sprint hopefully more what would we call them and we went through lots of words i don't even want to go over them all right now i don't want to create any kind of conflict or that that word would have been a lot better but try it i mean there was issues with each of them the only ones i find the only industries that have a problem with the word developer is interestingly enough the uh i.t one i heard this from dave west actually because and it's true i've tried that with a lot of them when you're when you're in a marketing group developer could mean you know we're developing marketing material um if i work in a pharmaceutical company developing means something different um then it's not doesn't necessarily mean programmer so it is using the word developer actually helps this guide be more welcoming more open to lots of different industries it's just us and it have to get over the fact that when we say the word developer we don't just mean programmers it's it's anyone that's focused on developing a valuable increment i think part of the guide that's welcoming so to speak is just the framework itself and you know kb we go through a lot of implementations where people are like almost afraid to adopt scrum they're afraid that if if we take this class and we're doing it all week and this and that that on monday everything changes like if you're working for example with a consumer package goods company like i do that for some bizarre reason on monday we're not going to be making uh awesome beer or fantastic desserts that we that we sell around the world and we're not going to still make tons of money and have great valuable outcomes for our customers no you're you're still going to do that on monday it's still going to happen everything's still going to be okay the difference is how we go about it right the beauty of the scrum framework is that we formalize all of these processes around creating goals and planning and checking in and having our sprint review in our retrospective we formalize all of this so we can operationalize the learning that we get and i think if we explain it that way for those of us that are out there teaching this stuff day to day for those of you out there that are living this stuff day to day if you can explain it that way you are calling everybody in because everyone's doing all these things anyway but they don't necessarily do it in a way that lets them constantly improve right we always remember where did all of this stuff start from where did all we learn continuous improvement is is at the heart of scrum and if we remember that and remind ourselves of that that's a way to call everybody in because nobody wants to keep going and not doing well or not getting better that's not why people go to work they don't go to work to fail on purpose or to never improve where all of us are going to work to make better things to make people's lives better whether it's working in healthcare like like we've done or whether it's or whether it's making great products that we sell in the in the market so if we remember that that's the heart of this that will help call everybody in that this is about continually improving inspecting and adapting what it is we do every single day and gentlemen are you saying that this definitive guide to scrum the rules of the game that just got released what everybody's reading right now and listening to us speak on this this wonderful webinar is really a good way to implement some of those accountabilities and be more welcome and inviting as we go on the ground to deliver really good stuff for the world is that what you're saying happy and done absolutely it's a good place to start right um what do what are the requirements we always we always give a prereqs for our classes read the scrum guide read it read it and they're going to read it but you know it's going to i i've read this thing different versions of it countless times and every time i read it it's something else right and you get with a bunch of other scrum nerds like me and and we we we pour over it like it's the constitution what did they mean by this word and it's just at the end of the day it's just a document um and it's a better document now and i i think it's good but scrum isn't the goal um the goal is the values or building awesome products and improving people's lives that's the goal these are a bunch of things we can do to get better at that and in my company we've we've been building products for a long time and we've tried a lot of different things in the bet we keep coming back to scrum it's the thing that's worked best for us if something better came along no offense can jeff we'd probably jump ship we're here to build value for our customers and um scrum is the best way we've found to do that and and this guy does this start i mean don't forget about the values like avi mentioned um i would take a team not doing scrum but folk that that had that instilled those five values over team doing scrum that had not it's these are tools that can help us and get to those values and and that's what's the key thing to me it's just a document yep 12 14 one minute left super close remarks he and avi i just want to say thank you to ken and to jeff for giving us this document back in the day and also for the iterations that have come since then i know that scrum has made a huge difference in my life and the life of those that i work with and in so many people that i meet tangentially to this and it's just it's amazing to just see the impact that this has had over the last 25 years so to both of you thank you so much and happy birthday to scrum absolutely yes happy birthday scrum and uh and i i really appreciate being a part of it so i've got a huge passion for scrum i i first encountered it in 2003 and i never looked back i was a contributing member of a team i'm like i want to keep doing this and whether they asked me to or not i i did it uh we called it covert scrum back then and and uh now now you're seeing it's a huge it's very much different it's not just a team or a little department it's whole organizations get this and are bringing this on so happy birthday scrum um here's to another 25 years absolutely don avi thank you so much ditto on everything you said today all the folks who are you're bringing in your questions and your comments we thank you so much uh ken schwaber jeff dr jeff sutherland thank you so much that ends our statement for today thank you gentlemen thanks guys everybody throughout this program we've been sharing some of our favorite scrum stories from the scrum and agile community but what about jeffs or ken's yep we asked them too and here is what they had to say you know i remember we're sitting in lexington the pete's coffee shop was sitting outside the bench and you said to me you know how come people don't really understand we're on a mission we've been on a mission to change the world but i've always felt we're kind of like the blues brothers you know you never know what you're going to run into some of it isn't some of it is not pretty [Laughter] deals like the blues brothers um i i'm just very pleased that we got it but it is it has been a mission otherwise i don't think we or a lot of the people that joined us as we um met and shared this would have kept going yeah the the big thing it did is people went home um if they went home um after having worked on a scrum team and they felt satisfied and they felt empowered they didn't feel beaten on it they didn't feel like um life and work was a terrible thing um and i do hope i haven't seen that spread as much particularly i'm looking toward washington dc but i haven't seen that spread as much as i was hoping but it is spreading life is fun the thing that's meant to most to me is that people have taken it and somehow they've taken a little bit of inspiration that we've given them and they come back and they say you know scrum has changed my life and they have a real sense of gratitude that things are better for them for their family for their work for their business it's very satisfying the the thing i've had to hold back on is to remember they changed their lives yeah absolutely all we did was kind of like whisper in their ear and off they went yeah thanks to everyone who shared their scrum stories you can still share yours just use the hashtag scrum 25th in your post time now for our final session questions answers and closing thoughts with dr jeff sutherland thanks tom for setting this up uh we really appreciate the help from all the people that have worked on this guide this has taken over a year a year ago we wanted to make the guide less prescriptive for everyone not just software developers still based on all the empirical evidence and the empirical way of working in scrum but the first iteration of that a lot of people didn't like we had to go back to the drawing board then many months later we came out with another iteration and there there was still people that didn't like that one so we had to go back to the drawing board again and involve many different players in many different organizations until we could get to one scrum guide that everybody could generally agree this is this is the best we can get right now and it's lighter it's easier to read it's more concise that it's actually more tightly coupled so you know i hope it is actually clear and i feel much more comfortable in handing the handing this to a sales team now than the more software-era guy that we had in the past so our hope as always is that this will enable people to really have a much better way of working uh and and build much more successful companies and in in this covered time the ability to work remotely and be agile has separated the pack we have companies whose stock has exploded in covet because because of their mostly agile is mostly scrum because of their scrum and their agility uh they move quickly way ahead of the pack where thousands of less agile companies are going bankrupt and continue to go bankrupt so that that makes all of you doing scrum critical to the survival of your organizations you know last year it used to be nice to be agile this year it depends your company depends on you to stay alive so it's a big responsibility and i i think uh with this guide it's going to give us some leverage to step up to it even more quickly by having it more simple and easy to understand i know there's probably a thousand questions uh zoom doesn't even tell me the number it's all it's more than 100 out there we know that and tom is sorted through them and kind of popped the the most often asked ones to the top right so tom you're going to help us with those questions i'll be happy to jeff and i just want to say first of all congratulations to you and ken for the 25th anniversary of scrum i'm sure i speak for everybody here in the audience when i say that the world is a better place for what the two of you created and have rolled out to the world so i do want to say thank you for that and uh you're not far off actually if you go through we're we're nearing a thousand questions which is pretty good so i am going to try to couple these together i'll be summarizing and looking for big themes so i apologize if i don't get the questions exactly as you worded them but we're trying you know in the interest of efficiency we're trying to make sure that we can address the questions more broadly um so jeff there's been a number of questions about the scrum master i'm going to start with this one the new scrum guide says the scrum master is accountable for the scrum team's effectiveness in what ways do you see the scrum master doing this differently than in the past well i think the the intent is the same as the past but as we were beginning to put this guy together ken said to me i think the biggest problem in scrum is the word servant leadership and i said why he said because many people have interpreted that as they don't need to enable the team to improve and they're not responsible for that improvement and we have many management teams saying you know we're paying these scrum masters a lot of money but they're just secretaries why should we why should we pay them and so we said we got to do something about that because the scrum masters livelihood depend on them being you know really valuable contributors to the to the community and how could we fix that so initially ken says let's just take servant leadership out of the guide and then many of the coaches actually that are in this in this conference today say no no no we can't do that so then we we thought about it we said okay you know really the problem is that the scrum master is not doing the leadership part of servant leadership so so let's just reverse the words it's still the same thing but the leadership is front and center so it's something that has always been important but as always when we update the guide a little shift in emphasis gets people more focused on the most important thing so scrum masters are now leaders who serve instead of servant leaders and some people will wonder if that is indeed more than just a reordering of those specific words and in prior conversations that you and i have had there is a bit more to it than just a reordering what is the difference between a leader who serves and a servant leader well you know i always go back to the models that i have in my mind when we created scrum one of them is what toichiono did on the toyota production line he said we're going to eliminate the manager or the foreman that general motors has and we're going to put a facilitative leader in charge and that facilitative leader will know every job on the line and we'll be able to train every person on that team and then we'll actually help them do the work okay so that's one time type of leader who serves another model has uh has been you know the the the great scrum teams in in rugby uh were always uh an inspiration particularly to the early teams in scrum and the the captains of those rugby teams were legendary i mean uh you could see that in the movie invictus when the when the south africa team beat the all blacks you know the president of uh south africa called the captain the rugby team to the mansion and said i want you to win against the all blacks and the whole story that unfolds then how that team captain figured out how to beat the all blacks that's what a great scrum master is okay so that's quite different than just taking notes at the daily meeting right so we want to inject that you know that feeling a sense of mission that you know not that you're going to tell people what to do but you're going to talk to the people and explain the importance of what we're doing create inspiration for the people and then you're you're going to get out there and take blows for your team that's what a great team captain does right they're on the field playing alongside and they're often the first people to get hit really hard okay and because of that people follow them and that's the reason the south africa team won against the all blacks so we we would like to see many many many great teams like that and we have in the world of scrum we've seen some amazing teams that have exceeded far exceeded any expectations teams that have done what i thought was impossible another aspect of this jeff sticking with scrum masters and leaders who serve is that the scrum master is not just focused on team in this new updated 2020 scrum guide there is more of a focus on helping and coaching the organization as a whole can you walk us through that yes and this is because from the very beginning you can go back to the work of uh professor taking china even even today taking tanaka are our mentors and we're constantly talking to them uh and nanaka has always said that that that frontline person is a catalyst for organizational change and to be the catalyst for that change they they they manage down and they manage up is the way that he would frame it so if you're going to do a nanaka scrum which is you know the scrum that i've always tried to teach then the scrum master has to you know deal with the management as well as facilitate the team that they both go together um so that's a big job and a lot of new scrum masters you know what they have to have a lot of learning and coaching before they can actually do it well but if they set that as a as a goal to move towards we'll have much better scrub and much better scrum masters okay i'm going to move on to another question and i quote i have seen some people interpret the guide in a wrong way and they have the product owner and scrum master as the same person and they ask us to clarify but i'm going to put a little twist on this on this question in particular because clarifying the scrum guide getting rid of misconceptions has been a major focus of yours and ken's in this new updated 2020 scrum guide correct yeah and that particular issue that you brought up and earlier some earlier scrum guys we said the product owner and the scrub master couldn't be the same person but um certainly in 2017 maybe the guy before that we remove that restriction we're still pointing out that that's that could be a problem the product owners and the scrum masters have different agendas but we took it out because we saw on some small high technology team you had a leader who was like a chief engineer at toyota who was who who really understood both the technology and the strategy and for a small team was able to manage manage those roles um and we still don't recommend it i mean even a two-person scrum team that i coached that went public and retired in two years i said one of you guys needs to be the scrum master what do you guys be the product owner even though you're both coding like crazy because if one of you isn't worried about making some money you're gonna run out of money and if one of you isn't worried about fixing what's broken committees don't fix things well right so that's what they did and that i think was one of the keys to success so another big theme that we saw were questions about changes in the daily scrum in particular the three questions you know we had the the classic three questions that we all probably can recite by heart why did those go what's the thinking well in 2017 we we made the questions optional and the reason for that we saw teams using other uh techniques that were were quite effective and we also saw a lot of misuse of the questions you know for some teams it was just a status report you know i worked on this yesterday i'll be working on this today and i'll i have no impediments and there's no cross-collaboration one of the best daily meetings i've seen we published in a paper called shock therapy and scott downey was a great coach and he decided that it was it there was only going to be one question of the daily meeting is that was why isn't the first story done and how do we get the maximum number of people on this team getting that one story done now as soon as that question was answered the daily meeting was over he got everybody going twice every single team 100 double productivity within one or two spreads and we're going five times as fast within six sprints one hundred percent of teams going five times as fast by actually asking one question in the daily meeting and it's because it generates the pattern that we call swarming okay it generates the dynamic that that needs to come out of that daily meeting to really make to get powerful results for the team so this less prescriptive approach is actually created to allow or implement it rather to allow for more flexibility for teams to be able to adjust and adapt in ways that they need right and also it gives the scrum master more more focus on the scrum master and he used to provide leadership and creativity on how to set up that daily meeting he's not just following a rules list right sure so another big bucket of questions that we saw and i want to thank our earlier panelists for addressing many of these but i still think it's it's worth a bit of a conversation about are these new commitments each of the three scrum artifacts now has a corresponding commitment walk us through the commitments for each artifact and why they're there how they help okay so the the the sprint goal has already been there always been there and an example of why that's needed i was in silicon valley working with a hardware software company building mobile devices and multiple teams building this new operating system for this new device and doing really well uh going really fast and i i was in palo alto and they called me up one day i was working somebody's out they said jeff the productivity of all teams was cut in half last sprint come on over so so i go over there and i get together with the product owners the scrum masters and the management and i ask them well do you want do you know why that happened and everybody said no so i said okay let's go out and we'll interview everybody go out and interview one or two developers and then we'll come back in an hour and figure it out well when we came back they said the backlog was not clear to the developers it was just a bunch of tasks they had no goal and so it's summertime and the surf is up they're all leaving early to go surfing and i thought you know these developers they're really smart developers in these companies and they're like racehorses you know if the gate opens and there's not another racehorse running the racehorse doesn't run and i said this is really a really bad problem because the best developers are the ones that will not run if there's no goal so we absolutely have a goal so what we did is we fixed the backlog and we said the goal of the next spread is to make this mobile device run 10 faster we have a performance problem so everything in there a lot of different things is all to try to push speed boom the productivity of every team double immediately in the very next sprint so once that became really clear to me like we had to have a sprint goal in the scrum guide so it's it's just as important today as then uh and we also really wanted commitment to that goal you know we de-emphasized commitment to getting 59 points in the spread because the managers were weaponizing the the velocity data you know if you got 58 points that were beating the teams up you didn't meet your 59 points so we said we we got that out of there okay it's a forecast what we want the team to do is to commit to the goal but it wasn't as clear as the last guide as it is in this one so that's the sprint goal the prodigal we got complaints and uh it was particularly one of the german trainers who may be on the on this call said you know the product owners we have in germany the biggest problems they have they have no vision of where where they're going and even though the word vision was in the guide uh it's a big problem so i talked to ken about it and his feeling was you know we need to make it concrete uh how do you translate that into a practical reality and he said okay we have a product backlog it's obviously designed for to achieve a larger business objective but that product backlog has a goal and the team needs to be working towards that goal even though sprint to sprint they have smaller sprints goals they need to add up to the total goal and if they don't understand that that direction they don't work as well and they don't deliver as good a product so we've elevated the goal to a major thing in the guide and we said the product backlog itself is related to a goal and the team is to conv is is achieving that goal that's their commitment now another story about this that's really important i was in a venture capital group i work with venture capitalists a lot investing in scrum companies uh and we had a panel in boston we asked them do you invest in lean startups and every single vc said no and people were stunned why not and they said because we invest in really smart people that are fanatic about achieving a goal and they will work on it for years without deviating and the only reason they pivot which is a useful concept of lean startup is it's like trying to cross the ocean and the wind is coming in a different direction so they will they will tack but they're they're fanatically focused on a target and they said that's where we make all our money so we don't invest in anything else so that again told me the vcs have figured out the product goal is the most important thing everything else is secondary um done again is something we've always had in there and uh it's always a definition of done to be clear definition of done has always been a huge issue with the scrum guide in every single guide and so uh but and the increment has has been important too but it really hasn't enough it hasn't had enough focus because we find you know the industry data shows 58 of scrum teams can't deliver an increment they're late at the normal budget customer is unhappy so this is probably in my view the lead the biggest problem in the industry is that people can't deliver and so i think by saying okay the definition of done the commitment that is tied to that increment is that as the definition of done and that increment is done gives that issue more force uh than it had before so i think tying these things together gives more push in the right direction uh in people's mind which is always the goal of the scrum guide and and every scrum guide kind of tries to correct a little bit the misperceptions you know everybody's going off in this other direction oh servant leadership means you know i just take notes of the daily meeting i'm not supposed to i'm not supposed to tell anybody anything no leader who serves that means the daily meeting those people are coming out of there they're swarming to get stuff done and it's your job as a scrum master to figure out how to make that happen so another thing that we're seeing in the questions that still keep popping in is a number of people who have noted that scrum teams are now self-managing when they in the last iteration of the scrum guide were self-organizing and i know this is particularly important to you jeff walk us through what that means okay so this is probably the third biggest problem in not just at scrum in any agile practice anywhere because you go into i ask people every time i'm in front of a group i say okay raise your hand if you have an agile developer in your organization that thinks agile means they just do whatever they want 100 of the hands go up so that means these people these people have taken self-organization and they've weaponized it to serve their own personal interest at the expense of destroying the product i mean that's it's a serious serious problem so the the the reason that self-organization is in there is it it comes out of complex adaptive systems theory where an intelligent system when it runs into a problem itself organizes to achieve a goal right so now we've got the goals front and center and so what do we do with self-organization well we said okay you're going to self-manage to achieve the goal that's what self-organization is in a complex adaptive systems theory the system is self-managing to achieve a goal so we're hoping that's going to solve the problem of uh you know let's let's look at an example that you know it's publicly a very large company stock price you know went like from 50 to 5. in that company we had audited a thousand developers we had we found out 300 of them were agile developers doing whatever they want within six months they had to lay off 400 people and the stock goes from 50 to 5. okay so so this is not just a minor problem okay this is people's jobs are at stake uh companies are at stake particularly now in covet people really need to work together to help make their organization successful so that they continue to have a job and can feed their family because right now there are a lot of people that have no job and so if we can build better companies and scrum is a fantastic tool for that we'll have more things for people to do that can benefit their families so i want to move in we've got about four minutes left jeff i'm gonna move into another question uh a sharp-eyed attendee asks this how important is lean to good scrum i notice lean making a debut in the updated guy and then of course he goes on to thank you and ken for your work so it is indeed true lean the word lean makes a makes an official appearance in this guide how important is it with doing really good scrum okay a few years ago uh senior manager actually general manager of one of the biggest companies in japan flew to boston and he met me for a beer and he said jeff i want you to bring scrum to japan i said there's already a scrub in japan you have trainers there he said they're not teaching the true scrum i said what's the true scrum he said the scrum of professor nanaka and takeuchi the scrum that's in the paper where you got the name scrum 1986 harvard business review new new product development game that is a paper about lean hardware companies one hundred percent of the of that paper is lean hardware companies and taking not to describe how the teams worked and they it reminded them of the game of rugby so they they said they're working so closely together we're going to call that scrum now the senior manager said my company is owned 20 by toyota we are going to be the trainers of toyota we have to bring a scrum into there that is actually better than lean and what they're teaching now doesn't work and he said not only that we want a joint venture with you company uh which today they they are the majority owners but uh we own part of it and we are the trainers at toyota for toyota research for toyota i.t and lean is is a central piece of our training and i teach i we always taught that in all my scrum courses so you know right now i'm thinking there's really four components if you're going to win to a company like toyota and you're going to elevate the best lean company in the world you need the scrum guide you need lean prints tools and principles you don't need everything but you need some fundamental lean tools uh single piece continuous flow which is really the basis of the pattern swarming so what i've done is put into these patterns uh these kind of things so the patterns are extremely important you cannot get people people tell me oh patterns are optional okay these eight patterns if you don't have them you will never get a team going five to ten times as fast in your lifetime and some people still argue to me but nobody's been able to show me a team that's going 10 times as fast that isn't implementing these patterns so the guide fundamental lean principles the patterns and then scaling needs to be part of the training today because what's happened is uh scaling in frameworks i think this is even published in the scrum at intel scaling frameworks were introduced and it slowed teams down and then the language leadership and intel comes to me and they said you're responsible for the sutherland you need to fix it because not only did the management throw out the scaling frameworks they said we do not want to hear the word scrum ever again at intel so i said we need to write down something that actually works at intel and i've heard you tell this story before jeff and just just to clarify they weren't banning scrum it just that was so much bad scrum out there that they didn't want people using the name because it was like a blanket covering defects instead of actually using the framework it was similar to what hendrick neberg founded spotify okay he went into spotify they're doing scrum and they have scrum masters but they're just following the rules and not getting the results so we said well we're going to change the name scrub master the agile code so they had to change the name to start getting the good scrum results right so these are the kind of problems you run into so we need to we need to teach scrum masters scrum guide basically in principles the high productive patterns and the fundamentals of scaling where you don't slow down when you add more teams and jeff i'm sorry to say we're gonna have to leave it there because we've actually gone a little bit over and scrum events start and end all the time so let me say thank you very much and thank jeff in particular and thank you all for attending and celebrating 25 years of scrum with us and on behalf of myself everybody who does scrum and i'm sure jeff and ken thank you for all you have done to help make scrum the most widely used agile framework we look forward to seeing what we can all accomplish in the future thanks again jeff thank you tom and thank all of you out there that are working so hard on getting good scrum into your organizations and i appreciate all the feedback we've got both positive and negative we're trying to respond to your needs as best we can and we hope the scrum guide helps [Music] you

Channel: Scrum Inc.

Views: 43,743

Keywords: scrum, agile, agile methodology, scrum inc, scrum methodology, scrum guide, scrum guide 2020, new scrum guide, scrum guide changes, scrum guide launch, scrum guide official, scrum guide video, scrum guide explained, scrum master, product owner, product backlog, sprint, sprint goal, sprint planning, accountabilities, waterfall, commitments, velocity, kanban, estimation, software development, technical debt, scrum team, capacity planning, development team, project management, jira

Id: Dfxo3PZwDI8

Length: 138min 28sec (8308 seconds)

Published: Wed Nov 18 2020