So this is plans to use this, but planning is indispensable. This is an Eisenhower quote when he was a general back in World War II, kind of talked about his philosophy when helping the troops kind of prepare for that traditional battle mode they're about to engage in. And so I kind of want to unpack that quote today in the context of who I am and the work that I do. I'm Sean, and I work at a last column media where a creative agency based in the United States. During the day, the majority of my effort is spent running our agency's production efforts, taking the business goals and the ideas of the people that we work with and translating those ideas into something that we can then deliver that has value at the end of the day. And when I'm not doing that, though, I am also involved in the company's leadership initiatives. Taking the company from where we are today, figuring out where we want to go, and how are we going to get there? So last column media has been around for about seven or eight years. During, we went through a couple different iterations of who we are to get to where we are today. But back in the early days, when we were just two people, now we're touching 30, I thought, OK, we need a process. We need a way to go from where we are to where we want to go. And in talking to other people in the community, other business people, they said, OK, yeah, this is a solved problem. You want to figure out how to maximize things like cash flow, how to look into things like profit, how you want to be a responsible leader within your organization. Answering all those questions got me really stuck trying to think of how do I think about all these things. So I was stuck making excuses, essentially procrastinating. Then business leaders were like, this is a solved problem.  That's what you need to do to take your business from where you are to where you want to go. So I didn't have the, before I make it sound like I can't stand the business plan, I do want to acknowledge that there is significant value in the business plan that I was not aware of or did not have the awareness of at the time when I was trying to think about ways to chart the path forward. So to acknowledge that the value of the business plan and the value of writing the business plan is it's a series of essentially communication exercises that help you distill what you're thinking of and help you think about things that you would not have considered as you were busy doing your day-to-day business. But yeah, to that end, it's important to have a vision, to have those projections, to engage in the questions of the business plan. But would I use it in day-to-day business operations? Would I use it to base every decision off of? The idea of four years from now, we want to be this type of company. We want to have these fixed metrics. And along the way, as you go through the ebb and flow of reality, you have to make different decisions. So as I tried to write that business plan, I found myself just with complete analysis paralysis. Distracting myself with the business plan, I was ignoring not 100%. But I wasn't focusing 100% of my attention to the day-to-day realities of the business. So I'm sure people in here have written five-year plans either for an organization that they work for or for themselves, who I as an individual want to be in five years. I know it is interesting to, there's an exercise I do in business school, where you write a 20-year plan and then you put it in a time capsule. And I think you open it 10, 15 years later, but you're not supposed to look at it until then. And talking to people that went through that, and you're like, oh yeah, that thing fell apart after the first year. But like I'm saying, there's a lot of value in the act of planning. Just would not try to run my day-to-day life on the plan that I wrote three years ago. But yeah, it turns out that I'm not really alone here. So I kind of want to introduce one of my fellow countrymen, somewhat controversial, have to acknowledge that. At the time when he said this, it kind of became an example of that politician double speak that turned, when he said it, it became pretty famous on the late night shows as a joke, right? Who is this guy? And at the time, it was also incredibly frustrating to get an answer like this. But if we kind of unpack all that and ignore the political side of things and just really focus on what he's saying, I think it's pretty. There are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns. The ones we don't know, we don't know. Right, so what Rumsfeld is really trying to say is that there are a lot of things out there that I don't know, I don't know. And the context for this was the hunt for Bin Laden and the invasion of Iraq and Afghanistan. And he was just being grilled by reporters who wanted to know what was going on, what the plan was, right? And he didn't know what the plan was because there were so many things he did not know. He didn't know that he didn't know. Right, so I faced these questions, right? As I thought to myself, I have to write this plan. You know, this massive stream of consciousness. You know, what do I do if this plan changes, right? What do I do if I learn something new, right? How can I adapt? How can I as an organization change and take advantage of a new opportunity if I spent all this time and effort thinking this through and writing a solid five-year plan that I am now committed to, that I have now sold to myself? Do I follow that plan? Do I ignore reality or do I adapt? Do I need an answer for all the known unknowns? And then, you know, lots of late nights trying to fall asleep. What are all the unknown unknowns, right? As a small business, two, three people wanting to be five, seven people thinking about all the different risks out there, all the different answers that I need to be prepared for. Do I, you know, what are, you know, and then ultimately at the end of the day when you come into work, who has fun just following the plan that I wrote three years ago, right? I don't know if that's really something that gets me motivated up and out of bed every day. So, you know, this is, I got him Kelly. Kelly's the CEO and founder of Last Call and he's probably one of the most flexible guys I know, very laid back and one of these things that I like to say is, right, welcome to Last Call Media. He has the plan for the next five years of your life and don't forget no delays or surprises. And some of you may be like, okay, no one ever says that, right? And others may be like, I think I've heard that before, I'm not sure where. And that, I think an example of that is the U.S. government. That's pretty much at Capitol Camp and government days to three, I think three or four years ago, I bumped into someone who had just recently been hired to work at a government agency in Washington, D.C. And in the interview, she was, you know, asked, what do you know about agility? What do you know about strategy? What do you know about synergy, right? All those buzzwords that we hear all the time. And obviously she nailed them. She got them all great and was hired. On day one, they handed her a book and they're like, this is the 200-page five-year plan for our digital strategy, right? And I didn't bump into her. I go to Capitol Camp every year. It's a great event in Washington, D.C. And I haven't found her. I don't know if she just abandoned the whole idea. She couldn't navigate that rigidity or she was wildly successful and now doesn't have time for Capitol Camp. But, by the way, I am still curious where that ended up. So, before I kind of dive in, you know, I've been knocking the plan a little bit, but it's important to acknowledge kind of why people plan, you know? Despite the fact that reality often contradicts the plan, people still find significant value in the plan. You know, I think the value of the plan is or has historically been, that's how management thinks things get done, right? You have a plan, you make a task. The larger the plan, the more tasks it has. Those tasks are assigned. You force that accountability. Management by objective. You, for the next three years, are gonna do this, this, this, and this. And that's how we're gonna be successful in this marketplace. And management does that, I think, because there are certain forces at play that dictate that we plan, right? We have to know what we're doing so we have to put a plan together to figure out how we're going to accomplish that goal, right? To solve an organizational problem, we're often handed things like a budget, a timeline, and a statement of work, or a scope, or some vision of that, right? And there are other, I call these forces, not constraints, or any other word, really, because there are a lot of these things that you can't see sometimes, right? You may not be 100% sure what the budget is, or what the end product will look like. And then you also have to balance that with things that are even harder to see, like company politics.  You may not be able to define them exactly. You know, if I throw a ball up in the air and it doesn't come back down, I'm not immediately going to think, oh, gravity just must not exist today. You know, the ball probably got stuck in a tree, or something else, right? And those forces that we have to constantly navigate shape the reality, or what is possible, in reality. So it's a constant balance between these forces, right? As in a business, right? If you find yourself in a business owner or someone who's leading a business, you may have constraints or forces such as cash flow and labor capacity, right? How do we work to balance those to kind of maximize the value of what we deliver, right? And I think there's an important thing to consider here if we start ignoring these forces, right? If we start ignoring company politics, I think that's gonna be one of the quickest ways for a project to lead to failure, right? And people are afraid of chaos. I think ultimately at the other end of the spectrum, when you don't plan and you don't have a mechanism for planning, you know, there's chaos, right? You can quickly, a project or an idea or an organization can quickly fall into chaos. So, I don't know anyone that likes chaos. I haven't met a project manager that thrives in chaos or business owners seem to be allergic to chaos and you definitely don't want to be six months into a project and a stakeholder walks in the room and you know, this thing is all sideways, right? Stakeholders also don't like chaos. And yet, despite the fact that we spend a lot of time planning, projects continue to turn chaotic, right? We spent a lot of time, we invested in that rock solid rigid plan, we made six months ago, but now what you thought back then is no longer what you're facing today. And some projects, that may be day one.  So, what do you do now? What's the mechanism? Do you go back to the drawing board? Do you write plan 2.0? Do you invest all that time and energy in that plan? Or do you do something else, right? So, I believe chaos comes from trying to force a simple process on something very complicated like software development, right? So, traditional management is stuck in this mentality of build, plan, deliver, right? That's how we get things done. But in reality, there's feedback and there's no mechanism for feedback in this linear relay race of a model, right? This is, the mentality here is I don't know or I think I know what I'm going to do six months from now. So, I want to be optimistic like I always am and think I got this right. So, let's plan, build, deliver, full stop. But I think in reality, what ends up happening is it's plan, build, keep building, budget overruns, projects behind schedule, chaos is there anyway. So, you're navigating all these different forces that have now really emerged and become chaotic. So, what we've decided and what I think is a growing and really successful trend in the software development world is agility, right? Agility challenges that model. Change is inevitable. So, let's stop pretending that we're never gonna change anything and avoiding change and instead, let's get better at it. Let's get faster at it. Let's encourage and embrace it, right? Let's stop focusing on what we wrote six months ago just because we wrote it and we got politics involved within our organization, got the commitment that we needed to move forward. And it's a feedback loop, right? So, inspect, adapt and create. And the key here is to create because as someone who works at an agency, the people that we work with aren't gonna pay for just for us to be perpetually inspecting and adapting. Constantly taking steps back. Constantly thinking about the bigger picture, right? There is significant value in all that but you have to ultimately at the end of the day deliver something of even more value. So, when I think about things that last call, I thought we should use this our ability to be adaptable as our competitive advantage. Let's see how quickly we can inspect, adapt, change course and deliver, right? So, today what I'm hoping we can all examine is how we can develop an awareness that enables us to be adaptable to deliver working software with the most value, right? And also at the same time, acknowledge and balance those forces such as scope, budget, timeline and politics. So, one of the things that I found over the years and how to be adaptable is to establish communication, right? So, communication, healthy lines of communication, which will lead to an awareness and when we have that shared awareness, we can discuss things like what the vision is for the project and what our goals and objectives are and in the context of all that, we can adapt, right? So, as we communicate, have that awareness, we can inspect, adapt and create. And I kind of tied that back to our mission statement at last call, right? Here's a little bit about what we do. We are a creative agency that enjoys work with purpose, right? Building really valuable solutions to assist organizations in the communities they work so hard to support. And despite how I seem so against the five year plan, we've done a lot of really amazing work for a lot of really great organizations, solving complex creative and technical problems. Like I said, we're based in the United States. Most of us are in Massachusetts. I'm based out of Manhattan. A few of us are based in Baltimore and we're a little bit distributed. It's an idea that we're exploring. So, as I think about inspecting and adapting, I also wanted to bring that same idea to our mission statement, right? So, last call media, we enjoy adapting to change over following a plan, right? From that agile manifesto to deliver the most valuable solutions. And that ties in a little bit to our website. I don't know how well-known this is, but we launched our current site back in October of 2013. And why this is much worth mentioning is because we built it on Drupal 8. So, a lot of us here today are considering our next Drupal 8 project. Maybe we have several Drupal 8 projects under our belt. But back in October of 2013, the team sat down and we decided, okay, Alpha 8, we're gonna start building this thing. And when we launched it, we're on Alpha 12. And obviously now we all know where we are today, right? But I think that's a great example of our agility, our technical agility, right? As things were constantly changing and core. As the platform was maturing, we had to constantly inspect and adapt and deliver. Oh, and something that's also really cool is we contributed a ton of code back. So that's really important to us. So, the first point is communication. We want to establish what it means to communicate, right? Sounds like, okay, we've all been down this road before. Communication means checking in weekly, setting proper client expectations, and responding to emails promptly, right? I'd like to challenge that a little bit. And I believe Healthy Lines of Communication is really all about developing strong interpersonal connection. And then eventually, that will lead to, when you're delivering, when you're inspecting and creating, that will lead to trust, right? And that is absolutely critical because in software development, we all know that there are these moments when things get a little chaotic, right? So we want to make sure that we can turn back and sort of fall back to that interpersonal connection that we have on a human to human level, right? So, when we aren't communicating, when we're ignoring being the worst possible thing you could do on a project that you're working on with a partner or a client, you know, we have to acknowledge that we're hired to make people's lives easier, to make their lives better. And when we decide to not communicate or not communicate the right amount, they can turn around and actually make our lives a lot worse, right? In the form of overruns and blown budgets and timelines.  So that means I spend a lot of time at 5,000 feet. And this was actually really interesting exercise for me because being and learning how to be a pilot has actually taught me to be a better communicator and therefore a better planner. Pilots are constant planners. You're always evaluating your origin, your destination and how you're gonna get there and the conditions that you need to navigate along the way. You know, you often, if you're flying somewhere, you might find yourself in a cloud, right? And so they don't trust me to fly the big jets like we probably flew here, so I fly the little planes. So when you're on a little single engine plane and you're flying through a cloud, I don't know if anyone here has had that experience. It's pretty disorienting, you can't see anything. One of the thrills of flying is that you're at a high altitude and you have this amazing view. But you end up in a cloud, you can't see anything, it's disorienting. It never gets less disorienting experience, can make it a little easier to navigate. So in that context, right, when I'm flying and I end up in a cloud, do I just keep flying through the crowd, or do I adapt? So in an aviation, there's the three C's, right?  So you find yourself with a new awareness, you're in a cloud, you don't know where you're headed, you can't see anything. What do you do? You climb. You immediately climb because a deep dive, right, like in software development, is the most dangerous thing you could possibly do when you're stuck all alone. You know, no diving into the weeds. You want to climb, maybe climb out of the cloud and gain some of that visibility, right? You want to confess. You want to communicate and be fully forthcoming and transparent about where you are and what your situation is.    Okay, climb to 7,000 feet, change your heading to this. And after 30 minutes, you should be back in clear skies, right? Thank you so much. Because there's nothing like late learning at 5,000 feet when you thought everything was okay and then not to be, you know, but then you slam it to the side of a mountain, right? So I don't know if, you know, in this analogy, I don't know how many of us have been in a project where all of a sudden you thought things were going great. You were on your heading and all of a sudden you did slam it to the side of a mountain and you're like, how did this happen? We had the plan. You know, there wasn't supposed to be any rain or I didn't know I'd fly into this hurricane, right? So the value of the plan then is in the time spent planning of constantly communicating and constantly adjusting course, right? Are you in a cloud? Are we in a cloud? What are we gonna do about being in this cloud? Acknowledging that the best plan is one that is likely to change. Even the best groomed backlog, the most solid user stories, the ones that you spent months refining and everything is great, you may not ever need to do those, right? So we need to reduce the impact that change has on what we ultimately end up delivering, right? So it's less painful to deliver significantly more value for the relationship. So again, when I think about the work that we do at last call and I think about what are our strengths, what are our competitive advantage, what is our competitive advantage in the marketplace, right? Our strength is in our ability to be constantly planning. We are incredible planners. We plan all the time. We constantly inspect and adapt and we constantly communicate, right? So how do we communicate internally? We have project teams, we have a creative team, we have several production teams, people work together obviously, we assemble a team for the project, they have daily stand-ups, something that's pretty common. We kind of require reviews every two weeks so we deliver what we've been working on every two weeks with the team and the partner. And I'd kind of like to challenge the traditional meeting structure for a minute here where you have this thing called a weekly status where you check in and the team tells the project manager everything's going great, right? Because in their current reality, things are going great and then that just gets affirmed and affirmed and affirmed and all of a sudden the partner thinks things are going great and the partner's boss and the partner's boss's boss's boss thinks everything's going great. When in reality you're stuck in a cloud and you don't know what to do. So at last call we did this quick audit. So when we were small, when we were two, going on seven people, we used to have an internal daily company stand-up. And that was actually a lot of fun. We worked, developed strong interpersonal connections and as we grew to 20 people, and they already had their daily stand-up with their team that they were on and then they left that stand-up and then immediately went to another stand-up, right? It started to sound a little silly.   So we did this audit, right? We wanted to inspect kind of what people got out of this meaning that just seemed to be a little silly. So we passed around note cards and I'll keep this one anonymous, but I really liked her point. She says, I like the stand-up because I get to hear what other people are up to and it's a nice way to ease into the day. Is it useful? I don't know. It could probably do my job just as well without this stand-up. I just really like it. And a plus percent of mental value, a minus for actual usefulness. So we gathered this from everyone that works at the company and we were able to pull some trends out of it. Hey, look, people don't actually want this daily stand-up but they really like the ability to hang out and get together and talk about what they're working on, how things are going for them, right? Because they were humans and we need to connect on the human to human level. So what we did is we, all right, we dropped the stand-up, right? That was a pretty bold move and people didn't really like it but we brought, introduced this idea of a coffee clutch. I don't know, probably in this room there are some Germans but in college when I took German, right, we had this every Wednesday at like six o'clock, you could go to the German department, you could hang out for an hour and the whole idea of that was just to talk about, talk in German, talk about whatever you wanted. So every Wednesday at nine a.m. we'd bring in bagels and we have our own version of the coffee clutch and that worked out really well and then it was like, okay, we're doing this too much, right? We inspected and adapted again after about a month and now it's every two weeks and I'm kind of feeling like we're gonna give it some time and then it will turn to a monthly thing. But, so we're talking about how we're able to get some meaningful data and how we're able to on a really simple level inspect and adapt and stop following our plan which would have been the stand-ups, right? Three years ago, we never would have thought that we would drop the daily stand-up, the company-wide daily stand-up. But kind of thinking about how we build teams at last call, so a few years ago we came across Scrum, I'm sure some individuals in here who love Scrum, rely heavily on Scrum, any Scrummasters, product owners, awesome. So this is all like, oh, I've seen this stuff and one of the things I find fascinating about them is when I learned them, I didn't really, okay, those are cool, keep those in mind, but then like as I was thinking about how to build high-performing teams, I kept going back to these values and I think what's incredibly powerful about them is that there's no one answer for any of these. Focus, one classic example is on the task at hand, right? Courage, one of my favorite of the values is I need you to have the courage, I need us to work together to figure out how to have the courage so that you can be open and honest about if you're stuck in a cloud. So don't spend a lot of time on packing these. It would be cool though if there were other, there's like more conversation around these and the community in general. There are two values that aren't on here that I've kind of found in the Scrum community and in my own reflection on these values and that's trust and humor. And I think the reason why they're not values is trust is something that is earned, right? Trusting someone day one isn't really the best plan, you should respect them and trust will be earned, right? As you're navigating chaos together and adopting the change. And then humor, right? I don't know, I mean everyone kind of has their own strategy. This definitely sounds very corny but because when you actually say this out loud, but one of the ways I found that really helps building interpersonal connection is by making jokes. So yeah, very corny to actually disclose that to a room full of people but you know and I obviously don't force myself to make a lot of jokes, right, I don't have my daily joke quota but when it comes up it's really helpful. So and then like finally in terms of communication, right? We need to be continuously improving as we get feedback on the project, our teams also need feedback, right? How are we performing? How are we liking this whole adapting to change thing? When we rolled out Scrum several years ago, we had project managers who were so focused on that iron triangle and it was a significant, it's a paradigm shift really and some project managers couldn't shake it whereas others totally embraced it. All right, so as we're communicating, following all these Scrum values, we're respecting each other, trust is building, we have this new awareness now because we're so great at communicating, right? So that shared awareness allows us to kind of all be on that same page about what the current reality is and that aligns us and enables us to adapt. Another controversial figure here for a second, Mike Tyson, right, so as he's famously said, everyone has a plan till they get punched in the mouth and as our plan is dancing around the ring, that first punch of reality can break our plan, right? Those fists of reality essentially deliver that new awareness and now what do we do, right? And if that punch comes from Mike Tyson, that's gonna really hurt. And I did spend quite some time trying to find figures who are not so controversial as Roosevelt and Mike Tyson, so that's something I'll continue exploring. But the major difference here is we're not committing to a plan, right? As we get punched in the face, do we get back up and keep trying that same plan or do we adapt, right? We're committing, and this idea here is we're not committing to the whole plan, right? We're committing to focus on the current iteration, we're committing to do the best that we can, we're committing to be adaptable, right? And the ways that we can do that, the ways that we can gain awareness in the scrum-like model or in any really agile framework is during a release. So as I said, great opportunities for awareness. We focus on these shippable increments once every two weeks. This would be an example of a project that had design, right, it may just be implementation and testing and specification, but as a general example, right? I think what makes that clearer, and I don't know if that's possible to read, but on the left is frequent release events, an agile methodology, and on the right you have your traditional waterfall methodology where you're building up, the partner kind of goes away, comes back three months later and delivers something that's incredibly high fidelity and it's totally wrong. So these releases, which we do every two weeks, are critical moments for us to gain awareness, to get that feedback that we need and then adapt. And I think this comes from big releases being a thing of waterfall, right? Where you write this really solid plan where you have your big design up front, you've gotten everyone aligned to the plan, it's very linear, everything is super high fidelity, every deliverable can take between five and eight months. It's the final version, of course, and when you get the CEO's signature, you then throw it on the server and you don't look at it again until the plan contradicts reality, right? And there's probably some language in here about change orders and how to manage that, which obviously just compounds and leads to increased noise. So you're on the left here, your client's on the left and your team is on the right, you're not communicating, you've probably been doing your weekly statuses for the past six months and now the development team did its best and it just continued, do your development team couldn't see through walls? This was an incredibly difficult project and now it's late, right? So how do we get here? There's this line item from, probably one of my favorite line items from a proposal that someone sent us was buried in between things like must have a header and must be able to upload images. There's this one requirement where you have state-of-the-art human-computer interaction and you probably read it in the same context as you did all those other items. Oh yeah, right, images, every website has images, every website has a header. State-of-the-art human-computer interaction, I don't really know what that means, but that's okay, we'll just keep moving forward.  And when that happens, the project manager or whoever's in this role, tries to shift the blame over to the client. Hey look, you didn't tell us what you meant by state-of-the-art human-computer interaction, right? And I think really it's a reflection of the fact that we weren't communicating and I think it's on us to ask, okay, what does this mean? And I think one of my favorite things about asking this question is this idea of doing less work. So when we find ourselves making decisions on behalf of other people that are not in our organization, we may find ourselves, okay, so the state-of-the-art human-computer interaction, I need to spend eight months and I'm gonna do really high-fidelity comps and I don't even know what it means state-of-the-art human-computer interaction as I think about it to come up with an example here.  That's not at all what we were here to talk about. Or you may ask and you're like, oh yeah, I don't know, someone put that in there but you can delete it and then you don't find yourself on the sofa. A great way to think about this, when I was at a conference, someone said it's like washing your car, right? When you wake up in the morning and you go and look at your car and it's all dirty.     So when you went outside to wash your car, did you have the awareness that it was going to rain and then you decided to wash your car anyway? Did you have an opportunity for awareness to communicate with the weather channel and you'd be like, oh, it's going to rain, I will wash my car tomorrow, right? So you had an opportunity there to not spend the four hours doing that, but you did it. Another thing that I've started doing is watching old TV shows. Not sure if anyone here is familiar with I Love Lucy. Great, great show. Lucy and Ethel are here and their husbands great characters. This is a scene where Lucy and Ethel go back to work, right? They've been at home for a while, time to go back to work, time to make some money and they take a job at a chocolate factory and can tie a lot of parallels here to software development, right? So they get comfortable with their plan at the chocolate factory, which led to some overconfidence. There were no feedback loops, right? And then after six hours in the job, their boss is like, wow, you're doing great. I'm going to give you more work to do, right? Since you've been just packaging these chocolates so well, I'm going to turn up the conveyor belt, right? And then the boss goes away for another six hours, it doesn't check in on them and then the chocolate starts coming out like crazy, falling all over the place. They're trying to hide the fact that they can't get everything done by stuffing it in their pockets. They lack confidence to be open to say, hey, look, help, help and communicate about how they were over committed. And when we talk about, so we're communicating, we have an awareness, right? But we can't just be communicating and have an awareness forever, right? We need to be working on something. So how we have approached that is by establishing a project vision. So this is something that we use to gain alignment throughout the course of a project, kind of what are the high level ideas here that we're trying to achieve. And when this thing is done, that will mean that we've delivered something of significant value to your organization. And so it's really what we're doing. This is an example of it that we wrote for a pretty large museum on the West Coast of the United States. It's what we're doing, who are we doing it for and most importantly, why are we doing it? It doesn't say that we're gonna build the world's most amazing Drupal site and we're gonna leverage organic groups and media and all your content authors are gonna love it, right? It's the ultimate business objective. And we got here through a series of communication, through a series of conversations, right? We get in the room and we like to ask people what their hopes and fears are, right? So get all the project stakeholders, including people who are not necessarily a stakeholder but are gonna be involved in a project at a later date, like marketing perhaps may have someone from communications join, that person would ultimately be responsible for training new site users. That person may be like, hey, look, this current platform that we're using is impossible to train people on. No one can ever figure out how to use it. We'll need to note that, right? Usability is a big concern. An easy one too, to at least recognize. Difficult often to implement. And, but more importantly, right? We wanna make sure IT who's often left out of initial conversations has a chance to say something like, okay, we have this pretty critical integration. So I'd like to make sure that you're aware of this so that 11 months from now when you're ready to flick the switch and change that A record, we can be like, we don't have to randomly scramble. And like I said, talk about that unique integration. We're looking for things constantly on the lookout for anything that is unique and unusual, right? We wanna catch these things, any sort of project inputs that will need to be considered at a later date. So if anyone's kind of in this room has ever participated in any sort of high level brainstorming exercise like that, you may have found yourself in what is often referred to as the grown zone. This is when you're brainstorming so many ideas, you diverge from one idea, several other ideas emerge, and then it's almost impossible to converge on an actual list of ideas. And then also in a prioritized list. So really it's a series of brainstorming exercises, techniques, politics gets involved. It can be incredibly challenging to navigate. And that kind of helps us with goals and direction. So, and we can also, so when we translate that vision into goals and direction, we're really breaking down the project into meaningful chunks that we can then check on on a regular basis. One of the biggest criticisms I've heard of an agile process is that you really lose sight of the vision when you're six or eight months down the road, kind of what you thought that you were going to start in the very beginning is no longer kind of where you are. And one of the things I found to be incredibly helpful there is putting together a build doc that essentially has what our goals and directions are and how we're going to schedule those kind of roughly. So that helps inform what we use as a push start. So, when you're starting a new project, a lot of times the tendency there may be to do like six months of planning. We want to get in there and we want to prototype as quickly as possible. We want to, whether or not that's Drupal and often the case it's not, it may just be a low fidelity sketch. We want to start translating these words and the actual things that we can put in front of people and get feedback on. And then, so we're communicating awareness, have that vision, how challenging is the problem that we're trying to solve? How much communication is necessary? So academically speaking, I haven't really touched on things like Scrum XP and all the other agile methodologies that fall underneath that umbrella, but this is where you would consider, hey, what approach does make sense here? How complicated, how complex is this problem and how much communication is necessary? So depending on the blue dot being the problem that you're trying to solve, depending on where that falls kind of informs the recommended management approach. So on the x-axis we have certainty, right? Where something being on the bottom left is where it's absolutely certain, right? You have a small team that's probably done this a hundred times before. They've worked together for years. They know how to do this thing. It's we're certain that this is how you solve this problem, right? And then the y-axis is how well in agreement are your requirements and how well in agreement are your stakeholders, right? Is management all over the place? Does everyone in the room want different things? So simple being at the bottom left, right? Where you'd find your traditional waterfall methodology is where we have a perfect understanding of all the things that we need to know and we have complete visibility to what it means to be done 11 months from now, right? So I think very few large projects ever find themselves in that situation. Maybe like a quick one week project, but for the most part, the larger engagements end up in the zone of complexity, which is that white space between complicated and anarchy. And that's kind of where the requirements aren't exactly 100% understood and how we're going to do it isn't exactly 100% understood, but we're going to work together, take incremental steps moving forward. Scrum is a great framework to use here. And then as a last example, when you find yourself in anarchy, right? Because when you have 40 people working on the same project and 30 of them are stakeholders and 15 of them are critical decision makers and you're in that anarchy situation and then you try to force it into a simple process like waterfall, that is another opportunity for chaos. That is where things begin to quickly fall apart. So a lesson that I learned here is to work really hard to not force simplicity. So communicating about a shared awareness, we've developed that vision, we're talking about that vision, we're adapting on our goals and direction and we're shipping something. And a few weeks ago or maybe now a couple months ago, I was reading an article and there was this quote, right? It's not the strongest of the species that survive not the most intelligent but the one most responsive to change. And I don't know if anyone here remembers seventh grade biology or I don't know what it would have been. Does anyone obviously know who this is? Not you? Anyway, it's Darwin. That was pretty cool. Incredibly validating. Alrighty, so I hope that you'll join us later for a contribution sprints. Rob here works with me at Last Call and he spent probably the good 20 minutes of this presentation contributing back. That stuff is really important to us since we've been involved in the Drupal project for a really long time. It's a great opportunity to give back it to know people and we'll definitely be there. Thanks. Absolutely. Hi. Is it on? I'm from a similar sized company as you from Germany and I wanted to ask how do you deal with how do you plan support? Great, so we have an ongoing support team. We call it the Continuous Delivery Team at Last Call so that is difficult because one of the reasons why one of the things that you need for a scrim methodology is a backlog and support you may have a backlog of tasks but you're constantly interrupted by new higher priority tasks. So Rob actually leads that team back at the office and what they do is they have a daily stand up where they review more Kanban style where they review all the outstanding support tasks, prioritize those support tasks and those become the tasks of the day. I don't know if that's... You switch the teams because nobody wants to be on a support team, right? So, it's one of the, I could go on for this for a couple of minutes but one of the things that's been really rewarding about the support team is it's a great place for people to learn and touch a lot of different technologies. So we don't, it's also really about how we talk about things, right? If we were like, oh, support, no one likes to support anything. Just give me all the shiny new Drupal projects, right? That's how we're communicating about things internally. Then of course, no one's gonna wanna get anywhere near it. But we've really positioned it as an exciting opportunity and I truly do believe that support can be really amazing and helpful for potentially new developers or new people to the project. You wanna kinda gain that skill and expertise. Think there's this guy? But... Okay, hi. I was wondering if you, I guess if you've had any suggestions or what your thoughts are on making sure that you're meeting specific requirements and deadlines, like if you're working from a request for proposals with the Agile method because it seems so much easier to do with Waterfall, you kinda know when those things are gonna be hit. So when you are working Agile, how do you make sure that you're hitting all the requirements and still getting the project out on time and fostering that creativity and ability to sort of change the project as it goes? Yeah, so one of the things that we do there is we immediately start to, and I'm not sure if this answers your question completely because I kinda think it starts to touch on things like budget, right? How do you develop something? How do you, sky's really the limit in the creative process and how do you turn that into something that you ultimately deliver? And as an agency, you're actually being responsible and not leading to significant overruns. So what we'll do, one of the first things that we'll do and if we get asked to respond to an RFP and we're the successful bidder, is we'll break that down into really solid definitions of done in a backlog. And what we'll do is we'll talk about kind of each one individually and it's a constant negotiation. And it's a constant opportunity to like share the awareness of those forces that we've been talking about. So, kinda really like a high level answer. But yeah, and then there's that reality at the end of the day, right? Where you've significantly underbid a fixed bid project and you're locked in. So we've definitely been there and we found that an agile process where we're constantly able to inspect, adapt, negotiate has led to far significant overruns. But overruns unfortunately do exist from time to time. Okay, thanks. Hey. Hi. In the end you showed us this diagram. I believe this was Stacey's diagram. Stacey's diagram, yeah. Okay, you told us when you reach, when your problem reaches the energy zone, work really hard not to make it a simple problem. But why not? And what do you do when your problem faces anarchy? Yeah, I think on larger projects sometimes you start in anarchy, right? You don't really know what you're doing. There's no authority. You just kinda have to get started and there's like, maybe there are 30 people involved. So yeah, it's a maze where things are constantly changing. Stakeholders who were not involved in the beginning may be 30 minutes or three weeks or three months late to the conversation. So I think really the only way to navigate out of anarchy and into the zone of complexity where we really need to be comfortable in the software development industry in that space is by frequently communicating, frequently documenting, frequently sharing our awareness and sort of helping, by delivering things will take shape and we'll slowly start to navigate out of there. But there is, there's this chart that I didn't include. It's the software development life cycle and things kinda get, you know, you start off a project, there's a lot of hope and then things slowly start to dip and then you end up in doubt and then there's recovery and now you're taking a photo of this graph. I don't know. And then you deliver, right? And then at the same time you're going from optimism to pessimism and moods change. So it's all about getting out of that area, out of that groan zone, out of anarchy as quickly as possible. So I think when you take a simple approach like a waterfall methodology where you force people to write all the things down and then not allow them to change, I think that is when you find yourself heading towards chaos. Because things do change. I think that's it. One more. What tools do you use to actually do the planning and share all the different tasks and deadlines? Great, great question. So it's gonna sound pretty medieval, right? But a lot of this stuff starts in the Google doc. I'm a huge fan over letting the tool support the process and if we're just brainstorming or throwing ideas together, we'll start in a Google doc. I also will, if I'm onsite and we're fleshing out an idea, I'll just get up and do it on a whiteboard. I've also been known to open up a Google presentation and just build a quick, we've been wireframing on something for days and it doesn't seem like we're getting anywhere. But if we can just on the spot, figure something out, we'll do that. In terms of tools that we have back at the office, we use RedMind is a really great tool, open source too. Alrighty, I think that's it.