Science & Technology 

What is Nexus? An Introduction to the Framework for Scaling Scrum

$23.20

Agile Software Development with Scrum (Series in Agile Software Development)

From Amazon

Sales Rank 50542 Schwaber, Ken/ Beedle, Mike

eXtreme Programming is an ideal many software shops would love…
Buy now

Language:
hi everyone good morning good afternoongood evening depending on where youmight be here around the world andwelcome to today's webinar what is Nexusan introduction to the framework forscaling scrum I'd like to thank PatriciaKahn for joining us today to talk aboutNexus and the Nexus framework my name isEric neighbored and I'll be your hosttoday taking questions and working withPatricia to help keep things movingforward so we go to next slide trip itjust don't excuse me just a little bitabout who we are what we're doing soscrum board is the home of scrum we'llrun by Ken Shui for the co-creator ofscrum and we continue to evolve thethinking in in the evolution itself ofscrum coming out with the new version ofthe scrum guide late last year workingwith coop co-creator Jeff Sutherlandcontinuing to evolve the thinking asTrish is gonna talk about today aroundNexus and how to use scale scrum andcontinue to help educate in and teachpeople how to apply scrum in aprofessional manner in something you'llhear a lot about today isprofessionalism and the importance ofprofessionalism while while deliveringour mission is improving the professionof software delivery and we do that inmany of these different ways to go tothe next slide so just a little bitabout this series this is a freecurrently monthly webinar although we'relooking at increasing the frequency ofthese webinars and really focusing in onhelping you learn more about how tobetter apply scrum you can ask questionsin multiple ways you can go to the argueyou can tweet hash at scrum dot orghashtag scrum calls and there's otherways we'll get to in a second butthere's also lots of recording so youcan go out to scrum dot org slash scrumpulse and see the list of all of thedifferent recorded webinars I think thistoday next slide so your microphones aremuted we encourage questions anddiscussion however so as I said you caneither tweet at us or just go into thebox on your menu there that saysquestions type a question and we'll takethose questions and answer them as astime permits with that Patricia I willhand it over to you thank you Ericso hi everyone my name is Patricia KongI am the product owner of enterprisesolutions at scrum de door so what thatmeans is that we are thinking aboutscrum and agility in the enterprise andhow we can look at the differentbenefits and challenges that we have inthe team level and see how we canexplore that at the enterprise level soI would be remiss if I didn't say happyValentine's Day happy Valentine's DayEric it's a it's a nice way to start theday off for me actually so here todayI'm here to give an introduction toNexus to talk about scaling scrum withthe Nexus framework but generally when Istart the conversation at conferences orwith clients we always want to talkabout first why are we scaling scale hasbeen such a big buzzword and generallyor thinking about it is it because weneed to go faster is it because we havea lot of people and when we talk aboutscaling there's so many difference butwhat we really think about is that thepurpose of scaling is to get more donein a given timeframe for us but then thequestion really is what do you want moreof when you're scaling output or valueand what should we be thinking about tohelp us from scaling too early or toofast or unrestrained and if anythingfrom that org message around scalingwould be don't scale if you don't haveto so let's think about some of thosethings in terms of output or value it'snot a rhetorical question we're lookingto scale values so how can we do thatwell scaling doesn't always mean addingpeople first what could we do tooptimize good practices because when wedon't there is a tremendous cost thatwe're going to face scaling definitelyhas a cost so what I have is just a fewinputswe're from Forrester Research so lastyear they wrote a good report it'scalled dealing with development teamdysfunction and in this first one aroundpractices says that over 80% ofdevelopment organizations say thatthey're adopting agile but theiradoption of agile practices lag sohere's some few data points it actuallyhasn't changed a lot from what I've seenpreviously but it looks here that only22% of teams are using short iterationswell that's how we inspect an adaptiveagile 21% is going to get Eric going usedaily stand-ups so let's say daily scrumhere but that's how we as a team wouldyou know use that at least one chance toopportunity to come and plan for the daywhat about retrospectives well that'sfor me the most important event in scrum13% so that we can look and say hey howare we working together what can we doto improve next time very practice 15%are only doing pure programming and thenyou have 16 percent that are usingprayer ties backlog and only 5 percentare thinking about minimal minimumviable product well that makes sensebecause if you're not prioritizing yourbacklog it's going to be kampar to havean MVP so when we think about valuelet's think about what we can do tooptimize these good practices and alsohow could we reduce the manual processesbecause we're talking about how to scaleright now so when we're talking aboutscaling and how teens or even just youknow you know one team work together howhow do we consider what must be done tointegrate the work so this this is fromthe same report dealing with developmentteam dysfunction says that 33% ofmanagers say that increasing automationis a top prioritywhich means 67% don't that's ok but whenwe have the question here how often doyou use the following tools when youdevelop software applications 25% talkabout using continuous integration tools11% automated regression testing toolsand 13% service visualization tools sothe question is here is what what can wedo to improve these things before we tryto push a change on or we try to changeteams inallow them to scale when they're notusing these types of you know greatengineering practices first thatactually helps scaling then the lastthing that was really surprising to mewas this data that was around developersbeing disconnected from businesspriorities and customers and was reallyconcerning to me because in the firstgraphic we saw that eighty percent overeighty percent of teens are sayingthey're doing agile okay the thing isthat they're feeling more disconnectedand they aren't aware of businessobjectives right so it says heredevelopers are six and a half times morelikely not to know business prioritiescompared with managers and for me that'show you check out that's how you getthese scrum Dombey that people talkabout that's how you kill the storm oldsoul because we're not figuring out howto preserve and benefit from bottom-upintelligence and the team havingdevelopment team is being connected tothe customers is an opportunity and it'sa way for them to build empathy fortheir customers or user so those arejust some things that I want to thinkabout that I think that we could work onin terms of scaling before just thinkingabout adding people so contrary to whatpeople might think I actually don't likecarrying the sound of my own voice Iwanted to set off the the text here thecontact you're around Nexus is by askingyou guys questions I'm going to ask youto participate a poll looks like Ericalready set it up and it's do you oryour team's currently use scrum and it'sjust a yes or no answer I'm going to askyou to fill that out it's pretty simplebecause it's yes or no it's not yes orno kind of or yes or no maybe so if youcould do that that would really help usget some context for what's coming upyouyouand if you are completely new to scrumit's going to be a great learningopportunity hopefully and if you're notyou're going to understand why scrumgorg has this very long hashtag when wetalk about next to sub hashtag scaledscrum it filled scrub we had our themajority of folks have have submittedand there are your resultsso 86% currently using scrum great thankyouI don't know how to make this go awayokay thank you so knowing that is reallygood because that means that this thisintroduction to Nexus is going to beeasy and it's going to seem like commonsense for for some of you and when we gothrough it it's going to seem like heymaybe this sounds like things that we'vealready been doing which is what I heara lot of and that's because it'snormally just an organic progression ofscrum I was actually just talking to Kentraver and he'll say hey Trish doesanybody say that this doesn't sound newand I'll say yeah and he says becauseit's not it's because it's how it's warmwas working well organically thesethings would have happened so for the86% of you in the 14% of you who may ormay not actually know scrum but aren'tat least not using it we can talk abouthow we can scale scrum without crushingits soul and that's what we're going totalk about so here's our graphic of justthe scrum framework you can see thatthere's the the team in the middle but Iwant to show actually thisrepresentation of it and this is adrawing and it's thanks to mark Donovanand Don McGrail who are two professionalscrum trainers and what we see here isthe the product owner who's in greenscrum master who's in blue thedevelopment team that's in red but theproduct owner is responsible as productbacklog maybe doing some refinement withthe team's development team is pullingwork from the red sprint backlog and thescrum master is a servant leader for thescrum team and the development team isworking to build a done increment atleast by the end of the tripI pulled this up because I want to sharea story of from our scales professionalscrum workshop which is where we runteams or run students through a casestudy and the case study that we have isactually it's called global car rentalsbut it's based off of real-life Nexusimplementations so in that what we haveis we had a team that was working atglobal car rentals and global carrentals is a rental company and theywere they found that their business wasslowing because of the car sharing taxibusinesses they said you know we havecars we should do this too so they triedit they built an app right and they useone scrum to do it one scrum team to doit and they said you know what this isworking we need to accelerate so how dowe do that with three teamswell they align themselves and they wereworking into a writer driver and backoffice team and the rider representingpeople who are taking rides drivers arethe people who driving the cars they canrate each other so you're I could be awriter driver and a back-office team tohelp and they're working off of that oneproduct to build the mobile app to getan integrated increment at least once asprint so they still had one productowner and they actually had three scrummasters one of their scrum mastersactually quit and went to a competitorbut that was okay they felt that youknow they could do with just two scrummasters they had started from one scrumteam and so they had a great aptitudeand so during the sprint what they wantto do one of their goals was toimplement something called basic searchand that's what we talked about in ourcase study and the basic search pricingis when let's say it's you know beforework busy times before work maybe afterwork at night when you come out from arestaurant or a club or something likethat there's some sort of surge pricingbecause there's high demand and lowsupply so how do we do that so that thewriters would pay more drivers couldearn more and we could record that datawell they think about that during Nexussprint planning and they say hey youknow what let's get together and seewhat what kind of dependencies weregoing to face and after we're finishedwith that and we understand okay howwould we how can wecoordinate this how are we thinkingabout pulling the dependencies apart forthe sprint then we can come into ourindividual teams turn planning for riotor driver back office and from that wecan pull our own individuals from abacklogs same ok the thing is is thathow during a sprint are we going tovisualize these dependencies for ourwhole Nexus for the three team togetherwell we can do that by forming a nexussprint backlog okay so we're still doingscrum so that means that every day atleast once our teams need to cometogether and still do a daily scrum sowe're talking about you know what is ourplan for the day and what impedimentsare we facing the thing is is to get aglobal view of what's happening at anexus to make sure that there's nothingbroken at the Nexus level so that globalview what they needed to do with a theNexus daily scrum so they say you knowwhat at least let's come together firsthave a quick conversation you knowsomebody should go there the rightperson should go to have a quickconversation and then distill that intoour daily scrum let's do that great okso toward the end of the scrum you'restill having the Nexus print reviewwhere we can all have great knowledgesharing inspect and adapt get someclarity and we're only looking at theone integrated product we're no longerjust looking at the separate thingsbecause what we care is you know thatone gift boxso the teams are still doing sprintretrospectives but what they found wasthat they would had a lot of commonproblems or common issues that wereNexus level issues so for this one wecould say it was they had a really busyproduct order because we're starting toscale they have to talk to differentclients talk to different partners talkto organizations and so what reallybenefits that is to be able to have thatNexus level conversation of aretrospective say this is what'saffecting our Nexus before and afterbecause we've come in before you can saythese are the high-level issues that areaffecting us not only just one team butsomatically all of us now we can come into our individual conversations to havethat and then figure out in the lastpart of the sandwich what actions we cantake into the next sprint so that'sreally interesting there is one timewhen they said you know what let's tryto do this all together but they foundthat they weren't able to address theirindividual team team conversations andretrospective items so that's why it'ssplit into three part now you have thatand one of the things that we know thatis a killer for scaling is dependenciesand integration issues so what we havehere is we have continuously doingrefinement across the sprint and that'swhat's helping them pull together pullapart the different dependencies theymight face so here you have differentteams just coordinating and what issomething that what I talked about couldkill scaling is a notion of dependenciesand integration so there's a couplethings that we're going to address herewhen we talk about how they formed anexus integration team so what happensis that when you're looking atdependency issues what there needs to beis there needs to be some sort ofaccountability for that that integrationfor those dependency issues because youhave a product owner who might be cominginto three teams or might be coming intonine teams which is what Nexus addressis and if there is some sort of issuewho would that person who would theproduct owner talk to will it make sensethat we would have a nexus integrationteam where you have people that arerepresentatives fromthe different teams so that they canhave that conversation there's anotherthing that we think about in terms ofaccountability is that it's not onlyjust looking at dependencies but how dothey create sort of this identity thatwe can have that has representation fromthe whole otherwise it's just stillspread out a bunch of teams or a bunchof people working together so that's theonly new thing that was added to Nexusin terms of a role and hopefully thisyou know this image of how we just addedthe minimal things of scrum make sense Iwant to drill in a little bit more tothe Nexus integration team because Iknow that it can be a little bitconfusing and it was one of the thingsthat we actually updated in the Nexusguide so the Nexus guide talked aboutpreviously we had said that the Nexusthe Nexus integration team was a scrumteam and and it's something that weactually removed because we found thatthat and the fact that it's called anexus integration team caused a lot ofconfusion because the fact is that thenext integration team isn't a separateteam and it's not doing integration sowhat are they actually doing whilethey're there to provide transparentaccountability for Nexus integrationright but after you can see in thatimage it's actually composed of theproduct owner who remains there butdifferent people from the differentteams to get that representation nowbeside the product owner role thoseother people can change because whatthey're doing is they're coaching andhelping the teams right so in terms ofaccountability they're looking atintegration but they're also reallyraising awareness of dependencies theymight be doing things like creating ashared definition of done orfacilitating shared architectureinfrastructure but the idea is thatwe're getting that representation fromeveryone and then they are us and we arethem that's actually a quote fromprofessional scrum trainer named RobMayer that I loved because it's talkingabout how do we get some sort ofrepresentation that maintains andpreserves the bottom-up intelligencethat we have from the team so when wetalk about the Nexus integration teamit's a virtual team the composition maychange between sprintsproviding ongoing coaching andconsulting to the Nexus they areconstantly highlighting cross teamissues so that Nexus sprint backlog isprobably their bread-and-butter lookingat crossing refinement is probably theirbread and butter some might go as far asto say they're like the scrum master toa scrum team and I can get behind thatto a certain point and we have to thinkabout that as you're scaling as thenumber of scrum teams increase thecomplexity that you have when you'reintegrating all those increments in asingle working increment increases sothis role becomes very vital there whenwe think about accountability so that iswhat we have when we look at the Nexusframework and hopefully that makes sensewhen we you know I showed that image ofscrum and how we could add to it itwould make sense that this is actuallyjust scaling scrum and everythingadditional there is just to raise thatlevel of transparency so another thingthat's interesting is you know Nexusintegration team can be confusing andeven the word Nexus can be confusing butthe reason that we chose that isn'tbecause it's great for marketing I thinkGoogle has a nexus foam and next is thatis out there belonging to so many otherthings but the reason that we chose theword Nexus is because of the definitionthat it's a relationship or connectionbetween people or things and Kenactually will refer to it and say heyMexico is the exoskeleton of scaledscrum and we used to have that as adefinition in the Nexus guide andeverybody was confused by it you knoweven some of us think what what doesthat mean well in essence what it meantwas we have a scrum team which is arelationship in a connection and now wehave a nexus and what we're looking todo is connect those people rightpreserve that bottom-up intelligence andthen like Edwin dando says we're tryingto scale scrum without crushing its soulthe exoskeleton is what we put on top topreserve that goodness but also tostrengthen it so that's why it's calledNexusnow when we get into scaling or thinkingabout is hey we have from if we buildthat strong foundation of scrum and wethink about how we can develop and ourbrand is professional scrumso how we can understand scrum how wethink about technical excellence how wehave pride in the agile values in scrumvalleys agile principles in scrum valueswhat else can we do well in the essenceof scaling those are the things that wetalk about is there's two things tothink about anticipation which means heyget a strong foundation of scrum hey laydown something like Nexus hey and anexus use the Nexus daily scrum and thenthere's this other part which is anotherfunny word called reification thereification is really the process ofmaking something real right let's makeit real well the way you can do that iswith different practices so all thosepractices that we talked about greatengineering practices or how you mightalign your team or different ways thatyou might visualize your work ourpractices that can help you scale wellor help you just use scrum well but it'snothing that we would add on to aframework because there's going to bepros or cons of what you can do becausewe can't understand or know who yourcustomer is or who your user is we won'tknow what legacy you're facing we don'tknow what architecture is we don't knowwhat your management is like you don'tknow what your politics are that you'refacing so those practices that you putinto place will be depending on what youthink is right so I hope that there wasan understanding of how we went throughscrum and how is a minimal addition interms of what could be added to scrum tolift the transparency but I wanted tomake some things clear here is that whenwe scale we're scaling for value notjust for output and I think a good wayto think about this is to think aboutyou have actually a 50 person problem100 person problem a 200 person problemor maybe do you just have a bloatedproduct that was something that that mycolleague kirpan there was and I weretalking about which is reallyinteresting and if you're thinking aboutscaling scrum or if you're thinkingabout scaling to get more work done toget more value in the same amount oftime well the Nexus extends that bycreating a network among your team it'scoordinating those conversations liftingup those transparency that transparencythat's needed when we're thinking aboutscaling we have to be rigorous aboutremoving dependencies and creating anintegrated increment at least everyscript that's what scaling is about andwithout first implementing thefoundational scrum concepts any scalingwill be painful will actually reduceproductivity so we have to think aboutand there's a lot of case studies outthere is that can you get ready and whenyou're scaling when does that actuallydrop down so those are things that youshould be thinking about when you'relooking at your scaling implementationand I am leaving this for last butintegration we drill on an integrationintegration Nexus integration is becauseit's so important it's a killer it canbe a killer issue but it's also anintegration of people so we talked aboutthat Nexus integration team think aboutit that's an integration of people andthat that is something that can help uscreate an entire identity rather thanjust a bunch of people or a bunch ofteams this is about us coming togetherand having an identity and being closerto understand the vision and the goalsthat we're trying to achieve so gettingstarted with the Nexus framework will86% of you said that you know scrum soone of those prerequisites are scrumexperience those 14% that doesn't meanyou will don't have scrum experience itmight just mean you're not using itother things that you might do is knowhow many teams you have or have someteams identified think about that Nexusintegration team the Nexus integrationteam the members there besides productowner are usually at people in the teamsthat are you know they're sticking theirhand out they're already doing itthey're already trying to coach theother team members and they're expertsin certain areas so if you're juststarting a Nexus life that'd be someexcellent to our masters maybe you knowstrong technical people and they'remaybe there's things to think about nowone of the biggest issues when we talkto people about scaling is the idea ofproduct what is our product we talked toa customer where they didn't know iftheir platform was a product or aplatform was several products on thatand that's a really normal issue butit's something to talk about and itmight be normal to haveyou know and Nexus it along a platformif you're trying to pull that identitytogether maybe maybe not think about thedefinition of done at the Nexus levelright what is it at the products levelwhat is it at the team level and getinto a spring cadence that you can agreeon those prerequisites are actuallypretty simple so we have different casestudies where there are teams that wereusing scrum and they understood scrumgot a very quick lesson in Nexus andwe're able to start there so that'ssomething to think about if you'restarting to scalenow we have just written a book I'm aco-author of the Nexus framework forscaling scrum with Curt Bittner and DaveWest it's something that walks youthrough a case study and it also givesyou different practices and challengesthat people that teams may hit whenthey're scaling it's funny because Curtwas actually saying how one of ourreviewers were getting frustrated thatthe teams in the book were you knowhitting and doing all these commonmistakes that we see and we said wellthose are things that we said shouldcertainly share and that this type ofbook but we certainly have white papersand case studies and we also have Nexusguys just like the scrum guide it wasrecently updated so like I had saidbefore one of the updates that we madewas around the Nexus integration teamthat new role we wanted to make surethat people understood that this ismostly comprised of people who are onthe teams already to lift up that voiceand we also wanted to make sure that weare aligned with the scrum guide sotalking about continuous improvement howwould you do that at the retrospectiveor how do you think about that at theretrospective that's in there and justin general lifting up transparency sotalking about the integrated incrementwe added you know some differentdefinitions around that we do haveworkshops like I mentioned and we havecertifications and assessment there is anexus open assessment which is freewhich helps you learn about what we'rethinking when we're thinking aboutscaling but we also have a lot ofwebinars so I'm this is a quickintroduction to the nexus framework andit hopefully it's giving you a littlebit of idea of where that thinking andhow that evolution came about but Ithink in a few weeks there I'm doing anexus in action so what would it looklike to actually be going through anexus and what are those details issomething that we're going to be doingin an upcoming webinar but we do havesome different ones and differentimplementations that you can listen toyou from the scrum pulse and I'm leavingabout 15 minutes for questions so that'sit for me Patricia kong patricia calmthat's from that order if you do havequestionsand they aren't going to have time tocome through today there you go right sowe've got lots of questions and keepthem coming but Lola will start hittingon some of them that I think I've gotfirst one here from Cebu once when thescrum framework is followed by everyoneaccording to the scrum guide why do weeven need another framework for scalingare they working together and creatingsomething that that's done and usableand valuable so I think if that'sworkingtoosha booth question then maybe youdon't if that's working for you then youdon't and that's why we actually saythat don't even consider something likenexus until you're hitting three teamsbecause if you have two teams theyshould be able to talk together but ifyou think about the complexity thathappens when you're talking about threeto nine teams working together then Ibelieve there's going to be a little bitof things you know some some differentevents that you're going to want totogglejust to make sure that you're lifting upthe transparency but if it's working foryou and you're able to manage that ameasurement measure that then go forcool so here's a question from Sam Ithink I think you kind of answered thisbut it it'd be great to just make surethat people understand it so the Nexusguy and guide seems to imply that allproduct backlog items for all teamsshould be represented in this NexusSprint backlog is that really the caseso all Peavy eyes are in the Nexusturret backlog is that what it was ohyeah well that would be hard so I wouldencourage that the Nexus sprint backlogreally be a visualization of if you youknow however you want and I would Iwould recommend and I think that wetalked about that at least in our classand then you know in the guide that itbe a visualization of the dependenciesthat you will be facing for the Sprintrather than everything because youwouldn't want it to be a representationof all the items from the differentbacklogs because that might be a lot butthe main thing that you want to keep inmind is let's have a visualization ofthe dependencies that we're going toface during the sprint because rememberthat's something that the Nexusintegration team can be looking at greatso again a question I think may havebeen answered during the session butagain always good to reiterate do westill need team level retros or is itonly the Nexus Retro we aren't breakingscrum so we should still have a Sprintretrospective of what the scrum teamfaced and what that has is that actuallywhat we added around it was a sandwichwhat we call a sandwich because we wantto talk about hey at the Nexus levelretrospective what was happening at theNexus well let's take those items backinto our team and talk about you knowwhat happened at the team levels butalso you know those different metriclevel conversations and then take thatinto the third part where if we canshare it back at the Nexus now we dohave an example of an organization wherethey said you know what we didn't findvalue and kind of going off in our owncorners we wanted to do it all in theopen but by doing it all in the openthey still had their individual sprintretrospective they just did everythingall at once though and now was onlythree to five teams now imagine if itwas 19 18 17 how different that might beand that also is going to depend on thelevel of transparency that you have sothey just did everything all at onceNexus level and then they had someindividual team items that they couldbring up with their scrum masters thereso they could address those and thenthey would still close it with the Nexusnormal thing yeah so the first greatthanks Trish and I think to add to thatand this kind of impacts the nextquestion as well as you're thinkingabout it your your Nexus retrospectiveis going to look at how are the teamsworking together and how do we improvehow the teams are working together nowat the scrum team level I'm going tohave conversations at my scrum teamlevelbetter about how does my scrum team workbetter and work better together and inthat case there those are conversationsthat you may not want to have or evenneed to have at the global level butthey're really about the individual teamso this kind of leads to the nextquestion which is is there a change intime boxes mmm-hmmthere is no change in time boxes and thereason that in the Nexus side we don'tactually prescribe time boxes andbecause it could be very differentdepending on the level of maturity ofthe Nexus but also the size of the Nexusso for instance we would just say heygenerally make sure that you're keepingit aligned with the scrum time boxes butthere's no change in that and we don'twe don't prescribe any of those thingsas you can see in the Nexus guide sothere's a bunch of questions hair aroundscrum of scrums and how is thisdifferent than scrum of scrums soanother way to think about that is tothink about what a scrum is firms tryingto address now the fact that we havesomething like the Nexus daily scrumwhere you're coming together the rightpeople from the different teams they'renot always the same people but the rightpeople are coming in from the differentteams to talk about hey what are ourmajor issues today as a nexus are thereany integration issues you know did didyou break the build that anythinghappened no okay let's move on that'swhat's important that scale right shouldwe have and we actually have actuallythe Nexus integration team provides thatto write a global representation of allthe teams in the Nexus should there beother things like community practicesand all those different great things yesbut that's I think how we would talkabout the Nexus of the scrum of scrumsby thinking about well what does theNexus daily scrum do to address some ofthose things that the scrum of scrumsmight have been addressing for you greatthanks Trish so here's a great questionabout how do you subset teams and so onif a subset of a full team is attendingthe Nexus daily and if so how do youensure thesame info was getting down to the dailyscrum I think my question would be ifyou need to go to the Nexus daily scrumwhat's stopping you from going and so ifit's the same subset that could become asmell if everybody needs to go I'veactually participated in the Nexus dailyscrum where I saw everybody go and itwas a five-minute Nexus daily scrum butthat would be a question of you know howdo you share and raising that level oftransparency and if it's not comingthrough then I would suggest next timeyou go to the Nexus daily scrum - andthat's the beauty of it and that's thedifference between that and the scrum ofscrums actually so I'm gonna have youchannel your inner Ken Shui Bernau andthose questions come up a few times so Ithink it's an important one how do wearrive at three to nine teams I don'tknow if this has anything to do with Kentrue but it's actually scientific aswe're going to try to make it work and Ithink it's something about Dunbar'snumber but the three to nine team issimilar to the three to nine teams thatyou see for the recommendation in theterm guide loose recommendation and itwas something about thinking about thoseconnections so I've been drilling thatnexus is about connections and there's Ithink it's Dunbar's number where we'reonly able to maintain that connection ofabout a hundred people all right so sothat's where this when you think aboutthat three to nineteen it makes sensebut it's actually just relational toscrum we should ask Ken why there'sthree to nineteen and explore that doyou want it do you want to express yourKent River so so it is based on a lot ofscience and how many people can scale sothat's why scrum is based on three tonine plus or minus three people on ascrum team and same Nexus how many teamscan work together once you go beyondthat and there's a lot of psycho psychopsychological and sociological researchthat shows once youbeyond those numbers scale just actuallydiminishes instead instead of growingbecause it's just impossible tocoordinate and work together and so onand it's that plus or minus three butit's about the right number that we'veseen and seen work quite often so I'mgonna keep going here there's lots ofquestions where's architecture fit intoNexus where is architecture fit intoscrumso there's definitely something that Iwould consider in terms of how do youfit that on to a scrum team and how youcould fit that on if you had multipleteams now one of the things that wetalked about is the Nexus integrationteam and I'm just you know giving apotential suggestion is that the Nexusintegration team is a representation ofpeople from the different teams butlet's say that we need someone to be inour conversation the Nexus integrationteam might be a way to invite them tohave that role so you know couldarchitecture come into that conversationbecause your enterprise architecturejoin that group mainly yeah there's nospecial rules for anybody though Johnall right right hands perfect right andessentially architecture is developed aspart of that sprint because if we don'twe don't know exactly what we'rebuilding until we plan it and we need tostart building that out just like youdesign it the best way to implement itis to ensure a design is right as youimplement it and produce that thatdoesn't mean that you don't havearchitects on your scrum teams itdoesn't mean that our key texture isn'timportant but that architecture evolvesover time and if we define anarchitecture upfront and then try toimplement it when things change thingsbreak I used to build a lot of housesand there was nothing worse than whensomebody would come in and say oh can'twe just put a window there after theproject product right the house was aproduct after that product was done wellthat doesn't take into account weightbearing and all these other things thatnow cause a full redesign of the housearchitecture just to add that one whensame thing happens quite often in sulfonsoftware so this kind of Christ of whatyou were just talking about the Trishso can the Nexus integration teaminclude other people that aren't on thescrum teams like business stakeholdersbusiness stakeholders would beinteresting but again a nexusintegration team is also an opportunityto bring people into the conversationthat are helping us think about the workthat we need to do to build productright now is it a place the othermisconception of the Nexus integrationteam one I hit on was it's not anintegration team in terms of it's notdoing that integration work right it's afocal point for integration the secondthing is that it's also not a managementteam so this isn't where we would takeall you know we're doing agile but nowwhere do the managers go they all go inthe nexus integration team it's notmeant for that so think about what makessense in terms of who you could invitefrom externally to bring them into yourconversation and if the stakeholdersthere just because they want to be thereand understand the status it might notbe the best use of their time or for thepurpose of Nexus 3 so can you talk alittle bit about the difference betweenNexus planning and sprint planning sureso Nexus I was going to actually flipback that that would be crazythe Nexus sprint planning is when we gettogether right so appropriate people ormaybe everybody that's happened to andthe Nexus gets together and say hey whatcan we do as a Nexus what makes sense weneed to have those conversations thatfail about what work we can pull whatdependencies we might be facing beforewe can then go into our individualsprint planning for the individual teamso the only difference is that it'sbefore we do our individual teamplanning and it's the main purpose ofthis is to look at you know what else wecan do to pull apart the work for theSprint in terms of dependencies and abig help for that is going to be inthe refinement isn't prescribed and frombut it is mandatory in Nexus and Ishould be done continuously throughoutthe sprint to see what kind of upcomingwork we're facing and what dependencieswe have so that we can start to addressthose up front a little bit earlierso do your sprints have to be at thesame cadence mm-hmm so I would HIGHLYadvise that if you are multiple teamsworking together that you try to get onthe same cadence if you cannot one ofthe suggestions that you might thinkabout and this may work or may not workis just getting on at least the samecomment cadence so that means if you'rein let's say you're worth running forweeks friends then another team if theywant to run a shorter sprint they can goto two-week Sprint's but it could neverbe let's say two and three because youwould never meet you would never meetand then you just have to figure out ifthat makes sense for you it's reallygreat because a lot of these questionsare challenges that we actually put intothe course and also the book now we havethe new book that that Kurt Dave and Iwroteso there's a lot of questions so I'mgoing to address this there's been a lotof questions around product owner and myI can take this is if there are part ofit if you want Trish as well but andyeah how many product owners do I havepermits come of the gist of the manyquestions that come out mm-hmm so whenwe were going through the story where Ijust showed the evolution of scrum toNexus when you have one team workingtogether right they're building oneproduct there's one product back up whenyou have multiple teams working togetherthey're still working on one product sothere's so they still have one productbacklog which is still ordered by oneproduct owner and I think the questionhere becomes hey that's really hard howdo we manage that when we have multipleteams well the thing is is that I knowwhen we're working on a product when wepull the rope we get to that productowner we know who owns the product thething is is that one of the things thatmight help is if we have a distributionor what we say at the service is aproduct owner in the different teams sothere's still one product owner in Nexusbecause we're still using scrum so we'retalking about one product but do weacknowledge that you know there'sseveral teams that might need that theproduct owner might need to delegatesome work to yes and I think the exampleor thing that we say is there's onesentiment else which is a great way Ithink to think about it is theresomething you want to add yeah I mean Ithink at the end of the day the productowner is ultimately responsible for theproduct and the product backlog and theydoesn't mean that they do all of thework and I think this is a commonmisnomer or myth that the product ownerthat has to do all the work no they relyon their stakeholders they rely onbusiness analysts they rely on productmanagers and and so on to do a lot ofthat work but they're the ones that areultimately responsible they're the onesthat are interfacing along with all ofthese other folks and but that you needsomebody who is accountable for theproduct and is accountable and empoweredto make thisaround the product as well if you havemultiple product owners you run into nowproduct by committee and that's beenproven over and over again that productby - by committee or democracy doesn'twork now we have lots of opinions so youneed one ultimate product owner thatdoesn't mean that they're not gettinginput from stakeholders they're notgetting feedback from product managersand so on but and now if you havemultiple products within the nexus maybeeven now that's an opportunity to breakout into multiple nexuses right now andrather than having one yep so there's agood question there sometimes to thinkabout when we face these conversationswas are you actually the product owneror is there some sort of you know or youor are you actually the product owner isthere some sort of other title that youyou should have that would make you feelmore comfortable but the other questionsreally are you know what is the actualproduct there are you working onmultiple products so actually maybe youdon't need to be one nexus maybe you'rejust actually one scrum team and anotherthing that you're seeing that it made methink about was there's there's there'san opportunity like I said before whenwe're thinking about having thedevelopment team being very close tostakeholders and customers right andthat's how we can inspect and adapt anexperiment quickly and when we have thisconversation of you know I'm the productowner there's this many product ownerswhat we lose is that opportunity becausewe saw that where the development teamwas getting further and further fromunderstanding what's the vision and whatdifferent goals were and I think that'ssomething that happens when you havemultiple product owners up in the earproduct ownersso this kind of gets the Nexus Plus dowe have a nexus of nexuses a nexus ofnexus s so we talk about a model calledNexus Plus and everything that startsfrom you know what you understand aboutsquirm what you understand about next ishow you would start a Nexus how youwould manage a Nexus in terms of youknow how do we make sure that everythingis going going well applies and then youget to that large scale of Nexus plusand while we say that a nexus plus whatyou're really going to need to thinkabout is is integration so a nexus ofNexus is I don't know what that reallymeans but you know is there just adedicated Nexus integration to you maybedo you have one Nexus depending on yourscale that's just focused on integrationmaybe but to understand that there is nospecial recipe or framework that we cangive it's just a copy-paste and thinkabout those same things that might workfor you and there's definitely somedifferent practices that you shouldthink about architecture is much moreimportant at that level of scale do weneed to have an individual team sprinkleor is there just one big Nexus goal itwould be both right so in the same wayfor a definition of done so there is theNexus goal that would be everythingeverybody all the teams are workingtowards that goal and Capital Oneactually did a webinar on theirimplementation of Nexus and that wasreally important to their success andthe implementations that I've heardabout from them or from some differentother companies is that the idea ofhaving a nexus goal and the idea of youknow all of us working together in anexus really in full really increase thesatisfaction among the team's teamsatisfaction definitely went up and whatyou see it was the correlation for thatis that there was a correlation whenthey did metrics between employeesatisfaction and customer satisfactionand those start with things likeunderstanding what we're working towardtogether as a nexus so that we're notjust a cog in theall working whether I'm on Team a andyou're on Team B we are all working onthe same thing now that doesn't meanthat we don't have our individual teamgoals or individual team definition havedone I'm just going to flick to the nextslide okay there's a lot of greatquestions and I think that I think thatthese questions might actually be in ourdifferent forms of blogs they arethere's a lot of information out therewe have a lot of white papers a lot ofcase studies more comingexcuse me any more webinars coming in aswellso I think a lot of these we've answeredas part of other as part of otherquestions mm-hmm I think it's a onethat's come up a lot it's just havinghow does this compare to other scalingframeworks or scaling methodologies so Iam NOT an expert in other scalingframeworks or methodologies but what Ican say and hopefully you get a sensefrom it here is that sometimes we'retalking about scaling frameworks we'relabeling everything to be the same and Ihave very strong feeling that Nexuscompared to other frameworks are applesand oranges and this is why is becauseNexus is just about scaling scrum if youwant to get multiple teams workingtogether how would you do that it's nottalking about transformation it's nottalking about anything bigger than thatI said I don't understand your portfoliomanagement I can't address your politicsthere's no prescription for thatare there some suggestions that we canmake yesand the other thing that that is reallyimportant to understand about Nexus isthat if you have been doing scrum or youhave some experience with scrum then youcan start doing Nexus quite easilybecause you're able to reinvest thatknowledge that you already have so ifthere's no big upfront weto do this before we can start doingNexus it's hey we understand scrum we'regonna add some more people we're goingto add some more practices let's find away to coordinate that together and thatcan be in a nexus so next question isnear and dear to your heart trash how doyou measure value did I paid somebody toput that in so how do you measure valuewell it's certainly not by measuringvelocity but what we're working on atsome good org and has been working onfor a while but now that Nexus isreleased we're visiting it is somethingcalled evidence-based management soevidence-based management is looking atdifferent areas of a product and there'sdifferent areas calledlike current value the current value ofyour organization or product time tomarket ability to innovate and we'relooking at something called unrealizedvalue which is market opportunity thoseare different things that you want tolook at when you're saying hey are wegetting any value out of X maybe that'sour agile initiative our scalinginitiatives if we're talking about howdo we measure value from a nexus pointof view those are different those aredifferently definitely some metrics thatI would want to know before I start toscale massively or I scale and measureagain so there's different things likethat and that is actually something thatis very relevant when we say hey when wescale are we just scaling it for outputor for a value so if there's more therethat's coming up in terms of what we'regoing to be putting out from scrum orgthere's a guy the EBM guide that'salready online on the scrum guide orgwebsite so you can read more there so akind of a I guess this is a two-partquestion I'll just ask the first partthen we can go to the second partrefinements not an event and scrum whydid you add it to Nexus so refinement isa really good practice at scrum at thescrum level and at Nexus it's addedbecause what we talked about was thatthe biggest killers of scaling areintegration issues and dependenciesand the best way that you can do that isto think about how we can continuouslyrefine so that's an added event and itsreally to address that to dependencyissue great well I think that's aboutall the time we have I want to thankeverybody today for all the questionsthere's a whole bunch more we'll look atthese and try to address themindividually with you as well we couldgo on all day but to keep to our timebox by the way a time box can be asshort as you want just no longersomething that it's crazy enough thisquestion comes up all of the time do Ihave to use the whole time box theanswer is no so anyway let's not let'scut this off now so we do keep withinthat time box I want to say thank you toPatricia let's say thank you to thehundreds of folks who have been askingvery very good questions and with thatthank you very much and have a good restof your day

