Epic Sync: Wrangling the Work of Highly Interdependent Dev Teams at Bungie

[Music] all right we're live welcome everyone my name is Linda fain and I'm the senior agility coach at Bungie so I've spent my whole career helping teams of creative people collaborate more effectively and had the opportunity in the last two years to help Bungie transform their ways of working to agile and lean methodologies so I'm essentially an agile coach but I'm internal to Bungie so I'm here today because I wanted to share with you what's been really a powerful yet simple practice that we've experimented with at Bungie that's enabled us to achieve the level of synchronization that we need to make such a massive unified game at scale like destiny - I've nicknamed it epic sink because Bungie's destiny two sinks

can be epic because destiny too is epic but I'm hoping that you'll find that concepts and approaches useful no matter what size your studio may be or what level of synchronization you want to achieve with teams working in parallel so show of hands how many of you attended Patrick Kelly's O'Kelly's talk on Wednesday and bungees transforming their methodologies excellent about 50% or so I'm gonna recap a couple of items from that and then pick the story up from there so throughout his 20 plus year history bungees had a process for making games that was successful and served us very well served our players very well we started with a typical smaller studio model with our work organized primarily around disciplines so art animation design engineering tests with a producer organizing their

work managing the handoffs between the disciplines in a fairly traditional waterfall fall workflow so we carried this structure through from the halo days into the original destiny development as one of our producers said in a post-mortem right when the original destiny was shipping he said that the hardest thing to do at Bungie was anything cross-disciplinary well that wasn't great because many of the rich integrated experiences and destiny involved work produced by multiple specialty disciplines so to meet this challenge of more tightly integrating discipline a disciplinary work for destiny - we started conducting early experiments with integrated small teams so this is our icon for small teams and you'll notice the disciplines are all in the the team unit so Bungie reorganized

the content developers into small teams following the agile scrum model these teams were designed with the characteristics they were across discipline so you had level designers engineers world artists tests working in close-knit unit physically co-located attendings daily stand-ups etc typically in seven to nine team members that's a sweet pot spot for managing collaboration and communication when you get beyond about 10 people the communication becomes oh the overhead starts some not having value it becomes unwieldy so the teams had a clear mission and focus even a unique identity for the first time we had cross discipline teams that had a unique identity they were semi autonomous and I say semi autonomous some localized decision-making with inappropriate

constraints as Connor Crowley said in his talk yesterday on change on managing change he said he called the team autonomy freedom in a box or freedom in a frame I think he called it which is a really good way to look at it because people think ah autonomous teams or just have people running amuck but no you can allow autonomy or freedom you could the teams into clear constraints so then we also focused on creating holistic player experiences so the individuals weren't focused just on their individual discipline contribution they're actually now focused on a unified player experience and actually wrote the requirements from the perspective of the player in the user story format that's known and agile so we were achieving close collaboration amongst people of different disciplines breaking down silos this provided visibility into an

understanding of each other's workflows and unique challenges so a artist gets to know what a designers workflow is and it develops trust empathy and they share common goals so cross discipline teamwork is where the real magic happens for creative teams in my experience all right so here we are now making the massive unified experience at his destiny - with roughly 40-plus of these new newly formed small cross-discipline teams the next challenge we took up was how do best synchronize these semi semi autonomous units you can imagine it's like I made it it looks like a mess we've got all of these small teams to really focus they know who they are they know what they're doing but they're all producing work that goes into a unified game so I'm

going to illustrate the sheer scale of destiny to team collaboration by showing you different moments of destiny and allow you to see some of the teams that touch these moments so for some of you they're familiar with the game this is the PvP the crucible so we have at PvP team PvP Maps weapons armor lighting VFX those are all small teams of seven to nine people then collaborating with in this case eight other teams just in these environments we have a massive playable area spanning several planets each with their own art palettes we have concept art palette skies etc public events so whether you can meet players tackle shared challenges and you'll recognize the spider tank pause on Titan so we have the abilities team audio progression and economy etc the director the underlying

destination maps allows players to explore the solar system complex social systems in destiny - including matchmaking clans guided games social spaces like this you'll recognize the farm and then character vignettes cinematic sequences this one featuring my favorite character Hawthorne so we achieved the benefits here we bet go back to wow you see all these teams you saw what we're producing and how integrated the world of destiny 2 is so we needed a team structure that was as integrated as the world we were creating so we achieve the benefit of focus and of cross discipline tight-knit units so those units then working in parallel are driving a complex web of

