 Okay, look at that, first problem, awesome. Maybe you have to click on that. Really? I think we don't have to manually click it. So I'm Allie Jones. I'm a technical architect at Acquia. I've been with Acquia for almost two years. I am awesome at snowboarding and love helping customers on enablement type projects where it's more of an oversight and guidance role, not necessarily purely technical development. Anything else? I'm Chris Urban. I'm all Drupal all the time, plus a new cowboy farmer's hat. You can find me at the Acquia booth talking about Drupal and other things, Drupal, and more Drupal. Okay, I think we get the idea. That's us, from breakfast this morning. So why are we here? We wanna talk about problems and how do we get here? So this will go a lot better. People are interactive. It's noon, you guys are awake, right? No poppy. Yeah, so we were trying to make this a little bit more interactive than just a straight. We'll tell you about all the problems we've seen. I wanna hear if you've had the same problems or variations of them. Okay, so little... Yeah, so in science, we thought we would interweave what if Michael Bay was the client? I don't know if people are familiar, he's the director of like Transformers, really over budget and not really focusing on time and explosions and maybe some plot holes. And how would you compensate if Michael Bay was your client? So yeah, that's the first sign. So one of the problems that we're gonna be talking about is going over budget. I don't know if anyone's been on a project that's gone over budget. Yeah, and then just some ways that we can discuss these problems and going and fixing them. So how do we get over budget? We have scope creep, we have poor planning and estimation and a lot of the times we're catering to the loudest voice instead of like actually a roadmap and sticking to your release plan and then obviously poor budget allocations making bad decisions on where your money is going and not really focusing on what we need to get done. That's good. So what we're gonna go through is how to avoid running into these problems. So let's start with scope creep and poor planning. One thing we like to do on larger projects where there are a lot of complex parts, not just the straight set of features, is to establish what the priority of those features should be developed or how they should be introduced into the project. Oftentimes the customer will come with a laundry list of stuff, you know, the product owner who loves the shiny red object, the technically oriented product owner who really wants to focus on a key integration. Very often the entire team, especially if there are multiple product owners, is not fully aware of what the value of all those features are. So one of the things we try to do during a discovery and planning session is have them categorize them into quadrants and it's pretty straightforward. Most of you have seen this, right? The sort of organization. So what you do is you basically map out and you don't have to formally estimate, you really just wanna roughly estimate in terms of effort and roughly estimate in terms of the value to the business. You don't wanna spend your time or you don't wanna spend the customer's time building something that is extremely complex with very low reward. You wanna focus as much of your time with the highest priority in the first quadrant. Those that provide the greatest value with the least amount of effort. It's kind of obvious when I explain it but sometimes the customer doesn't have the ability to take that step back and try to focus at a grand vision project level. Yeah, and stop focusing on button colors. The buttons will be there, we promise. Okay, next one. Next slide. So yeah, so just again, talking about the effort to value and then this is like talking about breaking things into releases and sometimes they get really caught up on the word MVP, most viable product and we forget that we can break things out into smaller pieces and the smaller chunks that you can break things out, the easier you can get a development team up and running and actually completing some things. So we really like to do this phased approach and that eventually gets us to MVP but not trying to do everything all at once. So then I just broke this down here. As you can see, we have our main area of components and then breaking that down to epics and features. So in this next slide, I broke this down a little bit more on what a component would be. So a component would be like users and accounts or user workflow, kind of a broader subject than narrowing it down again into your epics. This would be like your content type and then also then your features would be a smaller version of that. So really just trying to break things down into digestible chunks. So with that first chart, mapping out the effort to value, having them now organize what are the ones, what are the key features, what are the key epics to focus on first, you can develop a rough timeline of what you wanna build out that meets the customer's minimum viable product requirements, okay. All right, so one other thing coming back, actually before we go to this, let's go back this, is anyone using this process right now or something similar? Okay, similar, okay. So this is really to measure what is valuable to the customer, right? The original problem was maintaining staying within the budget. The other important element for staying. Sticking to a roadmap. Sticking to a roadmap. Yeah, sticking to the roadmap. So once this has been agreed on, we have this rough timeframe. This release is not a sprint, but it's probably a series of sprints. So to get to the final MVP launching customer facing, whatever that first releasable, fully releasable version is, oftentimes it really means that the release one is the version that's gonna be shopped around internally to other brand or product owners or other people that are affiliated on the periphery. They wanna get consensus, especially when it's a larger organization. A single product owner with a small team that's much more straightforward, but in a larger enterprise, they have to get buy-in at a corporate structure. And the sooner you can demonstrate the value of what this project is, that release one, then it makes it easier for everybody in the organization to see your vision, yeah, of what that first MVP is. And also I just wanna point out, although this is a straight line, you can start working on release one while you're still figuring out release three. And that way you can break things up and actually get moving on development and get something in front of people who need the buy-in while you're still figuring things out. You don't need everything figured out before you start working and really breaking it up into chunks helps that. So the other important element to this is now keeping an eye on the progress of those elements. This is a very simplified version, but the concept is really what we're trying to convey here. The MVP features are not everything in the backlog. There are all those other things that are below the MVP level, the things that you find out during discovery, those unturned rocks that you finally got around to turning over. And you should keep track of them on a weekly status report or every other week with the customer so that they are aware, there's no surprises, everything they wanted in their MVP, the ones marked with the X in the MVP column, that they're on track to be completed. So you may not have everything done by release one, but you hope to have all of the MVP done by whenever that MVP date is. Giving them some progress of where these things are on a weekly basis at a top level helps to identify maybe those features that are either more complex than originally estimated. So you would see that they're not complete and they're not forecast to be complete or something is easier than we thought it was gonna be. Have black line, go ahead. I was gonna say this is a really wild subject, how to not go over budget, tracking your budget. But that's the idea here because you're working with an estimate, right? You've got a pool of money and you can't go over it, but now this gives you the conversation to say, look, a feature that you wanted is going to take more effort, it's gonna take more effort. So do you wanna keep it in or do you want a horse trade for something that was not in the MVP below that black line? Does anyone not familiar with sizing? We have the T-shirt size is on this side. Cole, you wanna talk about? Yeah, so sizing at a feature or an Epic level is really just about the general relative size among the features that you're working on. So you try to come to consensus what a medium is, is something that you expect to be the average amount of time to take, maybe two, three sprints to complete a feature. I'm just using that arbitrarily where a large would be something that's more complex, complex integration, something that requires custom code, that would probably be a large, something that could be fixed with a contributed module. Really, one sprint, that's a small. So using that as a relative level, now you can horse trade to say, hey, in-page navigation mobile is not done. It doesn't look like it's gonna get done and you wanted it and we have it as a medium. Do you really wanna keep it? If not, there's accessibility is down here and it's about to roughly the same size and it's near that break point. Maybe you wanna trade. So this way you still find some value for the customer. Any other question? Yeah. So you guys are talking about as if there was a tacit understanding at the beginning of the project that not everything may get done within the estimate that was agreed upon. Yet you also discussed that there is a pot of money and an estimate involved. So how do you, what actual words do you use to set that expectation with the customer about the difference between we have an estimate for the requirements and now we're talking about things that look like they're going to take longer than the estimate and you have to make a decision about what you want to change in scope if you wanna not pay for it. Actually, you can go back to the other one. So there is two parts to that answer. First, yes, the initial discovery and planning you're making is initial. There are always things that you will uncover as you progress through development. The understanding is that the intent of the project is to get that MVP basket of features to be done. We know, like I said, that A, product owners change their mind and maybe an outside influence if not necessarily that the development is gonna take less or more time. It's just that these things we know will happen and let's have a plan to account for it. That's the agreement you have with the customer at the beginning to say this is our preliminary estimate. If this goes swimmingly, we're gonna get a lot of other stuff done that was in your backlog that was a high priority. If this goes horribly wrong, we're gonna have to prioritize among the MVP items that you had initially and either you add budget or you work within the existing budget and prioritize among that list or pick something else. Yeah, and so Chris mentioned the word horse trading earlier. We use that a lot where if we find something that's high effort but low value as opposed to something that needs longer time but is provided lots of value, we do have those conversations of, are you sure that this is considered most important? Can we put this in a future release? Can we document this now but continue and try to really just get that conversation going? So effort is pretty easy. Thanks. Forgot to mention that. Thank you. So effort is pretty easy for me to understand. Value, is that simply at the client's whim? Because we work with a lot of organizations where they're competing stakeholders and how do you determine the value of a particular element? Yeah, we'll get a little bit more into that but really creating a sense of accountability and a hierarchy of the decision making and defining that at the beginning of the project. So although you can have multiple product owners who own certain parts, ultimately someone needs to be determined that they're going to have a final say. And those aren't always like the best conversations but really necessary to have. It's really the most important takeaway there is that at the beginning of the project and as Ali said, we'll talk about this in a little bit. Establishing the vision of the project is really important to have everyone who has a say in that project together agreeing on it. There's that consensus. Very often we see projects, especially if you're working remotely, product owner in Chicago, product owner in New York, product owner in Dallas, they're not necessarily talking to each other and this is the first time they're hearing about the value of the guy in Dallas as opposed to the guy in Chicago. If there is no internal communication or very minimal communication, we end up being the facilitator of the communication via the project. And hopefully that epiphany from the customer side happens at that kickoff. They will come to a consensus to say, the value of priority, generating revenue, acquiring customers, whatever that absolute top line thing is, they agree on that and then they can metric what those features are to each other. Also, as a coming into a project, what I find as a technical architect, what I find very valuable might not be what's very valuable to the client and you need to be understanding of that. I think migration is super important and we need to talk about it from the very beginning, but buttons are really important to people and they might find that of high value and it's not my job to take that away from them. It's my job to help them understand the effort to do migration versus buttons and then have them determine the value and effort in an exercise together. Cool, so that brings us here. So again, coming back to like just the status reports, I would hope that you're communicating some top line information about your project. So same project, same point in the project, you can see which one is off the rails and which one is not, right? Which one? Top, bottom, the bottom, right? I am a third of the way through the project and I've blown through three quarters of my budget or two thirds of my budget. You should never have to get to this point because you would have seen that trend earlier, maybe in week two or week three. Relaying this information to a customer very often periodic consistent basis gives them that insight and puts you as a product manager, project manager, accountable for why that's happening. Is it because those features are taking more time to get done? Now that comes back to that report that I just talked about earlier, this feature is not gonna get done. Do we need to do horse trading? Do we have to have a change request? How do we wanna address this? Cool, that brings us to our next problem of... I think about problems. Of lack of vision, right? We just talked about having all the product owners have buy-in and really creating a vision of what this project is supposed to be from the very beginning, helps you when you're doing that horse trading. Does this go back to the mission statement that we said this was going to account for? Yep, okay. So this is the other side of the equation, right? These are all the things that you see happening beyond going over scope or over budget. You've got lack of ownership. Who, among the organization, which product owner is the person that's responsible for this component, this feature, this epic? Identifying those people up front, that's the first question. Who's gonna be the person that we're gonna ask for approval for this particular feature? It's clear to everybody on the project, it doesn't change. That's, you're laying down the law of the land. That miscommunication, having someone else step in as a proxy, that's opening you up to problems. Scope creep, we've talked about that already. No measure of success. So that is important. And this is not at the ticket level definition of done, but now think at the sprint level or at a release level or ultimately at the MVP level. We know what's in the MVP because we agreed on the feature set at the beginning. But how do you know that a sprint was successful? You've got a bunch of tickets in a sprint, you get them all done and how does everybody know that it was successful? At the beginning of the sprint, communicate what the priority, what's the top three priorities of that sprint? You wanna be able to get the CEO of the customer corners you in the elevator and says, hey, what are you guys working on? What's the dev team working on this sprint? And you can rattle off the top three things that now you've outlined what the goals of that sprint are. And at the end of the sprint, when you're doing a retro, is everybody doing a sprint retro? Okay, maybe there's another problem. So during that retro, you don't have to talk necessarily about all the details. It's good to do that, but you should address those three things that you identified as the goals of that sprint. Were we able to get it done? Yes or no? That's it, simple. If not, the sprint's not successful. This is you. Oh, this is me. Yeah, this is you. At the beginning of the project. So we talked about the sprint level. Now let's go back up to the project level. Having all of those product owners, all the people that are stakeholders in the product agree to what the consensus vision of the project is gonna be. What are we doing? Why are we spending this money on your development team? Why are we building it? We sell widgets. We wanna sell more widgets. We think this will help us sell more widgets. Putting it in terms that anyone on the team can understand easily. Because how many times you're saying, yeah, I'm building this project for X, Y, Z widgets. Can you really say what it's for? Is it to get more customers? Is it to increase revenue or both? You should have the ability to answer that in one line. So this is me. I'm a big fan of documentation and accountability and assigning roles. Especially on large projects, you have to delegate and people to create that sense of ownership and have more people have buy-in. It's really important to delegate roles. So you can see here, I'm very big on documenting at the very beginning of the project, what it means to be done. What does that actually mean? And that's a really good way to how you measure success. And then also assigning that to a person or a few people and when that needs to be done. So when you set up that expectation of you're in charge of this and this needs to be done before grooming starts, you can then say, when you get into a project and if that isn't happening, you can refer back to your definition of done. And here's just some examples. You can't really see the table. But defining what the criteria for done is, like what does it take for this user story to be accepted? And you have those expectations from the beginning and going through each part of the project. An ownership. Yeah. An ownership. And knowing who's responsible at each of those phases. Who's the point person that's gonna be responsible? Making sure everybody understands that. So the next part is the retrospectives that we mentioned earlier. Really closing that feedback loop because the sooner you can fix something, the sooner that you can keep moving forward. And we don't expect to be perfect every time or the clients or the projects to go as smoothly as we anticipated in the estimation and the scope of work, the SOW. And really like when you do the, the retrospectives are really important to make sure that you're accounting for things and moving forward. So, okay, this is, we're getting a little bit into documentation. We're gonna talk about this more too. So this is a little bit of a teaser. One thing that has to be outlined is all the stuff that's not just in the sprint. We talked about that, the project itself. What are the, what's the vision of the customer? What are their goals? We talked about the sprint level goals. Now, outside of that project, are there other pieces of the puzzle that you have to wait for? Design, creative, integrations, some other subject matter expert because they're the Salesforce guy and they're out on vacation. All of those elements should be mapped out at the beginning of the project and outlined so that everyone, the thing to avoid is surprise, right? You don't wanna have a surprise show up at the last minute. Vacation time, upcoming maternity or paternity leave. All of these things should be audited at the beginning of the sprint so everybody understands what kind of hiccups are there potentially gonna be. More importantly is how do you manage around that, right? At AQUA, we try to maintain the same resources on a project but sometimes it happens that you have to roll someone in or off in that role. How do you have a plan to accommodate that transition? All of that can be documented up at the beginning of the project. This is your favorite. Yeah. So then we'll go to problems of accountability. So really what Chris was just mentioning, the lack of documentation, unclear roles and responsibility and communication. Other things to include is terminology or business overview and structure and that's really great for if you have people coming on and off the project. If you define that role, then other people can move in and out of that role which happens a lot on big projects. One word of advice I try to say when you're starting a project, especially with multiple product owners and multiple people working on your team, try to document the project as much as you can assuming that you had to roll everybody off and someone else back on in a week. Would you have enough information documented that you could get away with it? If you can get to that kind of state, then when an actual transition does happen to land in your lap, you are ready to go and you can do it in two weeks. What's a comfortable amount of time? So who's had a demanding client before? Yeah. Yeah. So what do you mean by demanding client, Ellie? So problems that can happen when you have demanding clients is, we talked about changing client requests and something called bottlenecking which is when you have someone who just wants to do everything and they need to make decisions and it's preventing the project from moving forward which can then also lead to scope creep and how we would solve for those is really returning back to your defined vision priorities and your definition of done which creates a sense of governance and accountability and focusing on the documentation of done and your vision to do the horse trading that we mentioned earlier and really rein in the demands because you already define what it takes to be done and what you want the vision to be. So if you have that vision defined at the beginning of the project like we talked about, when the customer comes back, week 12 out of 20 to say, oh wait, we forgot about this feature, you can go back to their own vision statement and say, well, tell me how this fits with this vision, is this really a needed feature or not, right? You can do validation now. You have some defense mechanism or something that will support a decision you wanna have made. We see that you're doing this integration, you said it was low value and here you have this other feature that is a higher value. We can, we have to reconcile this. Why are we doing it this way? Having that conversation with the customer may uncover additional dependencies or other things that you have to account for. Right, which brings us to process, right? So now we've defined what it means to be done, we've defined what it means to be held accountable, which creates that sense of governance and then now we need to get into the thick of it and actually working through the projects. Poor puppy. One more explosion and then we'll go. Right, so some things that can happen when you're trying to force process on people is they don't like it. We have a very large Jiro workflow where you need to put things through tickets and a lot through statuses and that doesn't work for everyone and just because it worked once on a different project doesn't mean that it's gonna work again and you need to be accepting and flexible to how people learn and how people work and in order to do that you have to have that clear and consistent communication to unblock tickets. You need to work with people in different time zones and you need to define constraints so you avoid the demanding client requests. So how would we also try to get a process set in place? Well, we use our tools. So here's a few that we use. I'm sure everyone's familiar with Slack and Drupal 8. Has anyone heard of Drupal in their room? And really using these tools to your best interests. So the more you can have them work for you the less manual work you have to do and Jira's really great about reporting and then there's also Confluence in the, is it Atlassian? Atlassian. EcoSphere and then the Aquia Cloud's pretty cool if anyone's ever heard of that. So to get more into process, really divide and conquer. So this might seem like a lot of Jira boards for people but then you can break it down to the smaller sizeable chunks and although you do have your master board you can break things down for particular meetings for in progress and done and then really focus the effort and the meeting. So when you break it down like this and you have like a board for your sprint meetings, your sprint ceremonies, you can really divide and conquer. So quick question. How many people here are using Jira? Okay, how many people are not using Jira? I should ask that. So first question is, what are you using? Asana? Okay, anyone else? I didn't look with planer before. You can break things up. A spreadsheet? Okay, all right, just curious. So for those that don't use Jira, the way the board works, the project is set up. If you have a workflow, right? The easiest workflow to do doing done, the boards represent those in columns. So think like a Kanban board, but it's constrained by time. So you have it as a scrum board. In our workflows, there's probably about a dozen to 15 states from to do to done, depending for code review from the architect, QA, UAT from the customer and then releasing to the live environment. We take snapshots of each of the pieces along that entire spectrum and that's what these boards represent. So QA is only interested in what I need to do, what I'm doing and what I'm done. UAT, I only need to know what do I need to do, I'm doing and done. So they're like slices of that bigger, longer workflow. Thanks Chris. You're welcome. Also using your tools to automate communication. This is really important when you have teams working in different time zones, especially India. So here I have three examples kind of faded but using the GitHub Slack integration so you can know when pull requests are happening. This is also on GitHub where JIRA is reflected on the GitHub for the developers or when you have your product requirements, they change, it'll update. And then the last one is using Confluence to create task reports. So you have it defined somewhere when someone brings up a question and you're documenting that in some place, we'll get a little bit more into that. So you can refer back to those product requirements and questions that happen and like really taking that conversation out of email, taking the conversation out of Slack and putting them into one centralized place and creating that accountability. You can see there's a due date, a signing and Confluence does this for you. Not that you have to use Confluence but just documenting somewhere as your source of truth will help with the process and communication. One more tool I like is Howdy. If you've ever heard my talks on DevOps, ChatOps, Howdy is a tool that lets you use Slack to do your standups. So it's a synchronous, it'll pull all the developers, put the results into one channel. What did you work on yesterday? What am I working on today? Do I have any blockers? Do I need an after? You don't have to spend time on the phone doing that. Let the machine do it and then all you do on the phone is address blockers afters. Everybody can see what everybody's status is. Focus on the things you need to focus on. Yep. So another part of process is being proactive. We just had that big security update and lost it. Oh shit, I forgot to do that. I'm just kidding. I'm kidding, I'm kidding, I'm kidding. Just curse on our slides. Sorry. So yeah, so consistently managing and updating your site. You can see this, we just had this update and if you are not proactive, then you can run into problems where something can get hacked or you have to deal with something large at the end. And this creates the sense of escalation. You can start when you find something out and make sure that gets incorporated as you're going through your releases. Good? Yep. And that also brings us to preparation, right? So we need to be proactive and we need to prepare. Boom, boom, cool. So how do we prepare, right? So let's do a discovery and let's define what we call sprint zero, which is like the first task that we need to do. Set up and really important again to talking about delegation, setting up infrastructure and reoccurring meetings. It's really about managing expectations from as soon as you can. So you can get moving on the stuff that's really important. Is everyone here do us sprint zero when starting a project? Okay. So another, like obviously being prepared, you need the documentation. You should create that roadmap and define the roles, create meeting notes, the task log. And also another one we really like to do is a decision log. So you can document when something was decided that way when you get 12 weeks into the project and there's some miscommunication on the reasons we went a certain way. You have that all defined in one centralized place. So one other key, I think we have it on this one or the next one? A source of truth? Yeah. That's yours, go ahead. Yeah, so it brings us to creating a source of truth. I'm a really big fan of Confluence because it gives you these predefined templates that you can get more in depth into and just creating a defined way of documenting things that are all that's consistent throughout the project. So you can do this in Google Docs or something if you're not using Confluence. But if you use Confluence, it gives you the power to do something like this. So really can't see it. But you can see here, this is a table that's responsive. I have a table of contents on the side that, so it says the in-page anchor links. And then each product requirement has these consistent components where you're talking about when you want to release something, the document owner, and if there's any really Jira information. And then so down here, I am not a big fan of tables in Jira. So when we have to do things like field definitions, I'll do them in here. And then we have a one centralized place for this product requirement. So let's say the product requirement was the content type article. You can define those things here. And also then you, so Confluence becomes like the tree and each Jira ticket is like a leaf of that tree. But you all go back to the same place. And this is important because if you want to define a content type, that's one ticket. And if you want to migrate content, that's going to be several tickets. But here you're defining the source, the field notes and the field descriptions all in one place. So you keep referring to that and you update this, not individual Jira tickets to create a big picture of product requirements. So the other thing I'll add is beyond the product, the process coming back to that, you want to document all those things that you don't wish will happen, but you want to have documented. So when they do happen, you know what to do. Meaning that call that comes in at Friday at four o'clock to say nuts, there's a bug on the production server. We need to make a hot fix like right now because everything's going to go wrong this weekend. Having that documented, who's required to make the decision to give it a thumbs up? What's the process? How do we make this happen? Having that as a checklist in a document in Confluence takes all the emotion out of the decision log and keeps everybody on track. We need to do this, then we need to do this, and we need to do this. Yeah, I'm a big fan of taking all product requirement conversations out of email and putting it into a document where it's all in one place. And you keep referring back to that product requirement page and that way when you get down the line and someone's asking you why you did something, you can refer back to one single source of truth. Not let me find that email thread where we discuss this one small component of this feature. Okay, good. So solutions for- I jumped the gun. I knew it was right here. Emergency planning playbook, we just talked about it. So hopefully everybody has something like that. If not, do it right now because it's not a matter of if, it's a matter of when. You know it. You know it will happen, be prepared. This also gives you an opportunity to review that process with a customer. They are now not surprised and know what to do when it happens rather than running around like a chicken with your head cut off, phone call. How to restore everything. Do you do periodic restoration of backups? What happens if you lose your database? What happens if that over enthusiastic technical architect overwrites prod DB by mistake? That's never happened, right? Never. So having all of that documented, test it, make sure everybody knows what to do, right? Because that also always happens when, when your lead architect or your lead senior dev is on vacation. This is Chris's favorite side. That we had to put in here just in case you guys missed the recap of all of our really fun gifts. And then just to recap, we talked about going over budget. We talked about lack of vision, demanding client requests, lack of process and preparation. And how do we solve for those? We clearly define done and the vision statement. We're creating that centralized source of truth and we're closing the feedback loop. Just constant, consistent communication. And I guess we forgot to ask if anyone has any questions. Yeah. Does anybody have any questions? Yes, come on up to the microphone. Thanks. Even though we'll work for a big radio company. Before I ask a question, I thank you guys for like this. Some of the quote from Eisenhower, in preparing for battle, I have always found that plans are useless, but planning is indispensable. Exactly. That's a great, great quote. Yeah, that's... I've taken over some projects internally from my company and sometimes it's been a complete disaster from the beginning. And it's like, okay, we're starting over in the middle, right? We have a fragment of something that was in development. And in the negotiation part, that value complexity matrix is super valuable for selling a story. Do you guys have you guys found anything that makes it easy other than just whiteboarding and trying to sell it? Or have you found anything that like... We do sticky notes, like sticky. And we will get people in a room, which can be difficult if you have remotely. And then there's also the idea boards, which is like sticky notes as well. But again, just taking the conversation like out of an email or even out of like a meeting notes and putting those into the product requirement documentation pages is kind of how we do that. It's an excellent case for the face to face, let's block out time for a day or two days and hash it all out. Yeah, we... That's the only way to do it. We call them discoveries. And you can do that internally as well. Where it's like, let's get down and just talk about it. And communication is really important. It's just really like communication. And then creating that vision statement, even if you're in the middle of the project and being like, then you can refer back to that when you have to centralize all these components and all these moving parts and go back to say, does this really create value from our vision statement? And it sounds a little like hokey. You know, like let's sit down and write a vision statement. But it's really important because you create that sense of accountability for the whole project, not individual people, but still individual. Do you recommend only doing that once or a repetitive like first sprint? So in your case, I mean, you are resetting the clock basically. So you start all over again with a sprint zero. The only difference is you've got this, whatever, carcass to build from or try to take and continue to use. You should still treat the process the same way. It would be like, as if you started from the beginning and the customer said, hey, I had this internal development team and they built this, but we know it sucks. Can you help us? Yeah, rarely do we find that we start projects from scratch. Like the internet has been around. It is a thing and people have projects. So you're very rarely starting from scratch. So, and like you can also change the vision statement. Like we're not setting in stone and we can adapt to that as a project as a whole. But it's important to be able to refer to something. Yeah, guidelines, constraints, whatever you wanna call it, you're trying to contain. That's all you're trying to do. And just to go back to your quote about plans are useless. Yeah, you can, I agree with that, but that's also why we break things into releases because people really get caught up on MVP and like the whole thing and it needs to be like defined and done. But when you can get started on release one and get people moving and still having those hard conversations of maybe this didn't work out the first time, you can have the project moving without burning through the whole budget before you actually start working. I think it's also, we could talk for hours about this, but that's really the difference between wet agile, dripping agile and true agile. You should not have 20 sprints planned down to the ticket. You really only need the next couple. You have time to do the rest and things change naturally. It's easier not to fight that but have the plans, as Eisenhower said, what you want to try to go for, what you end up with may not be that final thing, right? Thanks for the question. Yeah, thanks. Thanks for the talk. You've been very informative. I can't say as I've worked on a project that was anywhere near as efficient as you have described or even came close to it. Neither have we. Okay, great. You've raised a pretty high bar here. But I'm interested in your discussion about horse trading. You come to a situation, I don't think I've ever worked in a project that didn't run into problems at some point and the negotiation piece, I don't see clients being willing to do that. You get to the point and you say, can we horse trade? And they say, no. Where do you go from there? I'm working on a very large project that works on maybe let's say eight very large components. Any one of those components could get pulled out and we might make launch, but the client says all of them have to be there to make it succeed. Yeah, so we're big on, sorry to interrupt. I didn't mean to say that. With the released approach, the phases, phased release approach, you can have those conversations where let's just get something out so we can get feedback and then get back to those components after we already have what we consider a release one. So that's kind of how I would have approached that. And also there's only so much time in a day so you can only get so many things done and they are hard conversations to have but when you define the accountability and the vision statement that we mentioned earlier, we use those as our fighting tools to fight back on those hard conversations. The other, it's more laborious and time intensive but literally mapping out what the outcome of removing something or the negligible impact of taking something out because we don't need it. Having that value effort of all the eight features that you mentioned are in that first quadrant, they still then now take that first quadrant and make it into four. Like you have to still pick among the eight. There cannot be eight number ones. There has to be one number one. That's probably the number one rule. Well, I just, I don't believe I just did that. But there has to be priority. There has to be a pecking order. You can't have everything number one. So it's like, yeah, that would be the paramount rule. The other point that can be made on it is the project management triangle, the actual scope, time, quality, all that. And what do you actually suffer by trying to get it done as quickly as possible? Yeah, I'll say that. A lot of the times nothing will get done when you don't prioritize anything. So really focusing on that. Hi. Hi. So, I don't know, hypothetically you're working on a project and a high priority security pass drops right as you're at hit a deadline or the previous edition of your site gets breached. And aside from documentation and a lot of obvious CYA maneuvers, how do you communicate that with your customer around, hey, we knowingly held off on a security patch and we got breached and just basically risk management around that. And also so we have a relationship with a customer afterwards so you don't kinda like, see you at buy. So anyways, if you have any thoughts. Yep. So I'm gonna start with, we advocate for full transparency as early and as often as possible. So the regular communications, the weekly status updates, our job, her job is to keep everyone up to speed with those pending updates. We know in this most recent case we had a week or so lead time. That disrupts everything because you're in the middle of a sprint or you're gonna be doing a production deployment. Now that has to all essentially be thrown out the window or layered on top with a hotfix release. And you are working on a budget so you are trying to get 60 hours work in 40 hours. You can't do that. So what are you gonna take 20 hours away from? The lowest priorities in that feature set. And you have to make allocations for it. This is actually kind of also, there's another way to reinforce this and to do this diligently on a sprint to sprint basis. You're not working only on features in every sprint. That's maybe 60, 70%. You always have technical debt and you have to have an allocation for that. And you will always have like five, 10% set aside for the normal contrived and core updates, the ones that are not the Drupalgedan level. You may be banking that to some extent. Now we haven't had any updates in the last three or four weeks. Maybe we had one module. But that also keeps it front and center from the customer's perspective. Hey, has there been any serious updates lately? Is there one coming up? Make them proactive about it. Yeah. So again, taking the conversation out of email and having that centralized place is really important. And I have a security update ticket in every sprint. So being proactive and knowing you have to account for that, even if you don't actually have a security update for that sprint, you've already counted for it before you start that body of work. No. Oops, sorry. Now to talk about when the project is over, I think that depends on the, like the SOW when you say when the project is over. And then those are like business driving decisions for your own company, let me just say. Does that help? Okay. I think like all of this is really great and I like love the process and workflow stuff. But. How to deal with a person who is extremely resistant to participate in that kind of stuff and to, you know, that sort of goes against rules and process of workflow and all that stuff. Okay. Well, so for that, they're again, coming back to a weekly SaaS report or even as soon as the beginning of the project, any risk to the project's success has to be documented and communicated. What I'm trying to say is if the thing, whatever that thing is, it's a product owner, it's the way the original site was built that you're migrating, whatever baby that is, if it's ugly, you have to tell them that it's ugly. And the sooner and more direct you say it, the better it is. If it's an issue about a key person on the project that is essentially going against the project, I, that should be communicated and make, this sounds, I know we're a little idealistic, but that needs to be outlined. And that may be more now a matter of escalation internally. Like you're dealing with a product owner, who's the stakeholder? Who's the person that signed the contract? Who's the guy who's signing the check? If that is, they're paying for something, that person has an expectation for what defines that project to be successful. And someone on the team is clearly not on the same page. That sounds like a pause for the project and get everybody in a room and kick that thing off again and start with a vision statement, start the clock all over again. Yeah, and that's why we were really big on defining the definition of done, not like to launch the project, but each of those steps, like what does it take to get a ticket done? What does it take? And honestly, you kind of write that for one project and then you reuse that and just tweak it a little bit depending on that project. And then you can use that as your tools, not like, hey, you suck. It's like, hey, this is what it requires to be done and taking that personality out of it and just creating facts of this is what it needs to move forward. It's gonna sound a little weird to say this, but I think the key is to abstract what the blocker is. If you're waiting for an API contractor and an endpoint from a customer, their development team is the one that's working on it and they thought they were gonna be done this week and it's not gonna be done till July, pause. You're waiting for that project. You're not gonna do anything until that API contract is done. If there's a person on that team that's blocking it, pause. You're not gonna get anything done because that's a requirement for that project to be working successfully. Treat them exactly the same way. Hey. Hey, I just wanted to address this scenario about the security release right at the most in opportune time. When you're on vacation. Yeah, yeah. And if it's a project that's over budget, behind time and off, often the customer is basically a low grade smouldering fire already. Dumpster fire, yeah. And that just throws a bucket of gasoline on it, right? Because they panic instantly. And one way I think to deal with that is when you're doing those first few sprints on a bad project, getting it back on the rails, you're kind of building trust. Inevitably there'll be some minor patch or security release in some contrib module. Like it happens every two weeks or whatever. And a good strategy is to say, hey, I wanna put this in and push it forward. It's probably mitigated, it doesn't apply to us, but we should know how to do a security patch in a hurry. Because it's gonna happen to you at some point in time and let's make a wiki page how to document it. And then when the actual thing happens at the most inopportune time, you have a little bit of leeway just because you've talked to them about it and they think you might know what to do. You know? Well, and it's almost, it's a rehearsal. It's an opportunity to rehearse a disaster. Yeah, yeah. And if it's rehearsed, then it's not a disaster. It's just the thing arrived. It's not about if, but when. How are we on time? 53 minutes, we're doing great. Awesome. Go ahead, sorry. Thank you for doing this. I've had the pleasure of working on small and large projects and having them completely fail. So like I totally get the fact like you have to prioritize or nothing gets done. Right now I'm working on a project that's going well but one of the challenges that we have is email is the primary form of communication. And a lot of things are getting lost in the emails. How do you recommend getting people open to the idea of using like a tool that's better suited for project management? I'm super persistent about this one. I don't like product requirements and email threads. I don't even like email threads. I rarely respond to emails. And all I can say is like when someone will ask me a question, I say put it in the template. And when you start, it's a lot of you doing that. You know, like they ask a question, you document it, you put it in. I think you mentioned these Google slides, right? Yeah, Google spreadsheets right now, Google Docs is how. So you can still, you don't have to use a tool that is robust as Confluence if you're not paying for that. It just provides a way to use templates but you can still have a Google searchable doc that you can refer back to. So persistence and also if you set that expectation early and often, then people will refer back to the templates. A project I'm on right now was really resistant to it. They only wanted to be talked to through email. And once they started seeing the value of it all being in a centralized place, they're now redoing all of their projects to follow this centralized source of truth idea. Cool. Another thing is to find a mechanism that is the path of least resistance. If they're already using email, maybe something like a Trello board, you know, and you make sure that everybody always sees the board to create a ticket. Then you can set up a session, not grooming, but let's call it a cleanup session where you review everything that's been emailed back and forth over the last week and we'll find those into tickets and put them in. But you use the term like a centralized source of truth. So you can talk about, I'm not saying never talk to me over email. We can have these discussions but when we refer back to it, it's all in one place. So like you can copy and paste into your product requirements page. And this is really important too, like things get lost in JIRA tickets or you have one ticket that says, I want to create an article with a black background and then two sprints later, someone said a white background and you're like, what ticket, what did I do this? When did this happen? But if you have that one page of the product requirement, then you refer back to that and say this is when we made this decision and you have comments and people can add to it. And then just kind of a follow-up question of that. You talked about the decision log. Are those major decisions that you're documenting or how detailed are, you know, how do you prioritize? Anything that could potentially change? I mean, I think it's, yeah, some things that are probably, you know, I don't know, the color of the button. No, that's when you would document. But it's something that I think it comes from experience. You know that there's a potential change or it's something that is, you know, touching multiple elements that are responsible, fall into the responsibility of multiple people. If it's something in an edge case, you know, the 404 page, there's probably one person that worries about it, but something like the homepage, everybody worries about the homepage. So I like to keep, and as I mentioned before, like all the product requirements, like if it relates to the article, I don't want to look in 15 places for that. I don't want to look at 10-jera tickets. I just want to look at the Confluence page. I use the Decision Log for a lot of times for things I don't agree on, like putting plain text in templates, like copying, pasting many navigations in templates. So when I disagree on something, but we're still making those decisions on a project anyways, I like to document them when, so when it comes back to a problem that happened out of some of those like business driving decisions, you can say, hey, remember when like we said, don't do this and you're doing it anyways? And that's really why I use the decision. Yeah, yeah, it's- Because that never happens, right? Yeah, but really like the Decision Log, again, is like to take a motion out of things. I like, I've mentioned buttons a bunch of times, but it's something I get really worked up on when we're in a two-hour design meeting or still talking about buttons, but no one cares about like XML data exports. So I will document those things to move on with my life. Like I can continue to like care about this one particular issue, we made this decision, we need to continue moving forward. So that's what I put in the Decision Log. Yeah, yeah, that's great. Or when like the scope changes, so when we have components and we do that horse trading, we'll say we took this out of MVP and then you have dates and documentation. All right, so just to give you the obligatory message we need to remind you, Friday is code sprints. Mentor sprints start at nine if you're first timer, go to Stoltz 2. Anyone here do code sprints? Well, you should. Use it as a documenter, testing, QA. There's lots of things you can do not being a developer. If you like to serve like this session, try to take the survey, just give us feedback. We'd like to hear what you thought of the session. And I think that's it. Did we put our contact info up? No. Why not? Because we want to avoid problems. So thank you. Sprint 59 minutes. Nailed it. Under budget. Under budget. All right, awesome, awesome. Thanks, bud. I got a really good idea. I'm not so bad for my part. I wasn't talking about that. No, no, no.