Many organizations want to “scale agile,” so that they can deliver more value in a given time frame. Ideally, a scaling initiative starts with one team using Scrum successfully. This team can act as a model for other teams. However, organizations tend to add more Scrum Teams hastily, and as a result, they overwhelm their ability to be agile because they tend to add more process and bureaucracy to manage those people. Agility scales successfully with a systematic, emergent, and managed initiative, and that starts with the teams. That is why Ken Schwaber the co-creator of Scrum and Scrum.org created the Nexus Framework. Nexus builds off of Scrum and is designed to enable multiple Scrum Teams to work together so that they can produce an integrated increment at least once every Sprint. It focuses on the key challenges of scaling agile delivery by encouraging transparency and a network among the teams.

In this webinar, Patricia Kong, Scrum.org Product Owner of Enterprise Solutions and co-creator of Nexus provides an overview to the Nexus Framework, its principles and the thinking behind it. She will discuss how Nexus, like Scrum, promotes bottom-up intelligence to discover and emerge what works best for the teams and organization. She uses case studies as examples showing how Nexus can be used, and visit the recent updates to the Nexus Guide.

$23.20

Agile Software Development with Scrum (Series in Agile Software Development)

From Amazon

Sales Rank 50542 Schwaber, Ken/ Beedle, Mike

eXtreme Programming is an ideal many software shops would love…
Buy now

Related posts

Leave a Comment