interdependencies between teams some of you might recognize this in your own work the red lines represent the dependencies just keep building building building into a web web of dependencies so it's a little jargony but dependency is work that your team requires from another team in order to complete your features it's normally hidden work hard to track you know sometimes you just might have like a stomachache and you're just thinking oh there's something we need from some other team I don't know what it is but I don't feel like we can complete our work so dependency is a thing that calls out when you are depending upon another team textbook agile scrum teams don't have dependencies but unified experienced teams building experiences at scale like destiny do so it can be overwhelming how do you sort

this out so how to synchronize these team units with each other how do you provide the measure of autonomy and maintain continual alignment while managing these dependencies so how we do it is what I'm going to share with you today first why is alignment so important so this is a cartoon by henrik Nyberg one of my favorite agile escs why is alignment important would you say it's not funny yeah I know you just feel oh gosh so in this like in any large-scale human endeavor you have team where you have teams working in parallel alignment is key in this example you have two teams working autonomously and it's clear they understood the end goal right they needed to cross the expanse of water so they had that end goal like they started out maybe in a huddle hey

guys we're gonna cross this expanse yeah we know what to do so they started out to achieve their goal but they clearly lacked some sort of regular communication or coordination to stay aligned also dependent dependency management so the teams working in parallel had a huge dependency right they needed to connect or hook up but that dependency was clearly not identified or managed famous example of a lack of alignment causing problem mister do you know what this is it's the Mars orbiter in 1999 so NASA lost 125 million dollar Mars orbiter and the core problem was at Lockheed Martin the engineer engineering team that was building the software used the building the thruster software for the orbiter I used Imperial English

units of measurement well the agency's team building the software system taking in the information actually use the metric system of measurement this caused the orbiter to to lose navigation and actually crash into the planet so they finally got the the it went all the way to Mars it finally got there they were gonna celebrate and then all of a sudden it couldn't move and it just went down and then crashed they investigating quickly found the the misalignment and that misalignment had existed for nearly ten months yet it had gone undetected they didn't realize that they were using different systems of measurement so the main point teams of very smart people can get out of alignment and caused problems so it's important to understand that when we have semi-autonomous team units working in parallel there's a natural drift that occurs as time progresses so I did this

animation to illustrate you have small divergences and understanding about scope or areas of responsibility that become wider as development goes on if teams get more and more out of alignment after a certain point there's no one individual team has the power to correct it they could maybe even see it coming and they just can't do anything at Bungie that Patrick the head of production for destiny 2 would use the analogy of a fleet of sailboats the teams were like fleets of sailboats in Armada all heading to the same point we just need to Courtney de to coordinating so with our new structure 40-plus small teams developing in parallel on destiny 2 we asked ourselves what could we do to ensure that we stay in line in alignment in sync so search for answers I went back to the fundamental agile values and principles so another show of hands how

many of you are familiar with agile values and principles quite a few about 3/4 yeah we you know there's a lot of wisdom there there's there's four values twelve principles and some of them you scan over and go that doesn't apply to me but you look in there there's some real nuggets so I went back to the values and principles to see you know is there something in there that could help me with this issue that we were trying to solve for him so the first value from the agile manifesto is people in interactions over processes and tools so it's not saying processing tools isn't important it's just that it's not a replacement for high-quality human communication and interaction collaboration you add to that the agile sixth agile principle which is face to face conversations of the most efficient effective means for communicating

research shows that 93% of communication effectiveness is actually determined by nonverbal cues so body language facial expressions tone inflection contains a ton of information furthermore face-to-face communication is found to be the most efficient you can achieve maximum productivity with minimum wasted effort in this digital age we think that asynchronous indirect communication like group emails or shared documents upon a share where people contribute asynchronously we think that's more efficient it's in a more efficient way to communicate with groups of people it we think it's more efficient because it feels more efficient you know you add a bunch of people to the CC line and hit Send there we communicated but if you really look at it it's not high quality

communication communication as a sender and receiver so you need to you have something you want to say and you have to get the the receiver has to actually receive it and face-to-face communication is the best way to actually have communication work face-to-face communication with all the social cues has also been proven to deepen under and empathy and help develop trust so empathy trust you know collective understanding those all have been proven to speed up the work of teams in addition to the values and principles I also looked at the agile practices of rituals and ceremonies so in agile we have rituals or ceremonies a cadence of team collaboration agile teams use

