 Hey everybody, I think we'll get going in just a second. I wanted to mention real quick Amanda one of the organizers came in and mentioned that the fire marshal has been shutting stuff down if too many people are standing So let's pack this house. We're psyched to have everybody here, but uh Beware Yeah, it looks like a couple up here Yeah, seriously, thank you so much all for being here five o'clock on Wednesday everybody's ready for a beer and you're here with us Yeah, thank you Didn't say we're providing it That's why we're gonna go quick Let's get going So welcome. This is agile with a lower case a art of collaborative PM Just a little housekeeping to get out of the way real quick I'm sure you guys have heard this all day, which is great because it's super important Make sure you join us for a contribution sprints on Friday all the information is up there Also all on the website Devs UX everybody's welcome come help make triple great Greater So I'm Nick Schweitzer I'm the development director at elevated third I manage our development team and place sort of a solutions architect lead dev role on most of our projects And I'm Kylie for Sunita. I'm one of the account managers at elevated third. So I manage internal and client teams and Our company is elevated third. So we're a digital agency based in Denver that helps organizations solve their technology And marketing problems. All right, so let's get into it. Why are we here? Before we jump into the content, let's do a quick survey. How many project managers in the room? nice devs design Other slash sales business Anyone do an agile right now or some version of it And also awesome right on well, we're really excited to have you guys here with us talking about it So again, thanks for joining us So we're here. We want to help cure your post-discovery hangover I'm sure everybody's been in this situation You get the client you work through discovery You got a brand new exciting project and you're super excited about all the great features you're going to implement and you haven't quite thought about implementation and Teams ready to go and you don't want to lose that momentum that you've gained through the discovery process So just to give you guys a little insight into what mean what we mean when we say a discovery process for us that's essentially a few weeks to a few months that we spend with our clients just determining what they are who they need what their requirements are and Like I said a couple weeks to a couple months But we'll typically make that a really collaborative process So, you know like we'll talk about through implementation. We like to involve our whole team. So that's tech design strategy will always have sales in there to sort of pass all that information along and We'll get that gift off the screen. That's distracting. There's a lot of gifts. So I apologize. I went gift crazy But we are making a few assumptions just sort of about where we're at because like I mentioned We are going to focus more on the implementation process So, you know, like I said, we do our discovery process up front And we really put a lot of effort into making sure that's a cross-functional team involved in that So, you know cross-functional is a buzzword. What does it mean for us? It means we've got at least one person from each department and They're actively contributing to the project. So you're not just sitting in meetings not doing anything We're actually working together having collaborative meetings and producing documents and deliverables for the client together Second you're coming out of discovery with a pretty solid set of documentation That's ready to go and implementation and that doesn't mean it's all complete and totally finished We'll we've got a whole section about documentation. So we'll definitely get there But those are just kind of our two big assumptions coming out of the discovery process Awesome. So that's why we're here now. Let me tell you about where we were So we saw the lady on the roller coaster. Everyone's coming off of this great post discovery high they're looking for some direction and What we found out that was happening with our projects is that we'd come off of discovery and that momentum would start to lag We'd start to plateau. We were getting our work done, but it wasn't necessarily the easiest way We were finding that that momentum was starting to not decline, but just hit a plateau So we weren't making as much progress as we should be making or as we wanted to be making So what we really were looking for was a way to find a clear direction for a more unified approach So get the team all working together in a unified way that was efficient and maximized Maximized our budget and our dollars and just produced better work So we thought to ourselves there has to be an easier way How can we satisfy client contracts and budget needs but still keeping a key focus on collaboration and a priority on team involvement? All right, so before we get into the specifics Why is the a lower case for us the a is lower case because we are not practitioners of a specific methodology We're not scrum enthusiasts. We don't love Kanban We just think agile has a lot of great stuff to offer and we really appreciate the core values And I think we try to bring that into a process that works for our team at an agency And you know, of course, that's not the same for everybody everywhere So, you know kind of that same point I we take agile very literally it's it's quick and well coordinated in movement And and that's really at the core of what we like to do in our process, you know Regardless of what we're producing who we're meeting with what the hours look like we wanted we want to do it fast fail fast fail often and create great software And and so to do that we take the best parts of agile and we modify them to fit our needs and We we like I said we like those core concepts But that does tend to evolve a little bit across projects which we can talk about a little more when we'll we'll get to sort of More specifically how we implement those values and make those a part of our process and and we found that you know It does tend to scale pretty well Whether you're talking about sort of a small implementation team of a couple people or maybe up to a larger team with a more enterprise level budget So the analogy I personally really like is the moneyball analogy We talk about this around the office all the time and the general idea is you don't want to blow your whole payroll on a superstar Right like you don't need a superstar in one role to have a successful project You just need to make sure your whole teams invested Understands their role and their responsibilities and expectations on the project and how they personally can make an impact and know when to step up and when it's their time to sort of shine on that project and And what that creates when you have the right people on the team is is a really great self-organizing atmosphere right where um you just get really great organic ideas and and Yeah, everybody comes together to make something really nice So now that you kind of have an idea of the platform that we're rooted in and what we're striving to do with that platform Where do we start? So just basically Nick kind of alluded to it earlier We really looked at the agile manifesto when we were talking about implementation and ways to make it better And those core values of them of agile manifesto Really resonated with us so we took them more as their literal meeting but then Bent them to fit our process and our needs for our team and then keep evolving them for each project not every client's the same Not every project's the same not every budget's the same So it's just taking those ideas and those core values and then molding them to fit your needs So starting with the first one meetings and communication. We're in a communication industry all we do is communicate all day long But let's focus on to What that is keep it simple so taking individuals and in and interactions over the processes and tools So a lot of people are familiar with agile in this room as we previously noted So we'll be using words and phrases like sprint product owners retrospective So sprint being a span of time to implement for that implement implementation phase Which we use two weeks friends, but there are projects where we've used three week sprints because that's what we needed But that's essentially the sprint meeting and then a product owner So having that client liaison and that key person who is your client lead and Incorporating them into the process as a product owner so that they're owning and are just as invested in the project as you are And your entire team is and then finally a retrospective So this is just a meeting to get your core internal team together and that project team together to talk about What worked well what didn't work well? And what can we do to make it better and more efficient because as Nick talked about with the flock of birds image It's really about creating that self-organizing and self-managing team so that if one person can't be in a meeting The meeting doesn't fall apart. It needs to keep running. It needs to get efficient So that's really the focus of of what we're talking about here So Communication tools consistency again rooted in keeping it simple and keeping your tools simple find what works for you When your team and stick with it it doesn't need to be complex You don't want to waste five minutes of a 15-minute stand-up figuring out who's calling in what's the number? I don't have a WebEx. Who's what's the screen share? It was time. It's inefficient It's just annoying so find what works for you find what works for your team and make it predictable I do things such as even have an entire meeting room keep that same meeting room for the entire project because You don't want to waste time or keep it just keep it easy for people like if they know where they need to be at 9 a.m. They just go there. It's easy. It's simple. Nobody wants to be in meetings But they're necessary and it gets them in and out and on on with their day and Then communication is streamlined and direct so something we also do and enforce on the beginning stages of our project is Just have a set of expectations. This is straight talk. We're honest with each other Everyone has a clear understanding of the expectations for the project and the meeting rules In these meetings, we don't want to spark notes of your entire day like just give us the facts and let's move on Just be honest and direct with each other And then having the right people in the right room No one wants to be in a meeting that they don't add any value to and then likewise your budget doesn't want that person in The meeting either so have the right people in the right room at the right time Use those stand-ups to discuss just the key things for the day So each person gets two minutes talk about what you're working on what you're working on tomorrow and any barriers You're facing if you can get those three things down with a room of five people You can be in and out of your stand-up within 15 minutes or less Again eluding back to retrospective So that's the time when you want to air your grievances or air What things that you felt it could go better for the next future phase? And that's again what you want to talk about when you're when we're looking back on our past sprints How can we evolve this sprint and make it better? We always want to keep striving to be better. So Right people right room right time live demos, I think that these are really scary, but they're really necessary so They're important for internal and client teams Internal teams because you don't want your internal team to be in the dark and this goes for a deaf design and strategy It's good to have these live shares and it keeps everyone in the same room on the same page so it's a great forum for Developers to call out any concerns with UX or design features or Also, it helps the design team and the account team stay on track and on pulse with where we're at with the project And nothing is more scary in the world as an account person than going into a client live demo without seeing the work before It's like going into a dark scary room and not knowing what's going to happen in eternal lights So you don't want that so it's good to keep all of the team on the same page And on track with where we're at For client teams so having these live demos for your client team is awesome And then going back to the internal team as you're sharing with the client The internal team knows what to expect and they can set that expectation and that precedence up Right off the bat for the client. So if there is a bug we can say hey, here's where we're at We are here. We know there's a bug here. This is the expectation. So it doesn't set up any ambiguity For that for that product owner it also keeps our product owner involved in the entire process and it keeps them invested it allows them to Draw any concerns that they have or as they're talking about it with their internal team bring any additional outside concerns in and then If that creates additional features, we're able to add those features into our sprint and prioritize as needed So it keeps everyone on the same page, which is great And then also these live demos for the client team also involve Get the client more involved which allows them to be more familiar when we could get to the testing phase So they're already familiar with your product and and what it's going to do and how it's going to function So finally take away here from communication meetings are boring, but games are fun So what we like to do is gamify our meeting So for our internal stand-ups we set the expectation up front that if you're late for the meeting or if you're veering off topic Two things that are that run meetings over you owe a dollar. So it's fun to keep Keep track of this. It also keeps the chemo count accountable So it keeps yourself accountable because you don't want to pay a dollar and keep everything off track And it keeps your internal team accountable for you So if you walk in third like two minutes late, you know, you're gonna owe a dollar and your team is going to call you out for it You can also do something fun with the money at the end right now all of our projects only have like six dollars in them And so maybe we'll split a 40 or something, but But it's fun to just keep it. It's good to have a low low dollar amount All right, so Next up we'll talk about planning and scoping and and agile value we thought we really connected with here was customer collaboration over contract negotiation, right because Contract negotiation is stressful and intense and lots of paperwork, but collaboration is great You know, everybody's involved and and you're all working together to produce something that everyone agrees is the right solution for the problem So, you know, this is something we like to involve the client and like assuming they're comfortable with that and and you know Want to be there. It's I think a huge benefit to the project to pull the client in for planning and scoping whether that's you know Your sprint planning meetings every couple weeks or just sort of the the initial sprint planning where you group features across your sprints Super important and I think you know, it's also really key to remember in these situations You know, most people aren't super familiar with agile methodology software development Like it's it's really important to be a coach and and really teach them to be a good product owner Just like the always lovable coach Taylor And and second don't set sail when the boat isn't built So collaboration is great, but don't let that replace having everything defined So it's really important that through the planning and scoping phases the internal and client teams are aligned on what the features are What the budget is what the user story priorities are and what the user stories actually are Before you actually start building and you know, of course these things are going to change through the process But it's important to have that common baseline So everyone's speaking the same language as you move into implementation on the project Additionally you need a good way to manage that stuff a budget and sprints aren't going to do you any good if you aren't keeping track of them And you know, I think even more important than a specific tool is just make sure your tools make you more efficient Similar to what Kylie talked about with communication like if the tools are getting in the way there You're probably not using them right. Maybe it's not the right tool for the job And I think also loop your client slash product owner Into those tools as much as they want to be you know, and I mean that of course across projects That's going to be varied levels of involvement But you know, I think really the takeaway is like there's you know, there's nothing to hide there And we want to be organized and on point and sort of share that expectation with everyone on the implementation team So for us those tools kind of the two categories that we really needed to fill are basically budget and hours management And then task and sprint management and we have two tools that we really like for those One's called Maven link for budget and hours management and a sauna for task and sprint management We won't get into those two in depth, but if anyone's curious like we're more than happy to talk about those afterwards So try this In your planning and scoping share budget progress and current risk with your client in a weekly meeting, you know And I mean I think this Isn't something that may be super natural to be checking in on this all the time But you know, it's important and this really helps prevent a lot of surprises And I think in terms of how you actually do this it can take a lot of different forms But really you know like like we've been saying over and over and over kind of pounded India the whole time It's just like make sure everybody's on the same page and do it early and do it often so next up is documentation and I think this is This is the piece that I think for us tends to have sort of the most flexibility Just in the sense that you know being in the agency world and sort of having clients and being accountable for Deliverables and hours. It's it's tough to always sort of say. Oh, yeah, just look at the style guide trust us It's gonna look right, you know So it kind of that that piece will evolve a little bit sort of depending on the client and project needs And and the agile value we really connected with here was was working software over comprehensive documentation So, you know, obviously this one is absolutely a compromise between those two things But I think we just sort of always keep that in the back of our mind that in the end We're working to produce working software does the things we're handing over sort of serve that end goal And you know like I mentioned, it's it's a balance, right his shared understanding is great, but shared understanding is not always easy, right and you have to make sure to really Hammer that home and and sometimes the best way to do that is documentation and and to write it down and and you know Like we mentioned, it's it's okay for that to change across projects. I think that that's something that You know, you can almost factor into the planning and scoping phase, right when you're planning out your sprints and deciding on your features You can sort of build those deliverables into that process so that you know Everyone involved can essentially look at your timeline and your milestones and see what those deliverables are going to be And if you need more you can add them if you need less you can take them away And then when it comes to actually Producing those documents. We find it's really important to prioritize living documents that are maintained and useful over throw away Which you know, I think sounds kind of obvious and seemed obvious to us But in implementation, it's a little bit tougher, right because you want to make sure Sort of everything you're producing in that discovery process that we mentioned earlier can carry you all the way through the Implementation phase and that you know, you're not sort of building a comp and then Titling it v1 and putting in a folder called old for everyone to find in two weeks and get really confused what it actually means So for us just to talk a little bit about I guess sort of our foundational documents and This is definitely not an exhaustive list of every single thing that we produce over the course of a project I think just sort of in our experience This is what we found are kind of like the key documents to get the team from discovery all the way through implementation so the first being user stories which are great to prioritize functionality and Just sort of start to get people on the same page about what are the user roles? what are the different features and You know those those can take a lot of different forms that you can you know if it's new you can go as low-fi as a spreadsheet If you have a more complex larger projects, you know a tool like Jira or Trello might be right for you I think that's just kind of finding the right size because it's definitely not a one-size-fits-all situation and then We have a risk mitigation doc as well Which is super helpful because this is essentially where we keep track of any current risks to the budget and scope of the project So I think what's really key about this is you don't want to frame it as a negative thing. It's not a scary document It's just a way to keep track of this is sort of how our project has evolved and you know a lot of times We'll have hours at the end of the project and we can squeeze those features in and and you know Those essentially can become icebox items, which we'll talk a little more about Later if you don't get to them before lunch Build spec this is just kind of what we call it at our company This is essentially a content architecture plan so this is really key especially in the Drupal world because we do a ton with very structured content and It's a way bigger headache to change field names and change architecture Once you've built it in Drupal and built functionality on top of it Then it is to just define that all on a spreadsheet and show it to the team and know okay Like I know this is what an event's gonna look like um Feature estimates which you know this is essentially a feature list of all the major features, you know some Practitioners of Agile might call these epics And you know, I mean I think this can take a different form sort of depending on each project But we'll typically use feature estimates as sort of a comprehensive feature list and then also an estimate for implementation that turns into sort of like smaller Defined tasks that we can move into our task manager and then essentially have estimates associated with each one of those tasks and then finally I Kind of group these all into one category just because it sort of ends up being some number of deliverables Wireframes obviously very important to define the look and feel and those are really great to produce in tandem with the build spec Because you obviously don't want to put anything on the page. That's not represented in Drupal And then style guide and designs like we said it gets kind of ambiguous What will actually deliver for that sometimes and a lot of times we're able to take the approach of? Sort of I guess MVP design if you will where we can produce a style guide and sort of a component list and then you know Oftentimes there are just maybe less technical people or less involved people on the product owner side Who just need to need to see like full page comps and you know at that point We've got all the components together in a style guide and we can just kind of build those into page comps and then give them something to look at So try this Like we mentioned if you haven't done a lot with user stories Like full disclosure. We're fairly new to them and it's been a huge huge help to our process and you know We just started using a spreadsheet because we just knew we needed something because having something was better than having nothing And and in the spirit of maintaining a living document Turn this into your UAT document when it's time to test you can essentially just repurpose everything So that way you're testing all the same user stories You've been talking about through the whole process and we'll talk a little more about that when we get to the UAT phase Cool, thanks So our next value that we really focus on is balancing the big picture with the little details Which is our interpretation of responding to change over following a plan and just really being agile With our agile plan. So when you create a plan, don't be discouraged because it's going to change It's always going to change estimates are going to change the project is going to change and evolve And that doesn't necessarily mean a bad thing, but it is unchartered territory. So I really I really focus on with our internal teams The role of the team leader and that team leader can be an account manager project manager the development director But somebody on that project team needs to be the leader and they need to keep the whole team in perspective and keep the team Positive when things change when we start to enter unchartered territory So as that team leader, it's your role to be the lighthouse in the storm as we navigate those rough waters Whether that be different technology a change in priority Timelines move whatever it is It's your goal to keep to stay above water and to keep the team driving in More most efficient way in order to create that success And then this is kind of goes back to the communication slide But it's just having the right people in the right room So set aside time on specific problems with the key people that need to be involved The entire team doesn't need necessarily need to be involved to tackle a problem Maybe it only needs to be design and development getting together to make sure the wireframes and the feature list are right Maybe it's a developer or two developers getting together to work through a problem or to test something But it's really just focusing on setting aside that key time to make those connections and to move forward on that That issue that you're trying to resolve So try this so it's really simple But I think this is something that is gets easily overlooked and again being that team leader It's your it's your job to manage the team So including an agenda and a goal in every single meeting Keeps keeps everyone on track and on target. So for stand-up. What are you working on today? What are you working on tomorrow? What what issues do you have and then also for the client team because there could be a lot of team members on the Product owner side that need to be involved in meetings So making sure there's a clear outline of what the objective is and what you need to get out of that meeting is Listed down that way everybody can come prepared to the meeting and they know what needs to be Done in the meeting in order to to make it a successful meeting Nobody wants a meeting about a meeting or wants to walk out of a meeting being like we didn't accomplish anything So including something as simple as an agenda and a goal really keeps the team focused Internally and externally if something comes out of that meeting such as a stand-up that requires additional discussion Schedule a separate time with those key people, but it keeps only the relevant people in that conversation and Doesn't waste anybody else's time which your budget will thank you for later All right, so my personal favorite part of the process user acceptance testing So this is very important if you guys haven't seen the Two unit test zero integration test meme you should Google it. It's awesome. This is my favorite But the whole idea right is that we're testing after every sprint We're doing live demos and and everybody knows how each individual feature works and remembers that oh, yeah We tested this and it worked after sprint to but why is it broken now? It's because you need to do integration tests right you're building this big complex system You need to make sure that it actually works together Which I think on the surface sounds very simple, but in practice. I think is much harder Because I'm sure everybody in here has been like and let's just push dev into uat a little bit It's okay. We can keep building features while we're testing like no problem Which is okay right like we want to respond to change and and we want to get those features in But we just got to make sure that this testing still happens because we don't want all our paper towels blown out of the bin when we launch So must haves here Implementation team and client team should be performing the same tests If you're not on the same page there Then that's going to be a really confusing bug fix process that will likely lead to a lot of scope creep and Also the uat document shouldn't include functionality that's outside of the current approved user stories So Actually, I'm gonna go back and talk about this a little more so like we talked about I just want to talk a little more about actually producing that uat document Because I think like for us that was kind of a daunting thing to figure out like how do we produce this giant document of all these tests to Make sure we're actually covering the whole systems functionality and then I was when we're like, oh, we already have that We have the user stories And in our user stories We also included a permissions grid, which you know for some sites Maybe it's literally just anonymous authenticated and administrator, but still all important roles to test You know maybe for a more complex set you've got five or six roles that are logging in and actually interacting and producing content And you can break those all out if you're using a spreadsheet break them out into different tabs of the spreadsheet And then you know try this pull people in from around your company or Friends or whoever wants to volunteer their time But probably people that work with you that maybe aren't familiar with the project right because the whole idea is you Want to build this system that works for people who are not developers, but are your users, right? And then take those people assign them user roles put them in the shoes of someone who's actually going to be using your website and Have them do all your testing for you You know, I think you you get a lot of really interesting feedback, and you know, it's really not as scary as it sounds All right, so you've done discovery You've done implementation you did testing now you've launched Yay, you're excited and now you have a giant post launch feature list things that didn't get done it within your sprints Or didn't get done by launch whether they were new priorities or just additional things that you thought of along the way that weren't included in the Implementation plan Well, then you put them in the icebox, but the icebox if you think about it. It's kind of gross. It's a little scary It's freezer burned. It's forgotten. It's ignored forever Well, we like to rebrand it as The refrigerator because refrigerator the food in there is perishable You need to be gone through you need to use it and you need to use it quickly within a reasonable amount of time So keep track of your features and address them within a reasonable amount of time setting up Release cycles with your client are important because it essentially this will keep building on your product creating a better product And it creates a better client relationship because you're continuing to grow and build their product to meet their business needs Which leads into here doesn't mean your process has to end. So this implementation process can keep going It's a cyclical process. So you can keep creating mini sprints and maybe you do a three-month release cycle That keeps those new features keeps everything fresh You keep the whole process going maybe at a smaller scale now since it's not as large as it was But what this really does is it just creates a better relationship like I mentioned because you're helping solve your clients business problems And as you continue to do that you continue to grow your own internal business, too So you're helping create solutions that fit the needs of the product and your your client So that creates great software and a happy client and then this quote is from the agile manifesto Which is really true to the value that we want to harness which is the highest priority is to satisfy the customer through early and continuous delivery of valuable software That's all I got for you today if you have any questions Please give us feedback. We'd love to hear what everyone thinks and we'll post the slides on our note on the Baltimore Drupal con site by today tomorrow. Yeah, and if you have any questions, let us know Yeah, yeah, we're happy to answer questions and you get you out of here a little early to get a beer or Stick around for an hour and talk process. Whatever Yeah, I'll repeat the question for the sake of the recording He's just asking if we use the same technology to share sort of all that information with our clients and with our internal team and Kylie looks like you had an answer to that The answer is yes, so we do share We'll share that same user story document Which is a Google Drive Slot or a Google sheets and then we'll also share some form or of permission set with the tool that we use Which is Maven link so we'll share that with our client and they have the ability to to post questions They don't necessarily have all access to financials, but I share that with them on our status call So I can do a screen share we're completely transparent with where we're at with the burn down And it's also nice to see like oh these features are running a little hot Which means that we might have to start looking into cutting a priority three or the opposite We are doing really good right here. We're being really efficient Which means we might be able to bring up some of those those priority three features and Then we also for the UATU UAT phase we use a sauna for task management so we'll create a separate a sauna project for our product owner and then as they go through their testing document of The user stories they can add tasks into there So then I would be the owner of managing that communication from the product owner project to our internal project Thanks for the question Yeah, yeah, that's that's a great question and you know we've had that response just talking to People around about it before and you know, I mean I think for us. It was a really good low-fi way to get into it You know we use a sauna which is pretty unstructured for task management and you know up to this point Google Sheets has been you know really great. It tracks revisions. You can share it with people And you know, I mean it's worked well I think we will you know get to the day where we outgrow that But you know up to this point. It's worked well for us Do you have a preference just curious? Oh Yeah Do you prefer a more structure? Yeah, absolutely revision history and Google Sheets is amazing Go back for years Yeah, cool. Yeah, um, that's that's a great question and just something we talk about a lot I mean we do as a company work time and materials So, you know, we'll essentially like if we are dealing with sort of more of a defined budget on the client side I think you know at that point We essentially have to push the flexibility into the features and how we manage those right so I mean I think that's where you know It just takes that really close management to watch your hours per feature and really make sure You know when you're building something you're tracking hours against that and so, you know Like how we've specifically addressed just tracking hours to the right place is in our a sauna task We've got fields that essentially Match to Features in Maven link, which is where all the time for those gets built to so we can see pretty granular Burndowns of hours and and I mean I think that's where talking early and often is really important because you know We are working with a real budget and you know, I mean that that's totally understandable You know, I mean we get it budgets are real But like I think if we're talking a lot and really I guess being agile on on the Development and design and sort of implementation side then I think we can Produce something that still works with sort of that flexible approach Flexibilities just in the work rather than the budget Yeah, I think just to add on to that a little bit when we get into that implementation phase part of not building the not Shipping setting sale before the boat is bill is just making sure that the estimate range that we're working with and our user story Priority list matches up to that that budget range that our client has so if we're Providing everything from a one two and three priority, but it can only be x amount of dollars Then we we essentially take that stress off of us and provide it back to our client saying this is great We want to do all this but you need you only have this much so Reprioritize and we can work together figure it out But it's just really we push back on setting that priority and and making that fit within what they can get And then as Nick stated as the project goes on that's when we can pull in those other priority threes Whether we're burning like pretty low or where we're at Yeah, not not much honestly the stories themselves stay the same So you know you don't want to be changing functionality really we just add some more administrative stuff, which you know likes each user story We'll typically I can't remember. I think we will keep priority and then we essentially add a field for Untested unresolved issues or testing complete to each one And then just sort of like test dates to track when it was actually test so other than that It's the same and like I mentioned we'll break it out into tabs per user role Which was more just to fit how we were structuring testing But you know, I mean if it's just a couple people testing and it works better for them to maybe just like you work from the top Down I'll work from the bottom up. Maybe that's the way to go. So yeah, the idea is minimal effort there for sure Yeah Yeah, that's a really good question, I don't think I have a good answer for it But I would love to do some research and get back to you about it. Yeah Yeah, absolutely No Yeah No, we were actually pretty fortunate our account director is a certified scrum master So she came and kind of helped train our account team in that so we've been rolling it out since then But we've just been reading documentation also just educating ourselves and then rolling it out to our teams Yeah, I couldn't point you towards anything specific, but you know, honestly Lots of there's lots of doing an experience and you know, I think this is my Sixth year at Drupal con and just kind of coming in talking to people and hearing other Agile presentations and sort of the the pains that other people were running into and honestly, I think for us It it felt like it came pretty naturally. I totally don't mean that as a cop-out answer But I think it should feel relatively natural once you're in it Yeah Nice well, well, thank you again for sticking around we appreciate it and have a great rest of the conference I