 All right. Hello, everyone. Welcome to our session, Scopey Change Management in Drupal 8. We're just working out some change management on the fact that Google likes to just re-engineer their UX for all of their tools at the best possible times. Yeah, I mean, actually. So we're super excited to be here in New Orleans. Everyone having a great time so far for Save Drupal Con? Woo! All right. So I'll just kick off with introductions. My name is Molly Burns. I'm an account director with Phase 2. I've been around the Drupal space since Drupal 4.7. And I was one of the early content managers for one of the largest early corporate Drupal platforms in Drupal 5 and Drupal 6. So I've sort of seen all of those dark days and edge cases around checkboxes. I remember when the blocks page, you managed it with moving, changing negative numbers and negative integers. And that was the administrative experience. And fast forward to now. And I'm working on a Drupal 8 platform. And I did a Drupal 8 site last year. So it's just amazing to see the software and this community evolved over the years. And super excited to be here talking with you all. And a fun fact about me is that I'm a crystal collector and I have a rockhound. I actually have one with me right now. So we want to start off and talk a little bit about some 0G moments. So I don't know if anyone's ever been in a project and your stomach drops. Something comes out of nowhere. And everyone's making a fuss. And that's the mode where we operate in. So we sort of wanted to kick this off and share some personal 0G moments. So the story that I'm going to tell is for my first project at Phase 2, first project that I was launching at Phase 2, I was working on a university site. We were upgrading from Drupal 6 to Drupal 7. And I don't know if anyone's ever worked with a university or been a part of university. But university IT, a lot of times it's legacy systems. They're hosting a lot of authenticated users in-house. Very complicated. There's a lot of characters, people that have been there for 20, 30 years that are running these servers. So it's definitely a new world and a deep world that I learned a lot about. And we were doing this project. And we were trying to get the servers ready. And they needed to be requisitioned internally in the university. And there was a whole lot of complicated steps to that. And we were at our final week when we were supposed to get the servers. And I get an email that says that the sysadmin was stung by 20 bees the day before. And I was, first of all, is he OK? What's going on? But secondly, just sort of like, OK, now we're definitely going to be delayed. And so we had to work through that. But I just remember being like, have anything else that could go wrong with these servers? Now there's a bunch of bee stings involved on the scene. Hi. Is that better? OK. I had built this personal fitness goal tracking app for a startup. And literally at the 11, 59, 59th hour, the product owner, the owner of the company, decided that she wanted to pivot. And have the entire product now be a management by objective goal setting app for the financial industry. Right? She got her investors on board with this. And we reused as much as we could. But there was just so much that was just had to be scrapped. So that was probably the most extreme case of a scope change that I've ever experienced. So in the name of kind of the after lunch lull, and also because this is an interactive conference, I wanted to just spend a couple minutes for folks to maybe share a story of one of their zero G moments with either the person next to them or a group of three, if that makes sense. Just to sort of get us connected and also kind of grounded in this and also to meet some new people, because that's one of the goals. So just take a few minutes to maybe share it. And this is not, you don't need to name any names. Yeah. And then we'll just kind of tap this mic and we'll restart up again once you guys have a chance to talk through that a little bit. So yeah. Four seconds to wrap up. The thing to talk about. Our projects go wrong every single day. And I'm just so impressed that you guys really had nothing to say to each other. OK, so let's run through what we're going to talk about today. So we're going to talk about starting with goals. Oh, just one quick note. We obviously are going to have a sci-fi space theme to this presentation. So just bear with us as we build that. So we're going to talk about starting with goals, methods for controlling or managing scope, how to deal with change. Then we'll talk about specifically Drupal 8 and how some of the factors of Drupal 8 will impact how we manage scope and change. And then we're going to do a couple of scenarios to kind of tie it all together. The first thing that I want to talk through is what we do when we start off any project or product build, which is define our goals. What are we doing? Are we going to the moon? Are we going to Mars? Are we building a platform? Are we building a site? Are we trying to drive donations for a nonprofit? What is the goal that the system is accomplishing? And everything we want to be doing in our projects, we want to be able to trace back to the primary goal or secondary goal. Sometimes projects have several goals and they are mostly aligned. But sometimes if they're in competition, we work on prioritizing goals and figuring out how we can achieve both goals or three goals. But getting a sense of before you even commit a line of code or decide on your technology, it's really important to figure out what you're building and why you're building it. And I can't tell you how many times people are like, let's just start building. Let's commit code. We want to start immediately. We want to get going. We want to get going. Why is it taking so long to start? It's like, believe me, you are going to be very glad that we spent two weeks walking through your requirements, helping you define your goals, and getting refined on why we're doing what we're doing. Because when you get into the thick of the project, through some of the scenarios, we're going to talk through in a bit, having those goals as your basis and your constraints for coordinating and collaborating and defining how you're going to approach different things that come up in the project is so critical. Kind of cheesily grabbing the definition of scope from Google. Some of the words that I really like here are opportunity and deal with. And I like deal with in terms of like, oh my God, this is another thing we have to deal with. And I also love that some of the synonyms include both gamut and confine. So there's so many contradictions when we talk about scope. But what we like to define it as is what we are working on. So as I mentioned earlier, I'm an account director, so I do a lot of work on the high level planning and strategy, working with different product owners. And this process of scope management, once you have your goals, the next real process for me, and what I kind of do a lot of is this process of transmuting confusion into clarity. So every project usually starts with a scenario where someone is trying to explain to someone else something that doesn't exist yet. And in that process, there are a lot of like, assumptions involved that come up and we're really working through trying to tease out what someone's understanding of one requirement is versus how we're gonna actually map that requirement to a set of tasks that can actually be achieved by a developer or a site builder. So that's a big part of the scope management. So let's say we're going back to our spaceship. We're building a spaceship, we get this box. We're expecting that we're gonna open this box and we're gonna get a spaceship. And this is what happens actually with a lot of Drupal and CMS build projects that I encounter. We're like, great, we're signed up, we're doing the Drupal, we assume, we open the box, it's all there. We just spin it up two weeks, we got our site, right? Okay, well, a lot of times it's really important to talk through what exactly people's expectations are and they're not necessarily going to be getting the hyperdrive spaceship when the box is opened. What actually they're gonna get when the box is open is a pile of Legos. And these pile of Legos are great content modeling tools and extensible CMS framework. There's a ton there that can be modified and configured to achieve business goals but it's not gonna be out of the box, that hyperdrive spaceship that some people might be expecting who haven't done a technology project before. And really doing this piece of education around the work it takes to put together and align all of the pieces. And with Drupal 8, we've got so much in core and it's a lot of opportunity for site builders but there's also a lot of time and care and expertise that goes into how to configure the system so it's really going to be the best possible system for the end users and for the product owners. So it's kind of, in my experience, having the conversation early on about what is in the contents of the box when you get it with Drupal is really, really important to start the conversation with that confusion into clarity. That's one of the big ones that I always really start with upfront in the project, just like, okay, this is what's in our box. And I guess that's one thing to take advantage of being here at DrupalCon is to learn what's in the box and what's not in the box because that's an important piece of communication to have with your product owners. Okay, so we talked about starting with goals. I'm gonna walk you through some other techniques that we use to manage scope. So first we're gonna define our features and I want you to just listen, right? Like, particularly if you come from a technical background or you've been working in technology as a project manager for a long time. Like, you can jump ahead to, oh, here's how we could do this or here's how we could do that. Stop, like, quiet your solution mind and just listen. A lot of times when you're thinking about how to do something, you might miss something really important. So first we're just gonna listen. I'm not talking waterfall here, we're just gonna listen. So someone's gonna say, I want the wings of this ship. I want the hyperdrive of that other ship. I want the invisibility cloaking device of the other ship. We're just gonna listen and write it down somewhere because we don't think that we can get it all. And then I want a quidditch pitch on the landing deck. Okay, so now that we've written them all down, now we can talk about what our technical approach would be. And again, this is not waterfall. It's not that we're gonna write everything down and go away for two years and come back with a web app. It could happen in the course of a single conversation but it's important to do those things serially. Once we figure out our technical approach, we have some idea of the cost. The cost could be time, it could be money, or it could be effort. But once we get our heads around how to make those features become software, we have some idea of what those trade-offs are gonna be and that's when we can define scope. So we have goals, we have features, we have technical approach. We throw them together in this matrix that measures value and cost. And then we have an idea of what's really important. So things that are off the chart, it is highly unlikely that we're gonna do those. No, it's too expensive. Is it really that valuable that it's off the chart valuable? In which case we need more effort or money or whatever. Otherwise you can get into conversations about other alternatives. Maybe we have the warp drive. Maybe we have a hyper drive. What can we do if we can't get that infinity drive? Also don't assume that just because something is low cost and low value that we're gonna get it for free. It's low value. So why do we even wanna talk about it? So putting things up even visually, like imagine doing this on a wall or a virtual wall with your product owners, it really helps take the heat and the emotion out of things when you see it based on these kind of facts. So we use this a lot to help manage scope. So conversation alert. Scope management is completely a team sport. The entire dev team, the entire product owner team, all the stakeholders need to participate in this. It is a conversation. It's a collaboration and we push ourselves toward finding creative solutions. At phase two, we actually have practice conversations of scope with all of our clients. It's outside of the fraughtness of real project scope changes. We do it in a really abstract way so that we can practice having these conversations about trade-offs for things that don't really matter. And the more we do this, then we are practiced at getting away from the finger pointing or the panic and moving into a solution space. So I would highly recommend whether you are actually practicing as changes as you're developing scope or as changes occur on your project. But to have these conversations is gonna be key for you to manage things. If you're just emailing, you're not, you just don't have that human connection which is really key for scope management. So now that we know what kind of spaceship we're building and we've got the gamma rays coming from outer space and we weren't expecting them to be here. So every project, as I mentioned before with the bees, can have some things called unknowns or changes that come on. And that's life as well as software projects. It's the only constant that we have in this ever-shifting world. So when there is a problem, which there inevitably will be a quote problem, I'm gonna talk through just some strategies about how to work through and manage change. So I don't know if anyone's familiar with this very famous Apollo 13 moment where they have a problem with the spaceship and they call down to Houston and everyone on the ground in Houston immediately gets to work with the folks on the spaceship to start problem solving. Now, had they seen this problem before? No, they hadn't seen the problem before. But they had worked through so many different scenarios about how to solve related problems and the teams had already been working together through drills and different scenarios. So they were really, really well-equipped to come together and through a very ingenious set of events bring these astronauts home. So that's definitely something that, back to what Ellie mentioned earlier and related to the team sport is that everyone in the project can be a part of the team to get to a place where we can manage unknown scenarios. So this quote actually comes from Donald Rumsfeld. It came out during the whole weapons of mass destruction thing which I won't opinionate of whether or not that was a no, no, no, not. However, I will share that this quote actually came up because it was used in a technical approach meeting that was put together by the lead developer on the bees and IT project that I worked on. His name is Ray Stewart. And he did this great presentation for the client about the Drupal 6 to Drupal 7 migration process. And he started with this quote and he walked through all of the different known knowns, all of the different known unknowns. And then he also started to posit what could be things that were unknown unknowns, the types of unknown unknowns that might come up in the project. And this was again my first big project and I just felt like it was such an incredible learning experience to see the lead dev actually be managing change in this way. And I've really taken this with me throughout until a lot of my subsequent work in subsequent projects. But, you know, the concept of the unknown unknown is a little bit sort of funky. So I kind of wanna walk through this example. So has anyone heard of the planet Mercury, you know, closest to the sun? All right. If anyone's been reading the news yesterday, there was this big moment in astronomy where Mercury was sort of doing this eclipse thing, it was called a transit, where Mercury was kind of marching in front of the sun and there's this like NASA writing news about it. So that's totally like a known known, like we know Mercury was transiting the sun. But there's also sort of an unknown unknown about Mercury and it's called Mercury retrograde. So Mercury retrograde is actually a term from astrology and it refers to when the planet looks like it's moving backwards in relationship to Earth. And different folks in the astrology world kind of out there stuff believe that the actions and the movements of the planets in the heavens might actually impact the daily life of people and may actually impact certain things like web servers. I've had a lot of experiences during Mercury retrograde where some servers are going down. Maybe it's Mercury retrograde, maybe it's not. We don't know. But that's just one example. So now let's talk about some strategies for actually managing risk and getting ahead of these unknown unknowns. So the worst time to actually have a conversation about how to manage risks and what solutions you're gonna put in place is when you're covered in ectoplasm on the spaceship in your fire suits in the middle of a huge fire. The best thing to do is to talk about these things beforehand so that when you are in that there's a problem moment you already have a basis to go from to work through solutioning. So some of the strategies that I'm a really big fan of are regular risk meetings. I'm working on a project right now. It's a Drupal 8 platform build. So we're building a Drupal 8 platform. It's gonna be the basis of a platform for a major media company. And the project came in, it was very, very rapid. And there's a lot of stakeholders, even shifting goals. So we decided early on, like hey, we need to have two risk meetings a week and we need to talk through all the risks and the mitigation plans openly and collaboratively with the product owner. And in the first meeting, I remember talking to the product owner, I said, you know, I said, this is my favorite meeting. I said, you're gonna love this meeting. And initially, she was a little nervous. She's like, all right, risk sounds kind of scary. And by the end of the first meeting, she was like, I get it, this is my favorite meeting. Because we were talking about the risks before they even happened, what we were seeing, and then we were putting plans in place to mitigate. So the hardest thing to do is see something coming and feel like you can't stop the train, right? But if you are getting ahead of risks with open, transparent mitigation plans, this is a little screenshot of the way that we track risks in this project. You know, you're able to really start to prep and get ahead. Another thing is important when you're launching websites. So I don't know how many people have had a situation where there's been a launch event that's happened and something crazy has happened. Like a Drupal 8 site that I launched last year, it got completely spidered by some unknown entity that was out on the internet that had been scraping their old site and pulling the content into some content repository. When we launched the site, it started to scrape the new site, but it was like out of nowhere and it caused a lot of stress on the database. So that's just one example of how in launch protocols and rollbacks, we had actually had a whole plan for what to happen if there was an issue at launch. And so when it actually did happen, we calmly had a plan and we moved into the solutioning mode. So there is another category of risks that I want to talk about, which are sort of a more tactical and long game risks I like to call them. And these are risks where you can say it in the beginning, but either people aren't ready to hear it, they need more evidence, or it needs to have a little bit more of a case built for something to move. And this happens a lot, especially when there are a lot of different personalities involved. So in the case of managing a long game risk, I often sort of will work with the project teams, with the product owners to lay out the plan and work from multiple angles. And a lot of times there will be a key moment of message delivery. Maybe it'll be in a meeting or it'll be in the context of a sprint review. And in that moment, it's really great to think about who's gonna be delivering the message for this kind of aha moment for sort of a risk solution to sort of unfold. And so in the context of this aha moment, a lot of times what I'll do is I'll tee up a conversation that I know needs to happen. And I use these, what I call the metaverse meeting tips. These are some meeting tips that actually came out of when I worked at this big media company in Drupal 6, very political, lots of big meetings and politics. And so the tips are really simple and they help you get to this long game risk management strategy. It's does this need to be said right now? Do I need to be the one to say it? And if someone else has to say it, like how do I make that facilitate that conversation to happen? And a lot of times I'll be in a meeting or I'll have a meeting coming up and I'll be working with a tech lead or one of the requirements folks that we work with and I'll say, hey, at a certain point in the meeting, I'm gonna turn to you and it'd be really great if you could say that a thing that you said to me yesterday and then they'll say it and then it'll start the conversation and move us towards a solution. So definitely working through these conversations from a strategic standpoint, both in the mitigation plans and also in sort of the more delicate long game risk management are really helpful. Okay, so once again, we have the conversation alert. So because you have practiced talking about risks, right? People are afraid of risks. They think it's a bad word. It is not and if we try to put our heads in the sands about it, we're always gonna be caught off guard when change happens and the shit hits the fan. So if you have practiced this, like you've written down, what do we do when new droids come in? Well, we gotta take them to the garage and clean them. And only then can we whine about wanting to go to Tashi's stage and to get some power converters. Right, that if we have not had that conversation, we're gonna be standing there whining and nobody wants that it doesn't help us move forward at all. Okay, so now we've talked about scope and change and now we're gonna talk about Drupal 8 and how that may change a little bit or influence or impact how we manage scope and change. Great, so as I mentioned earlier, you have been around Drupal for a while and I've sort of seen the system evolve and it was really great to be in Dries's keynote today and see all of these things, especially the admin experience, be like 46% or 72% of the focus. So there's a lot of great stuff that's happening in Drupal 8. And I've been working with it, this is I guess coming into the second year of working with Drupal 8. So there's definitely a lot of new things there and sort of new wrinkles that have come into play when managing the projects that I just wanna kinda talk through. So just to sort of give you guys a high level summary, I know people are pretty aware of a lot of this stuff but I'll just talk through some of the highlights and things that I particularly have kind of gravitated on of what's in Drupal 8. So there's been sort of a major, major rethink of the Drupal 8 admin experience in the UX which is definitely huge when we talk about what we're getting out of the box. There is definitely a lot of improvements there. And we also have tools like views which I don't know if people know views, it's a module used to be in Drupal contrib space but it was sort of like a requirement basically for building complex content lists and pretty much doing any kind of querying. So now that that's in core, we also have a complete rethinking of the multilingual and then in addition, we have the configuration management which is really a layer that's been built under a laying Drupal that allows you to move the database configurations which are all those checkbox and all those settings easily between environments so that your site can be more stable. And last but certainly not least, there's a brand new front end templating system which has been introduced in Drupal 8. It's based on Twig and it sits in with a lot of the other PHP breast practice libraries that have been brought in to Drupal 8. But you know, it's important to also note that back into kind of what we're getting in the box that we still have things in Drupal that are sort of Drupalisms that are part of the framework of the system that were within. One of the best examples is the pager count. So back in Drupal 5, I was when I was queuing sites, I saw, well, it says I'm on page two but the URL says page one, which seemed extremely broken. And you know, I logged a bug. Index starts at zero. Well, I mean, that's not how people count. Unless you're a computer programmer or a computer. So, you know, that is still in Drupal and you know, it's definitely still something that you know, work does designer won't fix. So there still are things like that that do come up and I think it's important to again, understand the constraints of what the box is and how the system is. And if you're gonna be trying to change something like that, just understanding the costs that it might take to sort of flip something. We really need this thing to be moved down, you know. It's like, no, you don't really need that or maybe you do and like, if you need that, then we can prioritize it. So I wanna talk through the module. So everyone knows in Drupal or if you don't know, modules are sort of like those extra Legos that you can add on to make the ship even more full-featured. And in Drupal 7 and before, there was tons and tons of modules in the contrib space that you could add onto your site. And to basically get a site that was relatively like functional, usually you needed a fair amount of modules like, you know, at least like 30 modules. You know, you needed modules to do content lists. You needed modules to do layout management. You needed modules to do even vanity URLs. You need a module for a WYSIWYG. You needed modules like features to do your configuration management so you could, you know, move your configuration through different environments. So there's a really, you know, deep amount of contrib modules that were in Drupal 7. In Drupal 8, a lot of these have actually been pulled into Drupal Core and you can actually get started and building a site and the modules that are in Drupal 8, you know, there obviously are modules and there's a healthy contrib space as well, but they're sort of even more specialized and even more kind of, you know, flashy features or special kinds of caching or workflow. And, you know, just as an example, the Memorial Sun Kettering site that presented on last year, Drupal Con, I think their previous site in Drupal 6 had like over 150 modules. The Drupal 8 site, I think, launched with under 20. I think it was nine contrib modules. So, I mean, that's the amount of difference. And we'll talk a little bit more about sort of where some of that other code goes, which is, you know, potentially in custom modules and some extensions, but, you know, I've also seen a lot of kind of RFPs where people have talking about their Drupal 6 site and they say, here's all of our modules. Are you upgrading all of them? And the answer really is, no, no, we're not gonna just start upgrading all of your Drupal 6 modules one by one to Drupal 8, is we're gonna look holistically at what you need to accomplish and really understand how we can do that in Drupal 8 and then back into what modules we need. So that's the modules conversation. And then sort of kind of to roll all the module conversation together, I wanna kind of come back to the global because the global aspect of Drupal 8 is a really great example of how the modules have been condensed and brought into core. So when I worked at the media platform in Drupal 6, we had a big global site platform, right? You know, sites in 20, 30 languages. There was about like 20 modules needed just to get the thing translated, localized, URL routed, country codes, translation imported. Everything was on like six different screens of checkboxes and you had to go to like four places to just turn Swedish on your site. And you know, now with Drupal 8, I mean that whole process has been completely, you know, re-architected and integrated into core. So on the Drupal platform that I'm working on now, we needed to spin the site up in another language just to show something, to see how it would look on reading right to left. And we did it in like under an hour. And I was just like shocked because before there was a lot of time spent pulling the patch from this module. Oh, we need to patch this module. This patch is in conflict with this thing just to get something like that to work. So, you know, this example is sort of on a small scale of kind of what we're seeing overall now with the sort of weight of module interactions and patch management that is a little bit different from previous versions of Drupal to the current Drupal. And then I wanna talk a little bit about front end magic, which I alluded to a little bit before, but this is really exciting and definitely will be impacting a lot of people's projects. The templating engine that's in Drupal 8 is called TWIG. It's a modern PHP templating engine. You don't actually need to know like Drupalized PHP, which you did need to know to theme a Drupal 6 and a Drupal 7 site. I remember when I worked at this media company that the skills needed for a good Drupal femur was like so specific. It was like, you know, a list of like JavaScript, amazing at JavaScript, CSS, HTML, plus PHP, plus you've done Drupal config. And now there's so much exploding in the front end world. There's all these different JavaScript frameworks, ReactJS, AngularJS, we got a lot of people talking about headless Drupal. And we really do have an opportunity to integrate a lot of the best practices and a lot of the cool stuff that's happening in front end development without necessarily having people to like fit it into Drupal. And the markup can be cleaner, which was always a big sort of, you know, fiery point of all the Drupal femur purists who love front end development, but like also really want to make beautiful markup. So that's definitely something that I think you guys are gonna be probably, you know, interacting with a lot and the opportunities for like bringing in people that haven't even worked with Drupal. On the Drupalite project that I worked on, we actually had the front end that was designed and built by design agency and the front end developer, she had never done any Drupal before, we were able to integrate it and we got about 80% code reuse. Wasn't completely headless, but it really did work, which was pretty incredible. So the last thing I wanna talk through here is this concept I call stack inception. So mentioned that we've pulled a lot more stuff into core, right? There's a whole lot of different layers, we've got symphony, the PHP layer, we've got composer, dependency management, we've got twig, we've got this thing called big pipe, kind of know what it is. There's all sorts of stuff that's under the hood now and what that means is that there's a higher level of complexity when it comes to debugging and edge cases and especially when you're working with a lot of different layers and you're trying to extend things within Drupal core. So we're gonna talk a little bit about what the stack inception, what it means from the object oriented programming perspective. Okay, so I want to talk about object orientation because it's gonna be important for you guys, even as PMs to know some of the basics of it. It will have an impact on how you're gonna manage your project in several ways. Okay, so an object is an entity that could be a physical thing or an idea or a part of code. So it actually can be all of those things which makes abstraction or thinking about goals to features to actual code a little simpler. It has state and behaviors. So it has something and it can do things. And there's these four elements that object orientation makes possible. So abstraction, that allows us to think about things not in their messiness but as clean things, right? So when we talk about goal feature code. Encapsulation allows me to hide my mess from you. So I have an, my object has an interface. It will give you a piece of data. You send me the command. It could be a pain for me to gather what you need but you don't need to be bothered by that. It's pretty sweet. So that's one of the key benefits of object orientation. Modularity, so an example of object orientation in life is the universal remotes. So I have a remote that'll work on my Sony and my Philips and my LED or LCD. I can't remember the name. Whatever, another TV. LED? I don't know, whatever. LG, thank you, thank you. So it'll work on all of those because we've got these interfaces that we can talk about and sometimes we call them APIs. And so modularity is the idea that at one point we might have had like a settings interface that then it basically dumps me into your mess on your Sony and it dumps you into the LG mess, right? And then you've got all these menus and I've got to click all this stuff. There's some benefit in that but there's also benefit in having like an input interface where I can then choose what my input is gonna be much more easily. So that's an example of modularity. And then hierarchy, you guys know what that means. There's no hidden meaning here. It basically allows that we can inherit from objects. So this is rudimentary, UML, to kind of explain some of the concepts of object orientation. So our parent class here is a vehicle. We're not even showing some of its states but we've got some behaviors like we can count tires, we can return an engine type and we can go. So these are the vehicles that inherit from vehicle and you can see how they're gonna have some different things, right? So airplane's gonna need to extend vehicle because it's gotta have something to do with wings. You could argue and boat similarly like the tires are less important but it's gotta have some flotation stuff. So they're gonna take vehicle and make it different. Spaceship might be so radical that you might say maybe it shouldn't even inherit from vehicle. And you could also maybe say maybe spaceship and airplane have a relationship, right? So see how I'm talking. I'm talking about things in the abstract and how they could relate to each other and how we can build on them. And that's kind of how you start thinking when you think about objects. So then we've got car which breaks down and note that we have some namespace stuff going on with Tesla and Mercedes S and that's a key part of the namespacing within PHP and Drupal. Note that Tesla has two parents, like it inherits from car but it also inherits from Elon Musk. He above him has a really long hierarchy of entrepreneurs and great thinkers so he's not like born like that. He has to inherit them. And but he's got a new method he's gonna pass in which is share it. And so if you are building a car from Tesla you're gonna have share it and you're gonna be able to through that do things that you couldn't do with MDX without getting sued by Acura. So does that make sense? So when you start to think about things you can see the power that comes from using objects. Okay so the key bit for Drupal is that you don't need to hack core. So I saw a guy with the IHackCore t-shirt and I wanted to take a picture and say sweetie you don't really need to do that anymore because what you can do is extend core. So you can take all the glory that it is but you need to do something different. You don't have to patch it. You can just take it and modify it and have it be your own thing. So we could say that Mark Watney modifying the MAV in the Martian was either a total hack or the most desperate and beautiful extension ever but that's the basics that's gonna be key as you're managing projects. Okay so the final thing about object orientation is that well this is really about software development in general. So inevitably your product owner is gonna say is that possible? Like I've got a great idea is that possible? Okay. Think about it may be possible but just because we can do it doesn't mean we should do it, right? So shooting Bruce Willis and a rag tag team of miners up to destroy an asteroid might have seemed like a good idea but was it really necessary? So again when we think about the goals and the features and the implementation keep that line right? Every time is that possible? Sure I used to say we can do everything except make Cindy Crawford come out of your monitor but do you really want all that? Sometimes people would want Cindy Crawford to come out of the monitor but thankfully that wasn't possible. Okay so here we go. Okay so now we're gonna do a little bit of role playing on our holodeck. These are our holodeck hats so when we're in character we'll be wearing these hats. I am gonna be the project manager and Allie is going to be our developer and we're gonna have a conversation about our Drupal 8 project that we're working on. Hey Allie, thanks for agreeing to meet such last minute. I know you've been working hard on the sprint. So I just had a review meeting with product Tina, the product owner and she was asking for a tweak to the comments page. Apparently it's really critical that we move the comment box from below the comment listing to above the comment listing. Since it mirrors the current system that we're rebuilding and it would be a big win for stakeholders for them to feel like the system is gonna be somewhat like the old system, I told her that it didn't seem like such a big deal and we could probably fit it in but I wanted to check in with you and just see your thoughts of how we could strategize to get that in. Yeah well actually like feature B that we've been working on, we thought I was gonna take this sprint and next sprint but I think we're gonna actually finish at this sprint. So write it up and we can take a look at it. If it's important to them let's pull it into next sprint. Okay great, thanks. All right, okay it's a week later and we're at our sprint stand up. So hey Ellie, I wanted to know if you could give your update. What have you been working on in the last 24? Do you have any blockers? What's happening? Okay so that comment boxing, oh my god. I don't even know where to start. Okay so I've kind of figured it out but so it started as a JavaScript error and so I've been trying to just debug where it's coming from, I'm not really sure. I'm just going into modules like I never thought I would but I mean thankfully I'm kind of able to do some debugging but I just have no idea. I don't know, it could take me an hour, it could take me a few days, I just have no idea. But it can be done by Friday right? I don't know, it could take me a few hours or a few days. Okay I just thought when you said a few days I just thought maybe Friday would be done but has anyone else seen anything in Drupal 8? Have you saw this issue before? No, this is totally new. I mean I think we kind of talked about it as unknown unknowns with using Drupal 8. This seems really edge casey but it's a total pain. I'm really having to debug the hell out of it. Okay well that's really good to know. Thanks for the update. I think I'm probably going to have to give product Tina a call and just give her the update and start to manage expectations around this. All right thank you. All right, so I'm going to take off our hats for a minute. I'm going to get a little meta here. So what should I do? I'm the project manager. So I have a few options. I'm going to walk through them and then we'll do a little voting. So my first option is I can push back on Ellie to get it done no matter how long it takes. Be like look I need you to work all night. We have to get this done. You said you can debug it in a few days but what if you spend 24 hours? Could you get it done faster? So that's option one. Option two is I could just kind of like quietly like every hour like send her an IM and just be like hey how's the comments going? And then maybe the end of each day send her an email. Just to make sure it's moving forward. I can call a product Tina, the product owner and tell her that we need one more week. Task was a little more complicated but that it was going to be definitely be done by next Friday. Or I could raise this in our risk meeting and work with the product owner to find the right solution on mitigating. So if everyone can just clap for their one and we'll go through the number. So for number one, who thinks we should do number one? All right, number two? Number three? Number four? All right, so now you know kung fu. So I wanted to lecture a little bit about why we don't do these things. So number one is like Molly is acting out of fear and total ignorance. Like without checking with the product owner she doesn't really know whether it's so important that she's gonna put in her chit for can you work overnight? And so she'd be just wasting. Number two is not only the same but totally passive aggressive which has no place in a product team. Number three is just, it's almost the same as number one. It's working from ignorance and panic. She's gonna set an arbitrary date that we may not be able to fill. So that kind of narrows us down to having number four as the sometimes hardest but most efficient and effective method. So we're gonna go back into the holodack. And this time Ellie is going to be product Tina, so. I'm the product owner. Hey product Tina, how's it going? Great, I'm totally excited to hear how things are going. Oh awesome, well the team's been doing really well. Sprint too, we're really going through the points. Things are coming together. It's exciting to see the system that we've been talking about for the last month and a half actually coming to fruition. So I'm super excited, I think you're gonna be excited when we do the Sprint review meeting next week. But I did actually wanna talk to you about I'm a risk that's come up and get together a plan to mitigate it. So do you remember the feature that you called me about last week, moving those comments to the top of the list? Yeah, so we've actually come across some pretty deep JavaScript bugs and errors that are sort of deep in the system actually related to some Drupal 8 edge cases that we've come across. So the sort of risk issue is that we don't know if it's gonna be done by this Friday as originally planned. What? Yeah. My boss is coming to town on Friday, she totally wants to see that. I know that you don't think it's really important but for her, it's super, super critical. Oh my God, you guys have to get it done. Yeah, I totally hear. You can't do this to me, Molly. All right, Prada Tina, I totally hear you and I was actually thinking about this because I know how important it is for her to see the site and this feature that's a little reminiscent of the old platform so she has confidence and she can share that confidence with stakeholders. So I was thinking about this and here's the plan that I put together. Let me know what you think. So what if we pulled together a small deck that sort of recapped a lot of the features we've been building in this sprint, some of the ones that we have actually replicated from the old system and then we could even put together a couple of slides about the process for the comment box and where we're at and actually circling back to that unknown unknowns that we walked through in the product kickoff and kind of, I can actually also invite Ellie to come to the meeting and maybe walk through those specific slides just so she has some confidence and we can be really transparent about it. So I wanted to see if that would be something that we'd wanna collaborate on so that we can work on this together. Okay. Well, first I think I need to apologize. Like I know we've talked about the unknowns, unknowns for a long time. I don't really think I understood what they were until this moment. So I'm sorry, I totally acted out of a place of emotion. I'm really glad that you moved us into solution space. I think that would work. Like I remember when we talked about unknowns, unknowns with my boss, she was kind of into it. Like she thinks that we're like in the new frontier with Drupalate. So I think that sounds good. As long as we can keep showing her that we're making progress on the other fronts, she actually might be kind of psyched that we've uncovered something that's totally new. Okay, great. So I'll work on pulling together the deck and then maybe we can set up a review meeting like Wednesday before your big meeting. Okay, that sounds good. Okay, great. All right, thanks. I think that the take home is that conversation is key. So whenever I'm at a party and I tell people that I work in tech, sometimes I'll get a response like, oh my God, it must be so great. You're working with computers all the time. You don't have to deal with people. Right? And I think, oh my gosh, it's all the humans. Like it is so much easier to just code it up than to deal with the humans and all the baggage that we have. And so one of the keys for us in managing scope and managing change and even with dealing with the newness, excitement, and inevitable quirks of Drupal 8 is to have conversations about it. So I think that's it. Yeah, that was it. Yep. So we're at booth 101 if you wanna come join us and continue the conversation or I guess you can come up here and we're happy to talk with you in the next couple of minutes. Thank you guys so much. And just one last note. Just a little fun fact. The example that we gave about the comments, it actually was a real issue that some of our staff for architects encountered in a Drupal 8 project. So there'll be more to come on that one. But yeah, come by and see us booth 101 and thank you all for coming. Yeah, thanks.