rituals to keep synchronized within the team on a daily basis so you might have daily stand up the demo review you've got back on grooming team retrospective it's all built in if a plan do check and act plan-do-check-act you've got the this ritual cadence so I'm familiar with those the agile scrum rituals but those who were actually to help teams stay aligned within themselves you know was there a ritual that could help create a situation where teams can align cross team not just within themselves but with other teams so could these concepts the values and principles rituals and cadence you know could could these concepts hold the key to synchronizing 40-plus teams on destiny to you so I did this calculation face-to-face communication plus regular ritual plus

many teams equals what you know was there an agile ritual so to look for the answer we explored the frameworks that were emerging that applied agile and scrum concepts at scale like the scaled agile framework scaled agile framework it's known as safe its if you want to go their website scaled agile framework it's incredibly overwhelming Enterprise Solution for agile very kind of scary and overwhelming so I just consulted that and started to see how it might apply to bungee so essentially briefly it looks at agile practices in three levels of your organization so you have the team layer the program layer and the portfolio layer so this is um converted for

bungees purposes team layer program layer would be an area or a feature in the game destiny franchise would be the actual release so at the team layer scrum teams are the Adam they work for the most part in two-week increments sprints and deliver user stories the first generation scrum cannon focused almost exclusively on this layer describing the practices roles rituals exhaustive literature you just you know look up scrum you'll see a lot of information about this team layer it has time boxed iterations we use at Bungie two-week increments but what I was really interested in is in the program layer so I asked some safe experts I said is there you know is there a ritual and safe that helps synchronize teams at that layer sure enough there was it was called program increment planning or PII planning so bear with me it's little jargon epi planning program increment

planning so what is a program increment it's a collection of work that is the output of many teams it has a time boxed iteration like a sprint but the time box is in 12 weeks or sitting what would be six sprints so it's typically there was so the PI Planning ritual brings teams together in one place one time to roughly plan quarters worth of work together and identify and resolve inter dependencies so the collection of quarterly scope in safe is called a release strain so we have the program increment planning happens at the beginning of the quarter that quarterly release train think about it as a or like use the analogy of a train it's a container like a train car of work for that quarter you put stuff onto the train car and it's in planned and that

big room P I planning exercise and then like a train it leaves the station to get developed over six Sprint's until it pulls into the next station at 12 weeks later so P I planning then is a process of determining what do you want to put on the next train that's leaving you can think what is the most important feature that we need to learn from this quarter you know are there features that contain a high amount of uncertainty that we need to reduce what are some of the big bets we want to prove out let's put it on the train get it on pull in the station and then we'll reassess so P I planning I had a name for it but how does one do P I planning I wanted to know more so stumbled onto a case study by Henrik Nyberg who's influential agile estándar geol thought leader who has a really playful accessible approach to scaled agile what you need because it can be pretty daunting he's worked with both Spotify and Lego and you can go online I see

youtube videos he'll he'll walk you through some of the scaled agile rituals that he has experimented with so I took the case study for Lego but I was like literally I took the case study I got the YouTube video and I transcribed it and I'm put it into a document and worked with Bungie production we looked through it and figure out how could this work for us how could we do P I planning or big room planning so we used it as a template for starting P I planning at Bungie this concept of quarterly big room planning exercise and epic sink what could this get us we had to you know weigh the the the cost-benefit so instead of drift quarter-over-quarter we would tightly sink every 12 weeks

and then we would develop and then sync develop sync a wonderful by-product is that we could actually allow a measure of freedom and autonomy for the teams during the development cycle during the sprints knowing that we'd be regularly coming together into alignment in 12 weeks to tighten things up so it reduce the amount of micromanagement every sprint it's like no give them freedom they're getting there up and then we get on course like the analogy of a flotilla of sailboats you know the one goes off you rein it back in our pitch so the concept of Pi planning in hand and understanding the mechanics Bunji production made the pitch to the destiny to development teams and leadership the pitch was what if we got everybody in a room at the same time face to face to sink on the vision for

the quarter plan the team's work identify and discuss and resolve dependencies bungees first planning day was born so our epics Inc RPI planning we call it took us a long time to come up with the term planning day if you try it you can come up with something different but we we call a planning day and it's stuck so as you can imagine there was initial a skepticism you know take the entire development team of destiny to offline for a day are you kidding it was a new idea and fairly large undertaking it was a bold move so you might be wondering you know how did you convince people well there was a general recognition that the way we planned and communicated largely

through indirect means was not optimal for the highly integrated development work we were doing on destiny too so we had an idea to try that had been proven successful in other companies most all were willing to at least once to see how it goes so that's how the production worked it's like okay just let's just try just try it once if we hate it we'll never do it again the spirit of being willing to try something bold like this and learn from it is one of the many things I love about working at Bungie so we went from this to this so what are you looking at this is the table layout for a hotel ballroom all of the content teams working on destiny - 300 people in the same location for a full day of planning and face-to-face cross team discussion and agreement and commitment so all of

those dependencies that were previously in people's heads are in their notebooks or you know free-floating anxieties were converted into physical entities post-it notes gathered in a central location in the room it would call the dependency board transparent to all so here's you can see we're planning day occurs in our build cycle so we had already had a well-established seasonal build cycle as Patrick mentioned we had winter build spring build etc so that comes at the end of a 12-week cycle so we put planning Day at the beginning of the quarter internal play tests at the end of the quarter learned from it and then decided what we wanted to put on the next train going out in the next quarter from that and so on and so on so if you look at the case studies about PID

planning you'll see that some people do it in two days so they take the whole company offline for two days we we couldn't do that because at Bungie we have so many releases in flight we couldn't take a whole team off for more than one day so what we did is we ended up breaking planning day into essentially three different steps the first step is one to two weeks before we prepped with the leads so we have the game director and design directors get all their ducks in a row as far as what's the product vision for this quarter and then they talked to the area product owners they break the epochs down to features the features are then given to the teams the product owner of the teams and the teams talk through features make sure they understand what they're trying to do also what's their capacity for the quarter you know who's who who they have to actually produce the work so that's done and then we get on-site for cross team planning day and

that's when we plan the Sprint's out identify the dependencies have the face-to-face conversations and revise team plans and commit then afterwards you can follow up on conversations work on stories and also check in on the dependent work but the actual day is the focus and we don't let anybody leave the room until we've resolved all of the dependencies that have been identified here's an example of our agenda I just thought would be useful a practical thing for you to have essentially there's four parts of the day the first one is welcome and goals for the day so this is where the the creative leads will get up and talk about the the pillars the goals the vision for the quarter so that then the teams can figure out at a more granular granular level how their team feeds into those pillars and vision then we have the

small teams get to just focus within their team and their table and do their planning for the core to make sure that they've got the capacity understanding and also what their scope is then comes the dependency discussions once the team has figured out essentially what they're doing they've realized oh we need this work from this other team so this is when we now have the cross team communication and then lastly we wrap up share major decisions made during the day so kind of bring it full circle so we played with other components for the agenda for example we used to have an activity that Henrik Nyberg put in his case study where the team's share their plans around the room like science fair you have each of the teams have their boards and you go around and you and if we just found it it took too much time and it wasn't it wasn't super valuable for us so we we changed it to

essentially sharing major decisions that were made during the day and people like that better all right so I'm gonna talk you through some artifacts trying to make this really practical so there are four artifacts that we use for planning day the first one is the team board the focal point for the team members planning out five or six Sprint's worth of work at their tables it has the team name their mission their commitments for the quarter and a place for dependency post-it notes so some are user stories and go on to the the boards in the sprints where they're essentially slotted and the team does a costing exercise so they know how much roughly effort each of the user stories will take so that's a team board the second artifact is a dependency board so you'll see it's a grid that has sprints down the left-hand side and all the teams

across from right to left and it's a big piece of butcher paper you'll see I'm going to show you a video towards the end where you can see it in action so it's a big thing of butcher paper with gridlines and I'm actually can reuse it over and over and we put it in in a prominent place in the planning room so the third artifact is electronic tracking or TFS so we use post-it notes to help facilitate the face-to-face communication and communication and collaboration because there's nothing like that eventually all the work goes into what we use TFS and people might use JIRA so that is a single source of truth coming out of planning day and you'll see teams we actually have monitors on each of the the team tables and they have someone that's inputting the items for their backlog that way you

don't come out of planting day feeling like you've just created a bunch of work you get the work done so last artifact is risk board so this is how we escalate things to leadership to the release leadership team if there's something that teams can't figure out themselves in cross team discussion it gets put on the risk board and managing the risk for it and resolving those risks is ownership of the release leadership team or that what's called the triage team okay so those are the artifacts so I'm going to go through the roles planning day roles so this is the team structure that Patrick showed you yesterday scrum master product owner at Bungie scrummasters are roughly producers at maybe a more junior producers that do a specific team product owners are often designers but not exclusively designers and then you have the other disciplines represented so each of those teams have a table at planning day the product

owners role is basically to prioritize a team's scope and they do the negotiations have been in the trade offs and ultimately own the prioritization and then if new work comes in they determine should we do it the scrum master producer facilitates the team planning and dependency identification they drive feasibility discussions so let's say new new work comes in a dependency gets put on the team they ask can we do it they determined can we do it then there's a couple of other roles that the team can self-organize to do we've got dependency runner this person who brings the red post-it notes we use the color red for dependency so whenever you see it floating around in the room you know as a dependency so they check the board for their team someone who manages the team board as well as someone who's entering work into

TFS all right so that's artifacts the primary roles and these are the support and helper roles so we have a game director and design director on site that provide clarity on vision and vision and pillars so they've given their presentation but you know that's great you see a PowerPoint that says these are the vision but then you sometimes you have trouble as a team figuring out well how do we connect to that vision the people that essentially own that vision are in the room so you can go right up to them and and ask how does my team I'm on the sandbox team how does that feed into the the vision that we have for this quarter I mentioned the release leadership team we a Bungie also called as the triage team so there's a cross discipline leadership team that are as final kind of buck stops with them as far as decisions on release planning and they can unblock the team's the amazing value of planning day I just

can't overstate this is the fact that you have all of the decision-makers on the release in one room I mean imagine you don't have to imagine but how hard it is to get attention and decisions made just through indirect means through email trying to schedule meetings with really busy people you can get one person but not three of them and then you get all of this triangulation and planning day you have everybody in the room so we even had one team report that they had an issue that was lingering for literally two months they got into planning they had all the decision-makers there they got it done in ten minutes it's very efficient it people think oh my god it's not efficient to get all these people in a room it's a it's more efficient trust me and then there's the agility coach or the chief scrum master that's me I kind of you'll see me in action in the video

I'm going to show later in this presentation so I'm like a sheriff I don't let anybody out of the room until all the dependencies have a resolved sticker on it I chase them down all right we talked through the artifacts the agenda the role roles I now wanted to illustrate how one user story or dependency might move through planning day so that way you know I'm giving you all these kind of explanations but now I just want to show you if we take a user story how does it move through planning day and how do we use artifacts to get the work committed to so I wanted to use a user story that would relate to destiny to campaign we had something called Cevallos ward of dawn which was this in-game vignette that was was really calm complex it wasn't an external vignette it was an in game than yet so

I'm gonna what I'm gonna do is I'm gonna show you the sequence as the player experiences it and then we'll break it down and see how this collaboration worked to make this possible this is a really loud one [Music] okay so in that you noticed that you were just you're shooting cabal at the opening campaign then all of a sudden Savalas starts talking and then he spreads his bubble shield and you have the cabal coming at you and they're their missiles are being deflected by that shield so why is this so complicated so the campaign team would normally be able to take care of most everything within their campaign but that required in in gameplay adjustments so there were individual adjustments

that had to be made as well as game objectives that were impacted so that required them to basically be dependent on what we call the NPC team or the vignette team so in order to execute on this they needed help very clear help from the NPC and vignette team and so how would this user story and its dependencies be managed during planning day all right so let's say this is the campaign team they're at their table they've got their team boy they got their backlog so they had campaign team we build the first six missions of the game that's their mission so what they do is they create a sticky note for the user story for the overall experience and using the user story format we do it

from the player's perspective so as a player when I clear the enemies in the tower Cevallos protective ward of Don is triggered so that's the the the end player experience so though the campaign team is responsible for the overall experience award of Don bubble shield itself is created by the NPC vignettes team not their team so they create a physical dependency in the form of a red post-it note two NPC team from campaign team and they say what sprint they would like it in a then the dependency runner from the team which is considered the requesting team goes to the dependency board what's the post-it note into the column for NPCs and in the sprint that they wanted so it would look something like this the requesting team would have the post a note in the NPC column they want its print 6 so the providing team then

checks the board and picks up the dependency the main job of the post-it note the poster note artifact is an agile coach you know Patrick O's love love post-it notes they're but they're really useful because they you know so much that we do as knowledge workers is invisible so post-it note actually crew makes a thing makes a physical thing of a thought and then that physical thing comes into being and then you have to deal with it and in this case in planning day we basically gets butts handed round it it actually represents a conversation that needs to happen and eventually it represents a commitment so it drives the main job of post-it note artifacts is to drive a conversation it's very effective so driving conversations and bringing them to resolution is the main point of planning day as someone said to me the process in

the ritual is a way to engineer human proximity I really like that engineering we were engineering human proximity so engineering human proximity would provide just a lightweight structure some tools to more efficiently get problem-solve face to face Alex Alistair Coburn coined the phrase osmotic communication so it's communication through osmosis through proximity so here we have in this picture we have a producer at the dependency board talking to a member of the UI team who happens to be in this room and there are other members of the team in proximity you know tuning in or tuning out is needed these are quality two-way conversations that happen they might not other they might otherwise get lost in emails or not even happen at all so after the conversation

between the campaign and the MPC team the read dependent dependent C note is then brought back to the providing team considered and placed on their backlog okay so then we go to the providing team this is their backlog incoming and they caught do a costing exercise and they're able to actually accommodate it put it and they put it into their electronic backlog which is the ultimate source of truth and the work is then it is a thing the work is on their backlog it will get done so the dependency sticky is then brought back to the board and then a notice added resolved so this might be kind of silly to you but we actually learned it seriously it's really helpful

to have a physical thing that says something is resolved because we open up so many of these issues that we need to deal with we want to close some that we have so we have some more cognitive capacity so it's really important to market resolved get that closure and what it says to everybody else is that there's a commitment that was made so it's a public way to make a commitment literally we we can't leave the room until all the dependencies are resolved either resolved by the other team accommodating the work or if they can't accommodate the work the future work of that team is then adjusted and the expectations are adjusted so it's intricate the intricate player experience the in-game word of Don vignette can now be worked on by two teams in parallel and that coordination is set up at planning day making rich intricate destiny to experiences like this possible [Music]

okay last bit of this and then I want to show you show you a video so complex problem-solving at planning day so I just described what can be considered the golden path the team realized they needed help they talked to the other team they had a conversation they understood it they cost it and they were able to accommodate but what happens when things come up and the teams can't agree maybe there is a difference in opinion on what is what is a priority so what happens in this case if the teams can't sort it out so let's say the NPC vignette team says we're all full there's no room at the end we can't do your ward of Don but the requesting team feels it it's the Word of God is really important so they're stuck well what's is they said what's unique about planning day is we have all of the decision-makers in one room and trade

offs can be discussed and decided right there on the spot so in case of an issue then the dependency goes to the risk board so I mentioned the risk board the you'll notice in proximity the release triage team is right next to the risk board their job is to look at the risk board and when something comes in they jump on it in that wonderful servant leadership mindset so then they talk to both teams and they understand the trade-offs and priorities and make a decision so goes to them if sometimes there might be some follow-up discussion needed but it's considered resolved because somebody on leadership owns solving that issue so those are the mechanics the dynamic ritual called planning day the agenda the roles artifacts an illustration of how it works do you want to see bungees

planning day in action [Music] we've seen a ton of positive outcomes from doing planning days here at bündchen we have hundreds and hundreds of people are funky all working in all sorts of different disciplines and teams and even with their best intentions they can run afoul look assuming that other teams are doing work that they're counting on having everyone sit in one room and really work through their problems and you come out of the day with a really clear understanding of what your team is to manage what do I say yeah yeah we're gonna do there's rituals in place like going up to the boards and writing out your dependencies new problems it requires them to go and talk to their teammates and figure out what they need to do and really make sure that the problem is fully solved and then we even students

who things like making sure they're resolved so there's that follow up and so it's exposed it to the leadership to their team every other team ability does increase that accountability you're willing to challenge it yourself that ask the question them is the students drinks does everyone know [Music] come out of this understanding your priorities and really challenging yourself to see what you can build so those people can then go out of this day with a really clear mandate about what they're doing the next day the rigor that you add I really forcing yourself to drill down and ask tough questions can allow for the project to be better scoped and ultimately more successful [Applause] [Music] right yay dependencies resolved

celebrate you celebrate alright so I just want to wrap up with a few additional slides and then some lessons learned and then I'd be happy to answer questions in the overflow area afterwards so you may be wondering how do we keep tabs on these dependencies after planning day because everyone gets excited you can see they're collaborating they're having fun and then it's like okay where did the dependency go well it's it's in their backlog but it's tracked separately with a midpoint check-in we call dependency check-in so this is done uncited Bunji we have a conference room you'll see here we have teams set up in different parts of the room and you come there you prepare basically the product owners and the producers only so we don't have the full teams there we prepare to check in

on dependent work go around the room have conversations you need and your team is lips your team is done when those depending on you have gotten what they need from the sink so we actually do this ritual word you're about to leave the room it's like okay I'm on the cabañas team anybody need to talk to me no okay I'm leaving or yes I do so it's it's really an agreement between the people in the room that they get what they need out of dependency check-in so we've done this almost 12 or 13 times now with many different releases and we've tweaked it we've never done it the same way twice but it always has the same elements as I said those basic elements of planning and dependency resolution but we played with some things that I wanted to share you share with you what we learned so one of the things is how much prep do you do how much prep did the teams do because you have that that part of the agenda where the teams get to actually work together

and plan plan so yeah the first time we didn't do that much prep and then we overcompensated the next time and the the product owners like did all the planning and the and the teams felt left out so we then just had to loosen it so it's like Goldilocks you know it's too hot too cold just right wrap up how to share out the team's plans efficiently so you have all the team as a plan how do you get that visibility it is in TFS but that's not really effective so at first as I said we tried that team science fair format but it was it just was undone useful and but what we did is we brought those team boards back and we would display them back at bungees so that anybody that wanted to actually look deeper into the the team's scope for that quarter could do all team members have to stay for the entire day getting an artist to stay in a room planning for a whole day is not

the easiest thing so while people really saw the value we it was important when we first did it we had like mandatory all the teams have to show up we even gave him snacks and food so you know made it worth their while but when once we did it people saw the value so it was it was not as much of a hard sale sell after that but what we've done is we allow the teams to self organize they can determine who they needs to be there for the dependencies check-in section so I really recommend if you do this gather data after every planning day this is something that you want to continually refine and reflect so I use Survey Monkey send out survey monkeys here's an example of one recently cross team planning day was a valuable in gaining cross team visibility and identifying dependencies so we have roughly like 89 percent said yes also does your team

have a winter build plan that they believe in because that's what we want to come out with do you have a plan that you believe in I can't believe it I can't believe it ninety percent said yes so that's a confidence that they're exuding we we have confidence in our plans briefly many configurations of planning day we've done large off-site mid off-site mixed off-site on-site and all on-site so you can you can do this you know if you have a big room at your studio there is a value in taking people off-site so I'd really recommend trying that first because then people are away from their workstations okay so I wanted to just recap here and then I'll give you some takeaways and then we'll be done planning day ritual what did we you know what did we gain so we saw a positive effect our first major winter build after the first two planning days

had more complete work in it than we had previously so we had regular alignment with all the teams with the product vision and pillars we what we got from planning day we had dependent work identified and tracked for the first time we had authentic cross team commitments made face to face so we did that human proximity engineering to get those commitments face to face and there's nothing like someone it's nothing like the go balance team telling in or that you know the visual effects team telling the cabañas team you're gonna get that effect like face to face there's something that's increases the accountability and it's efficient and transparent decision-making with the decisions reported out to everybody all told it increases the predictability now we know better what we're getting at the end of the quarter in our quarterly build and our agility our ability to pivot if need be this was a quote from

our d2 team retrospective planning days are now a vital part of shipping our games actually it had an expletive in there but I had to take it outside awesome key takeaways I want to leave you with the first one is as your game grows in size and complexity the benefits of well-designed well-executed sync ratar-o whatever your size and complexity whatever that growth is whether it's from five people to ten people or ten people to fifty never underestimate the value and impact of face-to-face communication do not use size as an excuse not to talk face-to-face I think that's the biggest takeaway you can engineer really efficient face-to-face communication

with dependent teams spending a whole day planning feels like a huge investment but it's well worth it be bold take a bold bold action to get to get your team synchronized and lastly don't get complacent continuously inspect and adapt listen to the benefits find you no measure the benefits of planning de measure people's engagement how you can you know make it better like we do surveys and somebody said no more oatmeal cookies it's like okay now we know let's make chocolate chip cookies so there's lots of stuff it will help you reduce your blind spots that's it my hope is that you take something away from this that you find useful or inspiring to try and experiment with in your own Studios whatever the size to keep your teams synchronized thank you